Re: [PATCH] DRAM_SUN50I_H616_TRIM_SIZE
Dne ponedeljek, 15. april 2024 ob 02:22:45 GMT +2 je Andre Przywara napisal(a):
> On Sat, 13 Apr 2024 21:43:52 +0800
> da...@189.cn wrote:
>
> Hi,
>
> thanks for sending a patch!
>
> > From: lalakii
> >
> > Add "DRAM_SUN50I_H616_TRIM_SIZE" option for 1.5gb board.
> >
> > Signed-off-by: lalakii
> > ---
> > arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h | 1 +
> > arch/arm/mach-sunxi/Kconfig| 7 +++
> > arch/arm/mach-sunxi/dram_sun50i_h616.c | 11 ++-
> > 3 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > index a8fdda124a..2d2526fead 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -166,6 +166,7 @@ struct dram_config {
> > u8 rows;
> > u8 ranks;
> > u8 bus_full_width;
> > + bool trim_size;
> > };
> >
> > static inline int ns_to_t(int nanoseconds)
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index fe89aec6b9..255a498557 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -108,6 +108,13 @@ config DRAM_SUN50I_H616_TPR12
> > default 0x0
> > help
> > TPR12 value from vendor DRAM settings.
> > +
> > +config DRAM_SUN50I_H616_TRIM_SIZE
> > +bool "H616 DRAM trim size"
> > +help
> > + Due to unknown issue, some H616 based boards may need to trim
>
> Well, it's not really an unknown issue, is it? The problem seems to be
> that the auto detection code cannot deal with the topology of the 1.5GB
> DRAM chips.
>
> The general problem with this approach is that it would need to be
> enabled at build time, which means the generated image will always trim
> the DRAM size, and would not be universal for each board anymore.
>
> So we need something to auto-detect this situation. Can you describe
> the failure mode, without this patch? Does the DRAM init code hang or
> give up already, or does this all pass, and then later on the board
> hangs or crashes when we try access the missing DRAM area?
> Maybe a small test access beyond 1.5GB would be able to check for this
> particular case?
Vendor DRAM check for 1.5 GB is pretty simple. First, it's checked if 2 GB
of RAM is detected. If so, 3 different patterns are written to 0x7000,
0xa000 and 0x8000 (in that order). Then, pattern from 0xa000 is
read. If it doesn't match to pattern written to this location, 1.5 GB is
assumed.
Best regards,
Jernej
>
> Cheers,
> Andre
>
>
> > + size a bit.
> > +
> > endif
> >
> > config SUN6I_PRCM
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > index 37c139e0ee..4598d60a57 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > @@ -1349,8 +1349,15 @@ static unsigned long mctl_calc_size(const struct
> > dram_config *config)
> > {
> > u8 width = config->bus_full_width ? 4 : 2;
> >
> > + unsigned long size;
> > +
> > + size = (1ULL << (config->cols + config->rows + 3)) * width *
> > config->ranks;
> > +
> > + if (config->trim_size)
> > + size = (size * 3) / (width == 4 ? 4 : 8);
> > +
> > /* 8 banks */
> > - return (1ULL << (config->cols + config->rows + 3)) * width *
> > config->ranks;
> > + return size;
> > }
> >
> > static const struct dram_para para = {
> > @@ -1379,6 +1386,8 @@ unsigned long sunxi_dram_init(void)
> > struct sunxi_prcm_reg *const prcm =
> > (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
> > struct dram_config config;
> > + if (IS_ENABLED(CONFIG_DRAM_SUN50I_H616_TRIM_SIZE))
> > + config.trim_size = true;
> > unsigned long size;
> >
> > setbits_le32(>res_cal_ctrl, BIT(8));
>
>
Re: [PATCH] sunxi: H616: Add OrangePi Zero 2W board support
Dne torek, 30. januar 2024 ob 15:16:42 CET je Andre Przywara napisal(a): > The OrangePi Zero 2W is a tiny development board featuring the Allwinner > H618 SoC, shipping with up to 4GB of LPDDR4 DRAM, a mini-HDMI connector, > two USB Type-C sockets and a 16MB SPI NOR flash. > There is an FPC connector to connect an expansion board, which sports > two more USB Type-A sockets and a 100MBit Ethernet port. Support for > the expansion board is not in the DT yet, probably a DT overlay would > cover this in the future. > > Add a defconfig file selecting the right drivers and DRAM options. > Since the .dts file was synced from the Linux kernel repo already, we > just need to add one line to the Makefile to actually build the .dtb. > > The DRAM parameters were derived from the values found in the BSP DRAM > drivers on the SPI NOR flash. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > arch/arm/dts/Makefile | 1 + > board/sunxi/MAINTAINERS | 5 + > configs/orangepi_zero2w_defconfig | 30 ++ > 3 files changed, 36 insertions(+) > create mode 100644 configs/orangepi_zero2w_defconfig > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index 0d4b917fb3b..ed3978037ed 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -837,6 +837,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \ > sun50i-h6-tanix-tx6-mini.dtb > dtb-$(CONFIG_MACH_SUN50I_H616) += \ > sun50i-h616-orangepi-zero2.dtb \ > + sun50i-h618-orangepi-zero2w.dtb \ > sun50i-h618-orangepi-zero3.dtb \ > sun50i-h618-transpeed-8k618-t.dtb \ > sun50i-h616-x96-mate.dtb > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS > index a2da6a4a7a2..4bcd9b9af7f 100644 > --- a/board/sunxi/MAINTAINERS > +++ b/board/sunxi/MAINTAINERS > @@ -460,6 +460,11 @@ M: Jernej Skrabec > S: Maintained > F: configs/orangepi_zero2_defconfig > > +ORANGEPI ZERO 2W BOARD > +M: Andre Przywara > +S: Maintained > +F: configs/orangepi_zero2w_defconfig > + > ORANGEPI ZERO 3 BOARD > M: Andre Przywara > S: Maintained > diff --git a/configs/orangepi_zero2w_defconfig > b/configs/orangepi_zero2w_defconfig > new file mode 100644 > index 000..5734d9d839c > --- /dev/null > +++ b/configs/orangepi_zero2w_defconfig > @@ -0,0 +1,30 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_SUNXI=y > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero2w" > +CONFIG_SPL=y > +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707 > +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e > +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e > +CONFIG_DRAM_SUN50I_H616_ODT_EN=0x > +CONFIG_DRAM_SUN50I_H616_TPR6=0x48808080 > +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663 > +CONFIG_DRAM_SUN50I_H616_TPR11=0x26262524 > +CONFIG_DRAM_SUN50I_H616_TPR12=0x100f100f > +CONFIG_MACH_SUN50I_H616=y > +CONFIG_SUNXI_DRAM_H616_LPDDR4=y > +CONFIG_DRAM_CLK=792 > +CONFIG_R_I2C_ENABLE=y > +CONFIG_SPL_SPI_SUNXI=y > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_SPL_I2C=y > +CONFIG_SPL_SYS_I2C_LEGACY=y > +CONFIG_SYS_I2C_MVTWSI=y > +CONFIG_SYS_I2C_SLAVE=0x7f > +CONFIG_SYS_I2C_SPEED=40 > +CONFIG_MTD=y > +CONFIG_SPI_FLASH_ZBIT=y > +CONFIG_AXP313_POWER=y > +CONFIG_SPI=y > +CONFIG_USB_EHCI_HCD=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_MUSB_GADGET=y >
Re: Adding support for Orange Pi Zero 3
Dne nedelja, 26. november 2023 ob 13:33:51 CET je Andre Przywara napisal(a): > On Sun, 26 Nov 2023 11:32:35 + > Bob McChesney wrote: > > Hi Bob, > > thanks for the reply! > > CC:ing Jernej for the THS SRAM issue and the HDMI support mentioned > below. > > > On Thu, Nov 23, 2023 at 03:17:09PM +, Andre Przywara wrote: > > > On Sat, 4 Nov 2023 19:17:44 + > > > electricworry wrote: > > > > > > Hi, > > > > > > > I would like to contribute improvements u-boot to enable support for > > > > the Orange Pi Zero 3 board. I have already gained a good understanding > > > > of the project and the standards for changes, and so I have made > > > > modifications and tested them on my board. > > > > > > thanks for your interest and for reaching out! > > > > > > I will answer your questions below, but for this particular topic there > > > are already support patches on the list (sorry for the disappointment!): > > > https://lore.kernel.org/u-boot/20231114013106.31336-1-andre.przyw...@arm.com/ > > > > > > > That's good. I'm happy that more experienced people have been working on > > this. It's been a good learning experience nevertheless. > > > > > Can you please apply those patches on top of mainline U-Boot and test > > > them? Then reply to patch 3/3 above with a Tested-by: line, stating your > > > name and email address? > > > Having independent reports of that working would make me more confident in > > > merging the series. > > > > I'm happy to do that and will be able to do it shortly. In this case > > would I be applying the patches on top of the next branch? > > The normal master branch would be safer. I don't typically work on the > next branch, and there might be changes in there which subtly break > sunxi. > > > > As a general advice: try to reach out early, to avoid working in parallel > > > on something, and also to avoid working in the wrong direction. > > > There is the #linux-sunxi IRC channel on the OFTC IRC network[1] (you can > > > join via any browser), also there is a mailing list for Allwinner related > > > upstream work: linux-su...@lists.linux.dev [2] > > > Another resource is our wiki: https://linux-sunxi.org > > > > > > [1] https://www.oftc.net/WebChat/ > > > https://oftc.irclog.whitequark.org/linux-sunxi > > > [2] https://subspace.kernel.org/lists.linux.dev.html > > > > Thank you. I wasn't aware of this community and have been working alone. > > It will be more productive to work and discuss with others so I'll join > > that mailing list too. > > Yeah, the IRC chat is the most responsive and most helpful, I find, so > try to join that. > > > > > > > Before submitting patches for review I've got a few questions I'd like > > > > to discuss. > > > > > > > > The board is an Allwinner H618. From what I can gather this is just an > > > > H616 with minor changes. The changes are so minor that I've been able > > > > to implement the support as changes to the existing files for H616. > > > > > > Just curious, what changes did you find in particular? So far we know > > > about the increased L2 cache, which is irrelevant from a software support > > > perspective, and the change of base address and layout of the CPUX_CFG > > > block, which is already covered by: > > > https://source.denx.de/u-boot/u-boot/-/commit/0a137ac5015933bf38ea2700abe70602ef63bbdd > > > Did you find anything else? > > > > I am not what anyone could call a hardware expert so I've just been > > working by diffing the codebase from the vendor against u-boot mainline. > > Most of us are indeed curious software developers, and we typically do > a mixture of looking at vendor code, checking manuals, and doing live > experiments to figure things out. > > > Changes that I've created patches for include their full dtb, the LPDDR4 > > support, the AXP313A power, and - perhaps incorrectly - zeroing a > > register so that the thermal driver in the kernel works properly and > > doesn't get false high temperature readings. > > Ah, glad I am not the only one seeing this! > I strangely haven't seen this all the time, but I indeed now need to do > a "mw.l 0x300 0x7ffe" in U-Boot, otherwise I see the kernel > screaming about +200C temperatures. > > > I say "perhaps incorrectly" > > because I feel like the kernel driver should be doing that work itself > > and the comment in the vendor u-boot code suggests it's a hack: "The > > bit[16] of register reg[0x0300] must be zero for the THS driver to > > work properly in the kernel. The BSP u-boot is putting the whole > > register to zero so we are doing the same." > > Very good, you are exactly on the same path as I am! I have a patch for > the THS driver that tries to clear the bit, via using the regmap > exported by syscon, but I need to test this further (was my plan for > today). I think this was somehow not working properly the last time I > checked. > Another approach was trying to claim an SRAM region - as this is what > this register
Re: [PATCH v4 1/1] sunxi: H616: add LPDDR4 DRAM support
Dne sobota, 11. november 2023 ob 10:10:00 CET je Mikhail Kalashnikov napisal(a): > From: iuncuim > > The H616 SoC family has support for several types of DRAM: DDR3, > LPDDR3, DDR4 and LPDDR4. > At the moment, the driver only supports DDR3 and LPDDR3 memory. > Let's extend the driver to support the LPDDR4 memory. This type > of memory widely used in device with T507(-H) SoC and new orangepi > zero3 with H618. > The compatibility with T507 is not yet complete, because there > is difference in the phy_init array. > The LPDDR4-2133 timings correspond to DRAM Rayson RS1G32LO4D2BDS-53BT > found on the NOR SPI from the Orangepi Zero 3 4GB. > > Signed-off-by: Mikhail Kalashnikov Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v3 1/1] sunxi: H616: add LPDDR4 DRAM support
Dne sobota, 11. november 2023 ob 08:43:22 CET je Mikhail Kalashnikov napisal(a):
> Hi Jernej,
>
> On 04.11.2023 11:31, Jernej Škrabec wrote:
> > Hi Mikhail,
> >
> > I have some notes on LPDDR4 from a long time ago. It mostly matches to your
> > code, but please take a look at comments below.
> >
> > Note that I have extra code, not included in this patch, for
> > mctl_phy_read_training(). At the very beginning, before any other register
> > access is done, this should be added:
> >
> > if (para->type == SUNXI_DRAM_TYPE_LPDDR4) {
> > writel(0, SUNXI_DRAM_PHY0_BASE + 0x800);
> > writel(0, SUNXI_DRAM_PHY0_BASE + 0x81c);
> > }
> >
> > Maybe that will help with other LPDDR4 boards?
>
> Current H618 and t507 boards do not yet require this feature. Yes, this
> feature may be required for future devices. I will add it in the next
> version.
>
> >> @@ -246,8 +251,13 @@ static void mctl_phy_configure_odt(const struct
> >> dram_para *para) {
> >>uint32_t val_lo, val_hi;
> >>
> >> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x390, BIT(5), BIT(4));
> >> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x3d0, BIT(5), BIT(4));
> >> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x410, BIT(5), BIT(4));
> >> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x450, BIT(5), BIT(4));
> >
> > I don't have above block. Something from newer libdram? Is it applicable to
> > all DRAM types?
>
> This function is present in the RE code for all types of memory. Binary
> file dumped from orangepi zero3 nor spi.I paid attention to this area
> code when comparing the sunxi u-boot dump (md.l) with the resulting
> mainline u-boot. Now I checked my tvbox with H616 and LPDDR3 and it
> doesn't have this block. In this case, maybe it would be better to make
> it only for devices with LPDDR4?
> >> + case SUNXI_DRAM_TYPE_LPDDR4:
> >> + writel(0x0, _ctl->mrctrl1);
> >> + writel(0x8030, _ctl->mrctrl0);
> >> + mctl_await_completion(_ctl->mrctrl0, BIT(31), 0);
> > I don't have above block. Maybe difference from newer version of libdram
> > code?
>
> This block was present in the sunxi t507 binaries for which the driver
> was originally intended. Now I checked original dump from orangepi zero3 NOR
> SPI.
> This is also present here.
>
>
> >>writel(reg_val, _ctl->odtcfg);
> >>writel(reg_val, _ctl->unk_0x2240);
> >>writel(reg_val, _ctl->unk_0x3240);
> > I have extra "writel(BIT(31), _com->cr);" after this block for all DRAM
> > types. Not sure if it changes anything.
> Looks like this has already been done in previous patches.
> >> + u16 trfc= ns_to_t(280);
> > My notes say 180 instead of 280. Did you check if register value matches if
> > booted with boot0
> I booted from NOR SPI of the sunxi u-boot and made a dump with md.l
> 0x047fb064. It show me value 0030006f, where 0x6f trfc value. Based on
> the transformation function - 111*1000/(792/2)=280,30(30) So, obtained
> value looks correct. Best regards,
> Mikhail
Ok, thanks for double checking. I think next version can be merged and then
issues can be fixed if they appear.
Best regards,
Jernej
Re: [PATCH v3 1/1] sunxi: H616: add LPDDR4 DRAM support
Hi Mikhail,
I have some notes on LPDDR4 from a long time ago. It mostly matches to your
code, but please take a look at comments below.
Note that I have extra code, not included in this patch, for
mctl_phy_read_training(). At the very beginning, before any other register
access is done, this should be added:
if (para->type == SUNXI_DRAM_TYPE_LPDDR4) {
writel(0, SUNXI_DRAM_PHY0_BASE + 0x800);
writel(0, SUNXI_DRAM_PHY0_BASE + 0x81c);
}
Maybe that will help with other LPDDR4 boards?
On Saturday, November 4, 2023 7:22:48 AM CET Mikhail Kalashnikov wrote:
> From: iuncuim
>
> The H616 SoC family has support for several types of DRAM: DDR3,
> LPDDR3, DDR4 and LPDDR4.
> At the moment, the driver only supports DDR3 and LPDDR3 memory.
> Let's extend the driver to support the LPDDR4 memory. This type
> of memory widely used in device with T507(-H) SoC and new orangepi
> zero3 with H618.
> The compatibility with T507 is not yet complete, because there
> is difference in the phy_init array.
> The LPDDR4-2133 timings correspond to DRAM Rayson RS1G32LO4D2BDS-53BT
> found on the NOR SPI from the Orangepi Zero 3 4GB.
>
> Signed-off-by: Mikhail Kalashnikov
>
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 2 +
> arch/arm/mach-sunxi/Kconfig | 17 ++
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 197 ++
> arch/arm/mach-sunxi/dram_timings/Makefile | 1 +
> .../dram_timings/h616_lpddr4_2133.c | 95 +
> 5 files changed, 277 insertions(+), 35 deletions(-)
> create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr4_2133.c
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> 11774deded..a8fdda124a 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -130,6 +130,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> #define MSTR_DEVICETYPE_LPDDR2 BIT(2)
> #define MSTR_DEVICETYPE_LPDDR3 BIT(3)
> #define MSTR_DEVICETYPE_DDR4 BIT(4)
> +#define MSTR_DEVICETYPE_LPDDR4 BIT(5)
> #define MSTR_DEVICETYPE_MASK GENMASK(5, 0)
> #define MSTR_2TMODE BIT(10)
> #define MSTR_BUSWIDTH_FULL (0 << 12)
> @@ -154,6 +155,7 @@ struct dram_para {
> u32 odt_en;
> u32 tpr0;
> u32 tpr2;
> + u32 tpr6;
> u32 tpr10;
> u32 tpr11;
> u32 tpr12;
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 9d5df2c102..e65bcb36a2 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -85,6 +85,12 @@ config DRAM_SUN50I_H616_TPR2
> help
> TPR2 value from vendor DRAM settings.
>
> +config DRAM_SUN50I_H616_TPR6
> + hex "H616 DRAM TPR6 parameter"
> + default 0x3300c080
> + help
> + TPR6 value from vendor DRAM settings.
> +
> config DRAM_SUN50I_H616_TPR10
> hex "H616 DRAM TPR10 parameter"
> help
> @@ -441,6 +447,9 @@ config SUNXI_DRAM_DDR2
> config SUNXI_DRAM_LPDDR3
> bool
>
> +config SUNXI_DRAM_LPDDR4
> + bool
> +
> choice
> prompt "DRAM Type and Timing"
> default SUNXI_DRAM_DDR3_1333 if !MACH_SUN8I_V3S
> @@ -484,6 +493,14 @@ config SUNXI_DRAM_H616_LPDDR3
> This option is the LPDDR3 timing used by the stock boot0 by
> Allwinner.
>
> +config SUNXI_DRAM_H616_LPDDR4
> + bool "LPDDR4 DRAM chips on the H616 DRAM controller"
> + select SUNXI_DRAM_LPDDR4
> + depends on DRAM_SUN50I_H616
> + help
> + This option is the LPDDR4 timing used by the stock boot0 by
> + Allwinner.
> +
> config SUNXI_DRAM_H616_DDR3_1333
> bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> select SUNXI_DRAM_DDR3
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c index ba5659d409..185f35850a
> 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -238,6 +238,11 @@ static const u8 phy_init[] = {
> 0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07,
> 0x17, 0x19, 0x1a
> +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR4)
> + 0x02, 0x00, 0x17, 0x05, 0x04, 0x19, 0x06, 0x07,
> + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> + 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x01,
> + 0x18, 0x03, 0x1a
> #endif
> };
>
> @@ -246,8 +251,13 @@ static void mctl_phy_configure_odt(const struct
> dram_para *para) {
> uint32_t val_lo, val_hi;
>
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x390, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x3d0, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x410, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x450, BIT(5), BIT(4));
I don't have above block. Something from newer libdram? Is it applicable to
all DRAM types?
> +
>
Re: [PATCH 0/3] sunxi: devicetree updates from Linux v6.6
On Friday, October 20, 2023 2:26:05 AM CEST Andre Przywara wrote: > This updates the devicetree files to match the Linux kernel repository > as of v6.6-rc6. > Mostly cosmetic changes, but we gain some new board files and the T113s > board .dtsi files, which are needed for the pending U-Boot patches. > > Split per architecture, with the T113s being separate due to its RISC-V > relationship. > > Andre Przywara (3): > sunxi: dts: arm64: update devicetree files from Linux-v6.6-rc6 > sunxi: dts: arm: update devicetree files from Linux-v6.6-rc6 > sunxi: dts: arm: add T113s/D1 DT files from Linux-v6.6-rc6 I compared all DTs and they are identical, except r_intc, as mentioned. Reviewed-by: Jernej Skrabec Best regards, Jernej > > arch/arm/dts/axp209.dtsi | 7 + > arch/arm/dts/sun50i-a64.dtsi | 3 +- > arch/arm/dts/sun50i-h6-pine-h64-model-b.dts | 2 +- > arch/arm/dts/sun50i-h616-orangepi-zero.dtsi | 134 +++ > arch/arm/dts/sun50i-h616-orangepi-zero2.dts | 121 +-- > arch/arm/dts/sun50i-h616-x96-mate.dts | 2 +- > arch/arm/dts/sun50i-h618-orangepi-zero3.dts | 94 ++ > arch/arm/dts/sun5i-r8-chip.dts| 6 + > arch/arm/dts/sun5i.dtsi | 11 +- > arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 +++ > arch/arm/dts/sun7i-a20-icnova-a20.dtsi| 62 ++ > arch/arm/dts/sun8i-a23-a33.dtsi | 2 +- > arch/arm/dts/sun8i-a83t.dtsi | 2 +- > .../arm/dts/sun8i-t113s-mangopi-mq-r-t113.dts | 35 + > arch/arm/dts/sun8i-t113s.dtsi | 59 ++ > arch/arm/dts/sun8i-v3s.dtsi | 2 +- > arch/arm/dts/sunxi-d1s-t113-mangopi-mq-r.dtsi | 126 +++ > arch/riscv/dts/sunxi-d1-t113.dtsi | 15 + > arch/riscv/dts/sunxi-d1s-t113.dtsi| 927 ++ > include/dt-bindings/clock/sun20i-d1-ccu.h | 158 +++ > include/dt-bindings/clock/sun20i-d1-r-ccu.h | 19 + > include/dt-bindings/clock/sun50i-h6-ccu.h | 2 +- > include/dt-bindings/clock/sun50i-h616-ccu.h | 2 +- > include/dt-bindings/clock/sun6i-rtc.h | 2 +- > include/dt-bindings/reset/sun20i-d1-ccu.h | 79 ++ > include/dt-bindings/reset/sun20i-d1-r-ccu.h | 16 + > include/dt-bindings/reset/sun50i-h6-ccu.h | 2 +- > include/dt-bindings/reset/sun50i-h6-r-ccu.h | 2 +- > include/dt-bindings/reset/sun50i-h616-ccu.h | 2 +- > 29 files changed, 1899 insertions(+), 132 deletions(-) > create mode 100644 arch/arm/dts/sun50i-h616-orangepi-zero.dtsi > create mode 100644 arch/arm/dts/sun50i-h618-orangepi-zero3.dts > create mode 100644 arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts > create mode 100644 arch/arm/dts/sun7i-a20-icnova-a20.dtsi > create mode 100644 arch/arm/dts/sun8i-t113s-mangopi-mq-r-t113.dts > create mode 100644 arch/arm/dts/sun8i-t113s.dtsi > create mode 100644 arch/arm/dts/sunxi-d1s-t113-mangopi-mq-r.dtsi > create mode 100644 arch/riscv/dts/sunxi-d1-t113.dtsi > create mode 100644 arch/riscv/dts/sunxi-d1s-t113.dtsi > create mode 100644 include/dt-bindings/clock/sun20i-d1-ccu.h > create mode 100644 include/dt-bindings/clock/sun20i-d1-r-ccu.h > create mode 100644 include/dt-bindings/reset/sun20i-d1-ccu.h > create mode 100644 include/dt-bindings/reset/sun20i-d1-r-ccu.h
Re: [PATCH 3/3] power: regulator: add AXP313 support
On Wednesday, October 18, 2023 5:50:14 PM CEST Andre Przywara wrote:
> The X-Powers AXP313a is a small PMIC with just three buck converters and
> three LDOs, one of which is actually fixed (so not modelled here).
>
> Add the compatible string and the respective regulator ranges to allow
> drivers to adjust voltages.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/power/pmic/axp.c| 1 +
> drivers/power/regulator/axp_regulator.c | 17 +
> include/axp_pmic.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/power/pmic/axp.c b/drivers/power/pmic/axp.c
> index 025dac24f28..0e1e45fba74 100644
> --- a/drivers/power/pmic/axp.c
> +++ b/drivers/power/pmic/axp.c
> @@ -87,6 +87,7 @@ static const struct udevice_id axp_pmic_ids[] = {
> { .compatible = "x-powers,axp209", .data = AXP209_ID },
> { .compatible = "x-powers,axp221", .data = AXP221_ID },
> { .compatible = "x-powers,axp223", .data = AXP223_ID },
> + { .compatible = "x-powers,axp313a", .data = AXP313_ID },
> { .compatible = "x-powers,axp803", .data = AXP803_ID },
> { .compatible = "x-powers,axp806", .data = AXP806_ID },
> { .compatible = "x-powers,axp809", .data = AXP809_ID },
> diff --git a/drivers/power/regulator/axp_regulator.c
> b/drivers/power/regulator/axp_regulator.c index 02f320eac1e..d27e09538e0
> 100644
> --- a/drivers/power/regulator/axp_regulator.c
> +++ b/drivers/power/regulator/axp_regulator.c
> @@ -173,6 +173,22 @@ static const struct axp_regulator_plat
> axp22x_regulators[] = { { }
> };
>
> +/*
> + * The "dcdc1" regulator has another range, beyond 1.54V up to 3.4V, in
> + * steps of 100mV. We cannot model this easily, but also don't need that,
> + * since it's typically only used for ~1.1V anyway, so just ignore it.
It can be modelled with look up table, as it's already done for some other
regulators?
Best regards,
Jernej
> + * Also the DCDC3 regulator is described wrongly in the (available) manual,
> + * experiments show that the split point is at 1200mV, as for DCDC1/2. +
> */
> +static const struct axp_regulator_plat axp313_regulators[] = {
> + { "dcdc1", 0x10, BIT(0), 0x13, 0x7f, 500, 1540, 10, 70 },
> + { "dcdc2", 0x10, BIT(1), 0x14, 0x7f, 500, 1540, 10, 70 },
> + { "dcdc3", 0x10, BIT(2), 0x15, 0x7f, 500, 1840, 10, 70 },
> + { "aldo1", 0x10, BIT(3), 0x16, 0x1f, 500, 3500, 100, NA },
> + { "dldo1", 0x10, BIT(4), 0x17, 0x1f, 500, 3500, 100, NA },
> + { }
> +};
> +
> static const struct axp_regulator_plat axp803_regulators[] = {
> { "dcdc1", 0x10, BIT(0), 0x20, 0x1f, 1600, 3400, 100, NA },
> { "dcdc2", 0x10, BIT(1), 0x21, 0x7f, 500, 1300, 10, 70 },
> @@ -274,6 +290,7 @@ static const struct axp_regulator_plat *const
> axp_regulators[] = { [AXP209_ID] = axp20x_regulators,
> [AXP221_ID] = axp22x_regulators,
> [AXP223_ID] = axp22x_regulators,
> + [AXP313_ID] = axp313_regulators,
> [AXP803_ID] = axp803_regulators,
> [AXP806_ID] = axp806_regulators,
> [AXP809_ID] = axp809_regulators,
> diff --git a/include/axp_pmic.h b/include/axp_pmic.h
> index 4ac64865831..aabafc8501b 100644
> --- a/include/axp_pmic.h
> +++ b/include/axp_pmic.h
> @@ -32,6 +32,7 @@ enum {
> AXP209_ID,
> AXP221_ID,
> AXP223_ID,
> + AXP313_ID,
> AXP803_ID,
> AXP806_ID,
> AXP809_ID,
Re: [PATCH 2/3] power: pmic: sunxi: add AXP313 SPL driver
On Wednesday, October 18, 2023 5:50:13 PM CEST Andre Przywara wrote:
> On boards using the AXP313 PMIC, the DRAM rail is often not setup
> correctly at reset time, so we have to program the PMIC very early in
> the SPL, before running the DRAM initialisation.
>
> Add a simple AXP313 PMIC driver that knows about DCDC2(CPU) and
> DCDC3(DRAM), so that we can bump up the voltage before the DRAM init.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/mach-sunxi/pmic_bus.c | 3 +
> board/sunxi/board.c| 3 +-
> drivers/power/Kconfig | 17 -
> drivers/power/Makefile | 1 +
> drivers/power/axp313.c | 134 +
> 5 files changed, 155 insertions(+), 3 deletions(-)
> create mode 100644 drivers/power/axp313.c
>
> diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
> index c0908406370..8e7625fe057 100644
> --- a/arch/arm/mach-sunxi/pmic_bus.c
> +++ b/arch/arm/mach-sunxi/pmic_bus.c
> @@ -22,6 +22,7 @@
> #define AXP209_I2C_ADDR 0x34
>
> #define AXP305_I2C_ADDR 0x36
> +#define AXP313_I2C_ADDR 0x36
>
> #define AXP221_CHIP_ADDR 0x68
>
> @@ -34,6 +35,8 @@ static int pmic_i2c_address(void)
> return AXP152_I2C_ADDR;
> if (IS_ENABLED(CONFIG_AXP305_POWER))
> return AXP305_I2C_ADDR;
> + if (IS_ENABLED(CONFIG_AXP313_POWER))
> + return AXP313_I2C_ADDR;
>
> /* Other AXP2xx and AXP8xx variants */
> return AXP209_I2C_ADDR;
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 65d79a02c25..39b0ad73a9c 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -584,7 +584,8 @@ void sunxi_board_init(void)
>
> #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
> defined CONFIG_AXP221_POWER || defined CONFIG_AXP305_POWER || \
> - defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
> + defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER || \
> + defined CONFIG_AXP313_POWER
> power_failed = axp_init();
>
> if (IS_ENABLED(CONFIG_AXP_DISABLE_BOOT_ON_POWERON) && !
power_failed) {
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 83cb31c937a..a9117d215eb 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -101,6 +101,15 @@ config AXP305_POWER
> Select this to enable support for the axp305 pmic found on most
> H616 boards.
>
> +config AXP313_POWER
> + bool "axp311 pmic support"
Typo: axp311 -> axp313
Other than that, it looks good. I can't test it since I don't have any
hardware with such PMIC.
So FWIW:
Acked-by: Jernej Skrabec
Best regards,
Jernej
> + depends on MACH_SUN50I_H616
> + select AXP_PMIC_BUS
> + select CMD_POWEROFF
> + ---help---
> + Select this to enable support for the AXP313 PMIC found on some
> + H616 boards.
> +
> config AXP809_POWER
> bool "axp809 pmic support"
> depends on MACH_SUN9I
> @@ -143,9 +152,10 @@ config AXP_DCDC1_VOLT
>
> config AXP_DCDC2_VOLT
> int "axp pmic dcdc2 voltage"
> - depends on AXP152_POWER || AXP209_POWER || AXP221_POWER ||
AXP809_POWER ||
> AXP818_POWER +depends on AXP152_POWER || AXP209_POWER || AXP221_POWER
||
> AXP809_POWER || AXP818_POWER || AXP313_POWER default 900 if AXP818_POWER
> default 1400 if AXP152_POWER || AXP209_POWER
> + default 1000 if AXP313_POWER
> default 1200 if MACH_SUN6I
> default 1100 if MACH_SUN8I
> default 0 if MACH_SUN9I
> @@ -158,13 +168,15 @@ config AXP_DCDC2_VOLT
> On A80 boards dcdc2 powers the GPU and can be left off.
> On A83T boards dcdc2 is used for VDD-CPUA(cluster 0) and should be
0.9V.
> On R40 boards dcdc2 is VDD-CPU and should be 1.1V
> + On boards using the AXP313 it's often VDD-CPU.
>
> config AXP_DCDC3_VOLT
> int "axp pmic dcdc3 voltage"
> - depends on AXP152_POWER || AXP209_POWER || AXP221_POWER ||
AXP809_POWER ||
> AXP818_POWER +depends on AXP152_POWER || AXP209_POWER || AXP221_POWER
||
> AXP809_POWER || AXP818_POWER || AXP313_POWER default 900 if AXP809_POWER ||
> AXP818_POWER
> default 1500 if AXP152_POWER
> default 1250 if AXP209_POWER
> + default 1100 if AXP313_POWER
> default 1100 if MACH_SUN8I_R40
> default 1200 if MACH_SUN6I || MACH_SUN8I
> ---help---
> @@ -177,6 +189,7 @@ config AXP_DCDC3_VOLT
> On A80 boards dcdc3 is used for VDD-CPUA(cluster 0) and should be
0.9V.
> On A83T boards dcdc3 is used for VDD-CPUB(cluster 1) and should be
0.9V.
> On R40 boards dcdc3 is VDD-SYS and VDD-GPU and should be 1.1V.
> + On boards using the AXP313 it's often VDD-DRAM and should be 1.1V
for
> LPDDR4.
>
> config AXP_DCDC4_VOLT
> int "axp pmic dcdc4 voltage"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index ba64b2c5938..c7ee4595fc8 100644
> ---
Re: [PATCH 1/3] sunxi: board: simplify early PMIC setup conditions
On Wednesday, October 18, 2023 5:50:12 PM CEST Andre Przywara wrote:
> So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
> setup in board.c. That combination of &&, || and negations is very hard
> to read, maintain and especially to extend.
>
> Fortunately we have those same conditions already modelled in the
> Kconfig file, so they are actually redundant. On top of that the real
> reason we have those preprocessor guards in the first place is about the
> symbols that are *conditionally* defined: without #ifdefs the build
> would break because of them being undefined for many boards.
>
> To simplify this, just change the guards to actually look at the symbols
> needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
> This drastically improves the readability of this code, and makes adding
> PMIC support a pure Kconfig matter.
>
> Signed-off-by: Andre Przywara
> ---
> board/sunxi/board.c | 32 ++--
> drivers/power/Kconfig | 2 +-
> 2 files changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index ebaa9431984..65d79a02c25 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -597,50 +597,46 @@ void sunxi_board_init(void)
> }
> }
>
> -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> - defined CONFIG_AXP818_POWER
> +#ifdef CONFIG_AXP_DCDC1_VOLT
> power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
> + power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> #endif
> -#if !defined(CONFIG_AXP305_POWER)
> +#ifdef CONFIG_AXP_DCDC2_VOLT
> power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
> power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
> #endif
> -#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
> +#ifdef CONFIG_AXP_DCDC4_VOLT
> power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
> #endif
> -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> - defined CONFIG_AXP818_POWER
> - power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
> -#endif
>
> -#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
> - defined CONFIG_AXP818_POWER
> +#ifdef CONFIG_AXP_ALDO1_VOLT
> power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
> #endif
> -#if !defined(CONFIG_AXP305_POWER)
> +#ifdef CONFIG_AXP_ALDO2_VOLT
> power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
> #endif
> -#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
> +#ifdef CONFIG_AXP_ALDO3_VOLT
> power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
> #endif
> -#ifdef CONFIG_AXP209_POWER
> +#ifdef CONFIG_AXP_ALDO4_VOLT
> power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT);
> #endif
>
> -#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \
> - defined(CONFIG_AXP818_POWER)
> +#ifdef CONFIG_AXP_DLDO1_VOLT
> power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT);
> power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT);
> -#if !defined CONFIG_AXP809_POWER
> +#endif
> +#ifdef CONFIG_AXP_DLDO3_VOLT
> power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT);
> power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT);
> #endif
> +#ifdef CONFIG_AXP_ELDO1_VOLT
> power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT);
> power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT);
> power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT);
> #endif
>
> -#ifdef CONFIG_AXP818_POWER
> +#ifdef CONFIG_AXP_FLDO1_VOLT
> power_failed |= axp_set_fldo(1, CONFIG_AXP_FLDO1_VOLT);
> power_failed |= axp_set_fldo(2, CONFIG_AXP_FLDO2_VOLT);
> power_failed |= axp_set_fldo(3, CONFIG_AXP_FLDO3_VOLT);
> @@ -649,7 +645,7 @@ void sunxi_board_init(void)
> #if defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
> power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
> #endif
> -#endif
> +#endif /* CONFIG_AXPxxx_POWER */
> printf("DRAM:");
> gd->ram_size = sunxi_dram_init();
> printf(" %d MiB\n", (int)(gd->ram_size >> 20));
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 7f3b990d231..83cb31c937a 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -180,7 +180,7 @@ config AXP_DCDC3_VOLT
>
> config AXP_DCDC4_VOLT
> int "axp pmic dcdc4 voltage"
> - depends on AXP152_POWER || AXP221_POWER || AXP809_POWER ||
AXP818_POWER ||
> AXP305_POWER +depends on AXP152_POWER || AXP221_POWER || AXP809_POWER
||
> AXP305_POWER default 1250 if AXP152_POWER
> default 1200 if MACH_SUN6I
> default 0 if MACH_SUN8I
This patch is great, but this last change doesn't seem to be directly
connected?
Best regards,
Jernej
Re: [PATCH v2 1/1] sunxi: H616: add LPDDR4 DRAM support
On Monday, October 16, 2023 7:34:41 AM CEST Mikhail Kalashnikov wrote:
> From: iuncuim
>
> The H616 SoC family has support for several types of DRAM: DDR3,
> LPDDR3, DDR4 and LPDDR4.
> At the moment, the driver only supports DDR3 and LPDDR3 memory.
> Let's extend the driver to support the LPDDR4 memory. This type
> of memory widely used in device with T507(-H) SoC and new orangepi
> zero3 with H618.
> The compatibility with T507 is not yet complete, because there
> is difference in the phy_init array.
> The LPDDR4-2133 timings correspond to DRAM Rayson RS1G32LO4D2BDS-53BT
> found on the Orangepi Zero 3 4GB.
>
> Signed-off-by: Mikhail Kalashnikov
>
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 2 +
> arch/arm/mach-sunxi/Kconfig | 16 ++
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 176 ++
> arch/arm/mach-sunxi/dram_timings/Makefile | 1 +
> .../dram_timings/h616_lpddr4_2133.c | 97 ++
> 5 files changed, 258 insertions(+), 34 deletions(-)
> create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr4_2133.c
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> 11774deded..a8fdda124a 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -130,6 +130,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> #define MSTR_DEVICETYPE_LPDDR2 BIT(2)
> #define MSTR_DEVICETYPE_LPDDR3 BIT(3)
> #define MSTR_DEVICETYPE_DDR4 BIT(4)
> +#define MSTR_DEVICETYPE_LPDDR4 BIT(5)
> #define MSTR_DEVICETYPE_MASK GENMASK(5, 0)
> #define MSTR_2TMODE BIT(10)
> #define MSTR_BUSWIDTH_FULL (0 << 12)
> @@ -154,6 +155,7 @@ struct dram_para {
> u32 odt_en;
> u32 tpr0;
> u32 tpr2;
> + u32 tpr6;
> u32 tpr10;
> u32 tpr11;
> u32 tpr12;
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 9d5df2c102..71e2f40b9e 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -85,6 +85,11 @@ config DRAM_SUN50I_H616_TPR2
> help
> TPR2 value from vendor DRAM settings.
>
> +config DRAM_SUN50I_H616_TPR6
> + hex "H616 DRAM TPR6 parameter"
> + help
> + TPR6 value from vendor DRAM settings.
> +
> config DRAM_SUN50I_H616_TPR10
> hex "H616 DRAM TPR10 parameter"
> help
> @@ -441,6 +446,9 @@ config SUNXI_DRAM_DDR2
> config SUNXI_DRAM_LPDDR3
> bool
>
> +config SUNXI_DRAM_LPDDR4
> + bool
> +
> choice
> prompt "DRAM Type and Timing"
> default SUNXI_DRAM_DDR3_1333 if !MACH_SUN8I_V3S
> @@ -484,6 +492,14 @@ config SUNXI_DRAM_H616_LPDDR3
> This option is the LPDDR3 timing used by the stock boot0 by
> Allwinner.
>
> +config SUNXI_DRAM_H616_LPDDR4
> + bool "LPDDR4 DRAM chips on the H616 DRAM controller"
> + select SUNXI_DRAM_LPDDR4
> + depends on DRAM_SUN50I_H616
> + help
> + This option is the LPDDR4 timing used by the stock boot0 by
> + Allwinner.
> +
> config SUNXI_DRAM_H616_DDR3_1333
> bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> select SUNXI_DRAM_DDR3
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c index ba5659d409..2c4b47bae7
> 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -238,6 +238,11 @@ static const u8 phy_init[] = {
> 0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07,
> 0x17, 0x19, 0x1a
> +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR4)
> + 0x02, 0x00, 0x17, 0x05, 0x04, 0x19, 0x06, 0x07,
> + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> + 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x01,
> + 0x18, 0x03, 0x1a
> #endif
> };
>
> @@ -246,8 +251,13 @@ static void mctl_phy_configure_odt(const struct
> dram_para *para) {
> uint32_t val_lo, val_hi;
>
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x390, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x3d0, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x410, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x450, BIT(5), BIT(4));
> +
> val_lo = para->dx_dri;
> - val_hi = para->dx_dri;
> + val_hi = (para->type == SUNXI_DRAM_TYPE_LPDDR4) ? 0x04040404 :
> para->dx_dri; writel_relaxed(MASK_BYTE(val_lo, 0), SUNXI_DRAM_PHY0_BASE +
> 0x388); writel_relaxed(MASK_BYTE(val_hi, 0), SUNXI_DRAM_PHY0_BASE + 0x38c);
> writel_relaxed(MASK_BYTE(val_lo, 1), SUNXI_DRAM_PHY0_BASE + 0x3c8); @@
> -265,7 +275,7 @@ static void mctl_phy_configure_odt(const struct dram_para
> *para) writel_relaxed(MASK_BYTE(val_hi, 1), SUNXI_DRAM_PHY0_BASE + 0x34c);
>
> val_lo = (para->type == SUNXI_DRAM_TYPE_LPDDR3) ? 0 : para-
>dx_odt;
> - val_hi = para->dx_odt;
> + val_hi =
Re: [PATCH 4/4] sunxi: DRAM: H6: use proper MMIO accessors in mctl_set_addrmap()
On Saturday, October 21, 2023 3:10:25 AM CEST Andre Przywara wrote:
> For accessing MMIO registers, we must not rely on the compiler to
> realise every access to a struct which we made point to some MMIO base
> address. From a compiler's point of view, those writes could be
> considered pointless, since no code consumes them later on: the compiler
> would actually be free to optimise them away.
>
> So we need at least the "volatile" attribute in the pointer declaration,
> but a better fix is of course to use the proper MMIO accessors (writel),
> as we do everywhere else.
> Since MMIO writes are already ordered within themselves (courtesy of the
> "device nGnRnE" memory attribures), and we don't do any DMA operation
> which would requrire synchronising with normal memory accesses, we can
> use the cheaper writel_relaxed() accessor, which have the additional
> advantange of saving one instruction, for each call.
>
> Signed-off-by: Andre Przywara
Great catch! I wonder if this ever caused any issue.
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> arch/arm/mach-sunxi/dram_sun50i_h6.c | 69
> 1 file changed, 39 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c index 8e959f4c600..89e855c1a7d
> 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -192,77 +192,86 @@ static void mctl_set_addrmap(const struct dram_config
> *config)
>
> /* Ranks */
> if (ranks == 2)
> - mctl_ctl->addrmap[0] = rows + cols - 3;
> + writel_relaxed(rows + cols - 3, _ctl->addrmap[0]);
> else
> - mctl_ctl->addrmap[0] = 0x1F;
> + writel_relaxed(0x1f, _ctl->addrmap[0]);
>
> /* Banks, hardcoded to 8 banks now */
> - mctl_ctl->addrmap[1] = (cols - 2) | (cols - 2) << 8 | (cols - 2)
<< 16;
> + writel_relaxed((cols - 2) | (cols - 2) << 8 | (cols - 2) << 16,
> +_ctl->addrmap[1]);
>
> /* Columns */
> - mctl_ctl->addrmap[2] = 0;
> + writel_relaxed(0, _ctl->addrmap[2]);
> switch (cols) {
> case 7:
> - mctl_ctl->addrmap[3] = 0x1F1F1F00;
> - mctl_ctl->addrmap[4] = 0x1F1F;
> + writel_relaxed(0x1f1f1f00, _ctl->addrmap[3]);
> + writel_relaxed(0x1f1f, _ctl->addrmap[4]);
> break;
> case 8:
> - mctl_ctl->addrmap[3] = 0x1F1F;
> - mctl_ctl->addrmap[4] = 0x1F1F;
> + writel_relaxed(0x1f1f, _ctl->addrmap[3]);
> + writel_relaxed(0x1f1f, _ctl->addrmap[4]);
> break;
> case 9:
> - mctl_ctl->addrmap[3] = 0x1F00;
> - mctl_ctl->addrmap[4] = 0x1F1F;
> + writel_relaxed(0x1f00, _ctl->addrmap[3]);
> + writel_relaxed(0x1f1f, _ctl->addrmap[4]);
> break;
> case 10:
> - mctl_ctl->addrmap[3] = 0;
> - mctl_ctl->addrmap[4] = 0x1F1F;
> + writel_relaxed(0, _ctl->addrmap[3]);
> + writel_relaxed(0x1f1f, _ctl->addrmap[4]);
> break;
> case 11:
> - mctl_ctl->addrmap[3] = 0;
> - mctl_ctl->addrmap[4] = 0x1F00;
> + writel_relaxed(0, _ctl->addrmap[3]);
> + writel_relaxed(0x1f00, _ctl->addrmap[4]);
> break;
> case 12:
> - mctl_ctl->addrmap[3] = 0;
> - mctl_ctl->addrmap[4] = 0;
> + writel_relaxed(0, _ctl->addrmap[3]);
> + writel_relaxed(0, _ctl->addrmap[4]);
> break;
> default:
> panic("Unsupported DRAM configuration: column number
invalid\n");
> }
>
> /* Rows */
> - mctl_ctl->addrmap[5] = (cols - 3) | ((cols - 3) << 8) | ((cols -
3) << 16)
> | ((cols - 3) << 24); + writel_relaxed((cols - 3) | ((cols - 3) << 8) |
> ((cols - 3) << 16) | ((cols - 3) << 24), + _ctl-
>addrmap[5]);
> switch (rows) {
> case 13:
> - mctl_ctl->addrmap[6] = (cols - 3) | 0x0F0F0F00;
> - mctl_ctl->addrmap[7] = 0x0F0F;
> + writel_relaxed((cols - 3) | 0x0f0f0f00, _ctl-
>addrmap[6]);
> + writel_relaxed(0x0f0f, _ctl->addrmap[7]);
> break;
> case 14:
> - mctl_ctl->addrmap[6] = (cols - 3) | ((cols - 3) << 8) |
0x0F0F;
> - mctl_ctl->addrmap[7] = 0x0F0F;
> + writel_relaxed((cols - 3) | ((cols - 3) << 8) |
0x0f0f,
> +_ctl->addrmap[6]);
> + writel_relaxed(0x0f0f, _ctl->addrmap[7]);
> break;
> case 15:
> - mctl_ctl->addrmap[6] = (cols - 3) | ((cols - 3) << 8) |
((cols - 3) <<
> 16) | 0x0F00; - mctl_ctl->addrmap[7] = 0x0F0F;
> + writel_relaxed((cols - 3) | ((cols - 3) << 8) | ((cols -
3) << 16) |
> 0x0f00, + _ctl-
Re: [PATCH 3/4] sunxi: DRAM: H6: split struct dram_para
On Saturday, October 21, 2023 3:10:24 AM CEST Andre Przywara wrote:
> Currently there is one DRAM parameter struct for the Allwinner H6 DRAM
> "driver". It contains many fields that are compile time constants
> (set by Kconfig variables), though there are also some fields that are
> probed and changed over the runtime of the DRAM initialisation.
>
> Because of this mixture, the compiler cannot properly optimise the code
> for size, as it does not consider constant propagation in its full
> potential.
>
> Help the compiler out by splitting that structure into two: one that only
> contains values known at compile time, and another one where the values
> will actually change. The former can then be declared "const", which will
> let the compiler fold its values directly into the code using it.
> To facilitate this, the definition of the struct has to become "static
> const" outside of any functions, so move that part out of
> sunxi_dram_init().
>
> That results in code savings around 500 bytes, which helps the
> notorously tight H6 SPL to stay within it current limit.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h6.h | 12 +-
> arch/arm/mach-sunxi/dram_sun50i_h6.c | 134 +-
> 2 files changed, 77 insertions(+), 69 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h index
> a7c6435220f..058f2cabb6e 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> @@ -313,17 +313,19 @@ check_member(sunxi_mctl_phy_reg, dx[3].reserved_0xf0,
> 0xaf0); */
> #define RD_LINES_PER_BYTE_LANE (BITS_PER_BYTE + 6)
> struct dram_para {
> - const u32 clk;
> - const enum sunxi_dram_type type;
> + u32 clk;
> + enum sunxi_dram_type type;
> + u8 dx_read_delays[NR_OF_BYTE_LANES][RD_LINES_PER_BYTE_LANE];
> + u8 dx_write_delays[NR_OF_BYTE_LANES][WR_LINES_PER_BYTE_LANE];
> +};
> +
> +struct dram_config {
> u8 cols;
> u8 rows;
> u8 ranks;
> u8 bus_full_width;
> - const u8 dx_read_delays[NR_OF_BYTE_LANES][RD_LINES_PER_BYTE_LANE];
> - const u8 dx_write_delays[NR_OF_BYTE_LANES]
[WR_LINES_PER_BYTE_LANE];
> };
>
> -
> static inline int ns_to_t(int nanoseconds)
> {
> const unsigned int ctrl_freq = CONFIG_DRAM_CLK / 2;
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c index 1187f1960a0..8e959f4c600
> 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -179,15 +179,15 @@ static void mctl_sys_init(u32 clk_rate)
> writel(0x8000, _ctl->unk_0x00c);
> }
>
> -static void mctl_set_addrmap(const struct dram_para *para)
> +static void mctl_set_addrmap(const struct dram_config *config)
> {
> struct sunxi_mctl_ctl_reg * const mctl_ctl =
> (struct sunxi_mctl_ctl_reg
*)SUNXI_DRAM_CTL0_BASE;
> - u8 cols = para->cols;
> - u8 rows = para->rows;
> - u8 ranks = para->ranks;
> + u8 cols = config->cols;
> + u8 rows = config->rows;
> + u8 ranks = config->ranks;
>
> - if (!para->bus_full_width)
> + if (!config->bus_full_width)
> cols -= 1;
>
> /* Ranks */
> @@ -265,7 +265,8 @@ static void mctl_set_addrmap(const struct dram_para
> *para) mctl_ctl->addrmap[8] = 0x3F3F;
> }
>
> -static void mctl_com_init(const struct dram_para *para)
> +static void mctl_com_init(const struct dram_para *para,
> + const struct dram_config *config)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg
*)SUNXI_DRAM_COM_BASE;
> @@ -275,7 +276,7 @@ static void mctl_com_init(const struct dram_para *para)
> (struct sunxi_mctl_phy_reg
*)SUNXI_DRAM_PHY0_BASE;
> u32 reg_val, tmp;
>
> - mctl_set_addrmap(para);
> + mctl_set_addrmap(config);
>
> setbits_le32(_com->cr, BIT(31));
>
> @@ -294,12 +295,12 @@ static void mctl_com_init(const struct dram_para
> *para) clrsetbits_le32(_com->unk_0x008, 0x3f00, reg_val);
>
> /* TODO: DDR4 */
> - reg_val = MSTR_BURST_LENGTH(8) | MSTR_ACTIVE_RANKS(para->ranks);
> + reg_val = MSTR_BURST_LENGTH(8) | MSTR_ACTIVE_RANKS(config->ranks);
> if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> reg_val |= MSTR_DEVICETYPE_LPDDR3;
> if (para->type == SUNXI_DRAM_TYPE_DDR3)
> reg_val |= MSTR_DEVICETYPE_DDR3 | MSTR_2TMODE;
> - if (para->bus_full_width)
> + if (config->bus_full_width)
> reg_val |= MSTR_BUSWIDTH_FULL;
> else
> reg_val |= MSTR_BUSWIDTH_HALF;
> @@ -311,7 +312,7 @@ static void mctl_com_init(const struct dram_para *para)
> reg_val = DCR_DDR3 | DCR_DDR8BANK | DCR_DDR2T;
> writel(reg_val | 0x400, _phy->dcr);
>
> - if
Re: [PATCH 2/4] sunxi: DRAM: H6: const-ify DRAM function parameters
On Saturday, October 21, 2023 3:10:23 AM CEST Andre Przywara wrote:
> There are quite some functions in the Allwinner H6 DRAM "driver", some
> of them actually change the parameters in the structure passed to them,
> but many are actually not.
>
> To increase the optimisation potential for the code, mark those functions
> that just read members of the passed dram_para struct as "const".
> Use the opportunity to avoid the forward declarations by moving the
> mctl_core_init() function.
>
> This in itself does not decrease the code size, but lays the groundwork
> for future changes doing so.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h6.h | 6 +--
> arch/arm/mach-sunxi/dram_sun50i_h6.c | 48 +--
> .../mach-sunxi/dram_timings/h6_ddr3_1333.c| 2 +-
> arch/arm/mach-sunxi/dram_timings/h6_lpddr3.c | 2 +-
> 4 files changed, 27 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h index
> be02655cdd5..a7c6435220f 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> @@ -313,8 +313,8 @@ check_member(sunxi_mctl_phy_reg, dx[3].reserved_0xf0,
> 0xaf0); */
> #define RD_LINES_PER_BYTE_LANE (BITS_PER_BYTE + 6)
> struct dram_para {
> - u32 clk;
> - enum sunxi_dram_type type;
> + const u32 clk;
> + const enum sunxi_dram_type type;
> u8 cols;
> u8 rows;
> u8 ranks;
> @@ -331,6 +331,6 @@ static inline int ns_to_t(int nanoseconds)
> return DIV_ROUND_UP(ctrl_freq * nanoseconds, 1000);
> }
>
> -void mctl_set_timing_params(struct dram_para *para);
> +void mctl_set_timing_params(const struct dram_para *para);
>
> #endif /* _SUNXI_DRAM_SUN50I_H6_H */
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c index 43a2d19f084..1187f1960a0
> 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -36,25 +36,6 @@
> * similar PHY is ZynqMP.
> */
>
> -static void mctl_sys_init(struct dram_para *para);
> -static void mctl_com_init(struct dram_para *para);
> -static bool mctl_channel_init(struct dram_para *para);
> -
> -static bool mctl_core_init(struct dram_para *para)
> -{
> - mctl_sys_init(para);
> - mctl_com_init(para);
> - switch (para->type) {
> - case SUNXI_DRAM_TYPE_LPDDR3:
> - case SUNXI_DRAM_TYPE_DDR3:
> - mctl_set_timing_params(para);
> - break;
> - default:
> - panic("Unsupported DRAM type!");
> - };
> - return mctl_channel_init(para);
> -}
> -
> /* PHY initialisation */
> static void mctl_phy_pir_init(u32 val)
> {
> @@ -152,7 +133,7 @@ static void mctl_set_master_priority(void)
> MBUS_CONF(HDCP2, true,HIGH, 2, 100, 64, 32);
> }
>
> -static void mctl_sys_init(struct dram_para *para)
> +static void mctl_sys_init(u32 clk_rate)
> {
> struct sunxi_ccm_reg * const ccm =
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> @@ -173,7 +154,7 @@ static void mctl_sys_init(struct dram_para *para)
>
> /* Set PLL5 rate to doubled DRAM clock rate */
> writel(CCM_PLL5_CTRL_EN | CCM_PLL5_LOCK_EN |
> -CCM_PLL5_CTRL_N(para->clk * 2 / 24), >pll5_cfg);
> +CCM_PLL5_CTRL_N(clk_rate * 2 / 24), >pll5_cfg);
> mctl_await_completion(>pll5_cfg, CCM_PLL5_LOCK,
CCM_PLL5_LOCK);
>
> /* Configure DRAM mod clock */
> @@ -198,7 +179,7 @@ static void mctl_sys_init(struct dram_para *para)
> writel(0x8000, _ctl->unk_0x00c);
> }
>
> -static void mctl_set_addrmap(struct dram_para *para)
> +static void mctl_set_addrmap(const struct dram_para *para)
> {
> struct sunxi_mctl_ctl_reg * const mctl_ctl =
> (struct sunxi_mctl_ctl_reg
*)SUNXI_DRAM_CTL0_BASE;
> @@ -284,7 +265,7 @@ static void mctl_set_addrmap(struct dram_para *para)
> mctl_ctl->addrmap[8] = 0x3F3F;
> }
>
> -static void mctl_com_init(struct dram_para *para)
> +static void mctl_com_init(const struct dram_para *para)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg
*)SUNXI_DRAM_COM_BASE;
> @@ -354,7 +335,7 @@ static void mctl_com_init(struct dram_para *para)
> }
> }
>
> -static void mctl_bit_delay_set(struct dram_para *para)
> +static void mctl_bit_delay_set(const struct dram_para *para)
> {
> struct sunxi_mctl_phy_reg * const mctl_phy =
> (struct sunxi_mctl_phy_reg
*)SUNXI_DRAM_PHY0_BASE;
> @@ -413,7 +394,7 @@ static void mctl_bit_delay_set(struct dram_para *para)
> }
> }
>
> -static bool mctl_channel_init(struct dram_para *para)
> +static bool mctl_channel_init(const struct dram_para *para)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
>
Re: [PATCH 1/1] sunxi: dram: Fix incorrect ram size detection for some H6 boards
On Saturday, October 21, 2023 1:38:39 AM CEST Andre Przywara wrote:
> On Mon, 02 Oct 2023 20:59:34 +0200
> Jernej Škrabec wrote:
>
> Hi Jernej,
>
> > Dne ponedeljek, 02. oktober 2023 ob 14:42:40 CEST je Gunjan Gupta
napisal(a):
> > > > > bool mctl_mem_matches(u32 offset)
> > > > > {
> > > > >
> > > > > + dsb();
> > > >
> > > > This looks a bit odd, do you have an explanation for that? And are you
> > > > sure that is really needed?
> > > > I understand why we need the DSB after the writel's below, but before
> > > > that?
> > >
> > > I started with Ondrej Jirman's patch from LibreELEC's tree that had a
> > > dsb call added
> > > after the first writel call. That reduced the frequency of the errors
> > > but didn't removed
> > > it completely. My reason for moving it before the writel was to make
> > > sure any memory
> > > access is completed before starting the actual logic for the test.
> > > That reduced the
> > > frequency even further, but didn't resolve the issue. I did try
> > > removing it leaving only
> > > udelay added to the code, but that brings back the issue.
> > >
> > > > The only thing I could think of is that we are missing a barrier in
> > > > mctl_core_init() - which is the function called before
> > > > mctl_mem_matches().
> > > > Can you move that dsb(); into mctl_auto_detect_dram_size(), right
> > > > after
> > > > the mctl_core_init() call (where you add the udelay() below)? And I
> > > > wonder
> > > > if a dmb() would already be sufficient?
> > >
> > > Sure, I will try experimenting with it.
> > >
> > > > I noticed recently that the clr/setbit_le32() functions don't have a
> > > > barrier at all, maybe that should be fixed instead?
> > >
> > > I haven't done much of the low level programming myself. Mostly have
> > > done user space
> > > programming along with fixing minor kernel module compilation issues
> > > due to kernel api
> > > changes. So I wasn't sure what all places to debug. But if you point
> > > me to places with
> > > things to try, I surely can give time playing around testing the
> > > proposed fixes.> >
> > > > > @@ -623,6 +623,8 @@ static void mctl_auto_detect_dram_size(struct
> > > > > dram_para *para)> > > >
> > > > > para->cols = 11;
> > > > > mctl_core_init(para);
> > > > >
> > > > > + udelay(50);
> > > >
> > > > The location of that udelay() looks a bit odd, any chance that belongs
> > > > at
> > > > the end of mctl_channel_init() instead? And how did you come up with
> > > > that
> > > > and the value of 50? Just pure experimentation?
> > >
> > > Before adding the udelay, I added 7 print statements to print all the
> > > members of the para
> > > struct. That itself solved the issue along with the dsb added to the
> > > top of the mctl_mem_matches
> > > function. This is what gave me the clue that a delay is needed there.
> > > The value of 50 is
> > > indeed from pure experimentation
> >
> > Oh, I found one major difference between BSP and mainline driver. Please
> > test patch attached below. I don't know if this path is always taken when
> > wrong configuration is tested or not.
> >
> > Best regards,
> > Jernej
> >
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > @@ -420,6 +420,7 @@ static bool mctl_channel_init(struct dram_para *para)
> >
> > (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> >
> > struct sunxi_mctl_phy_reg * const mctl_phy =
> >
> > (struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
> >
> > + bool ret = true;
> >
> > int i;
> > u32 val;
> >
> > @@ -537,7 +538,7 @@ static bool mctl_channel_init(struct dram_para *para)
> >
> > debug("DRAM PHY DX%dRSR0 = %x\n", i,
> > readl(_phy->dx[i].rsr[0]));
> >
> > debug("Error while initializing DRAM PHY!\n");
>
> So those error messages (and the ones before them, not shown here) look
> odd: if I
Re: [PATCH] sunxi: H616: DRAM: refactor mctl_phy_configure_odt()
Dne sobota, 14. oktober 2023 ob 19:02:36 CEST je Andre Przywara napisal(a):
> The original H616 DDR3 ODT configuration code wrote board specific values
> into a sequence of paired registers.
> For LPDDR3 support we needed to special-case one group of registers,
> because for that DRAM type we need to write 0 into the lower register of
> each pair. That already made the code less readable.
>
> LPDDR4 support will make things even messier, so let's refactor that
> code now: We allow to write different values into the lower and upper
> half of each pair. The masking is moved into a macro, and used in each
> write statement.
>
> The effect is not as obvious yet, as we don't need the full flexibility at
> the moment, but the motivation will become clearer with LPDDR4 support.
>
> The generated binary is identical with and without the patch.
>
> Signed-off-by: Andre Przywara
This looks much nicer.
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> arch/arm/mach-sunxi/dram_sun50i_h616.c | 84 ++
> 1 file changed, 31 insertions(+), 53 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 7e580b62dca..ba5659d4094 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -241,61 +241,39 @@ static const u8 phy_init[] = {
> #endif
> };
>
> +#define MASK_BYTE(reg, nr) (((reg) >> ((nr) * 8)) & 0x1f)
> static void mctl_phy_configure_odt(const struct dram_para *para)
> {
> - unsigned int val;
> -
> - val = para->dx_dri & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x388);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x38c);
> -
> - val = (para->dx_dri >> 8) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c8);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3cc);
> -
> - val = (para->dx_dri >> 16) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x408);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x40c);
> -
> - val = (para->dx_dri >> 24) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x448);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x44c);
> -
> - val = para->ca_dri & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x340);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x344);
> -
> - val = (para->ca_dri >> 8) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x348);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c);
> -
> - val = para->dx_odt & 0x1f;
> - if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> - writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380);
> - else
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384);
> -
> - val = (para->dx_odt >> 8) & 0x1f;
> - if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> - writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> - else
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4);
> -
> - val = (para->dx_odt >> 16) & 0x1f;
> - if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> - writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400);
> - else
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404);
> -
> - val = (para->dx_odt >> 24) & 0x1f;
> - if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> - writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440);
> - else
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444);
> + uint32_t val_lo, val_hi;
> +
> + val_lo = para->dx_dri;
> + val_hi = para->dx_dri;
> + writel_relaxed(MASK_BYTE(val_lo, 0), SUNXI_DRAM_PHY0_BASE + 0x388);
> + writel_relaxed(MASK_BYTE(val_hi, 0), SUNXI_DRAM_PHY0_BASE + 0x38c);
> + writel_relaxed(MASK_BYTE(val_lo, 1), SUNXI_DRAM_PHY0_BASE + 0x3c8);
> + writel_relaxed(MASK_BYTE(val_hi, 1), SUNXI_DRAM_PHY0_BASE + 0x3cc);
> + writel_relaxed(MASK_BYTE(val_lo, 2), SUNXI_DRAM_PHY0_BASE + 0x408);
> + writel_relaxed(MASK_BYTE(val_hi, 2), SUNXI_DRAM_PHY0_BASE + 0x40c);
> + writel_relaxed(MASK_BYTE(val_lo, 3), SUNXI_DRAM_PHY0_BASE + 0x448);
> + writel_relaxed(MASK_BYTE(val_hi, 3), SUNXI_DRAM_PHY0_BASE + 0x44c);
> +
> + val_lo = para->ca_dri;
> + val_hi = para->ca_dri;
> + writel_relaxed(MASK_BYTE(val_lo, 0), SUNXI_DRAM_PHY0_BASE + 0x340);
> + writel_relaxed(MASK_BYTE(val_hi, 0), SUNXI_DRAM_PHY0_BASE + 0x344);
> + writel_relaxed(MASK_BYTE(val_lo, 1), SUNXI_DRAM_PHY0_BASE + 0x348);
> + writel_relaxed(MASK_BYTE(val_hi, 1), SUNXI_DRAM_PHY0_BASE + 0x34c);
> +
> + val_lo = (para->type == SUNXI_DRAM_TYPE_LPDDR3) ? 0 : para->dx_odt;
> + val_hi = para->dx_odt;
> + writel_relaxed(MASK_BYTE(val_lo, 0), SUNXI_DRAM_PHY0_BASE + 0x380);
Re: [PATCH 1/1] sunxi: dram: Fix incorrect ram size detection for some H6 boards
Dne ponedeljek, 02. oktober 2023 ob 14:42:40 CEST je Gunjan Gupta napisal(a):
> > > bool mctl_mem_matches(u32 offset)
> > > {
> > > + dsb();
> > This looks a bit odd, do you have an explanation for that? And are you
> > sure that is really needed?
> > I understand why we need the DSB after the writel's below, but before that?
>
> I started with Ondrej Jirman's patch from LibreELEC's tree that had a
> dsb call added
> after the first writel call. That reduced the frequency of the errors
> but didn't removed
> it completely. My reason for moving it before the writel was to make
> sure any memory
> access is completed before starting the actual logic for the test.
> That reduced the
> frequency even further, but didn't resolve the issue. I did try
> removing it leaving only
> udelay added to the code, but that brings back the issue.
>
> > The only thing I could think of is that we are missing a barrier in
> > mctl_core_init() - which is the function called before mctl_mem_matches().
> > Can you move that dsb(); into mctl_auto_detect_dram_size(), right after
> > the mctl_core_init() call (where you add the udelay() below)? And I wonder
> > if a dmb() would already be sufficient?
>
> Sure, I will try experimenting with it.
>
> > I noticed recently that the clr/setbit_le32() functions don't have a
> > barrier at all, maybe
> > that should be fixed instead?
>
> I haven't done much of the low level programming myself. Mostly have
> done user space
> programming along with fixing minor kernel module compilation issues
> due to kernel api
> changes. So I wasn't sure what all places to debug. But if you point
> me to places with
> things to try, I surely can give time playing around testing the proposed
> fixes.
>
> > > @@ -623,6 +623,8 @@ static void mctl_auto_detect_dram_size(struct
> > > dram_para *para)
> > > para->cols = 11;
> > > mctl_core_init(para);
> > >
> > > + udelay(50);
> > The location of that udelay() looks a bit odd, any chance that belongs at
> > the end of mctl_channel_init() instead? And how did you come up with that
> > and the value of 50? Just pure experimentation?
>
> Before adding the udelay, I added 7 print statements to print all the
> members of the para
> struct. That itself solved the issue along with the dsb added to the
> top of the mctl_mem_matches
> function. This is what gave me the clue that a delay is needed there.
> The value of 50 is
> indeed from pure experimentation
Oh, I found one major difference between BSP and mainline driver. Please test
patch attached below. I don't know if this path is always taken when wrong
configuration is tested or not.
Best regards,
Jernej
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -420,6 +420,7 @@ static bool mctl_channel_init(struct dram_para *para)
(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
struct sunxi_mctl_phy_reg * const mctl_phy =
(struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
+ bool ret = true;
int i;
u32 val;
@@ -537,7 +538,7 @@ static bool mctl_channel_init(struct dram_para *para)
debug("DRAM PHY DX%dRSR0 = %x\n", i,
readl(_phy->dx[i].rsr[0]));
debug("Error while initializing DRAM PHY!\n");
- return false;
+ ret = false;
}
if (sunxi_dram_is_lpddr(para->type))
@@ -553,7 +554,7 @@ static bool mctl_channel_init(struct dram_para *para)
writel(0x7ff, _com->maer1);
writel(0x, _com->maer2);
- return true;
+ return ret;
}
static void mctl_auto_detect_rank_width(struct dram_para *para)
Re: [PATCH 1/1] sunxi: dram: Fix incorrect ram size detection for some H6 boards
Dne ponedeljek, 02. oktober 2023 ob 13:26:26 CEST je Andre Przywara napisal(a):
> On Sun, 1 Oct 2023 21:43:32 +0530
> Gunjan Gupta wrote:
>
> (fixing Jernej's email)
>
> Hi Gunjan,
>
> thanks for sending a patch!
>
> > On some H6 boards like Orange Pi 3 LTS, some times U-Boot fails to detect
> > ram size correctly. Instead of 2GB thats available, it detects 4GB of ram
> > and then SPL just hangs there making board not to boot further.
> >
> > On debugging, I found that the rows value were being determined correctly,
> > but columns were sometimes off by one value. I found that adding some
> > delay after the mctl_core_init call along with making use of dsb in the
> > start of the mctl_mem_matches solves the issue.
> >
> > Signed-off-by: Gunjan Gupta
> > ---
> >
> > arch/arm/mach-sunxi/dram_helpers.c | 1 +
> > arch/arm/mach-sunxi/dram_sun50i_h6.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/mach-sunxi/dram_helpers.c
> > b/arch/arm/mach-sunxi/dram_helpers.c
> > index cdf2750f1c..5758c58e07 100644
> > --- a/arch/arm/mach-sunxi/dram_helpers.c
> > +++ b/arch/arm/mach-sunxi/dram_helpers.c
> > @@ -32,6 +32,7 @@ void mctl_await_completion(u32 *reg, u32 mask, u32 val)
> > #ifndef CONFIG_MACH_SUNIV
> > bool mctl_mem_matches(u32 offset)
> > {
> > + dsb();
>
> This looks a bit odd, do you have an explanation for that? And are you
> sure that is really needed?
> I understand why we need the DSB after the writel's below, but before that?
> The only thing I could think of is that we are missing a barrier in
> mctl_core_init() - which is the function called before mctl_mem_matches().
> Can you move that dsb(); into mctl_auto_detect_dram_size(), right after
> the mctl_core_init() call (where you add the udelay() below)? And I wonder
> if a dmb() would already be sufficient? I noticed recently that the
> clr/setbit_le32() functions don't have a barrier at all, maybe that should
> be fixed instead?
Looking at original BSP DRAM code, there is no data barriers that I can find.
Cache shouldn't be a thing before DRAM is initialized, right? Conversely,
I suggest adding memory barriers before each udelay(), as it is there for a
reason.
>
> > /* Try to write different values to RAM at two addresses */
> > writel(0, CFG_SYS_SDRAM_BASE);
> > writel(0xaa55aa55, (ulong)CFG_SYS_SDRAM_BASE + offset);
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > index bff2e42513..a031a845f5 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > @@ -623,6 +623,8 @@ static void mctl_auto_detect_dram_size(struct dram_para
> > *para)
> > para->cols = 11;
> > mctl_core_init(para);
> >
> > + udelay(50);
>
> The location of that udelay() looks a bit odd, any chance that belongs at
> the end of mctl_channel_init() instead? And how did you come up with that
> and the value of 50? Just pure experimentation? I think the original BSP
> DRAM code has plenty of delay calls, so we might have missed this one
> here, but I would love to see some explanation here.
I checked original driver and we have *almost* all delays. There are two
missing. Both in mctl_phy_pir_init(). One before mctl_await_completion() and
another after it. Both are 1 us long.
Maybe that solves it (in combination with data barriers)?
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > for (para->cols = 8; para->cols < 11; para->cols++) {
> > /* 8 bits per byte and 16/32 bit width */
> > if (mctl_mem_matches(1 << (para->cols + 1 +
>
>
Re: [PATCH] usb: musb-new: sunxi: read SRAM controller address from DT
Dne torek, 13. junij 2023 ob 13:21:58 CEST je Andre Przywara napisal(a):
> Some older SoCs (<=A20, F1C100s) do not have a dedicated SRAM buffer for
> the USB-OTG controller, but require the CPU to relinquish one of its SRAM
> blocks to the USB controller. This is done by flipping a bit in the SRAM
> controller (aka "syscon").
> So far we were doing this using the hardcoded SRAM controller address,
> but that breaks the abstraction, and we can find that address in the DT.
>
> Follow the "allwinner,sram" phandle property in the devicetree to get to
> the SRAM node. The reg property in there gives us the SRAM MMIO address,
> as seen by the CPU, but we need the SRAM *controller* address, which is
> two levels up from that node.
>
> Utilise U-Boot's DT code to do the traversal and DT address translation
> for us, then store the controller address in the glue struct, to later
> hand it to the routine that programs the SRAM controller.
> This allows us to drop the usage of the hardcoded SUNXI_SRAMC_BASE from
> the MUSB code.
>
> Signed-off-by: Andre Przywara
> ---
> Hi,
>
> this patch goes on top of Sam's musb sunxi fixes. Can someone look at
> the DT calls? There are quite some interfaces to U-Boot's DT framework,
> so I want to be sure to got the right one.
> If that patch looks fine, I would send a new series including Sam's two
> patches, this patch here, and a (simple) patch adding F1C100s support.
>
> Cheers,
> Andre
>
> drivers/usb/musb-new/sunxi.c | 26 +++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index 4bf0ee346a4..1da05e29a56 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -23,13 +23,12 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include "linux-compat.h"
> #include "musb_core.h"
> @@ -93,6 +92,7 @@ struct sunxi_glue {
> struct sunxi_musb_config *cfg;
> struct device dev;
> struct phy phy;
> + uintptr_t syscon_base;
> };
> #define to_sunxi_glue(d) container_of(d, struct sunxi_glue, dev)
>
> @@ -181,6 +181,7 @@ static void USBC_ForceVbusValidToHigh(__iomem void *base)
> */
> static void sunxi_musb_claim_sram(uintptr_t syscon_base)
> {
> + debug("%s(0x%lx);\n", __func__, (unsigned long)syscon_base);
> /*
>* BIT(0) of SRAM_CTRL_REG1 (syscon+0x04) controls SRAM-D ownership:
>* '0' -> exclusive access by CPU
> @@ -326,7 +327,7 @@ static int sunxi_musb_init(struct musb *musb)
>* block 'D', ownership of which needs to be handed over by
>* the CPU
>*/
> - sunxi_musb_claim_sram(SUNXI_SRAMC_BASE);
> + sunxi_musb_claim_sram(glue->syscon_base);
> }
>
> USBC_EnableDpDmPullUp(musb->mregs);
> @@ -450,6 +451,7 @@ static int musb_usb_probe(struct udevice *dev)
> struct sunxi_glue *glue = dev_get_priv(dev);
> struct musb_host_data *host = >mdata;
> struct musb_hdrc_platform_data pdata;
> + struct ofnode_phandle_args args;
> void *base = dev_read_addr_ptr(dev);
> int ret;
>
> @@ -476,6 +478,24 @@ static int musb_usb_probe(struct udevice *dev)
> return ret;
> }
>
> + ret = dev_read_phandle_with_args(dev, "allwinner,sram", NULL, 1, 0,
> + );
> + if (ret && ret != -ENOENT) {
> + dev_err(dev, "failed to get SRAM node\n");
> + return ret;
> + } else if (!ret) {
> + /* The SRAM *controller* address is in the grandparent node. */
> + ofnode node = ofnode_get_parent(ofnode_get_parent(args.node));
Above is not the safest thing to do in case of corrupted DT. It will trigger
assert.
> + struct resource res;
> +
> + ret = ofnode_read_resource(node, 0, );
ofnode_get_addr() seems better choice here. What do you think?
Best regards,
Jernej
> + if (ret) {
> + dev_err(dev, "failed to read SRAM controller base\n");
> + return ret;
> + }
> + glue->syscon_base = res.start;
> + }
> +
> ret = generic_phy_get_by_name(dev, "usb", >phy);
> if (ret) {
> pr_err("failed to get usb PHY\n");
>
Re: [PATCH v2 7/7] sunxi: H616: enable USB support for H616 boards
Dne ponedeljek, 12. junij 2023 ob 01:32:41 CEST je Andre Przywara napisal(a): > Now that the PHY driver supports the H616 USB PHY, we can enable USB > support for the two H616 boards. > As the OrangePi Zero2 has a USB-C port hard-wired to peripheral mode, > let's enable USB gadget mode for port 0, so people can use fastboot, > ethernet or mass storage functionality. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v2 6/7] phy: sun4i: Add H616 USB PHY support
Dne ponedeljek, 12. junij 2023 ob 01:32:40 CEST je Andre Przywara napisal(a): > Now that the Allwinner USB PHY driver supports the H616 quirk, let's > enable support for USB ports on that SoC. > > We connect the compatible string to a new struct describing the SoCs USB > PHY properties, and unblock the PHY driver selection in Kconfig. > > A later patch will enable USB support in the H616 boards' defconfigs. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v2 5/7] phy: sun4i-usb: Add H616 USB PHY quirk support
Dne ponedeljek, 12. junij 2023 ob 01:32:39 CEST je Andre Przywara napisal(a): > The H616 USB PHY is some kind of special snowflake: Only port2 works out > of the box, but all other ports need some help from this port2 to work > correctly: The CLK_BUS_PHY2 and RST_USB_PHY2 clock and reset need to be > enabled, and the SIDDQ bit in the PMU PHY control register needs to be > cleared. For this register to be accessible, CLK_BUS_ECHI2 needs to be > ungated. Don't ask > > Follow the respective Linux patch (b45c6d80325b) and add a quirk bit, > triggering the special sequence as outlined above, for PHYs other than > PHY2: ungate this one special clock, and clear the SIDDQ bit. We also > pick the clock and reset from PHY2 and enable them as well. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v2 4/7] phy: sun4i-usb: Replace types with explicit quirk flags
Dne ponedeljek, 12. junij 2023 ob 01:32:38 CEST je Andre Przywara napisal(a): > So far we were assigning some crude "type" (SoC name, really) to each > Allwinner USB PHY model, then guarding certain quirks based on this. > This does not only look weird, but gets more or more cumbersome to > maintain. > > Remove the bogus type names altogether, instead introduce flags for each > quirk, and explicitly check for them. > This improves readability, and simplifies future extensions. > > Port of Linux patch 8dd256bae653. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 3/3] sunxi: Kconfig: rework PHY_USB_SUN4I selection
Dne petek, 09. junij 2023 ob 12:56:21 CEST je Andre Przywara napisal(a): > At the moment we use "select" in each Allwinner SoC's Kconfig section to > include the USB PHY driver in the build. This means it cannot be disabled > via Kconfig, although USB is not really a strictly required core > functionality, and a particular board might not even include USB ports. > > Rework the Kconfig part by removing the "select" lines for each SoC's > section, and instead letting it default to "y" in the PHY driver section > itself. We use "depends on !" to exclude the few SoCs we don't support > (yet). The Allwinner V3s does not enable USB (PHY) support at the moment, > even though it should work: let the PHY default to "n" to keep the > current behaviour. > > Signed-off-by: Andre Przywara I stumbled on this issue before, but it didn't bother me enough to actually do something about that. Thanks! Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 2/3] phy: sun4i-usb: add Allwinner F1C100s support
Dne petek, 09. junij 2023 ob 12:56:20 CEST je Andre Przywara napisal(a): > The Allwinner F1C100s implements a single USB PHY, connected to its MUSB > OTG controller. The USB PHY is of the simpler, older type (like the A10), > the only real difference is that it's indeed only one PHY. > > Add a struct describing those F1C100s USB PHY properties, and connect it > to the new compatible string. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 1/3] phy: sun4i-usb: Fix of_xlate() argument check
Dne petek, 09. junij 2023 ob 12:56:19 CEST je Andre Przywara napisal(a): > In its of_xlate() function, the Allwinner USB PHY driver compares the > args_count variable against the number of implemented USB PHYs, although > this is the *number of arguments* to the DT phandle property. Per the DT > binding for this PHY device, this number is always one, so this check > will always fail if the particular SoC implements exactly one USB PHY. > So far this affected only the V3s (which has USB support disabled), but > the F1C100s also sports one PHY only. > > Fix that check to compare args_count against exactly 1, and the args[0] > content (requested PHY number) against the number of implemented PHYs. > > This fixes USB operation on the Allwinner V3s and allows to enable USB > on the Allwinner F1C100s SoC. > > Signed-off-by: Andre Przywara Nice catch! Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 5/5] sunxi: H616: add LPDDR3 DRAM support
Dne sreda, 07. junij 2023 ob 02:07:45 CEST je Andre Przywara napisal(a):
> From: iuncuim
>
> The H616 SoC has support for several types of DRAM: DDR3, LPDDR3,
> DDR4 and LPDDR4.
> At the moment, the driver only supports DDR3 memory.
> Let's extend the driver to support the LPDDR3 memory. All "magic"
> values obtained from the boot0.
> ---
> arch/arm/mach-sunxi/Kconfig | 8 +
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 193 +-
> arch/arm/mach-sunxi/dram_timings/Makefile | 1 +
> .../arm/mach-sunxi/dram_timings/h616_lpddr3.c | 95 +
> 4 files changed, 242 insertions(+), 55 deletions(-)
> create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr3.c
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 197d77ea658..5ce82a955c6 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333
> This option is the DDR3 timing used by the boot0 on H6 TV boxes
> which use a DDR3-1333 timing.
>
> +config SUNXI_DRAM_H616_LPDDR3
> + bool "LPDDR3 DRAM chips on the H616 DRAM controller"
> + select SUNXI_DRAM_LPDDR3
> + depends on DRAM_SUN50I_H616
> + ---help---
> + This option is the LPDDR3 timing used by the stock boot0 by
> + Allwinner.
> +
> config SUNXI_DRAM_H616_DDR3_1333
> bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> select SUNXI_DRAM_DDR3
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 4e988cebf59..082746ea7f3 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -228,10 +228,17 @@ static void mctl_set_addrmap(const struct dram_config
> *config)
> }
>
> static const u8 phy_init[] = {
> +#ifdef CONFIG_SUNXI_DRAM_H616_DDR3_1333
> 0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19,
> 0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06,
> 0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08,
> 0x09, 0x05, 0x18
> +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR3)
> + 0x18, 0x06, 0x00, 0x05, 0x04, 0x03, 0x09, 0x02,
> + 0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> + 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07,
> + 0x17, 0x19, 0x1a
> +#endif
> };
>
> static void mctl_phy_configure_odt(const struct dram_para *para)
> @@ -263,19 +270,31 @@ static void mctl_phy_configure_odt(const struct
> dram_para *para)
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c);
>
> val = para->dx_odt & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384);
>
> val = (para->dx_odt >> 8) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4);
>
> val = (para->dx_odt >> 16) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404);
>
> val = (para->dx_odt >> 24) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444);
Above dx_odt oriented changes are not needed. They depend on Kconfig symbol,
which can simply be set to 0.
I didn't do detailed check, but if it works, it should be ok. Were calculated
values here compared to vendor driver?
Best regards,
Jernej
>
> dmb();
> @@ -794,31 +813,47 @@ static void mctl_phy_ca_bit_delay_compensation(const
> struct dram_para *para,
> writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> writel(val, SUNXI_DRAM_PHY0_BASE + 0x7f4);
>
> - /* following configuration is DDR3 specific */
> - val = (para->tpr10 >> 7) & 0x1e;
> - if (para->tpr2 & 1) {
> - writel(val, SUNXI_DRAM_PHY0_BASE + 0x794);
> - if (config->ranks == 2) {
> - val = (para->tpr10 >> 11) & 0x1e;
> - writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e4);
> - }
> - if (para->tpr0 & BIT(31)) {
> - val = (para->tpr0 << 1) & 0x3e;
> - writel(val,
Re: [PATCH 4/5] sunxi: H616: add DRAM type selection
Dne sreda, 07. junij 2023 ob 02:07:44 CEST je Andre Przywara napisal(a): > From: iuncuim > > Allwinner H616 SoC supports several types of DRAM memory. To further > integrate other types of memory, we need to add this delimitation. > --- > arch/arm/mach-sunxi/Kconfig | 10 +- > arch/arm/mach-sunxi/dram_timings/Makefile | 3 +-- > configs/orangepi_zero2_defconfig | 1 + > configs/x96_mate_defconfig| 1 + > 4 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 6dcbb096f74..197d77ea658 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -442,7 +442,7 @@ config ARM_BOOT_HOOK_RMR > This allows both the SPL and the U-Boot proper to be entered in > either mode and switch to AArch64 if needed. > > -if SUNXI_DRAM_DW || DRAM_SUN50I_H6 > +if SUNXI_DRAM_DW || DRAM_SUN50I_H6 || DRAM_SUN50I_H616 > config SUNXI_DRAM_DDR3 > bool > > @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333 > This option is the DDR3 timing used by the boot0 on H6 TV boxes > which use a DDR3-1333 timing. > > +config SUNXI_DRAM_H616_DDR3_1333 > + bool "DDR3-1333 boot0 timings on the H616 DRAM controller" > + select SUNXI_DRAM_DDR3 > + depends on DRAM_SUN50I_H616 > + ---help--- > + This option is the DDR3 timing used by the boot0 on H616 TV boxes > + which use a DDR3-1333 timing. I'm always a bit unsure about help part. There is no need for "---", right? I also usually ident help block with extra two spaces. Do we have any rules for that? Apart from that and SoB tag, it looks good. Best regards, Jernej > + > config SUNXI_DRAM_DDR2_V3S > bool "DDR2 found in V3s chip" > select SUNXI_DRAM_DDR2 > diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile > b/arch/arm/mach-sunxi/dram_timings/Makefile > index 39a8756c297..4d78c04c9ae 100644 > --- a/arch/arm/mach-sunxi/dram_timings/Makefile > +++ b/arch/arm/mach-sunxi/dram_timings/Makefile > @@ -3,5 +3,4 @@ obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK) += lpddr3_stock.o > obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S)+= ddr2_v3s.o > obj-$(CONFIG_SUNXI_DRAM_H6_LPDDR3) += h6_lpddr3.o > obj-$(CONFIG_SUNXI_DRAM_H6_DDR3_1333)+= h6_ddr3_1333.o > -# currently only DDR3 is supported on H616 > -obj-$(CONFIG_MACH_SUN50I_H616) += h616_ddr3_1333.o > +obj-$(CONFIG_SUNXI_DRAM_H616_DDR3_1333) += h616_ddr3_1333.o > diff --git a/configs/orangepi_zero2_defconfig > b/configs/orangepi_zero2_defconfig > index 6cb942f511a..e38cc20ac72 100644 > --- a/configs/orangepi_zero2_defconfig > +++ b/configs/orangepi_zero2_defconfig > @@ -7,6 +7,7 @@ CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e > CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e > CONFIG_DRAM_SUN50I_H616_TPR10=0xf83438 > CONFIG_MACH_SUN50I_H616=y > +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y > CONFIG_R_I2C_ENABLE=y > CONFIG_SPL_SPI_SUNXI=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig > index 122c1a99e32..c86cf43771c 100644 > --- a/configs/x96_mate_defconfig > +++ b/configs/x96_mate_defconfig > @@ -10,6 +10,7 @@ CONFIG_DRAM_SUN50I_H616_TPR10=0x2f0007 > CONFIG_DRAM_SUN50I_H616_TPR11=0x > CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7557 > CONFIG_MACH_SUN50I_H616=y > +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y > CONFIG_R_I2C_ENABLE=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL_I2C=y >
Re: [PATCH 3/5] sunxi: H616: dram: split struct dram_para
Dne sreda, 07. junij 2023 ob 02:07:43 CEST je Andre Przywara napisal(a): > Currently there is one DRAM parameter struct for the Allwinner H616 DRAM > "driver". It contains many fields that are compile time constants > (set by Kconfig variables), though there are also some fields that are > probed and changed over the runtime of the DRAM initialisation. > > Because of this mixture, the compiler cannot properly optimise the code > for size, as it does not consider constant propagation in its full > potential. > > Help the compiler out by splitting that structure into two: one that only > contains values known at compile time, and another one where the values > will actually change. The former can then be declared "const", which will > let the compiler fold its values directly into the code using it. > > We also add "const" tags for some new "struct dram_config" pointers, to > further increase code optimisation. > To help the compiler optimise the code further, the definition of the > now "const struct dram_para" has to happen at a file-global level, so > move that part out of sunxi_dram_init(). > > That results in quite some code savings (almost 2KB), and helps to keep > the code small with the LPDDR3 support added later. > > Signed-off-by: Andre Przywara Nice trick. It could be used also in other DRAM drivers. Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 2/5] sunxi: H616: dram: const-ify DRAM function parameters
Dne sreda, 07. junij 2023 ob 02:07:42 CEST je Andre Przywara napisal(a): > There are quite some functions in the Allwinner H616 DRAM "driver", some > of them actually change the parameters in the structure passed to them, > but many are actually not. > To increase the optimisation potential for the code, mark those functions > that just read members of the passed dram_para struct as "const". > This in itself does not decrease the code size, but lays the groundwork > for future changes doing so. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 1/5] sunxi: dram: make MBUS configuration functions static
Dne sreda, 07. junij 2023 ob 02:07:41 CEST je Andre Przywara napisal(a):
> The usage of the C keyword "inline" seems to be a common
> misunderstanding: it's a *hint* only, and modern compilers will inline
> (or not) functions based on their own judgement and provided compiler
> options.
> So while marking functions as "inline" does not do much, missing the
> "static" keyword will force to compiler to spell out a version of the
> function for potential external callers, which actually increases the
> code size (though hopefully the linker will drop the function).
>
> Change the "inline" attribute for the mbus_configure_port() functions in
> some Allwinner DRAM drivers to "static", so that the explicit version
> can actually be dropped from the object file, reducing the code size.
>
> "static inline" has a use case in header files, where it avoids a warning
> if a .c file including this header does not use the particular function.
> In a .c file itself "static inline" is not useful otherwise, so just use
> static here as well.
>
> Signed-off-by: Andre Przywara
Nice catch! Could it be put into common functions? These functions look the
same. Anyway:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> arch/arm/mach-sunxi/dram_sun50i_h6.c | 3 ++-
> arch/arm/mach-sunxi/dram_sun50i_h616.c | 2 +-
> arch/arm/mach-sunxi/dram_sunxi_dw.c| 18 +-
> 3 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> index b332f3a3e4a..bff2e42513c 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -93,7 +93,8 @@ enum {
> MBUS_QOS_HIGH,
> MBUS_QOS_HIGHEST
> };
> -inline void mbus_configure_port(u8 port,
> +
> +static void mbus_configure_port(u8 port,
> bool bwlimit,
> bool priority,
> u8 qos,
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 1f9416d6eaf..02f6b2a06d4 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -31,7 +31,7 @@ enum {
> MBUS_QOS_HIGHEST
> };
>
> -inline void mbus_configure_port(u8 port,
> +static void mbus_configure_port(u8 port,
> bool bwlimit,
> bool priority,
> u8 qos,
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 4af5922f334..9382d3d0be8 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -81,15 +81,15 @@ enum {
> MBUS_QOS_HIGHEST
> };
>
> -static inline void mbus_configure_port(u8 port,
> -bool bwlimit,
> -bool priority,
> -u8 qos, /* MBUS_QOS_LOWEST ..
> MBUS_QOS_HIGEST */
> -u8 waittime,/* 0 .. 0xf */
> -u8 acs, /* 0 .. 0xff */
> -u16 bwl0, /* 0 .. 0x,
> bandwidth limit in MB/s */
> -u16 bwl1,
> -u16 bwl2)
> +static void mbus_configure_port(u8 port,
> + bool bwlimit,
> + bool priority,
> + u8 qos, /* MBUS_QOS_LOWEST ..
> MBUS_QOS_HIGEST */
> + u8 waittime,/* 0 .. 0xf */
> + u8 acs, /* 0 .. 0xff */
> + u16 bwl0, /* 0 .. 0x, bandwidth limit
> in MB/s */
> + u16 bwl1,
> + u16 bwl2)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
>
Re: [PATCH v2 04/10] sunxi: Convert H616 DRAM options to single setting
Dne torek, 11. april 2023 ob 12:13:04 CEST je Andre Przywara napisal(a):
> On Mon, 10 Apr 2023 10:21:13 +0200
>
> Jernej Skrabec wrote:
> > Vendor DRAM settings use TPR10 parameter to enable various features.
> > There are many mores features that just those that are currently
> > mentioned. Since new will be added later and most are not known, let's
> > reuse value from vendor DRAM driver as-is. This will also help adding
> > support for new boards.
> >
> > Signed-off-by: Jernej Skrabec
>
> Thanks, based on my previous review, and the changes to the bit names:
>
> Reviewed-by: Andre Przywara
>
> Just one note here, mostly for the reference when people stumble upon
> this patch: this enables the CA bit delay compensation code for the X96,
> which was not enabled before, because C
> was not set. I don't know if the fixed values written by this
> code here were meant for the OrangePi Zero2 (which though never
> runs this code), but for the X96 Mate the values written by this patch
> will be changed in a later patch.
DRAM_SUN50I_H616_UNKNOWN_FEATURE was tested with T95 box, but there is no
upstream support for it (yet). I think this series was tested with enough
(mostly not supported in mainline) devices that it's safe to say it works.
Note that there are several versions of vendor DRAM driver which naturally
differ slightly. This series is based on V0.651.
Thanks for merging!
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > ---
> >
> > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 9 +
> > arch/arm/mach-sunxi/Kconfig | 38 +---
> > arch/arm/mach-sunxi/dram_sun50i_h616.c| 197 +-
> > configs/orangepi_zero2_defconfig | 5 +-
> > configs/x96_mate_defconfig| 1 +
> > 5 files changed, 117 insertions(+), 133 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> > c9e1f84bfcdd..dbdc6b694ec1 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -137,6 +137,14 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> >
> > #define MSTR_ACTIVE_RANKS(x) (((x == 2) ? 3 : 1) << 24)
> > #define MSTR_BURST_LENGTH(x) (((x) >> 1) << 16)
> >
> > +#define TPR10_CA_BIT_DELAY BIT(16)
> > +#define TPR10_DX_BIT_DELAY0BIT(17)
> > +#define TPR10_DX_BIT_DELAY1BIT(18)
> > +#define TPR10_WRITE_LEVELING BIT(20)
> > +#define TPR10_READ_CALIBRATION BIT(21)
> > +#define TPR10_READ_TRAININGBIT(22)
> > +#define TPR10_WRITE_TRAINING BIT(23)
> > +
> >
> > struct dram_para {
> >
> > u32 clk;
> > enum sunxi_dram_type type;
> >
> > @@ -147,6 +155,7 @@ struct dram_para {
> >
> > u32 dx_odt;
> > u32 dx_dri;
> > u32 ca_dri;
> >
> > + u32 tpr10;
> >
> > };
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 14fb9a95905a..1b47a49f938c 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -52,38 +52,6 @@ config DRAM_SUN50I_H616
> >
> > like H616.
> >
> > if DRAM_SUN50I_H616
> >
> > -config DRAM_SUN50I_H616_WRITE_LEVELING
> > - bool "H616 DRAM write leveling"
> > - ---help---
> > - Select this when DRAM on your H616 board needs write leveling.
> > -
> > -config DRAM_SUN50I_H616_READ_CALIBRATION
> > - bool "H616 DRAM read calibration"
> > - ---help---
> > - Select this when DRAM on your H616 board needs read calibration.
> > -
> > -config DRAM_SUN50I_H616_READ_TRAINING
> > - bool "H616 DRAM read training"
> > - ---help---
> > - Select this when DRAM on your H616 board needs read training.
> > -
> > -config DRAM_SUN50I_H616_WRITE_TRAINING
> > - bool "H616 DRAM write training"
> > - ---help---
> > - Select this when DRAM on your H616 board needs write training.
> > -
> > -config DRAM_SUN50I_H616_BIT_DELAY_COMPENSATION
> > - bool "H616 DRAM bit delay compensation"
> > - ---help---
> > - Select this when DRAM on your H616 board needs bit delay
> > - compensation.
> > -
> > -config DRAM_SUN50I_H616_UNKNOWN_FEATURE
> > - bool "H616 DRAM unknown feature"
> > - ---help---
> > - Select this when DRAM on your H616 board needs this unknown
> > - feature.
> > -
> >
> > config DRAM_SUN50I_H616_DX_ODT
> >
> > hex "H616 DRAM DX ODT parameter"
> > help
> >
> > @@ -98,6 +66,12 @@ config DRAM_SUN50I_H616_CA_DRI
> >
> > hex "H616 DRAM CA DRI parameter"
> > help
> >
> > CA DRI value from vendor DRAM settings.
> >
> > +
> > +config DRAM_SUN50I_H616_TPR10
> > + hex "H616 DRAM TPR10 parameter"
> > + help
> > + TPR10 value from vendor DRAM settings. It tells which features
> > + should be configured, like write leveling, read calibration, etc.
> >
> > endif
> >
> > config SUN6I_PRCM
> >
> > diff --git
Re: [RFC PATCH] sunxi: arm64: boot0.h: runtime check for RVBAR address
Dne sreda, 05. april 2023 ob 22:30:11 CEST je Andre Przywara napisal(a):
> Some SoCs of the H616 family use a die variant, that puts some CPU power
> and reset control registers at a different address. There are examples
> of two instances of the same board, using different die revisions of the
> otherwise same H313 SoC. We need to write to a register in that block
> *very* early in the SPL boot, to switch the core to AArch64.
>
> Since the devices are otherwise indistinguishable, let the SPL code read
> that die variant and use the respective RVBAR address based on that.
> That is a bit tricky, since we need to do that in hand-coded AArch32
> machine language, shared by all 64-bit SoCs. To avoid build dependencies
> in this mess, we always provide two addresses to choose from, and just
> give identical values for all other SoCs. This allows the same code to
> run on all 64-bit SoCs, and controls this switch behaviour purely from
> Kconfig.
>
> Signed-off-by: Andre Przywara
> ---
> Hi,
>
> this patch goes on top of the two patches I sent earlier, that
> introduce CONFIG_SUNXI_RVBAR_ADDRESS. I don't have a device with that
> die variant, so just roughly tested this by inverting the ldrne and
> swapping the addresses.
> Please let me know if you have such a device and can confirm that this
> code works on the original and alternative die alike.
>
> Cheers,
> Andre
>
> arch/arm/include/asm/arch-sunxi/boot0.h | 14 ++
> arch/arm/mach-sunxi/Kconfig | 17 -
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
> b/arch/arm/include/asm/arch-sunxi/boot0.h index 1a396f78488..b27df3b9b5e
> 100644
> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> @@ -20,8 +20,8 @@
> b reset
> .space 0x7c
>
> - .word 0xe28f0058 // add r0, pc, #88
> - .word 0xe59f1054 // ldr r1, [pc, #84]
> + .word 0xe28f0070 // add r0, pc, #112 // @(fel_stash -
.)
> + .word 0xe59f106c // ldr r1, [pc, #108] // fel_stash - .
> .word 0xe081 // add r0, r0, r1
> .word 0xe580d000 // str sp, [r0]
> .word 0xe580e004 // str lr, [r0, #4]
> @@ -32,8 +32,12 @@
> .word 0xee1cef10 // mrc 15, 0, lr, cr12, cr0, {0}
> .word 0xe580e010 // str lr, [r0, #16]
>
> - .word 0xe59f1024 // ldr r1, [pc, #36] ; 0x17a0
> - .word 0xe59f0024 // ldr r0, [pc, #36] ;
CONFIG_*_TEXT_BASE
> + .word 0xe59f1034 // ldr r1, [pc, #52] ; RVBAR_ADDRESS
> + .word 0xe59f0034 // ldr r0, [pc, #52] ; SUNXI_SRAMC_BASE
> + .word 0xe5900024 // ldr r0, [r0, #36] ; SRAM_VER_REG
> + .word 0xe21000ff // andsr0, r0, #255; 0xff
> + .word 0x159f102c // ldrne r1, [pc, #44] ; RVBAR_ALTERNATIVE
> + .word 0xe59f002c // ldr r0, [pc, #44] ; CONFIG_*TEXT_BASE
> .word 0xe581 // str r0, [r1]
> .word 0xf57ff04f // dsb sy
> .word 0xf57ff06f // isb sy
> @@ -45,6 +49,8 @@
> .word 0xeafd // b @wfi
>
> .word CONFIG_SUNXI_RVBAR_ADDRESS // writable RVBAR
mapping addr
> + .word SUNXI_SRAMC_BASE
> + .word CONFIG_SUNXI_RVBAR_ALTERNATIVE // address for die
variant
> #ifdef CONFIG_SPL_BUILD
> .word CONFIG_SPL_TEXT_BASE
> #else
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 0527b3863a7..be0910499bb 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -111,7 +111,7 @@ config SUNXI_SRAM_ADDRESS
> SRAM to a different address.
>
> config SUNXI_RVBAR_ADDRESS
> - hex "RVBAR address"
> + hex
> depends on ARM64
> default 0x09010040 if SUN50I_GEN_H6
> default 0x017000a0
> @@ -122,6 +122,21 @@ config SUNXI_RVBAR_ADDRESS
> entry point when switching to AArch64. This store is on different
> addresses, depending on the SoC.
>
> +config SUNXI_RVBAR_ALTERNATIVE
> + hex
> + depends on ARM64
> + default 0x8140 if MACH_SUN50I_H616
As discussed on IRC by warpme, above default has a typo.
Apart from that, changes look good, so once fixed:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> + default 0x09010040 if SUN50I_GEN_H6
> + default 0x017000a0
> + ---help---
> + The H616 die exists is at least two variants, with one having the
> + RVBAR registers at a different address. If the SoC variant ID
> + (stored in SRAM_VER_REG[7:0]) is not 0, we need to use the
> + other address.
> + Set this alternative address to the same as the normal address
> + for all other SoCs, so the content of the SRAM_VER_REG becomes
> + irrelevant there, and we can use the same code.
> +
> config SUNXI_A64_TIMER_ERRATUM
> bool
Re: [PATCH 2/2] sunxi: remove support for boot0 header reservation
Dne sreda, 05. april 2023 ob 16:27:31 CEST je Andre Przywara napisal(a): > In the early days of the Allwinner A64 U-Boot support, we relied on a > vendor provided "boot0" binary to perform the DRAM initialisation. This > replaced the SPL, and required to equip the U-Boot (proper) binary with > a vendor specific header to be recognised as a valid boot0 payload. > Fortunately these days are long gone (we gained SPL and DRAM support in > early 2017!), and we never needed to use that hack on any later 64-bit > Allwinner SoC. > > Since this is highly obsolete by now, remove the Kconfig option and the > small pieces of "code" associated with it. > > Provide some comments about the purpose of the remaining boot0 code on > the way. > > Signed-off-by: Andre Przywara I think it's time to remove this code too. Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > arch/arm/include/asm/arch-sunxi/boot0.h | 18 +++--- > arch/arm/mach-sunxi/Kconfig | 9 - > configs/a64-olinuxino-emmc_defconfig| 1 - > configs/a64-olinuxino_defconfig | 1 - > configs/amarula_a64_relic_defconfig | 1 - > configs/bananapi_m64_defconfig | 1 - > configs/nanopi_a64_defconfig| 1 - > configs/oceanic_5205_5inmfd_defconfig | 1 - > configs/orangepi_win_defconfig | 1 - > configs/pine64_plus_defconfig | 1 - > configs/sopine_baseboard_defconfig | 1 - > 11 files changed, 11 insertions(+), 25 deletions(-) > > diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h > b/arch/arm/include/asm/arch-sunxi/boot0.h index 59ea75a96b5..1a396f78488 > 100644 > --- a/arch/arm/include/asm/arch-sunxi/boot0.h > +++ b/arch/arm/include/asm/arch-sunxi/boot0.h > @@ -1,13 +1,17 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > - * Configuration settings for the Allwinner A64 (sun50i) CPU > + * Very early code for Allwinner 64-bit CPUs. > + * > + * The BROM runs entirely in AArch32 state, so the SPL is entered using > this + * ISA. Depending on the rest of the firmware stack, this may also be > true + * for U-Boot proper. > + * Provide the "RMR reset into 64-bit" sequence, in AArch32 machine > language, + * so that we can have all of U-Boot in AArch64. The first > instruction is + * chosen so that if the CPU is already using AArch64, it > will skip the code + * and jump straight to the reset vector. > */ > > -#if defined(CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER) && > !defined(CONFIG_SPL_BUILD) -/* reserve space for BOOT0 header information > */ > - b reset > - .space 1532 > -#elif defined(CONFIG_ARM_BOOT_HOOK_RMR) > +#ifdef CONFIG_ARM_BOOT_HOOK_RMR > /* > * Switch into AArch64 if needed. > * Refer to arch/arm/mach-sunxi/rmr_switch.S for the original source. > @@ -47,7 +51,7 @@ > .word CONFIG_TEXT_BASE > #endif > .word fel_stash - . > -#else > +#else/* !CONFIG_ARM_BOOT_HOOK_RMR */ > /* normal execution */ > b reset > #endif > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index b46667ce01e..0527b3863a7 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -386,15 +386,6 @@ config MACH_SUN8I > default y if MACH_SUN8I_R40 > default y if MACH_SUN8I_V3S > > -config RESERVE_ALLWINNER_BOOT0_HEADER > - bool "reserve space for Allwinner boot0 header" > - select ENABLE_ARM_SOC_BOOT0_HOOK > - ---help--- > - Prepend a 1536 byte (empty) header to the U-Boot image file, to be > - filled with magic values post build. The Allwinner provided boot0 > - blob relies on this information to load and execute U-Boot. > - Only needed on 64-bit Allwinner boards so far when using boot0. > - > config ARM_BOOT_HOOK_RMR > bool > depends on ARM64 > diff --git a/configs/a64-olinuxino-emmc_defconfig > b/configs/a64-olinuxino-emmc_defconfig index 8ec9eb3e9c2..a5989fab1c6 > 100644 > --- a/configs/a64-olinuxino-emmc_defconfig > +++ b/configs/a64-olinuxino-emmc_defconfig > @@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y > CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino-emmc" > CONFIG_SPL=y > CONFIG_MACH_SUN50I=y > -CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y > CONFIG_MMC_SUNXI_SLOT_EXTRA=2 > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SUPPORT_EMMC_BOOT=y > diff --git a/configs/a64-olinuxino_defconfig > b/configs/a64-olinuxino_defconfig index 16cef18beef..0b469c25d0d 100644 > --- a/configs/a64-olinuxino_defconfig > +++ b/configs/a64-olinuxino_defconfig > @@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y > CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino" > CONFIG_SPL=y > CONFIG_MACH_SUN50I=y > -CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y > CONFIG_MMC_SUNXI_SLOT_EXTRA=2 > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SUN8I_EMAC=y > diff --git a/configs/amarula_a64_relic_defconfig > b/configs/amarula_a64_relic_defconfig index ae44b66d109..292af6e372e 100644 > --- a/configs/amarula_a64_relic_defconfig > +++
Re: [PATCH 1/2] sunxi: boot0.h: allow RVBAR MMIO address customisation
Dne sreda, 05. april 2023 ob 16:27:30 CEST je Andre Przywara napisal(a): > To switch the ARMv8 Allwinner SoCs into the 64-bit AArch64 ISA, we need > to program the 64-bit start code address into an MMIO mapped register > that shadows the architectural RVBAR register. > This address is SoC specific, with just two versions out there so far. > Now a third address emerged, on a *variant* of an existing SoC (H616). > > Change the boot0.h start code to make this address a Kconfig > selectable option, to allow easier maintenance. > We make this address user-visible (even though it shouldn't be), to > allow putting this in defconfig. This is needed because there are > apparently revisions of the H616 SoC out there using different > addresses, so this becomes a per-board decision. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > arch/arm/include/asm/arch-sunxi/boot0.h | 7 ++- > arch/arm/mach-sunxi/Kconfig | 12 > 2 files changed, 14 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h > b/arch/arm/include/asm/arch-sunxi/boot0.h index 46b7e073b59..59ea75a96b5 > 100644 > --- a/arch/arm/include/asm/arch-sunxi/boot0.h > +++ b/arch/arm/include/asm/arch-sunxi/boot0.h > @@ -39,11 +39,8 @@ > .word 0xf57ff06f // isb sy > .word 0xe320f003 // wfi > .word 0xeafd // b @wfi > -#ifndef CONFIG_SUN50I_GEN_H6 > - .word 0x017000a0 // writeable RVBAR mapping address > -#else > - .word 0x09010040 // writeable RVBAR mapping address > -#endif > + > + .word CONFIG_SUNXI_RVBAR_ADDRESS // writable RVBAR mapping addr > #ifdef CONFIG_SPL_BUILD > .word CONFIG_SPL_TEXT_BASE > #else > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 6417aee944b..b46667ce01e 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -110,6 +110,18 @@ config SUNXI_SRAM_ADDRESS > Some newer SoCs map the boot ROM at address 0 instead and move the > SRAM to a different address. > > +config SUNXI_RVBAR_ADDRESS > + hex "RVBAR address" > + depends on ARM64 > + default 0x09010040 if SUN50I_GEN_H6 > + default 0x017000a0 > + ---help--- > + The read-only RVBAR system register holds the address of the first > + instruction to execute after a reset. Allwinner cores provide a > + writable MMIO backing store for this register, to allow to set the > + entry point when switching to AArch64. This store is on different > + addresses, depending on the SoC. > + > config SUNXI_A64_TIMER_ERRATUM > bool
Re: [PATCH v2 2/2] video: sunxi: dw-hdmi: Use DM for HVCC regulator
Dne sobota, 08. april 2023 ob 02:26:39 CEST je Andre Przywara napisal(a):
> From: Samuel Holland
>
> The HDMI PHY depends on the HVCC supply being enabled. So far we have
> relied on it being enabled by an earlier firmware stage (SPL or TF-A).
> Attempt to enable the regulator here, so we can remove that dependency.
>
> Signed-off-by: Samuel Holland
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> drivers/video/sunxi/sunxi_dw_hdmi.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
> b/drivers/video/sunxi/sunxi_dw_hdmi.c index ef18d1f281f..0324a050d03 100644
> --- a/drivers/video/sunxi/sunxi_dw_hdmi.c
> +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
> @@ -19,11 +19,13 @@
> #include
> #include
> #include
> +#include
>
> struct sunxi_dw_hdmi_priv {
> struct dw_hdmi hdmi;
> struct reset_ctl_bulk resets;
> struct clk_bulk clocks;
> + struct udevice *hvcc;
> };
>
> struct sunxi_hdmi_phy {
> @@ -333,6 +335,9 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> int ret;
>
> + if (priv->hvcc)
> + regulator_set_enable(priv->hvcc, true);
> +
> /* Set pll3 to 297 MHz */
> clock_set_pll3(29700);
>
> @@ -384,6 +389,10 @@ static int sunxi_dw_hdmi_of_to_plat(struct udevice
> *dev) if (ret)
> return ret;
>
> + ret = device_get_supply_regulator(dev, "hvcc-supply", >hvcc);
> + if (ret)
> + priv->hvcc = NULL;
> +
> return 0;
> }
Re: [PATCH v2 1/2] video: sunxi: dw-hdmi: Use DM for clock gates and resets
Dne sobota, 08. april 2023 ob 02:26:38 CEST je Andre Przywara napisal(a):
> From: Samuel Holland
>
> This abstracts away the CCU register layout, which is necessary for
> supporting new SoCs like H6 with a reorganized CCU. One of the resets is
> referenced from the PHY node instead of the controller node, so it will
> have to wait until the PHY code is factored out to a separate driver.
>
> Signed-off-by: Samuel Holland
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> drivers/video/sunxi/sunxi_dw_hdmi.c | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
> b/drivers/video/sunxi/sunxi_dw_hdmi.c index 4f5d0989286..ef18d1f281f 100644
> --- a/drivers/video/sunxi/sunxi_dw_hdmi.c
> +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
> @@ -5,12 +5,14 @@
> * (C) Copyright 2017 Jernej Skrabec
> */
>
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -20,6 +22,8 @@
>
> struct sunxi_dw_hdmi_priv {
> struct dw_hdmi hdmi;
> + struct reset_ctl_bulk resets;
> + struct clk_bulk clocks;
> };
>
> struct sunxi_hdmi_phy {
> @@ -336,14 +340,16 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
> clrsetbits_le32(>hdmi_clk_cfg, CCM_HDMI_CTRL_PLL_MASK,
> CCM_HDMI_CTRL_PLL3);
>
> - /* Set ahb gating to pass */
> - setbits_le32(>ahb_reset1_cfg, 1 << AHB_RESET_OFFSET_HDMI);
> + /* This reset is referenced from the PHY devicetree node. */
> setbits_le32(>ahb_reset1_cfg, 1 << AHB_RESET_OFFSET_HDMI2);
> - setbits_le32(>ahb_gate1, 1 << AHB_GATE_OFFSET_HDMI);
> - setbits_le32(>hdmi_slow_clk_cfg,
CCM_HDMI_SLOW_CTRL_DDC_GATE);
>
> - /* Clock on */
> - setbits_le32(>hdmi_clk_cfg, CCM_HDMI_CTRL_GATE);
> + ret = reset_deassert_bulk(>resets);
> + if (ret)
> + return ret;
> +
> + ret = clk_enable_bulk(>clocks);
> + if (ret)
> + return ret;
>
> sunxi_dw_hdmi_phy_init(>hdmi);
>
> @@ -362,6 +368,7 @@ static int sunxi_dw_hdmi_of_to_plat(struct udevice *dev)
> {
> struct sunxi_dw_hdmi_priv *priv = dev_get_priv(dev);
> struct dw_hdmi *hdmi = >hdmi;
> + int ret;
>
> hdmi->ioaddr = (ulong)dev_read_addr(dev);
> hdmi->i2c_clk_high = 0xd8;
> @@ -369,6 +376,14 @@ static int sunxi_dw_hdmi_of_to_plat(struct udevice
> *dev) hdmi->reg_io_width = 1;
> hdmi->phy_set = sunxi_dw_hdmi_phy_cfg;
>
> + ret = reset_get_bulk(dev, >resets);
> + if (ret)
> + return ret;
> +
> + ret = clk_get_bulk(dev, >clocks);
> + if (ret)
> + return ret;
> +
> return 0;
> }
Re: [PATCH 8/8] sunxi: Parameterize H616 DRAM code some more
Dne sreda, 04. januar 2023 ob 01:38:12 CET je Andre Przywara napisal(a):
> On Sun, 11 Dec 2022 17:32:13 +0100
>
> Jernej Skrabec wrote:
> > Part of the code, previously known as "unknown feature" also doesn't
> > have constant values. They are derived from TPR0 parameter in vendor
> > DRAM code. Introduce that parameter here too, to ease adding new boards.
>
> That seems to also miss the value for the OPi Zero2 defconfig.
Again, Zero2 doesn't use all features.
>
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 1 +
> > arch/arm/mach-sunxi/Kconfig | 6
> > arch/arm/mach-sunxi/dram_sun50i_h616.c| 35 +++
> > 3 files changed, 35 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> > c7890c83391f..ff736bd88d10 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -158,6 +158,7 @@ struct dram_para {
> >
> > u32 dx_dri;
> > u32 ca_dri;
> > u32 odt_en;
> >
> > + u32 tpr0;
> >
> > u32 tpr10;
> > u32 tpr11;
> > u32 tpr12;
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index b050f0a56971..7858a7045f7e 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -73,6 +73,12 @@ config DRAM_SUN50I_H616_ODT_EN
> >
> > help
> >
> > ODT EN value from vendor DRAM settings.
> >
> > +config DRAM_SUN50I_H616_TPR0
> > + hex "H616 DRAM TPR0 parameter"
> > + default 0x0
>
> Is 0x0 really a feasible default value? I'd suggest we don't provide a
> default, so force people to be prompted for a value, if nothing is in
> (a new board's) defconfig.
This is not used on all boards, so imo is ok to have it as default.
Best regards,
Jernej
>
> The rest looks OK, though I can't really comment on the actual bits -
> but who can anyway ;-)
>
> Cheers,
> Andre
>
> > + help
> > + TPR0 value from vendor DRAM settings.
> > +
> >
> > config DRAM_SUN50I_H616_TPR10
> >
> > hex "H616 DRAM TPR10 parameter"
> > help
> >
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > b/arch/arm/mach-sunxi/dram_sun50i_h616.c index df06cea42464..6d8f8d371bfe
> > 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > @@ -808,15 +808,35 @@ static bool mctl_phy_init(struct dram_para *para)
> >
> > writel(phy_init[i], [i]);
> >
> > if (para->tpr10 & TPR10_UNKNOWN_FEAT0) {
> >
> > + if (para->tpr0 & BIT(30))
> > + val = (para->tpr0 >> 7) & 0x3e;
> > + else
> > + val = (para->tpr10 >> 3) & 0x1e;
> > +
> >
> > ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x780);
> > for (i = 0; i < 32; i++)
> >
> > - writel(0x16, [i]);
> > - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x78c);
> > - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> > - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> > - writel(0x8, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> > - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> > - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> > + writel(val, [i]);
> > +
> > + val = (para->tpr10 << 1) & 0x1e;
> > + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> > + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> > +
> > + /* following configuration is DDR3 specific */
> > + val = (para->tpr10 >> 7) & 0x1e;
> > + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> > + /*
> > +* TODO: Offsets 0x79c, 0x794 and 0x7e4 may need
> > +* to be set here. However, this doesn't seem to
> > +* be needed by any board seen in the wild for now.
> > +* It's not implemented because it would unnecessarily
> > +* introduce PARA2 and TPR2 options.
> > +*/
> > + if (para->tpr0 & BIT(31)) {
> > + val = (para->tpr0 << 1) & 0x3e;
> > + writel(val, SUNXI_DRAM_PHY0_BASE + 0x78c);
> > + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> > + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> > + }
> >
> > }
> >
> > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x3dc);
> >
> > @@ -1110,6 +1130,7 @@ unsigned long sunxi_dram_init(void)
> >
> > .dx_dri = CONFIG_DRAM_SUN50I_H616_DX_DRI,
> > .ca_dri = CONFIG_DRAM_SUN50I_H616_CA_DRI,
> > .odt_en = CONFIG_DRAM_SUN50I_H616_ODT_EN,
> >
> > + .tpr0 = CONFIG_DRAM_SUN50I_H616_TPR0,
> >
> > .tpr10 = CONFIG_DRAM_SUN50I_H616_TPR10,
> > .tpr11 = CONFIG_DRAM_SUN50I_H616_TPR11,
> > .tpr12 = CONFIG_DRAM_SUN50I_H616_TPR12,
Re: [PATCH 7/8] sunxi: Parameterize bit delay code in H616 DRAM driver
Dne sreda, 04. januar 2023 ob 01:37:47 CET je Andre Przywara napisal(a):
> On Sun, 11 Dec 2022 17:32:12 +0100
> Jernej Skrabec wrote:
>
> Hi Jernej,
>
> > These values are highly board specific and thus make sense to add
> > parameter for them. To ease adding support for new boards, let's make
> > them same as in vendor DRAM settings.
>
> So scrolling up and down: does this patch miss the TPR11 and TPR12
> values in the OPi-Zero2 defconfig?
No, because 0 (which is default) is correct here.
> And should we not default to 0 in
> Kconfig to help spotting this omission more easily for new boards?
Not all boards need to set all the values. I set default values for symbols
which seem to have same value for multiple boards.
> If I pieced the bits together correctly, we end up with the same values
> in the register with TPR11=0xfffedddb and TPR12=0xeddca998, and ODT_EN
> being irrelevant.
>
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 4 +
> > arch/arm/mach-sunxi/Kconfig | 18 ++
> > arch/arm/mach-sunxi/dram_sun50i_h616.c| 189 +-
> > 3 files changed, 162 insertions(+), 49 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> > b5140c79b70e..c7890c83391f 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -145,6 +145,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> >
> > #define TPR10_READ_CALIBRATION BIT(21)
> > #define TPR10_READ_TRAININGBIT(22)
> > #define TPR10_WRITE_TRAINING BIT(23)
> >
> > +#define TPR10_UNKNOWN_FEAT3BIT(30)
>
> As mentioned in the other patch: if we don't know the meaning of this
> bit, I'd prefer using BIT(30) directly, or at least encode BIT30
> in the name.
>
> > struct dram_para {
> >
> > u32 clk;
> >
> > @@ -156,7 +157,10 @@ struct dram_para {
> >
> > u32 dx_odt;
> > u32 dx_dri;
> > u32 ca_dri;
> >
> > + u32 odt_en;
> >
> > u32 tpr10;
> >
> > + u32 tpr11;
> > + u32 tpr12;
> >
> > };
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 778304b77e26..b050f0a56971 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -67,11 +67,29 @@ config DRAM_SUN50I_H616_CA_DRI
> >
> > help
> >
> > CA DRI value from vendor DRAM settings.
> >
> > +config DRAM_SUN50I_H616_ODT_EN
> > + hex "H616 DRAM ODT EN parameter"
> > + default 0x1
> > + help
> > + ODT EN value from vendor DRAM settings.
> > +
> >
> > config DRAM_SUN50I_H616_TPR10
> >
> > hex "H616 DRAM TPR10 parameter"
> > help
> >
> > TPR10 value from vendor DRAM settings. It tells which features
> > should be configured, like write leveling, read calibration,
etc.
> >
> > +
> > +config DRAM_SUN50I_H616_TPR11
> > + hex "H616 DRAM TPR11 parameter"
> > + default 0x0
> > + help
> > + TPR11 value from vendor DRAM settings.
> > +
> > +config DRAM_SUN50I_H616_TPR12
> > + hex "H616 DRAM TPR12 parameter"
> > + default 0x0
> > + help
> > + TPR12 value from vendor DRAM settings.
> >
> > endif
> >
> > config SUN6I_PRCM
> >
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > b/arch/arm/mach-sunxi/dram_sun50i_h616.c index 3b2ba168498c..df06cea42464
> > 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > @@ -574,7 +574,7 @@ static bool mctl_phy_write_training(struct dram_para
> > *para)>
> > static void mctl_phy_bit_delay_compensation(struct dram_para *para)
> > {
> >
> > - u32 *ptr;
> > + u32 *ptr, val;
> >
> > int i;
> >
> > if (para->tpr10 & TPR10_UNKNOWN_FEAT2) {
> >
> > @@ -582,49 +582,93 @@ static void mctl_phy_bit_delay_compensation(struct
> > dram_para *para)>
> > setbits_le32(SUNXI_DRAM_PHY0_BASE + 8, 8);
> > clrbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 0x10);
> >
> > + if (para->tpr10 & TPR10_UNKNOWN_FEAT3)
> > + val = para->tpr11 & 0x3f;
> > + else
> > + val = (para->tpr11 & 0xf) << 1;
> > +
> >
> > ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x484);
> > for (i = 0; i < 9; i++) {
> >
> > - writel_relaxed(0x16, ptr);
> > - writel_relaxed(0x16, ptr + 0x30);
> > + writel_relaxed(val, ptr);
> > + writel_relaxed(val, ptr + 0x30);
> >
> > ptr += 2;
> >
> > }
> >
> > - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x4d0);
> > - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x590);
> > - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x4cc);
> > - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x58c);
> > +
>
Re: [PATCH 5/8] sunxi: Always configure ODT on H616 DRAM
Dne sreda, 04. januar 2023 ob 01:37:17 CET je Andre Przywara napisal(a): > On Sun, 11 Dec 2022 17:32:10 +0100 > > Jernej Skrabec wrote: > > Vendor H616 DRAM code always configure part which we call ODT > > configuration. Let's reflect that here too. > > I wonder if we need this patch at all. "depends on !H616" looks > counter-intuitive, since this suggests it's always off. I don't see it that way. It just means it's unused for H616. > As it stands, it doesn't hurt. "default y" does the right thing, and if > people want to shoot themselves in the foot: fine by me. > > At least I would like to keep the Kconfig part. We could change the > condition in the code into an explaining comment, if you still want to > force this on. > > And coming back from patch 7/8: how does this correspond to > DRAM_SUN50I_H616_ODT_EN? The thing is that I can't give you good explanation for anything above due to nature of reverse engineering. It's just how vendor code is done and I would argue that my original assumption when I was writing this driver was wrong and I shouldn't use this symbol at all in first place. I'm not even sure if I named mctl_phy_configure_odt() completely correct. It has to do something with ODT, but I don't know if it gets enabled here or not. To me, it looks more like that just some parameters are set here. Best regards, Jernej > > Cheers, > Andre > > > Signed-off-by: Jernej Skrabec > > --- > > > > arch/arm/mach-sunxi/Kconfig| 2 +- > > arch/arm/mach-sunxi/dram_sun50i_h616.c | 3 +-- > > 2 files changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > > index abcbd0fb9061..778304b77e26 100644 > > --- a/arch/arm/mach-sunxi/Kconfig > > +++ b/arch/arm/mach-sunxi/Kconfig > > @@ -488,12 +488,12 @@ config DRAM_ZQ > > > > config DRAM_ODT_EN > > > > bool "sunxi dram odt enable" > > > > + depends on !MACH_SUN50I_H616 > > > > default y if MACH_SUN8I_A23 > > default y if MACH_SUNXI_H3_H5 > > default y if MACH_SUN8I_R40 > > default y if MACH_SUN50I > > default y if MACH_SUN50I_H6 > > > > - default y if MACH_SUN50I_H616 > > > > ---help--- > > Select this to enable dram odt (on die termination). > > > > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c > > b/arch/arm/mach-sunxi/dram_sun50i_h616.c index 14a01a3c4e54..bf5b4ddfb5c2 > > 100644 > > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c > > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c > > @@ -736,8 +736,7 @@ static bool mctl_phy_init(struct dram_para *para) > > > > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x3dc); > > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x45c); > > > > - if (IS_ENABLED(CONFIG_DRAM_ODT_EN)) > > - mctl_phy_configure_odt(para); > > + mctl_phy_configure_odt(para); > > > > clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 4, 7, 0xa);
Re: [PATCH 0/8] sunxi: Update H616 DRAM driver
Hi Andre! Dne sreda, 04. januar 2023 ob 01:47:16 CET je Andre Przywara napisal(a): > On Sun, 11 Dec 2022 17:32:05 +0100 > Jernej Skrabec wrote: > > Hi Jernej, > > > Current H616 DRAM driver is completely customized to Orange Pi Zero2 > > board, which is currently the only H616 board supported by U-Boot. > > Needless to say, this is not ideal for adding new boards. With changes > > in this series, all DDR3 boards are supported and all that is needed is > > just vendor DRAM values extracted from Android image. New DRAM types > > should also be easier to support, since a lot of constants used before > > are not really DRAM type dependent. > > > > Changes were verified by decompiling driver and generated values were > > compared to previous, hard coded ones. This was done without dram_para > > structures, so compiler was able to heavily optimize code and produce > > constants. > > so many thanks again for putting this together! > I came to like (the idea of) this series very much lately, as this > removes timing/delay values from the code, and easily allows putting the > vendor provided values in the defconfig. > I used that approach as well for the D1 driver, and am wondering if we > should extend this to other SoCs, potentially unifying the Kconfig part? While it would be nice, I'm not sure it's worth the effort and there is a chance that something might break during rework. > > And you hinted at a v2, can you provide an estimate for this? If you > send it still this week, I would like to put it into U-Boot's next > branch, otherwise it goes straight into master, should the merge window > open next week as planned. I have changes for v2 in my github repo. I don't have any estimation, since I had some time off from programming lately and I'm just only catching up. Weekend at earliest, but no promises. > > Btw., to verify the feasibility of drivers/ram/sunxi, I moved the H616 > driver into there, together with the Kconfig parts, I wonder what you > think about this? An example of how this looks is in the D1 driver > patches. Looks good, but I don't know what are implications regarding interface. Is just code move or that implies that some ram framework must be used? Best regards, Jernej > > Cheers, > Andre > > > Please take a look. > > > > Best regards, > > Jernej > > > > Jernej Skrabec (8): > > sunxi: Fix write to H616 DRAM CR register > > sunxi: cosmetic: Fix H616 DRAM driver code style > > sunxi: parameterize H616 DRAM ODT values > > sunxi: Convert H616 DRAM options to single setting > > sunxi: Always configure ODT on H616 DRAM > > sunxi: Make bit delay function in H616 DRAM code void > > sunxi: Parameterize bit delay code in H616 DRAM driver > > sunxi: Parameterize H616 DRAM code some more > > > > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 18 + > > arch/arm/mach-sunxi/Kconfig | 67 +-- > > arch/arm/mach-sunxi/dram_sun50i_h616.c| 445 +++--- > > configs/orangepi_zero2_defconfig | 8 +- > > 4 files changed, 348 insertions(+), 190 deletions(-)
Re: [PATCH 4/8] sunxi: Convert H616 DRAM options to single setting
Dne torek, 13. december 2022 ob 17:51:35 CET je Andre Przywara napisal(a): > On Tue, 13 Dec 2022 17:23:12 +0100 > > Jernej Škrabec wrote: > > Hi, > > > > Dne ponedeljek, 12. december 2022 ob 18:50:44 CET je Andre Przywara > > > > napisal(a): > > > On Sun, 11 Dec 2022 17:32:09 +0100 > > > Jernej Skrabec wrote: > > > > > > Hi, > > > > > > > Vendor DRAM settings use TPR10 parameter to enable various features. > > > > There are many mores features that just those that are currently > > > > mentioned. Since new will be added later and most are not known, let's > > > > reuse value from vendor DRAM driver as-is. This will also help adding > > > > support for new boards. > > > > > > Looks good. I checked that the actual code in > > > mctl_phy_bit_delay_compensation() just gets indented (no real changes), > > > and > > > is now guarded by the new checks. > > > The values in the _defconfig still result in the same decisions, though > > > many are blocked anyway by no one actually calling that bit_delay > > > function > > > at all. (I wonder what happens when we enable it?) > > > > I'm not sure I understand. Bit delay compensation should be enabled for > > X96 > > Mate, according to values you send in previous e-mail. > > But DRAM_SUN50I_H616_BIT_DELAY_COMPENSATION is not set by any (of the two) > defconfigs atm, and I don't see this in your t95 (WIP?) branch on github > either. So that whole code was completely unused (until now). Hm, I remember writing this code for T95, but I'm not sure why it's not enabled in defconfig. I'm sure values are ok and match vendor driver. It's interesting to see how some parts of initialization procedure have some wiggle room and still appear to be stable. > > > In any case, DRAM > > configuration looks like a black magic at times, so I would rather stick > > to > > vendor procedure, especially due to missing register documentation, and > > not > > just randomly enable things which sounds nice. I tried enabling unused > > procedures for T95 and either they didn't went through or amount of > > detected RAM was lower than presetn. > > Sure, I was just confused that we have some elaborate code, with values > backed by the vendor BSP, but then don't use that. But if it gets used > now, it's all fine, I guess. Great! Best regards, Jernej > > > > One small thing below. > > > > > > > Signed-off-by: Jernej Skrabec > > > > --- > > > > > > > > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 10 + > > > > arch/arm/mach-sunxi/Kconfig | 38 +--- > > > > arch/arm/mach-sunxi/dram_sun50i_h616.c| 197 > > > > +- > > > > configs/orangepi_zero2_defconfig | 5 +- > > > > 4 files changed, 117 insertions(+), 133 deletions(-) > > > > > > > > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h > > > > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index > > > > c9e1f84bfcdd..b5140c79b70e 100644 > > > > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h > > > > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h > > > > @@ -137,6 +137,15 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, > > > > 0x4240); > > > > > > > > #define MSTR_ACTIVE_RANKS(x) (((x == 2) ? 3 : 1) << 24) > > > > #define MSTR_BURST_LENGTH(x) (((x) >> 1) << 16) > > > > > > > > +/* TODO: figure out what unknown features do */ > > > > +#define TPR10_UNKNOWN_FEAT0BIT(16) > > > > +#define TPR10_UNKNOWN_FEAT1BIT(17) > > > > +#define TPR10_UNKNOWN_FEAT2BIT(18) > > > > > > Could you just put the bit number in the macro? Like TPR10_BIT16? That > > > both avoids inventing meaningless names, and helps readers to correlate > > > code more easily. Or skip the symbol altogether for those and use just > > > "BIT(16)" in the code. > > > > I actually know what these are for now, so I can give much better names. > > However, I still don't know what TPR10_UNKNOWN_FEAT3 does, which is in the > > last commit, so I'll rework that one to use BIT(30) directly. > > Great, thanks! > > Cheers, > Andre > > > Best regards, > > Jernej > > > > > Cheers, > > > Andre > > > > > > > +#define TPR10_WRITE_LEVELING BIT(20) >
Re: [PATCH 4/8] sunxi: Convert H616 DRAM options to single setting
Hi,
Dne ponedeljek, 12. december 2022 ob 18:50:44 CET je Andre Przywara
napisal(a):
> On Sun, 11 Dec 2022 17:32:09 +0100
> Jernej Skrabec wrote:
>
> Hi,
>
> > Vendor DRAM settings use TPR10 parameter to enable various features.
> > There are many mores features that just those that are currently
> > mentioned. Since new will be added later and most are not known, let's
> > reuse value from vendor DRAM driver as-is. This will also help adding
> > support for new boards.
>
> Looks good. I checked that the actual code in
> mctl_phy_bit_delay_compensation() just gets indented (no real changes), and
> is now guarded by the new checks.
> The values in the _defconfig still result in the same decisions, though
> many are blocked anyway by no one actually calling that bit_delay function
> at all. (I wonder what happens when we enable it?)
I'm not sure I understand. Bit delay compensation should be enabled for X96
Mate, according to values you send in previous e-mail. In any case, DRAM
configuration looks like a black magic at times, so I would rather stick to
vendor procedure, especially due to missing register documentation, and not
just randomly enable things which sounds nice. I tried enabling unused
procedures for T95 and either they didn't went through or amount of detected
RAM was lower than presetn.
> One small thing below.
>
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 10 +
> > arch/arm/mach-sunxi/Kconfig | 38 +---
> > arch/arm/mach-sunxi/dram_sun50i_h616.c| 197 +-
> > configs/orangepi_zero2_defconfig | 5 +-
> > 4 files changed, 117 insertions(+), 133 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index
> > c9e1f84bfcdd..b5140c79b70e 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -137,6 +137,15 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> >
> > #define MSTR_ACTIVE_RANKS(x) (((x == 2) ? 3 : 1) << 24)
> > #define MSTR_BURST_LENGTH(x) (((x) >> 1) << 16)
> >
> > +/* TODO: figure out what unknown features do */
> > +#define TPR10_UNKNOWN_FEAT0BIT(16)
> > +#define TPR10_UNKNOWN_FEAT1BIT(17)
> > +#define TPR10_UNKNOWN_FEAT2BIT(18)
>
> Could you just put the bit number in the macro? Like TPR10_BIT16? That
> both avoids inventing meaningless names, and helps readers to correlate
> code more easily. Or skip the symbol altogether for those and use just
> "BIT(16)" in the code.
I actually know what these are for now, so I can give much better names.
However, I still don't know what TPR10_UNKNOWN_FEAT3 does, which is in the
last commit, so I'll rework that one to use BIT(30) directly.
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > +#define TPR10_WRITE_LEVELING BIT(20)
> > +#define TPR10_READ_CALIBRATION BIT(21)
> > +#define TPR10_READ_TRAININGBIT(22)
> > +#define TPR10_WRITE_TRAINING BIT(23)
> > +
> >
> > struct dram_para {
> >
> > u32 clk;
> > enum sunxi_dram_type type;
> >
> > @@ -147,6 +156,7 @@ struct dram_para {
> >
> > u32 dx_odt;
> > u32 dx_dri;
> > u32 ca_dri;
> >
> > + u32 tpr10;
> >
> > };
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index cad53f19912c..abcbd0fb9061 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -52,38 +52,6 @@ config DRAM_SUN50I_H616
> >
> > like H616.
> >
> > if DRAM_SUN50I_H616
> >
> > -config DRAM_SUN50I_H616_WRITE_LEVELING
> > - bool "H616 DRAM write leveling"
> > - ---help---
> > - Select this when DRAM on your H616 board needs write leveling.
> > -
> > -config DRAM_SUN50I_H616_READ_CALIBRATION
> > - bool "H616 DRAM read calibration"
> > - ---help---
> > - Select this when DRAM on your H616 board needs read
calibration.
> > -
> > -config DRAM_SUN50I_H616_READ_TRAINING
> > - bool "H616 DRAM read training"
> > - ---help---
> > - Select this when DRAM on your H616 board needs read training.
> > -
> > -config DRAM_SUN50I_H616_WRITE_TRAINING
> > - bool "H616 DRAM write training"
> > - ---help---
> > - Select this when DRAM on your H616 board needs write training.
> > -
> > -config DRAM_SUN50I_H616_BIT_DELAY_COMPENSATION
> > - bool "H616 DRAM bit delay compensation"
> > - ---help---
> > - Select this when DRAM on your H616 board needs bit delay
> > - compensation.
> > -
> > -config DRAM_SUN50I_H616_UNKNOWN_FEATURE
> > - bool "H616 DRAM unknown feature"
> > - ---help---
> > - Select this when DRAM on your H616 board needs this unknown
> > - feature.
> > -
> >
> > config DRAM_SUN50I_H616_DX_ODT
> >
> > hex "H616 DRAM DX ODT parameter"
> > help
> >
> > @@ -98,6 +66,12 @@ config DRAM_SUN50I_H616_CA_DRI
> >
>
Re: [PATCH 0/8] sunxi: Update H616 DRAM driver
Hi Andre, Dne ponedeljek, 12. december 2022 ob 02:04:51 CET je Andre Przywara napisal(a): > On Sun, 11 Dec 2022 17:32:05 +0100 > Jernej Skrabec wrote: > > Hi Jernej, > > many thanks for putting this together! > I will have a more elaborate look at each patch later. > > > Current H616 DRAM driver is completely customized to Orange Pi Zero2 > > board, which is currently the only H616 board supported by U-Boot. > > Not anymore, I merged the X96 Mate support lately, after the DT got > merged into the Linux tree. Right. First part of sentence is still true, although I later remembered that some values are based on T95 values, those that are not used by Orange Pi Zero2. > > Those are the values for the box I came up with: > CONFIG_DRAM_SUN50I_H616_DX_ODT=0x03030303 > CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e > CONFIG_DRAM_SUN50I_H616_CA_DRI=0x1c12 > CONFIG_DRAM_SUN50I_H616_TPR0=0xcc05 > CONFIG_DRAM_SUN50I_H616_TPR10=0x2f0007 > CONFIG_DRAM_SUN50I_H616_TPR11=0x > CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7557 > > based on this boot0 found in some firmware update image: > 00045400 be 02 00 ea 65 47 4f 4e 2e 42 54 30 cc ba f3 80 > |eGON.BT0| 00045410 00 c0 00 00 30 00 00 00 00 00 00 00 00 00 02 > 00 |0...| 00045420 00 00 02 00 00 00 00 00 00 00 00 00 34 2e > 30 00 |4.0.| 00045430 00 00 00 00 03 00 00 00 88 02 00 00 03 > 00 00 00 || 00045440 03 03 03 03 0e 0e 0e 0e 12 1c 00 00 > 01 00 00 00 || 00045450 fb 30 00 00 00 00 00 00 40 08 00 > 00 04 00 00 00 |.0..@...| 00045460 08 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 || 00045470 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 || 00045480 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 || 00045490 05 0c 00 c0 00 00 00 > 00 00 00 00 00 00 00 00 00 || 000454a0 80 80 80 33 07 00 > 2f 00 dd dd ff ff 57 75 df fe |...3../.Wu..| 000454b0 40 00 00 00 00 > 00 00 00 00 00 00 00 08 00 02 01 |@...| > > I would be grateful if you could verify this. Looks correct. I'll use them in my v2 patches. > > I built it, and it reported the 4GB correctly, also managed to boot into > Linux just fine. No extensive testing, nor didn't I compare register > dumps or disassembly (yet). > > Cheers, > Andre > > P.S. Any plans on upstreaming support for your T95 H616 TV > box? That would probably help the case here. Not really, X96 Mate is basically the same as T95, except DRAM configuration. As I said, I verified that these patches provide same register values as before. This includes those which were modeled after T95 DRAM values. Best regards, Jernej > > > Needless to say, this is not ideal for adding new boards. With changes > > in this series, all DDR3 boards are supported and all that is needed is > > just vendor DRAM values extracted from Android image. New DRAM types > > should also be easier to support, since a lot of constants used before > > are not really DRAM type dependent. > > > > Changes were verified by decompiling driver and generated values were > > compared to previous, hard coded ones. This was done without dram_para > > structures, so compiler was able to heavily optimize code and produce > > constants. > > > > Please take a look. > > > > Best regards, > > Jernej > > > > Jernej Skrabec (8): > > sunxi: Fix write to H616 DRAM CR register > > sunxi: cosmetic: Fix H616 DRAM driver code style > > sunxi: parameterize H616 DRAM ODT values > > sunxi: Convert H616 DRAM options to single setting > > sunxi: Always configure ODT on H616 DRAM > > sunxi: Make bit delay function in H616 DRAM code void > > sunxi: Parameterize bit delay code in H616 DRAM driver > > sunxi: Parameterize H616 DRAM code some more > > > > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 18 + > > arch/arm/mach-sunxi/Kconfig | 67 +-- > > arch/arm/mach-sunxi/dram_sun50i_h616.c| 445 +++--- > > configs/orangepi_zero2_defconfig | 8 +- > > 4 files changed, 348 insertions(+), 190 deletions(-)
Re: [PATCH 8/8] sunxi: Parameterize H616 DRAM code some more
Dne nedelja, 11. december 2022 ob 17:32:13 CET je Jernej Skrabec napisal(a):
> Part of the code, previously known as "unknown feature" also doesn't
> have constant values. They are derived from TPR0 parameter in vendor
> DRAM code. Introduce that parameter here too, to ease adding new boards.
>
> Signed-off-by: Jernej Skrabec
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 1 +
> arch/arm/mach-sunxi/Kconfig | 6
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 35 +++
> 3 files changed, 35 insertions(+), 7 deletions(-)
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c index df06cea42464..6d8f8d371bfe
> 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -808,15 +808,35 @@ static bool mctl_phy_init(struct dram_para *para)
> writel(phy_init[i], [i]);
>
> if (para->tpr10 & TPR10_UNKNOWN_FEAT0) {
> + if (para->tpr0 & BIT(30))
> + val = (para->tpr0 >> 7) & 0x3e;
> + else
> + val = (para->tpr10 >> 3) & 0x1e;
> +
> ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x780);
> for (i = 0; i < 32; i++)
> - writel(0x16, [i]);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x78c);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> - writel(0x8, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> + writel(val, [i]);
> +
> + val = (para->tpr10 << 1) & 0x1e;
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> +
> + /* following configuration is DDR3 specific */
> + val = (para->tpr10 >> 7) & 0x1e;
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> + /*
> + * TODO: Offsets 0x79c, 0x794 and 0x7e4 may need
> + * to be set here. However, this doesn't seem to
> + * be needed by any board seen in the wild for now.
> + * It's not implemented because it would unnecessarily
> + * introduce PARA2 and TPR2 options.
> + */
I just noticed that PARA2 check actually checks rank. I think it's important
to implement it (register 0x79c) and uses only TPR10 value, which is already
present.
Best regards,
Jernej
> + if (para->tpr0 & BIT(31)) {
> + val = (para->tpr0 << 1) & 0x3e;
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x78c);
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> + }
> }
>
> writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x3dc);
Re: [PATCH] sunxi: define SYS_MONITOR_LEN in Kconfig, not _defconfig
Dne sreda, 23. november 2022 ob 23:51:17 CET je Andre Przywara napisal(a):
> Commit 08574ed339fb ("Convert CONFIG_SYS_MONITOR_LEN to Kconfig") moved
> the definition of said config variable from the common sunxi header to
> *every board's* defconfig.
> This is a platform choice, not board specific, so remove the variable
> from there, instead set the one value for all Allwinner boards in
> Kconfig.
>
> Signed-off-by: Andre Przywara
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 0/5] video: sunxi: dw-hdmi: Partial OF conversion
Hi Samuel! Dne ponedeljek, 28. november 2022 ob 08:02:23 CET je Samuel Holland napisal(a): > This series starts converting the DE2 video driver to use devicetree for > MMIO addresses and clock/reset/regulator consumers. This is necessary > for adding new SoC support (H6, D1, etc.) and will also be helpful when > adding DSI output support. > > I picked up a couple of patches from Jernej's branch and added a couple > on top. Specifically, the regulator consumer uses the AXP regulator > driver[1] (when enabled) to stop relying on TF-A. > > I tested this series on a Pine A64 LTS board. > > [1]: > https://patchwork.ozlabs.org/project/uboot/cover/20221128064757.2933-1-samu > e...@sholland.org/ > > > Jernej Skrabec (2): > video: sunxi: dw-hdmi: Probe driver by compatible > video: sunxi: dw-hdmi: Read address from DT node > > Samuel Holland (3): > clk: sunxi: Add DE2 display-related clocks/resets > video: sunxi: dw-hdmi: Use DM for clock gates and resets > video: sunxi: dw-hdmi: Use DM for HVCC regulator Thanks for working on this! Whole series is Reviewed-by: Jernej Skrabec Best regards, Jernej > > drivers/clk/sunxi/clk_a64.c | 22 > drivers/clk/sunxi/clk_a83t.c| 22 > drivers/clk/sunxi/clk_h3.c | 17 ++ > drivers/clk/sunxi/clk_h6.c | 21 +++ > drivers/clk/sunxi/clk_h616.c| 21 +++ > drivers/clk/sunxi/clk_r40.c | 29 ++ > drivers/clk/sunxi/clk_v3s.c | 9 +++ > drivers/video/sunxi/sunxi_dw_hdmi.c | 87 +++-- > 8 files changed, 200 insertions(+), 28 deletions(-)
Re: [PATCH 4/6] sunxi: f1c100: add UART1 support
Dne torek, 18. oktober 2022 ob 11:23:41 CEST je Andre Przywara napisal(a):
> On 12/10/2022 22:42, Jernej Škrabec wrote:
>
> Hi Jernej,
>
> many thanks for the review of this series, that's much appreciated!
>
> > Dne sreda, 12. oktober 2022 ob 18:34:56 CEST je Andre Przywara napisal(a):
> >> Some boards use UART1 for its debug UART, so define the pins for the SPL
> >> and the pinmux name and mux value for U-Boot proper.
> >>
> >> Signed-off-by: Andre Przywara
> >> ---
> >>
> >> arch/arm/mach-sunxi/board.c | 4
> >> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 +
> >> 2 files changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> >> index 62bb40b8c89..77216157908 100644
> >> --- a/arch/arm/mach-sunxi/board.c
> >> +++ b/arch/arm/mach-sunxi/board.c
> >> @@ -147,6 +147,10 @@ static int gpio_init(void)
> >>
> >>sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
> >>sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
> >>sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP);
> >>
> >> +#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV)
> >> + sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0);
> >> + sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0);
> >> + sunxi_gpio_set_pull(SUNXI_GPA(3), SUNXI_GPIO_PULL_UP);
> >>
> >> #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
> >>
> >>sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1);
> >>sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG_UART1);
> >>
> >> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index 9ce2bc1b3af..061104be056
> >> 100644
> >> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> @@ -245,6 +245,7 @@ static const struct sunxi_pinctrl_function
> >> suniv_f1c100s_pinctrl_functions[] = { #else
> >>
> >>{ "uart0", 5 },/* PE0-PE1 */
> >>
> >> #endif
> >>
> >> + { "uart1", 5 },/* PA0-PA3 */
> >
> > Comment should be PA2-PA3. With that fixed:
> Well, PA0 and PA1 are RTS and CTS for UART1, so if you don't mind, I
> will keep it like this. Not that the comment really matters anyway ;-)
Ok.
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > Reviewed-by: Jernej Skrabec
> >
> > Best regards,
> > Jernej
> >
> >> };
> >>
> >> static const struct sunxi_pinctrl_desc __maybe_unused
> >>
> >> suniv_f1c100s_pinctrl_desc = { --
> >> 2.25.1
Re: Re: [PATCH 0/2] sunxi: update devicetree files from the kernel
Dne ponedeljek, 26. september 2022 ob 12:34:38 CEST je Andre Przywara napisal(a): > On Wed, 14 Sep 2022 00:40:02 +0100 > Andre Przywara wrote: > > Hi, > > can someone please have a look and confirm that this is legit? Could be as > easy as just diff'ing against what's in the kernel tree and checking that > the differences are just due to the r_intc change. > > I would like to push the DT update still into the release, so that we live > up to the promise of providing a good experience with $fdtcontroladdr. I checked that all files are either equal or have r_int difference. FWIW: Reviewed-by: Jernej Skrabec Best regards, Jernej > > Cheers, > Andre > > > This syncs the .dts and .dtsi files from the Linux kernel repository > > as of v6.0-rc4 into U-Boot. As before, we skip the r_intc change, as > > this breaks older kernels. > > The first patch handles the 64-bit parts, the second one the 32-bit > > SoCs. > > > > Thanks, > > Andre > > > > Andre Przywara (2): > > sunxi: dts: arm64: update devicetree files > > sunxi: dts: arm: update devicetree files > > > > arch/arm/dts/Makefile | 3 +- > > arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 40 +-- > > arch/arm/dts/sun4i-a10-pcduino.dts| 6 +- > > arch/arm/dts/sun50i-a64-amarula-relic.dts | 2 +- > > arch/arm/dts/sun50i-a64-bananapi-m64.dts | 4 +- > > arch/arm/dts/sun50i-a64-nanopi-a64.dts| 2 +- > > arch/arm/dts/sun50i-a64-olinuxino.dts | 30 ++ > > arch/arm/dts/sun50i-a64-orangepi-win.dts | 6 +- > > arch/arm/dts/sun50i-a64-pinebook.dts | 4 +- > > arch/arm/dts/sun50i-a64-pinephone-1.0.dts | 4 + > > arch/arm/dts/sun50i-a64-pinephone-1.1.dts | 4 + > > arch/arm/dts/sun50i-a64-teres-i.dts | 8 + > > arch/arm/dts/sun50i-a64.dtsi | 10 +- > > arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts | 4 +- > > arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 4 +- > > arch/arm/dts/sun50i-h5-orangepi-prime.dts | 4 +- > > arch/arm/dts/sun50i-h6-orangepi-3.dts | 4 +- > > arch/arm/dts/sun50i-h6-orangepi-lite2.dts | 4 +- > > arch/arm/dts/sun50i-h6-tanix.dtsi | 2 +- > > arch/arm/dts/sun50i-h6.dtsi | 12 +- > > arch/arm/dts/sun50i-h616-orangepi-zero2.dts | 55 +--- > > arch/arm/dts/sun50i-h616-x96-mate.dts | 177 +++ > > arch/arm/dts/sun50i-h616.dtsi | 286 +- > > arch/arm/dts/sun5i-a13-licheepi-one.dts | 6 +- > > arch/arm/dts/sun6i-a31.dtsi | 13 +- > > arch/arm/dts/sun7i-a20-pcduino3.dts | 6 +- > > arch/arm/dts/sun8i-a23-a33.dtsi | 9 +- > > arch/arm/dts/sun8i-a23-ippo-q8h-v1.2.dts | 74 + > > arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts| 74 + > > arch/arm/dts/sun8i-a33-et-q8-v1.6.dts | 58 +--- > > arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts | 58 +--- > > .../dts/sun8i-h2-plus-bananapi-m2-zero.dts| 8 +- > > arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 2 +- > > arch/arm/dts/sun8i-h3-beelink-x2.dts | 6 +- > > arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 6 +- > > arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 8 +- > > arch/arm/dts/sun8i-h3-nanopi-neo-air.dts | 2 +- > > arch/arm/dts/sun8i-h3-nanopi-r1.dts | 4 +- > > arch/arm/dts/sun8i-h3-nanopi.dtsi | 5 +- > > arch/arm/dts/sun8i-h3-orangepi-2.dts | 6 +- > > arch/arm/dts/sun8i-h3-orangepi-lite.dts | 4 +- > > arch/arm/dts/sun8i-h3-orangepi-one.dts| 4 +- > > arch/arm/dts/sun8i-h3-orangepi-pc.dts | 4 +- > > arch/arm/dts/sun8i-r16-bananapi-m2m.dts | 4 +- > > arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts | 5 + > > arch/arm/dts/sun8i-r40-cpu-opp.dtsi | 52 > > arch/arm/dts/sun8i-r40-feta40i.dtsi | 5 + > > arch/arm/dts/sun8i-r40.dtsi | 44 ++- > > arch/arm/dts/sun8i-t3-cqa3t-bv3.dts | 5 + > > arch/arm/dts/sun8i-v3s.dtsi | 6 +- > > arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts | 5 + > > arch/arm/dts/sun9i-a80.dtsi | 1 - > > arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 8 +- > > arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 4 +- > > arch/arm/dts/sunxi-h3-h5.dtsi | 13 +- > > arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi | 4 +- > > include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 + > > include/dt-bindings/clock/sun50i-h616-ccu.h | 1 + > > include/dt-bindings/clock/sun6i-rtc.h | 10 + > > 59 files changed, 562 insertions(+), 638 deletions(-) > > create mode 100644 arch/arm/dts/sun50i-h616-x96-mate.dts > > mode change 100644 => 12 arch/arm/dts/sun8i-a23-ippo-q8h-v1.2.dts > > mode change 100644 => 12 arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts > > mode change 100644 => 12 arch/arm/dts/sun8i-a33-et-q8-v1.6.dts >
Re: [PATCH 5/6] sunxi: f1c100: dtsi: add UART1 pins
Hi Andre,
Dne sreda, 12. oktober 2022 ob 18:34:57 CEST je Andre Przywara napisal(a):
> The F1Cx00 SoCs connect the first PortA pins to UART1.
>
> Add this to the SoC .dtsi, so boards can reference UART1 pins.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> arch/arm/dts/suniv-f1c100s.dtsi | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/dts/suniv-f1c100s.dtsi
> b/arch/arm/dts/suniv-f1c100s.dtsi index 0edc1724407..bc563c12e95 100644
> --- a/arch/arm/dts/suniv-f1c100s.dtsi
> +++ b/arch/arm/dts/suniv-f1c100s.dtsi
> @@ -175,6 +175,11 @@
> pins = "PE0", "PE1";
> function = "uart0";
> };
> +
> + uart1_pa_pins: uart1-pa-pins {
> + pins = "PA2", "PA3";
> + function = "uart1";
> + };
> };
>
> timer@1c20c00 {
> --
> 2.25.1
Re: [PATCH 4/6] sunxi: f1c100: add UART1 support
Hi Andre,
Dne sreda, 12. oktober 2022 ob 18:34:56 CEST je Andre Przywara napisal(a):
> Some boards use UART1 for its debug UART, so define the pins for the SPL
> and the pinmux name and mux value for U-Boot proper.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/mach-sunxi/board.c | 4
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 62bb40b8c89..77216157908 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -147,6 +147,10 @@ static int gpio_init(void)
> sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
> sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
> sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP);
> +#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV)
> + sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0);
> + sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0);
> + sunxi_gpio_set_pull(SUNXI_GPA(3), SUNXI_GPIO_PULL_UP);
> #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
> sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1);
> sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG_UART1);
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index 9ce2bc1b3af..061104be056
> 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -245,6 +245,7 @@ static const struct sunxi_pinctrl_function
> suniv_f1c100s_pinctrl_functions[] = { #else
> { "uart0", 5 },/* PE0-PE1 */
> #endif
> + { "uart1", 5 },/* PA0-PA3 */
Comment should be PA2-PA3. With that fixed:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> };
>
> static const struct sunxi_pinctrl_desc __maybe_unused
> suniv_f1c100s_pinctrl_desc = { --
> 2.25.1
Re: [PATCH 3/6] sunxi: f1c100: move SKIP_LOWLEVEL_INIT_ONLY into Kconfig
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:34:55 CEST je Andre Przywara napisal(a): > So far we stated the lack of a lowlevel() init function for the F1C100s > board by defining the respective SKIP_* symbol in the board's > defconfig. However we don't expect any *board* to employ such low level > code, so expect this to be never used for the ARMv5 Allwinner SoCs. > > Select the appropriate symbols in the Kconfig, so that we can remove > them from the defconfig, and avoid putting them in future defconfigs for > other boards. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > arch/arm/mach-sunxi/Kconfig | 2 ++ > configs/licheepi_nano_defconfig | 2 -- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 9aa66deb9fd..fc5d8bb3c19 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -185,6 +185,8 @@ config MACH_SUNIV > select CPU_ARM926EJS > select SUNXI_GEN_SUN6I > select SUPPORT_SPL > + select SKIP_LOWLEVEL_INIT_ONLY > + select SPL_SKIP_LOWLEVEL_INIT_ONLY > > config MACH_SUN4I > bool "sun4i (Allwinner A10)" > diff --git a/configs/licheepi_nano_defconfig > b/configs/licheepi_nano_defconfig index 14e6bcda927..09f1a19cdbe 100644 > --- a/configs/licheepi_nano_defconfig > +++ b/configs/licheepi_nano_defconfig > @@ -1,6 +1,4 @@ > CONFIG_ARM=y > -CONFIG_SKIP_LOWLEVEL_INIT_ONLY=y > -CONFIG_SPL_SKIP_LOWLEVEL_INIT_ONLY=y > CONFIG_SYS_DCACHE_OFF=y > CONFIG_ARCH_SUNXI=y > CONFIG_DEFAULT_DEVICE_TREE="suniv-f1c100s-licheepi-nano" > -- > 2.25.1
Re: [PATCH 2/6] sunxi: fix 32MB load address layout
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:34:54 CEST je Andre Przywara napisal(a): > The default load addresses for the various payloads (kernel, DT, > ramdisk) on systems with just 32MB of DRAM have some issues: > For a start the preceding comment doesn't match the actual values: > apparently they were copied from the 64MB S3 layout, then halved, but > since 0x5 is NOT the half of 0x10, they don't match up. > Also those projected maximum sizes are quite restrictive: it's not easy > to build a compressed kernel image with just 4MB. The only defconfig in > mainline Linux that supports the F1C100s (the only 32MB user so far) > creates a 6MB compressed / 15MB uncompressed kernel. > Rearrange the default load addresses to accommodate such a kernel: we > allow an 7MB/16MB kernel, and up to 5MB of ramdisk, stuffing the smaller > binaries like the DTB towards the end, just before the relocated U-Boot. > Shrink the size for DTB and scripts on the way, there is no need for > allowing up to 512K for them. > > Signed-off-by: Andre Przywara > --- > include/configs/sunxi-common.h | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index 416a0422861..fe90d55bd45 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -165,17 +165,17 @@ > > #elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 32) > /* > - * 32M RAM minus 1MB heap + 8MB for u-boot, stack, fb, etc. > - * 8M uncompressed kernel, 4M compressed kernel, 512K fdt, > - * 512K script, 512K pxe and the ramdisk at the end. > + * 32M RAM minus 2.5MB for u-boot, heap, stack, etc. > + * 16M uncompressed kernel, 7M compressed kernel, 128K fdt, 64K script, > + * 128K DT overlay, 128K PXE and the ramdisk in the rest (max. 5MB) DT overlays and PXE could be even much smaller, but I guess it doesn't make much of a difference. Reviewed-by: Jernej Skrabec Best regards, Jernej > */ > #define BOOTM_SIZE__stringify(0x170) > -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(050)) > -#define FDT_ADDR_R__stringify(SDRAM_OFFSET(0C0)) > -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(0C5)) > -#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(0D0)) > -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(0D5)) > -#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(0D6)) > +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(100)) > +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(1d5)) > +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(1d4)) > +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(1d0)) > +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1d2)) > +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(180)) > > #else > #error Need at least 32MB of DRAM. Please adjust load addresses. > -- > 2.25.1
Re: [PATCH 1/6] sunxi: Kconfig: introduce SUNXI_MINIMUM_DRAM_MB
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:34:53 CEST je Andre Przywara napisal(a): > Traditionally we assumed that every Allwinner board would come with at > least 256 MB of DRAM, and set our DRAM layout accordingly. This affected > both the default load addresses, but also U-Boot's own address > expectations (like being loaded at 160 MB). > > Some SoCs come with co-packaged DRAM, but only provide 32 or 64MB. So > far we special-cased those *chips*, as there was only one chip per DRAM > size. However new chips force us to take a more general approach. > > Introduce a Kconfig symbol, which provides the minimum DRAM size of the > board. If nothing else is specified, we use 256 MB, and default to > smaller values for those co-packaged SoCs. > Then select the different DRAM maps according to this new symbol, so > that different SoCs with the same DRAM size can share those definitions. > > Inspired by an idea from Icenowy. > > This is just refactoring: compiled for all boards before and after this > patch: the binaries were identical. > > Signed-off-by: Andre Przywara Nice approach. Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > Kconfig| 6 +++--- > arch/arm/mach-sunxi/Kconfig| 12 > boot/Kconfig | 4 ++-- > include/configs/sunxi-common.h | 31 +-- > 4 files changed, 34 insertions(+), 19 deletions(-) > > diff --git a/Kconfig b/Kconfig > index 2ea735d38e4..d297513bac6 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -312,9 +312,9 @@ config SYS_MALLOC_LEN > default 0x400 if SANDBOX > default 0x200 if ARCH_ROCKCHIP || ARCH_OMAP2PLUS || ARCH_MESON > default 0x20 if ARCH_BMIPS || X86 > - default 0x12 if MACH_SUNIV > - default 0x22 if MACH_SUN8I_V3S > - default 0x402 if ARCH_SUNXI > + default 0x402 if SUNXI_MINIMUM_DRAM_MB >= 256 > + default 0x22 if SUNXI_MINIMUM_DRAM_MB >= 64 > + default 0x12 if SUNXI_MINIMUM_DRAM_MB >= 32 > default 0x40 > help > This defines memory to be allocated for Dynamic allocation > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 6b16f43494f..9aa66deb9fd 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -615,6 +615,18 @@ config SYS_BOARD > config SYS_SOC > default "sunxi" > > +config SUNXI_MINIMUM_DRAM_MB > + int "minimum DRAM size" > + default 32 if MACH_SUNIV > + default 64 if MACH_SUN8I_V3S > + default 256 > + ---help--- > + Minimum DRAM size expected on the board. Traditionally we assumed > + 256 MB, so that U-Boot would load at 160MB. With co-packaged DRAM > + we have smaller sizes, though, so that U-Boot's own load address and > + the default payload addresses must be shifted down. > + This is expected to be fixed by the SoC selection. > + > config UART0_PORT_F > bool "UART0 on MicroSD breakout board" > ---help--- > diff --git a/boot/Kconfig b/boot/Kconfig > index 6b3b8f072cb..45f86e946cd 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -499,8 +499,8 @@ config SYS_TEXT_BASE > default 0x8080 if ARCH_OMAP2PLUS || ARCH_K3 > default 0x8170 if MACH_SUNIV > default 0x2a00 if MACH_SUN9I > - default 0x42e0 if MACH_SUN8I_V3S > - default 0x4a00 if ARCH_SUNXI > + default 0x4a00 if SUNXI_MINIMUM_DRAM_MB >= 256 > + default 0x42e0 if SUNXI_MINIMUM_DRAM_MB >= 64 > hex "Text Base" > help > The address in memory that U-Boot will be running from, initially. > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index 0f0ef4f64bb..416a0422861 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -135,7 +135,21 @@ > #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(FE0)) > #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(FF0)) > > -#elif defined(CONFIG_MACH_SUN8I_V3S) > +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 256) > +/* > + * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, > etc. + * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, > + * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. > + */ > +#define BOOTM_SIZE__stringify(0xa00) > +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(200)) > +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(300)) > +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(310)) > +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(320)) > +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(330)) > +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(340)) > + > +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 64) > /* > * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc. > * 16M uncompressed kernel, 8M compressed kernel, 1M fdt, > @@ -149,7 +163,7 @@ > #define FDTOVERLAY_ADDR_R
Re: [PATCH] sunxi: defconfig: Add X96 Mate TV box
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:26:10 CEST je Andre Przywara napisal(a): > The X96 Mate TV box is a TV box with the Allwinner H616 SoC. It is > available with up to 4GB of DRAM and 64GB eMMC. > The DRAM chips require a different configuration when compared to the > OrangePi Zero2, we must not use read/write training and write leveling. > > Add a defconfig for the box, so that we can easily build U-Boot for it. > We synced the .dts file already from the kernel tree. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > configs/x96_mate_defconfig | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 configs/x96_mate_defconfig > > diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig > new file mode 100644 > index 000..4276f4f543b > --- /dev/null > +++ b/configs/x96_mate_defconfig > @@ -0,0 +1,15 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_SUNXI=y > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h616-x96-mate" > +CONFIG_SPL=y > +CONFIG_DRAM_SUN50I_H616_READ_CALIBRATION=y > +CONFIG_MACH_SUN50I_H616=y > +CONFIG_MMC0_CD_PIN="PF6" > +CONFIG_R_I2C_ENABLE=y > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_SPL_I2C=y > +CONFIG_SPL_SYS_I2C_LEGACY=y > +CONFIG_SYS_I2C_MVTWSI=y > +CONFIG_SYS_I2C_SLAVE=0x7f > +CONFIG_SYS_I2C_SPEED=40 > +CONFIG_SUPPORT_EMMC_BOOT=y > -- > 2.25.1
Re: [PATCH] sunxi-mmc: increase stabilization delay from 1ms to 20ms
Dne petek, 22. julij 2022 ob 18:55:14 CEST je Andre Przywara napisal(a):
> On 21/07/2022 23:08, Da Xue wrote:
>
> Hi,
>
> > Some users experienced problems booting u-boot from SPL hanging here:
> >
> > Trying to boot from MMC1 or Trying to boot from MMC2
> >
> > This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC.
> > Increasing the delay after mmc reset fixes these boot problems.
> > Some MicroSD cards are impacted more than others so it is possible that
> > MicroSD internals need time to stabilize. Below is some failure data.
> >
> > sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms
> > sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms
> > sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
> >
> > A quick comparison of schematics show series resistors for ESD
> > protection on the MicroSD GPIOs not present on all H3/H5 boards.
> > It is not known if this is related to the issue.
> >
> > This patch adds a fixed 20ms delay to mmc init to mitigate the problem.
> > If boot time optimization is required and the platform does not require
> > the delay. The delay can be replaced with:
> >
> > writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl);
> > if (wait_for_bit_le32( >reg->gctrl,
> > SUNXI_MMC_GCTRL_RESET, false, 20, false)) {
> > printf("%s: Timeout\n", __func__);
> > return -ETIMEDOUT;
> > }
>
> So what about adding this for everyone (we should have it regardless) then?
>
> And then have an extra Kconfig option to specify an extra delay, and
> define this only in your board defconfig? Because IIUC this is specific
> to your board?
>
> And as I mentioned: it looks odd to have this here and have it fixing
> your SD card problems:
> - The soft reset should reset just the internal controller logic (MMC
> state machine and FIFOs), this shouldn't affect cards. IIUC, nothing
> should happen on the MMC *pins* because of this operation.
> - Why isn't this a problem for U-Boot proper, and Linux, FWIW?
As I said before, I have issue only at cold boot in SPL. Once I pass this
point, it works all the time, even if rebooted. Why is that so it's unclear.
Thinking about this a bit, I have another question. How is it possible that
BROM manages to read SD card just fine and loads SPL beforehand? Is it using
lower speed? It also couldn't be power issue, since card must have been
properly powered up by BROM...
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > Signed-off-by: Da Xue
> > ---
> >
> > drivers/mmc/sunxi_mmc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > index 1bb7b6d0e9..f7942b69ce 100644
> > --- a/drivers/mmc/sunxi_mmc.c
> > +++ b/drivers/mmc/sunxi_mmc.c
> > @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
> >
> >/* Reset controller */
> >writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl);
> >
> > - udelay(1000);
> > + udelay(2);
> >
> >return 0;
> >
> > }
Re: Re: Re: Re: Increasing stabilization time in sunxi_mmc_core_init
Dne četrtek, 21. julij 2022 ob 23:23:28 CEST je Da Xue napisal(a): > On Thu, Jul 21, 2022 at 4:58 PM Da Xue wrote: > > On Thu, Jul 21, 2022 at 4:49 PM Jernej Škrabec wrote: > > > Dne četrtek, 21. julij 2022 ob 22:33:09 CEST je Da Xue napisal(a): > > > > On Thu, Jul 21, 2022 at 4:05 PM Jernej Škrabec > > > > > > > > > > wrote: > > > > > Dne četrtek, 21. julij 2022 ob 21:56:35 CEST je Da Xue napisal(a): > > > > > > On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec > > > > > > > > > > > > wrote: > > > > > > > Hi! > > > > > > > > > > > > > > Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara > > > > > > napisal(a): > > > > > > > > On 21/07/2022 12:03, Da Xue wrote: > > > > > > > > > > > > > > > > Hi Da, > > > > > > > > > > > > > > > > > Users were reporting non-boot on our H5 boards > > > > > > > > > (ALL-H3-CC-H5). > > > > > > > > > u-boot > > > > > > > > > gets stuck in SPL with this message for SD/eMMC > > > > > > > > > respectively. > > > > > > > > > > > > > > > > > > Trying to boot from MMC1 or Trying to boot from MMC2 > > > > > > > > > > > > > > > > > > I tested about 20 MicroSD cards from different brands and > > > > > > > > > some > > > > > > > > > were > > > > > > > > > happy and some were not. Increasing the udelay to 8-10ms in > > > > > > > > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset > > > > > > > > > seems to > > > > > > > > > fix > > > > > > > > > the issue for the MicroSD cards. > > > > > > > > > > > > > > > > That's interesting, thanks for the report. I don't remember > > > > > > > > hearing > > > > > > > > of > > > > > > > > issues with MMC before, at least not in the SPL. > > > > > > > > > > > > > > I certainly experienced this issue on board in question. I > > > > > > > vaguely > > > > > > > remember > > > > > > > asking about this issue on IRC. I also tried all sorts of > > > > > > > tweaks, but > > > > > > > it > > > > > > > never occured to me that mmc reset timeout would be too short. > > > > > > > > > > > > > > Da, how did you find this? > > > > > > > > > > > > Someone on the Armbian forum posted that they had the same problem > > > > > > with eMMC so I got suspicious. I scoped the MicroSD clock line and > > > > > > realized the frequency goes high and then drops to very low as if > > > > > > it > > > > > > never found the card. > > > > > > I had a hunch it was a stabilization delay and got lucky. > > > > > > > > > > > > > I only test one other H5 board occasionally, namely OrangePi > > > > > > > PC2, but > > > > > > > I > > > > > > > never observed such issue there. I always needed about 5 > > > > > > > attempts to > > > > > > > boot > > > > > > > ALL-H3-CC- H5 board, but once it's cold booted, warm boots > > > > > > > always > > > > > > > succeed. > > > > > > > > > > > > I had run into this too so it didn't make any sense. I tried 5ms > > > > > > and > > > > > > it helped on some cards but not others. > > > > > > I know the Orange Pis do not have the series resistor for ESD > > > > > > protection of the SD GPIOs but that shouldn't affect this. > > > > > > So...who knows? > > > > > > > > > > > > > Best regards, > > > > > > > Jernej > > > > > > > > > > > > > > > It's a bit odd that waiting after the *controller* reset > > > > > > > > should > > > > > > > > affect > > > >
Re: Re: Re: Increasing stabilization time in sunxi_mmc_core_init
Dne četrtek, 21. julij 2022 ob 22:33:09 CEST je Da Xue napisal(a):
> On Thu, Jul 21, 2022 at 4:05 PM Jernej Škrabec
wrote:
> > Dne četrtek, 21. julij 2022 ob 21:56:35 CEST je Da Xue napisal(a):
> > > On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec
> > >
> > > wrote:
> > > > Hi!
> > > >
> > > > Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara
napisal(a):
> > > > > On 21/07/2022 12:03, Da Xue wrote:
> > > > >
> > > > > Hi Da,
> > > > >
> > > > > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5).
> > > > > > u-boot
> > > > > > gets stuck in SPL with this message for SD/eMMC respectively.
> > > > > >
> > > > > > Trying to boot from MMC1 or Trying to boot from MMC2
> > > > > >
> > > > > > I tested about 20 MicroSD cards from different brands and some
> > > > > > were
> > > > > > happy and some were not. Increasing the udelay to 8-10ms in
> > > > > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to
> > > > > > fix
> > > > > > the issue for the MicroSD cards.
> > > > >
> > > > > That's interesting, thanks for the report. I don't remember hearing
> > > > > of
> > > > > issues with MMC before, at least not in the SPL.
> > > >
> > > > I certainly experienced this issue on board in question. I vaguely
> > > > remember
> > > > asking about this issue on IRC. I also tried all sorts of tweaks, but
> > > > it
> > > > never occured to me that mmc reset timeout would be too short.
> > > >
> > > > Da, how did you find this?
> > >
> > > Someone on the Armbian forum posted that they had the same problem
> > > with eMMC so I got suspicious. I scoped the MicroSD clock line and
> > > realized the frequency goes high and then drops to very low as if it
> > > never found the card.
> > > I had a hunch it was a stabilization delay and got lucky.
> > >
> > > > I only test one other H5 board occasionally, namely OrangePi PC2, but
> > > > I
> > > > never observed such issue there. I always needed about 5 attempts to
> > > > boot
> > > > ALL-H3-CC- H5 board, but once it's cold booted, warm boots always
> > > > succeed.
> > >
> > > I had run into this too so it didn't make any sense. I tried 5ms and
> > > it helped on some cards but not others.
> > > I know the Orange Pis do not have the series resistor for ESD
> > > protection of the SD GPIOs but that shouldn't affect this.
> > > So...who knows?
> > >
> > > > Best regards,
> > > > Jernej
> > > >
> > > > > It's a bit odd that waiting after the *controller* reset should
> > > > > affect
> > > > > SD cards, and 1ms seems plenty for just the reset.
> > > > > I just checked and at least the SOFT_RESET and FIFO_RESET bits are
> > > > > self
> > > > > clearing. Can you try to use wait_for_bit_le32() to wait for those
> > > > > parts
> > > > > to finish? See sun8i_emac_eth_start() for an example.
> > >
> > > I tested some more and here's the data:
> > > sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms
> > > sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms
> > > sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
> > > Given this, I don't think it's an issue with the bit set delays. Might
> > > need more than 10ms even. I didn't change the udelay in probe.
> >
> > Idea here is that we wouldn't need to determine the appropriate delay, but
> > instead, wait_for_bit_le32() would monitor reset bit and continue only
> > after reset bit would clear itself. Hopefully that happens after
> > everything is stable.
>
> I changed it to 50ms delay
>
> writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl);
> if (wait_for_bit_le32( >reg->gctrl,
> SUNXI_MMC_GCTRL_RESET, false, 50, false)) {
> printf("%s: Timeout\n", __func__);
> return ret;
> }
>
> and that seems to work. Shall I send the patch?
Certainly, that's major improvement. Just 1 small nitpick - you don't need to
introduce ret variable, just return error -ETIMEDOUT directly.
Maybe timeout can be raised even to 100 ms, now that it continues as soon as
possible. Better to be on
Re: Re: Increasing stabilization time in sunxi_mmc_core_init
Dne četrtek, 21. julij 2022 ob 21:56:35 CEST je Da Xue napisal(a): > On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec > > wrote: > > Hi! > > > > Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara napisal(a): > > > On 21/07/2022 12:03, Da Xue wrote: > > > > > > Hi Da, > > > > > > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5). u-boot > > > > gets stuck in SPL with this message for SD/eMMC respectively. > > > > > > > > Trying to boot from MMC1 or Trying to boot from MMC2 > > > > > > > > I tested about 20 MicroSD cards from different brands and some were > > > > happy and some were not. Increasing the udelay to 8-10ms in > > > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to fix > > > > the issue for the MicroSD cards. > > > > > > That's interesting, thanks for the report. I don't remember hearing of > > > issues with MMC before, at least not in the SPL. > > > > I certainly experienced this issue on board in question. I vaguely > > remember > > asking about this issue on IRC. I also tried all sorts of tweaks, but it > > never occured to me that mmc reset timeout would be too short. > > > > Da, how did you find this? > > Someone on the Armbian forum posted that they had the same problem > with eMMC so I got suspicious. I scoped the MicroSD clock line and > realized the frequency goes high and then drops to very low as if it > never found the card. > I had a hunch it was a stabilization delay and got lucky. > > > I only test one other H5 board occasionally, namely OrangePi PC2, but I > > never observed such issue there. I always needed about 5 attempts to boot > > ALL-H3-CC- H5 board, but once it's cold booted, warm boots always > > succeed. > > I had run into this too so it didn't make any sense. I tried 5ms and > it helped on some cards but not others. > I know the Orange Pis do not have the series resistor for ESD > protection of the SD GPIOs but that shouldn't affect this. > So...who knows? > > > Best regards, > > Jernej > > > > > It's a bit odd that waiting after the *controller* reset should affect > > > SD cards, and 1ms seems plenty for just the reset. > > > I just checked and at least the SOFT_RESET and FIFO_RESET bits are self > > > clearing. Can you try to use wait_for_bit_le32() to wait for those parts > > > to finish? See sun8i_emac_eth_start() for an example. > > I tested some more and here's the data: > sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms > sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms > sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms > Given this, I don't think it's an issue with the bit set delays. Might > need more than 10ms even. I didn't change the udelay in probe. Idea here is that we wouldn't need to determine the appropriate delay, but instead, wait_for_bit_le32() would monitor reset bit and continue only after reset bit would clear itself. Hopefully that happens after everything is stable. Best regards, Jernej > > > > And since you mentioned it's card related: can you check whether the > > > delay is actually needed somewhere else, later? At some point where we > > > wait to the card to response, for instance? > > > > > > I am not against taking this patch, if it fixes problems for you, but > > > just want to avoid that it papers over other issues. > > > > > > Cheers, > > > Andre > > > > > > > Author: Da Xue > > > > Date: Wed Jul 20 19:11:55 2022 -0400 > > > > > > > > sunxi: raise stabilization time for mmc from 1ms to 8ms > > > > > > > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c > > > > index 1bb7b6d0e9..499e057725 100644 > > > > --- a/drivers/mmc/sunxi_mmc.c > > > > +++ b/drivers/mmc/sunxi_mmc.c > > > > @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc) > > > > > > > > /* Reset controller */ > > > > writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl); > > > > > > > > - udelay(1000); > > > > + udelay(8000); > > This might need to be even higher. Like 20ms. > > > > > return 0; > > > > > > > > } > > > > > > > > I don't know the implications of this change so I am seeking feedback. > > > > Are other boards having this issue as well or is it specific to our > > > > hardware? > > > > > > > > Best, > > > > Da
Re: Increasing stabilization time in sunxi_mmc_core_init
Hi! Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara napisal(a): > On 21/07/2022 12:03, Da Xue wrote: > > Hi Da, > > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5). u-boot > > gets stuck in SPL with this message for SD/eMMC respectively. > > > > Trying to boot from MMC1 or Trying to boot from MMC2 > > > > I tested about 20 MicroSD cards from different brands and some were > > happy and some were not. Increasing the udelay to 8-10ms in > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to fix > > the issue for the MicroSD cards. > > That's interesting, thanks for the report. I don't remember hearing of > issues with MMC before, at least not in the SPL. I certainly experienced this issue on board in question. I vaguely remember asking about this issue on IRC. I also tried all sorts of tweaks, but it never occured to me that mmc reset timeout would be too short. Da, how did you find this? I only test one other H5 board occasionally, namely OrangePi PC2, but I never observed such issue there. I always needed about 5 attempts to boot ALL-H3-CC- H5 board, but once it's cold booted, warm boots always succeed. Best regards, Jernej > It's a bit odd that waiting after the *controller* reset should affect > SD cards, and 1ms seems plenty for just the reset. > I just checked and at least the SOFT_RESET and FIFO_RESET bits are self > clearing. Can you try to use wait_for_bit_le32() to wait for those parts > to finish? See sun8i_emac_eth_start() for an example. > > And since you mentioned it's card related: can you check whether the > delay is actually needed somewhere else, later? At some point where we > wait to the card to response, for instance? > > I am not against taking this patch, if it fixes problems for you, but > just want to avoid that it papers over other issues. > > Cheers, > Andre > > > Author: Da Xue > > Date: Wed Jul 20 19:11:55 2022 -0400 > > > > sunxi: raise stabilization time for mmc from 1ms to 8ms > > > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c > > index 1bb7b6d0e9..499e057725 100644 > > --- a/drivers/mmc/sunxi_mmc.c > > +++ b/drivers/mmc/sunxi_mmc.c > > @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc) > > > > /* Reset controller */ > > writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl); > > > > - udelay(1000); > > + udelay(8000); > > > > return 0; > > > > } > > > > I don't know the implications of this change so I am seeking feedback. > > Are other boards having this issue as well or is it specific to our > > hardware? > > > > Best, > > Da
Re: [PATCH 1/2] sunxi: Fix old GMAC pinmux setup
Dne sreda, 16. marec 2022 ob 01:54:42 CET je Andre Przywara napisal(a):
> Commit 5bc4cd05d7d4 ("sunxi: move non-essential code out of s_init()")
> moved the call to eth_init_board() from s_init() into board_init_f().
> This means it's now only called from the SPL, which makes sense for
> most of the other moved low-level functions. However the GMAC pinmux and
> clock setup in eth_init_board() was not happy about that, so it broke
> the sun7i GMAC.
>
> Since Ethernet is of no use in the SPL anyway, just move the call into
> board_init(), which is only run in U-Boot proper.
>
> This fixes Ethernet operation for the A20 SoCs, which broke in
> v2022.04-rc1, with the above mentioned commit.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
I guess this function will soon go away with introduction of clock and pinctrl
driver.
Best regards,
Jernej
> ---
> arch/arm/mach-sunxi/board.c | 1 -
> board/sunxi/board.c | 3 +++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 0071de19ffd..9a7673d82dc 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -333,7 +333,6 @@ void board_init_f(ulong dummy)
> clock_init();
> timer_init();
> gpio_init();
> - eth_init_board();
>
> spl_init();
> preloader_console_init();
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index a0961590479..28f702bc296 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -308,6 +309,8 @@ int board_init(void)
> #endif
> #endif /* CONFIG_DM_MMC */
>
> + eth_init_board();
> +
> return 0;
> }
>
> --
> 2.35.1
>
>
Re: Re: [PATCH] sunxi: add board documentation
Dne torek, 14. december 2021 ob 02:07:58 CET je Andre Przywara napisal(a): > On Mon, 13 Dec 2021 18:20:37 +0100 > Jernej Škrabec wrote: > > Hi Jernej, > > thanks for having a look! > > > Dne ponedeljek, 13. december 2021 ob 02:03:22 CET je Andre Przywara > > napisal(a): > > > Add some long overdue instructions for building and installing U-Boot on > > > Allwinner SoC based boards. > > > This describes the building process, including TF-A and crust, plus > > > installation to SD card, eMMC and SPI flash, both from Linux and U-Boot > > > itself. Also describe FEL booting. > > > > > > Signed-off-by: Andre Przywara > > > --- > > > Hi, > > > > > > please have a look whether this makes sense. Feel free to just try > > something, > > > and point out ambiguities or missing bits. For missing topics, please > > > send a follow-up patch ;-) > > > > This documentation seems to include all of board/sunxi/README.sunxi64 and > > README.nand. I think it would make sense to remove those files. If any file gets > > out of sync for any reason, it would be very confusing for end user. > > Indeed, I think README.sunxi64 is redundant now. > I didn't look at README.nand too closely, but since I don't even mention > NAND, I don't think it can be removed just yet. I guess I just convert > it to RST and move it into this directory. > > > I would also remove all non-essential command parameters, so all commands are > > as simple as possible. Power users will know about them anyway and non- skilled > > users might perceive that it's harder that it really is. I have in mind "- j5 - > > s" for make, "-v -p" for sunxi-fel > > I see, makes sense. > > > and DEBUG=1 for TF-A (maybe I missed some > > places). Actually, DEBUG=1 could be mentioned afterwards as troubleshooting > > step. In my experience, stable version of TF-A was never source of boot issues > > nor it provided any useful information for debugging anything else. > > Well, I'd tend to keep DEBUG=1 enabled, this lists the regulators > enabled, which helps debugging. Also in the past DEBUG=0 was very > silent, which wasn't helpful to verify that TF-A actually started. I patched out enabling regulators in TF-A, we already discussed this in the past. > > Do you typically build or recommend DEBUG=0? I set DEBUG=1 only when I actually want to debug this part of boot process, which is very rarely. I don't remember that I would help anyone with building TF-A, so I don't make recommendations in either direction. For LibreELEC, we build it with DEBUG=0, unless debug build of ATF package was requested. Again, basically never. Release images are build with DEBUG=0. Note that based on my experience, many LibreELEC users don't actually own serial adapter, so it doesn't really matter what U-Boot and TF-A print out. Fortunatelly, boot issues in LE are very rare these days (I don't remember last time someone reported it). Best regards, Jernej > > > Some comments bellow. > > > > > > > > Also this is quite long, shall this be split up in two (or more) files? > > > > > > This is what rst.ninjs.org made of it, if you prefer to read it formatted: > > > https://paste.c-net.org/PleasantNeedy > > > > > > Cheers, > > > Andre > > > > > > doc/board/allwinner/index.rst | 9 + > > > doc/board/allwinner/sunxi.rst | 304 ++ > > > 2 files changed, 313 insertions(+) > > > create mode 100644 doc/board/allwinner/index.rst > > > create mode 100644 doc/board/allwinner/sunxi.rst > > > > > > diff --git a/doc/board/allwinner/index.rst b/doc/board/allwinner/ index.rst > > > new file mode 100644 > > > index 000..7352ccd5c0a > > > --- /dev/null > > > +++ b/doc/board/allwinner/index.rst > > > @@ -0,0 +1,9 @@ > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > + > > > +Allwinner (sunxi) boards > > > + > > > + > > > +.. toctree:: > > > + :maxdepth: 2 > > > + > > > + sunxi > > > diff --git a/doc/board/allwinner/sunxi.rst b/doc/board/allwinner/ sunxi.rst > > > new file mode 100644 > > > index 000..693eb32e168 > > > --- /dev/null > > > +++ b/doc/board/allwinner/sunxi.rst > > > @@ -0,0 +1,304 @@ > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > +.. Copyright (C) 2021 Arm Ltd. > > > + > > > +Allwinner SoC based boards > >
Re: [PATCH] sunxi: add board documentation
Hi Andre!
Dne ponedeljek, 13. december 2021 ob 02:03:22 CET je Andre Przywara
napisal(a):
> Add some long overdue instructions for building and installing U-Boot on
> Allwinner SoC based boards.
> This describes the building process, including TF-A and crust, plus
> installation to SD card, eMMC and SPI flash, both from Linux and U-Boot
> itself. Also describe FEL booting.
>
> Signed-off-by: Andre Przywara
> ---
> Hi,
>
> please have a look whether this makes sense. Feel free to just try
something,
> and point out ambiguities or missing bits. For missing topics, please
> send a follow-up patch ;-)
This documentation seems to include all of board/sunxi/README.sunxi64 and
README.nand. I think it would make sense to remove those files. If any file
gets
out of sync for any reason, it would be very confusing for end user.
I would also remove all non-essential command parameters, so all commands are
as simple as possible. Power users will know about them anyway and non-skilled
users might perceive that it's harder that it really is. I have in mind "-j5 -
s" for make, "-v -p" for sunxi-fel and DEBUG=1 for TF-A (maybe I missed some
places). Actually, DEBUG=1 could be mentioned afterwards as troubleshooting
step. In my experience, stable version of TF-A was never source of boot issues
nor it provided any useful information for debugging anything else.
Some comments bellow.
>
> Also this is quite long, shall this be split up in two (or more) files?
>
> This is what rst.ninjs.org made of it, if you prefer to read it formatted:
> https://paste.c-net.org/PleasantNeedy
>
> Cheers,
> Andre
>
> doc/board/allwinner/index.rst | 9 +
> doc/board/allwinner/sunxi.rst | 304 ++
> 2 files changed, 313 insertions(+)
> create mode 100644 doc/board/allwinner/index.rst
> create mode 100644 doc/board/allwinner/sunxi.rst
>
> diff --git a/doc/board/allwinner/index.rst b/doc/board/allwinner/index.rst
> new file mode 100644
> index 000..7352ccd5c0a
> --- /dev/null
> +++ b/doc/board/allwinner/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Allwinner (sunxi) boards
> +
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + sunxi
> diff --git a/doc/board/allwinner/sunxi.rst b/doc/board/allwinner/sunxi.rst
> new file mode 100644
> index 000..693eb32e168
> --- /dev/null
> +++ b/doc/board/allwinner/sunxi.rst
> @@ -0,0 +1,304 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +.. Copyright (C) 2021 Arm Ltd.
> +
> +Allwinner SoC based boards
> +==
> +For boards using an Allwinner ARM based SoC ("sunxi"), the U-Boot build
> +system generates a single integrated image file: ``u-boot-sunxi-with-
spl.bin.``
> +This file can be used on SD cards, eMMC devices, SPI flash and for the
> +USB-OTG based boot method (FEL). To build this file:
> +
> +* For 64-bit SoCs, build Trusted Firmware (TF-A, formerly known as ATF)
first,
> + you will need its ``bl31.bin``. See below for more details.
> +* Optionally on 64-bit SoCs, build the crust management processor firmware.
> +* Build U-Boot::
> +
> + $ export BL31=/path/to/bl31.bin# required for 64-bit SoCs
> + $ export SCP=/src/crust/build/scp/scp.bin # optional for some 64-bit
SoCs
NIT: I guess path for SCP could be in same form, at least first part?
> + $ make _defconfig
> + $ make -j5 -s
> +* Transfer to an uSD card (see below for more details)::
> +
> + $ dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=8k seek=1
Most, if not all, distros require root for above command, so $ -> #? I see
that you used # below. Alternative would be to prepend command with sudo,
which is imo more beginners friendly.
> +* Boot and enjoy!
> +
> +For more details, and alternative boot locations or installations, see
below.
> +
> +Building Arm Trusted Firmware (TF-A)
> +
> +Boards using a 64-bit Soc (A64, H5, H6, H616, R329) require the BL31 stage
of
> +the `Arm Trusted Firmware-A`_ firmware. This provides the reference
> +implementation of secure software for Armv8-A, offering PSCI and SMCCC
> +services. Allwinner support is fully mainlined. To build bl31.bin::
> +
> + $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
> + $ cd trusted-firmware-a
> + $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_a64 DEBUG=1
> + $ export BL31=$(pwd)/build/sun50i_a64/debug/bl31.bin
> +
> +The target platform (``PLAT=``) for A64 and H5 SoCs is sun50i_a64, for the
H6
> +sun50i_h6, for the H616 sun50i_h616, and for the R329 sun50i_r329. Use::
> +
> + $ find plat/allwinner -name platform.mk
> +
> +to find all supported platforms. `docs/plat/allwinner.rst`_ contains more
> +information and lists some build options.
> +
> +Building the Crust management processor firmware
> +
> +For some SoCs and boards, the integrated OpenRISC management controller can
> +be used to provide
Re: Re: Broken build with disabling OpenSSL crypto
Hi Alex!
Dne četrtek, 07. oktober 2021 ob 00:05:24 CEST je Alex G. napisal(a):
> Hi Jernej,
>
> On 10/6/21 4:27 PM, Jernej Škrabec wrote:
> > Hi everyone!
> >
> > Commit cb9faa6f98ae ("tools: Use a single target-independent config to
enable
> > OpenSSL") recently introduced option to disable usage of OpenSSL via
> > CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit
b4f3cc2c42d9
> > ("tools: kwbimage: Do not hide usage of secure header under
> > CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That
totally
> > defeats the purpose of first commit. I suggest that it gets reverted.
> >
> > I would like disable OpenSSL for my usage, since it gives me troubles when
> > cross-compiling U-Boot inside LibreELEC build system. It's not needed for
our
> > case anyway.
> >
> > Best regards,
> >
>
> Can you please give the following diff a try, and if it works for you, submit
as patch?
This works, I'll submit it as a patch. Should I keep you as original author
and add your SoB tag?
Best regards,
Jernej
>
> Alex
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 4a86321f64..7f72ff9645 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -96,7 +96,8 @@ AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/,
\
>
> # Cryptographic helpers that depend on openssl/libcrypto
> LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
> - fdt-libcrypto.o)
> + fdt-libcrypto.o) \
> + kwbimage.o
>
> ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
>
> @@ -117,7 +118,6 @@ dumpimage-mkimage-objs := aisimage.o \
> imximage.o \
> imx8image.o \
> imx8mimage.o \
> - kwbimage.o \
> lib/md5.o \
> lpc32xximage.o \
> mxsimage.o \
> @@ -169,8 +169,8 @@ HOST_EXTRACFLAGS += -
DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x
> HOST_EXTRACFLAGS+= -DCONFIG_FIT_CIPHER
> endif
>
> -# MXSImage needs LibSSL
> -ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$
(CONFIG_TOOLS_LIBCRYPTO),)
> +# MXSImage needs LibSSL <- Nope! Read the frogging notice at the top
> +ifneq ($(CONFIG_TOOLS_LIBCRYPTO),)
> HOSTCFLAGS_kwbimage.o += \
> $(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo
"")
> HOSTLDLIBS_mkimage += \
>
Re: Re: Broken build with disabling OpenSSL crypto
Hi!
Dne četrtek, 07. oktober 2021 ob 21:41:00 CEST je Tom Rini napisal(a):
> On Wed, Oct 06, 2021 at 11:27:43PM +0200, Jernej Škrabec wrote:
>
> > Hi everyone!
> >
> > Commit cb9faa6f98ae ("tools: Use a single target-independent config to
enable
> > OpenSSL") recently introduced option to disable usage of OpenSSL via
> > CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit
b4f3cc2c42d9
> > ("tools: kwbimage: Do not hide usage of secure header under
> > CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That
totally
> > defeats the purpose of first commit. I suggest that it gets reverted.
> >
> > I would like disable OpenSSL for my usage, since it gives me troubles when
> > cross-compiling U-Boot inside LibreELEC build system. It's not needed for
our
> > case anyway.
>
> How hard is it to specify openssl as a dependency for U-Boot, in the
> LibreELEC build system? I assume openssl is being used in other parts
> of the build anyhow. Thanks!
Sure, OpenSSL package is present and we fixed issue with pkg-config in the
meantime (it picked target paths instead for the host). However, that doesn't
change anything. CONFIG_TOOLS_LIBCRYPTO is still borked and should be either
fixed or dropped. I prefer first option because OpenSSL dependency can be
removed and that allows more concurrency (multiple packages are built at the
same time).
Best regards,
Jernej
Broken build with disabling OpenSSL crypto
Hi everyone!
Commit cb9faa6f98ae ("tools: Use a single target-independent config to enable
OpenSSL") recently introduced option to disable usage of OpenSSL via
CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit b4f3cc2c42d9
("tools: kwbimage: Do not hide usage of secure header under
CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That totally
defeats the purpose of first commit. I suggest that it gets reverted.
I would like disable OpenSSL for my usage, since it gives me troubles when
cross-compiling U-Boot inside LibreELEC build system. It's not needed for our
case anyway.
Best regards,
Jernej
Re: Re: [PATCH] configs: OrangePi PC2: Update defaults
Dne sobota, 12. junij 2021 ob 07:50:27 CEST je Jernej Škrabec napisal(a): > Dne ponedeljek, 07. junij 2021 ob 19:42:45 CEST je Jernej Skrabec napisal(a): > > OrangePi PC2 board has DRAM with ODT, so enable it. ZQ value is also > > slightly different in vendor images, so update it as well. H5 SoC is > > also connected to voltage regulator. It's default value is pretty low, > > so in order to avoid instability, enable driver for it and set it to > > appropriate voltage. > > > > Signed-off-by: Jernej Skrabec > > --- > > configs/orangepi_pc2_defconfig | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig > > index f72ffe27b26c..5e4cca793f53 100644 > > --- a/configs/orangepi_pc2_defconfig > > +++ b/configs/orangepi_pc2_defconfig > > @@ -3,13 +3,15 @@ CONFIG_ARCH_SUNXI=y > > CONFIG_SPL=y > > CONFIG_MACH_SUN50I_H5=y > > CONFIG_DRAM_CLK=672 > > -CONFIG_DRAM_ZQ=3881977 > > -# CONFIG_DRAM_ODT_EN is not set > > +CONFIG_DRAM_ZQ=4145117 I re-checked BSP DT and original ZQ value is correct. So this patch should only enable ODT, which is really enabled in BSP and DRAM ICs support it. Best regards, Jernej > > CONFIG_MACPWR="PD6" > > CONFIG_SPL_SPI_SUNXI=y > > +CONFIG_SPL_I2C_SUPPORT=y > > CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2" > > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > > CONFIG_SUN8I_EMAC=y > > +CONFIG_SY8106A_POWER=y > > +CONFIG_SY8106A_VOUT1_VOLT=1100 > > I'm not sure if voltage regulator adjustment needs to be enabled. By default, > it's set to 1.1 V using resistor divider. However, it can be still needed if > board is rebooted and OS set it to lower value before reboot. > > Best regards, > Jernej > > > CONFIG_USB_EHCI_HCD=y > > CONFIG_USB_OHCI_HCD=y > > CONFIG_USB_MUSB_GADGET=y > > -- > > 2.31.1 > > > > > > >
Re: [PATCH] configs: OrangePi PC2: Update defaults
Dne ponedeljek, 07. junij 2021 ob 19:42:45 CEST je Jernej Skrabec napisal(a): > OrangePi PC2 board has DRAM with ODT, so enable it. ZQ value is also > slightly different in vendor images, so update it as well. H5 SoC is > also connected to voltage regulator. It's default value is pretty low, > so in order to avoid instability, enable driver for it and set it to > appropriate voltage. > > Signed-off-by: Jernej Skrabec > --- > configs/orangepi_pc2_defconfig | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig > index f72ffe27b26c..5e4cca793f53 100644 > --- a/configs/orangepi_pc2_defconfig > +++ b/configs/orangepi_pc2_defconfig > @@ -3,13 +3,15 @@ CONFIG_ARCH_SUNXI=y > CONFIG_SPL=y > CONFIG_MACH_SUN50I_H5=y > CONFIG_DRAM_CLK=672 > -CONFIG_DRAM_ZQ=3881977 > -# CONFIG_DRAM_ODT_EN is not set > +CONFIG_DRAM_ZQ=4145117 > CONFIG_MACPWR="PD6" > CONFIG_SPL_SPI_SUNXI=y > +CONFIG_SPL_I2C_SUPPORT=y > CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SUN8I_EMAC=y > +CONFIG_SY8106A_POWER=y > +CONFIG_SY8106A_VOUT1_VOLT=1100 I'm not sure if voltage regulator adjustment needs to be enabled. By default, it's set to 1.1 V using resistor divider. However, it can be still needed if board is rebooted and OS set it to lower value before reboot. Best regards, Jernej > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > CONFIG_USB_MUSB_GADGET=y > -- > 2.31.1 > >
Re: [PATCH v2] sunxi: clock: H6/H616: Fix PLL clock factor encodings
Hi!
Dne četrtek, 27. maj 2021 ob 01:49:48 CEST je Andre Przywara napisal(a):
> On Wed, 5 May 2021 13:53:05 +0100
> Andre Przywara wrote:
>
> Hi,
>
> > Most clock factors and dividers in the H6 PLLs use a "+1 encoding",
> > which we were missing on two occasions.
>
> can someone please confirm that I didn't mess this up?
>
> Cheers,
> Andre
>
> > This fixes the MMC clock setup on the H6, which could be slightly off due
> > to the wrong parent frequency:
> > mmc 2 set mod-clk req 5200 parent 117600 n 2 m 12 rate 4900
> >
> > Also the CPU frequency was a tad too high before.
> >
> > Signed-off-by: Andre Przywara
> > ---
> > Changelog v1 .. v2:
> > - Also fix PLL5 factor calculation (video, currently unused)
> > - Also fix PLL1 factor calculation (CPU clock)
> >
> > arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 4 ++--
> > arch/arm/mach-sunxi/clock_sun50i_h6.c | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h index
> > 62abfc4ef6b..2e076cf594d 100644
> > --- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > +++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > @@ -233,14 +233,14 @@ struct sunxi_ccm_reg {
> >
> > #define CCM_PLL1_OUT_ENBIT(27)
> > #define CCM_PLL1_CLOCK_TIME_2 (2 << 24)
> > #define CCM_PLL1_CTRL_P(p) ((p) << 16)
> >
> > -#define CCM_PLL1_CTRL_N(n) ((n) << 8)
> > +#define CCM_PLL1_CTRL_N(n) (((n) - 1) << 8)
> >
> > /* pll5 bit field */
> > #define CCM_PLL5_CTRL_EN BIT(31)
> > #define CCM_PLL5_LOCK_EN BIT(29)
> > #define CCM_PLL5_LOCK BIT(28)
> > #define CCM_PLL5_OUT_ENBIT(27)
> >
> > -#define CCM_PLL5_CTRL_N(n) ((n) << 8)
> > +#define CCM_PLL5_CTRL_N(n) (((n) - 1) << 8)
H6 and H616 DRAM drivers actually consider this "- 1" in the code. Either drop
this change or fix DRAM drivers.
With that:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> >
> > #define CCM_PLL5_CTRL_DIV1(div1) ((div1) << 0)
> > #define CCM_PLL5_CTRL_DIV2(div0) ((div0) << 1)
> >
> > diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > b/arch/arm/mach-sunxi/clock_sun50i_h6.c index 492fc4a3fca..a947463e0a5
> > 100644
> > --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > @@ -94,7 +94,7 @@ unsigned int clock_get_pll6(void)
> >
> > int m = IS_ENABLED(CONFIG_MACH_SUN50I_H6) ? 4 : 2;
> >
> > uint32_t rval = readl(>pll6_cfg);
> >
> > - int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT);
> > + int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) +
1;
> >
> > int div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
> >
> > CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
> >
> > int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
Re: 32-bit DMA limit for devices (and drivers)
Hi! Dne petek, 30. april 2021 ob 15:34:28 CEST je Andre Przywara napisal(a): > On Fri, 30 Apr 2021 14:02:52 +0200 (CEST) > Mark Kettenis wrote: > > Hi Mark, > > thanks for the reply! > > (CC:ing Alex and Heinrich for the UEFI questions below) > > > > Date: Fri, 30 Apr 2021 12:21:21 +0100 > > > From: Andre Przywara > > > > > > Hi, > > > > > > We now see the first Allwinner devices [1] having DRAM located above > > > 4GB in address space (4GB DRAM starting at 1GB). After one fix[2] > > > this works somewhat fine, but the sun8i-emac network device is still > > > limited to 32-bit DMA addresses. With U-Boot relocating itself (plus > > > stack and heap) to the end of DRAM, it now runs completely beyond 4GB > > > on those machines, so not giving pure 32-bit addresses for buffers > > > anymore. > > > In Linux we handle this easily by just keeping the default DMA > > > mask at 32 bits, and letting the DMA framework deal with the nasty > > > details. > > > > > > I was wondering how this should be handled in U-Boot? The straight > > > forward solution would be: > > > - Let the driver allocate the RX and TX buffers separately, placing them > > > > > > below 4GB in the address space (using lmb_reserve(), I guess?) > > > > > > - Use those RX buffers and hand the addresses back to the upper layers. > > > - We already copy TX packets, so this would also be covered, in this > > > > > > situation. Other drivers might need to introduce copying. > > > > What you describe here is called a bounce buffer approach. I believe > > Linux developers also refer to this as swiotlb. > > Yes, but it's not entirely the same as bounce buffering in Linux, > since we allocate the buffers ourselves, in the driver, so we have full > control over it. The problem I face is that malloc() works on the heap > (which is high), or we use the automatic priv_alloc mechanism, which > uses the heap as well, IIUC. > > > > This sounds like a common problem, so I was wondering if there is a > > > more generic solution to this? Maybe there are already platforms or > > > devices affected? Or should the whole heap and stack be moved below 4GB > > > (if this is easily possible)? > > > In our case we make the buffers part of our priv struct, so should > > > there be an option to let the priv_auto allocation come from below 4GB? > > > > > > Grateful for any input on this! > > > > I looked into this a bit when I was trying to figure out what to do on > > Apple M1 systems where I have a somewhat related issue. These systems > > have an IOMMU that can't be bypassed. Since I don't want to add IOMMU > > infrastructure to U-Boot, I set up the IOMMU to map a fixed block of > > physical memory and make sure that all allocations of memory come from > > that block of memory. In this case this is fairly easy to achieve. > > U-Boot allocates memory from the top of usable memory, so as long as I > > let the IOMMU map that high memory, things work. U-Boot doesn't need > > a lot of memory, so a block of 512MB is more than sufficient. > > I'd rather not play around with the visible memory size (see below). > And while technically there is a (scatter/gather) IOMMU in the SoC, it > would be too big guns for that small problem. IOMMU is connected only to video related cores, so it's not an option here. Best regards, Jernej > > > In your case this means that as long as you set the top of usable > > memory to an address < 4G, U-Boot itself should be fine and no bounce > > buffers are needed. You have to make sure the addresses in the U-Boot > > environment for loading things like the kernel and the FDT are set to > > an address < 4G as well. > > > > For EFI things are different though. You want to expose all physical > > memory in the EFI memory map. > > Not only for UEFI, since U-Boot populates the DT memory node even for > booti/bootm, in arch/arm/lib/bootm-fdt.c:arch_fixup_fdt(). > So limiting the memory is not an option, since this would be passed on > to the OS. > > > This means that an EFI application > > (such as an OS loader) may pick memory > 4G and use it to do I/O. > > I think we should be safe here, as the driver has full control over the > buffers: For TX we copy already, to use "fire-and-forget", so we > just start the DMA and return. And for RX U-Boot network drivers > return the buffer address, so it's our own buffer again. So wherever > higher layers put the packets, we should be good (given our own buffers > are). > > > So I guess my question boils down to: How can I best allocate buffers > from "low" memory? And do those buffers carveouts make it into the UEFI > memory map, as reserved regions? Or can UEFI differentiate between > boot services and runtime services allocations? The buffers would be > needed during boot services, for the UEFI network protocol. But later > on they can be abandoned. > > > this purpose U-Boot already implements bounce buffers. See the > > CONFIG_EFI_LOADER_BOUNCE_BUFFER option. > >
Re: [linux-sunxi] [PATCH] sunxi: clock: H6/H616: Fix PLL6 clock calculation
Hi! Dne sreda, 28. april 2021 ob 12:05:55 CEST je Andre Przywara napisal(a): > The "n" factor of the PLL_PERIPH0 clock is using the usual +1 encoding, > so we need to adjust the register value before doing the calculation. > > This fixes the MMC clock setup on those SoCs, which could be slightly off > due to the wrong parent frequency: > mmc 2 set mod-clk req 5200 parent 117600 n 2 m 12 rate 4900 > > Signed-off-by: Andre Przywara Good catch! Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [linux-sunxi] [PATCH] sunxi: board: Add H616 MMC2 pins
Dne ponedeljek, 26. april 2021 ob 14:14:46 CEST je Andre Przywara napisal(a): > We hardcode the pinctrl setting for the MMC controllers in boards.c, > since we need them also in the SPL, where there is no DT yet. > > Add the respective setting for the H616 SoC, to enable eMMC on boards > with this SoC as well. > Also to make diagnosing this problem easier, print a warning if a board > tries to setup MMC2 pins without a respective SoC setting being defined. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH] sunxi: DT: A64: update devicetree files
Dne sreda, 21. april 2021 ob 11:27:12 CEST je Andre Przywara napisal(a): > Import updated devicetree file from Linux v5.12-rc8. > > Besides some node and audio port renames this changes the PHY modes to > either rgmii-id or rgmii-txid. From the board files the Pinephone sees > a lot of updates. > > This also adds the long missing USB PHY property for controller 0, which > allows the U-Boot PHY driver to eventually use port 0 in host mode > (pending another U-Boot patch). > > Signed-off-by: Andre Przywara > --- > arch/arm/dts/sun50i-a64-bananapi-m64.dts | 16 ++-- > arch/arm/dts/sun50i-a64-nanopi-a64.dts| 2 +- > arch/arm/dts/sun50i-a64-orangepi-win.dts | 10 +-- > arch/arm/dts/sun50i-a64-pine64-lts.dts| 15 > arch/arm/dts/sun50i-a64-pine64-plus.dts | 2 +- > arch/arm/dts/sun50i-a64-pine64.dts| 8 +- > arch/arm/dts/sun50i-a64-pinebook.dts | 13 ++- > arch/arm/dts/sun50i-a64-pinephone-1.0.dts | 7 +- > arch/arm/dts/sun50i-a64-pinephone-1.1.dts | 7 +- > arch/arm/dts/sun50i-a64-pinephone-1.2.dts | 16 +++- > arch/arm/dts/sun50i-a64-pinephone.dtsi| 90 +++ > .../dts/sun50i-a64-pinetab-early-adopter.dts | 26 ++ > arch/arm/dts/sun50i-a64-pinetab.dts | 13 ++- > arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 11 +-- > arch/arm/dts/sun50i-a64-sopine.dtsi | 3 +- > arch/arm/dts/sun50i-a64-teres-i.dts | 12 +-- > arch/arm/dts/sun50i-a64.dtsi | 40 ++--- > 17 files changed, 215 insertions(+), 76 deletions(-) > create mode 100644 arch/arm/dts/sun50i-a64-pinetab-early-adopter.dts Files are identical, so: Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH] sunxi: DT: A64: update devicetree files
Hi Andre!
Dne sreda, 21. april 2021 ob 11:27:12 CEST je Andre Przywara napisal(a):
> Import updated devicetree file from Linux v5.12-rc8.
>
> Besides some node and audio port renames this changes the PHY modes to
> either rgmii-id or rgmii-txid. From the board files the Pinephone sees
> a lot of updates.
>
> This also adds the long missing USB PHY property for controller 0, which
> allows the U-Boot PHY driver to eventually use port 0 in host mode
> (pending another U-Boot patch).
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/dts/sun50i-a64-bananapi-m64.dts | 16 ++--
> arch/arm/dts/sun50i-a64-nanopi-a64.dts| 2 +-
> arch/arm/dts/sun50i-a64-orangepi-win.dts | 10 +--
> arch/arm/dts/sun50i-a64-pine64-lts.dts| 15
> arch/arm/dts/sun50i-a64-pine64-plus.dts | 2 +-
> arch/arm/dts/sun50i-a64-pine64.dts| 8 +-
> arch/arm/dts/sun50i-a64-pinebook.dts | 13 ++-
> arch/arm/dts/sun50i-a64-pinephone-1.0.dts | 7 +-
> arch/arm/dts/sun50i-a64-pinephone-1.1.dts | 7 +-
> arch/arm/dts/sun50i-a64-pinephone-1.2.dts | 16 +++-
> arch/arm/dts/sun50i-a64-pinephone.dtsi| 90 +++
> .../dts/sun50i-a64-pinetab-early-adopter.dts | 26 ++
> arch/arm/dts/sun50i-a64-pinetab.dts | 13 ++-
> arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 11 +--
> arch/arm/dts/sun50i-a64-sopine.dtsi | 3 +-
> arch/arm/dts/sun50i-a64-teres-i.dts | 12 +--
> arch/arm/dts/sun50i-a64.dtsi | 40 ++---
> 17 files changed, 215 insertions(+), 76 deletions(-)
> create mode 100644 arch/arm/dts/sun50i-a64-pinetab-early-adopter.dts
>
> diff --git a/arch/arm/dts/sun50i-a64-bananapi-m64.dts b/arch/arm/dts/sun50i-
a64-bananapi-m64.dts
> index 883f217efb8..f7fe9fa50cb 100644
> --- a/arch/arm/dts/sun50i-a64-bananapi-m64.dts
> +++ b/arch/arm/dts/sun50i-a64-bananapi-m64.dts
> @@ -36,18 +36,18 @@
> leds {
> compatible = "gpio-leds";
>
> - pwr-led {
> + led-0 {
> label = "bananapi-m64:red:pwr";
> gpios = < 3 24 GPIO_ACTIVE_HIGH>; /*
PD24 */
> default-state = "on";
> };
>
> - green {
> + led-1 {
> label = "bananapi-m64:green:user";
> gpios = < 4 14 GPIO_ACTIVE_HIGH>; /*
PE14 */
> };
>
> - blue {
> + led-2 {
> label = "bananapi-m64:blue:user";
> gpios = < 4 15 GPIO_ACTIVE_HIGH>; /*
PE15 */
> };
> @@ -105,7 +105,7 @@
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> phy-handle = <_rgmii_phy>;
> phy-supply = <_dc1sw>;
> status = "okay";
> @@ -331,10 +331,10 @@
> "Microphone", "Microphone
Jack",
> "Microphone", "Onboard
Microphone";
> simple-audio-card,routing =
> - "Left DAC", "AIF1 Slot 0 Left",
> - "Right DAC", "AIF1 Slot 0 Right",
> - "AIF1 Slot 0 Left ADC", "Left ADC",
> - "AIF1 Slot 0 Right ADC", "Right ADC",
> + "Left DAC", "DACL",
> + "Right DAC", "DACR",
> + "ADCL", "Left ADC",
> + "ADCR", "Right ADC",
> "Headphone Jack", "HP",
> "MIC2", "Microphone Jack",
> "Onboard Microphone", "MBIAS",
> diff --git a/arch/arm/dts/sun50i-a64-nanopi-a64.dts b/arch/arm/dts/sun50i-
a64-nanopi-a64.dts
> index e58db8a6cab..09b3c7fb82c 100644
> --- a/arch/arm/dts/sun50i-a64-nanopi-a64.dts
> +++ b/arch/arm/dts/sun50i-a64-nanopi-a64.dts
> @@ -35,7 +35,7 @@
> leds {
> compatible = "gpio-leds";
>
> - blue {
> + led {
> label = "nanopi-a64:blue:status";
> gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24
*/
> };
> diff --git a/arch/arm/dts/sun50i-a64-orangepi-win.dts b/arch/arm/dts/sun50i-
a64-orangepi-win.dts
> index fde9c7a99b1..70e31743f0b 100644
> --- a/arch/arm/dts/sun50i-a64-orangepi-win.dts
> +++ b/arch/arm/dts/sun50i-a64-orangepi-win.dts
> @@ -120,7 +120,7 @@
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> phy-handle = <_rgmii_phy>;
> phy-supply = <_gmac_3v3>;
> status = "okay";
> @@ -330,10 +330,10 @@
> "Microphone", "Microphone
Jack",
> "Microphone", "Onboard
Microphone";
> simple-audio-card,routing =
> - "Left DAC", "AIF1 Slot 0 Left",
> - "Right DAC", "AIF1 Slot 0 Right",
> - "AIF1 Slot 0 Left ADC", "Left
Re: [PATCH v2 18/19] video: sunxi: Add DW HDMI PHY driver
Dne ponedeljek, 08. marec 2021 ob 08:57:31 CET je Jagan Teki napisal(a): > On Sun, Mar 7, 2021 at 1:25 AM Jernej Skrabec wrote: > > This commit adds standalone driver for DW HDMI PHY. It deprecates code > > which is included in sunxi dw-hdmi platform driver. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > arch/arm/mach-sunxi/Kconfig | 1 + > > drivers/video/sunxi/Makefile| 2 +- > > drivers/video/sunxi/sunxi_dw_hdmi_phy.c | 423 > > drivers/video/sunxi/sunxi_dw_hdmi_phy.h | 24 ++ > > Would be good if this PHY management code handles via drivers/phy. > Hope this would possible? You mean move this code there? Yeah, it's possible, but then we have to move sunxi_dw_hdmi_phy.h to general or arch includes folder, because it implements additional functionality which is not covered by general PHY interface. Best regards, Jernej
Re: [PATCH v2 09/19] video: sunxi: de2: switch to public uclass functions
Dne torek, 09. marec 2021 ob 01:40:32 CET je Andre Przywara napisal(a):
> On Sun, 07 Mar 2021 08:35:23 +0100
> Jernej Škrabec wrote:
>
> Hi,
>
> > Dne nedelja, 07. marec 2021 ob 02:32:52 CET je Andre Przywara napisal(a):
> > > On Sat, 6 Mar 2021 20:54:27 +0100
> > >
> > > Jernej Skrabec wrote:
> > > > Currently DE2 driver uses functions which are defined in internal
> > > > headers. They are not meant to be used outside of uclass framework.
> > > > Switch DE2 driver to public ones. This has additional benefit that
> > > > device_probe doesn't need to be called manually.
> > >
> > > Indeed, good solution: for the calls in _probe(), we call de2_init()
> > > right afterwards, which would explicitly call probe for the display, so
> > > this both saves this call and the usage of the internal function.
> > > For the calls in simplefb_setup: the DM framework checks if a device
> > > has already been activated, so there is no problem with double probes.
> > >
> > > However, actually testing this on a Pine64-LTS revealed that this breaks
> > > on the A64: I only get a black screen (bisecting down to this commit).
> > >
> > > I didn't investigate any further yet, just wanted to give a heads up.
> >
> > Thanks! I'll check what's going on.
>
> I think I know what's going on, see below.
>
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > >
> > > > drivers/video/sunxi/sunxi_de2.c | 29 ++---
> > > > 1 file changed, 10 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/video/sunxi/sunxi_de2.c
> > > > b/drivers/video/sunxi/sunxi_de2.c index 6b836a011944..e02d359cd259
> > > > 100644
> > > > --- a/drivers/video/sunxi/sunxi_de2.c
> > > > +++ b/drivers/video/sunxi/sunxi_de2.c
> > > > @@ -19,8 +19,6 @@
> > > >
> > > > #include
> > > > #include
> > > > #include
> > > >
> > > > -#include
> > > > -#include
> > > >
> > > > #include
> > > > #include "simplefb_common.h"
> > > >
> > > > @@ -198,13 +196,6 @@ static int sunxi_de2_init(struct udevice *dev,
> > > > ulong
> > > > fbbase,>
> > > >
> > > > disp_uc_plat->source_id = mux;
>
> The mux value is set *after* the call to uclass_find_device_by_name()
> (or uclass_get_device_by_driver()) returned, and then we call this
> function with it, which *used* to call probe().
> Now probe is already called as part of uclass_get_device_by_driver(),
> so *before* we had a chance to determine and set the mux value/
> source_id.
> For the H3/H5 it's 0, so it conveniently works with the probably zeroed
> uc_plat structure there.
Oh, thanks for looking into this!
>
> Not sure how to fix this, as we get a handle to the device only after
> the uclass_find/get functions returned, so don't know where to set
> source_id before that.
>
> Shall this H3 vs. A64 check be moved into the HDMI driver and it's probe
> routine?
This info shouldn't be needed once TCON is implemented as standalone driver
probed via compatible string. I guess workaround can be implemented in HDMI
driver to get TCON number from DT instead, although this is a bit clumsy.
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > > > - ret = device_probe(disp);
> > > > - if (ret) {
> > > > - debug("%s: device '%s' display won't probe (ret=%d)
\n",
> > > > - __func__, dev->name, ret);
> > > > - return ret;
> > > > - }
> > > > -
> > > >
> > > > ret = display_read_timing(disp, );
> > > > if (ret) {
> > > >
> > > > debug("%s: Failed to read timings\n", __func__);
> > > >
> > > > @@ -245,8 +236,8 @@ static int sunxi_de2_probe(struct udevice *dev)
> > > >
> > > > if (!(gd->flags & GD_FLG_RELOC))
> > > >
> > > > return 0;
> > > >
> > > > - ret = uclass_find_device_by_name(UCLASS_DISPLAY,
> > > > -"sunxi_lcd", );
> > > > + ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
> > > > +
> >
> > DM_DRIVER_GET(sunxi_lcd), )
Re: [PATCH v2 09/19] video: sunxi: de2: switch to public uclass functions
Dne nedelja, 07. marec 2021 ob 02:32:52 CET je Andre Przywara napisal(a):
> On Sat, 6 Mar 2021 20:54:27 +0100
>
> Jernej Skrabec wrote:
> > Currently DE2 driver uses functions which are defined in internal
> > headers. They are not meant to be used outside of uclass framework.
> > Switch DE2 driver to public ones. This has additional benefit that
> > device_probe doesn't need to be called manually.
>
> Indeed, good solution: for the calls in _probe(), we call de2_init()
> right afterwards, which would explicitly call probe for the display, so
> this both saves this call and the usage of the internal function.
> For the calls in simplefb_setup: the DM framework checks if a device
> has already been activated, so there is no problem with double probes.
>
> However, actually testing this on a Pine64-LTS revealed that this breaks
> on the A64: I only get a black screen (bisecting down to this commit).
>
> I didn't investigate any further yet, just wanted to give a heads up.
Thanks! I'll check what's going on.
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/video/sunxi/sunxi_de2.c | 29 ++---
> > 1 file changed, 10 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/video/sunxi/sunxi_de2.c
> > b/drivers/video/sunxi/sunxi_de2.c index 6b836a011944..e02d359cd259 100644
> > --- a/drivers/video/sunxi/sunxi_de2.c
> > +++ b/drivers/video/sunxi/sunxi_de2.c
> > @@ -19,8 +19,6 @@
> >
> > #include
> > #include
> > #include
> >
> > -#include
> > -#include
> >
> > #include
> > #include "simplefb_common.h"
> >
> > @@ -198,13 +196,6 @@ static int sunxi_de2_init(struct udevice *dev, ulong
> > fbbase,>
> > disp_uc_plat->source_id = mux;
> >
> > - ret = device_probe(disp);
> > - if (ret) {
> > - debug("%s: device '%s' display won't probe (ret=%d)\n",
> > - __func__, dev->name, ret);
> > - return ret;
> > - }
> > -
> >
> > ret = display_read_timing(disp, );
> > if (ret) {
> >
> > debug("%s: Failed to read timings\n", __func__);
> >
> > @@ -245,8 +236,8 @@ static int sunxi_de2_probe(struct udevice *dev)
> >
> > if (!(gd->flags & GD_FLG_RELOC))
> >
> > return 0;
> >
> > - ret = uclass_find_device_by_name(UCLASS_DISPLAY,
> > -"sunxi_lcd", );
> > + ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
> > +
DM_DRIVER_GET(sunxi_lcd), );
> >
> > if (!ret) {
> >
> > int mux;
> >
> > @@ -262,8 +253,8 @@ static int sunxi_de2_probe(struct udevice *dev)
> >
> > debug("%s: lcd display not found (ret=%d)\n", __func__, ret);
> >
> > - ret = uclass_find_device_by_name(UCLASS_DISPLAY,
> > -"sunxi_dw_hdmi",
);
> > + ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
> > +
DM_DRIVER_GET(sunxi_dw_hdmi), );
> >
> > if (!ret) {
> >
> > int mux;
> > if (IS_ENABLED(CONFIG_MACH_SUNXI_H3_H5))
> >
> > @@ -332,8 +323,8 @@ int sunxi_simplefb_setup(void *blob)
> >
> > mux = 1;
> >
> > /* Skip simplefb setting if DE2 / HDMI is not present */
> >
> > - ret = uclass_find_device_by_name(UCLASS_VIDEO,
> > -"sunxi_de2", );
> > + ret = uclass_get_device_by_driver(UCLASS_VIDEO,
> > +
DM_DRIVER_GET(sunxi_de2), );
> >
> > if (ret) {
> >
> > debug("DE2 not present\n");
> > return 0;
> >
> > @@ -342,8 +333,8 @@ int sunxi_simplefb_setup(void *blob)
> >
> > return 0;
> >
> > }
> >
> > - ret = uclass_find_device_by_name(UCLASS_DISPLAY,
> > -"sunxi_dw_hdmi",
);
> > + ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
> > +
DM_DRIVER_GET(sunxi_dw_hdmi), );
> >
> > if (ret) {
> >
> > debug("HDMI not present\n");
> >
> > } else if (device_active(hdmi)) {
> >
> > @@ -355,8 +346,8 @@ int sunxi_simplefb_setup(void *blob)
> >
> > debug("HDMI present but not probed\n");
> >
> > }
> >
> > - ret = uclass_find_device_by_name(UCLASS_DISPLAY,
> > -"sunxi_lcd", );
> > + ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
> > +
DM_DRIVER_GET(sunxi_lcd), );
> >
> > if (ret)
> >
> > debug("LCD not present\n");
> >
> > else if (device_active(lcd))
Re: [PATCH 04/19] common: edid: extract code for detailed timing search
Dne četrtek, 04. marec 2021 ob 02:41:45 CET je Andre Przywara napisal(a):
> On Tue, 23 Feb 2021 21:46:16 +0100
>
> Jernej Skrabec wrote:
> > Code which searches for valid detailed timing entry will be used in more
> > places. Extract it.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > common/edid.c | 49 -
> > 1 file changed, 28 insertions(+), 21 deletions(-)
> >
> > diff --git a/common/edid.c b/common/edid.c
> > index 1cb7177742e8..a6c875d9c8e8 100644
> > --- a/common/edid.c
> > +++ b/common/edid.c
> > @@ -169,6 +169,29 @@ static bool cea_is_hdmi_vsdb_present(struct
> > edid_cea861_info *info)>
> > return false;
> >
> > }
> >
> > +static bool edid_find_valid_timing(void *buf, int count,
> > + struct display_timing *timing,
> > + bool (*mode_valid)(void *priv,
> > + const struct
display_timing *timing),
> > + void *mode_valid_priv)
> > +{
> > + struct edid_detailed_timing *t = buf;
> > + bool found = false;
> > + int i;
> > +
> > + for (i = 0; i < count && !found; i++, t++)
> > + if (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) != 0) {
>
> I am slightly puzzled, edid_detailed_timing is a different structure
> from edid_monitor_descriptor, as used below. Effectively the code
> checks in both cases for the first halfword to be not 0, but if this
> wasn't the correct structure before, and this is fixing it on the
> way, can you mention it in the commit message?
The thing is that descriptors can be either detailed timing descriptors or
display descriptor. So technically original code is ok - you can first cast
pointer to display descriptor and then check if that's true or not.
I'll mention this change in commit message anyway.
Best regards,
Jernej
>
> Other than that the code looks to be correctly refactored.
>
> Cheers,
> Andre
>
> > + decode_timing((u8 *)t, timing);
> > + if (mode_valid)
> > + found =
mode_valid(mode_valid_priv,
> > + timing);
> > + else
> > + found = true;
> > + }
> > +
> > + return found;
> > +}
> > +
> >
> > int edid_get_timing_validate(u8 *buf, int buf_size,
> >
> > struct display_timing *timing,
> > int *panel_bits_per_colourp,
> >
> > @@ -177,8 +200,7 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
> >
> > void *mode_valid_priv)
> >
> > {
> >
> > struct edid1_info *edid = (struct edid1_info *)buf;
> >
> > - bool timing_done;
> > - int i;
> > + bool found;
> >
> > if (buf_size < sizeof(*edid) || edid_check_info(edid)) {
> >
> > debug("%s: Invalid buffer\n", __func__);
> >
> > @@ -195,25 +217,10 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
> >
> > return -ENOENT;
> >
> > }
> >
> > - /* Look for detailed timing */
> > - timing_done = false;
> > - for (i = 0; i < 4; i++) {
> > - struct edid_monitor_descriptor *desc;
> > -
> > - desc = >monitor_details.descriptor[i];
> > - if (desc->zero_flag_1 != 0) {
> > - decode_timing((u8 *)desc, timing);
> > - if (mode_valid)
> > - timing_done =
mode_valid(mode_valid_priv,
> > -
timing);
> > - else
> > - timing_done = true;
> > -
> > - if (timing_done)
> > - break;
> > - }
> > - }
> > - if (!timing_done)
> > + /* Look for detailed timing in base EDID */
> > + found = edid_find_valid_timing(edid->monitor_details.descriptor, 4,
> > + timing, mode_valid,
mode_valid_priv);
> > + if (!found)
> >
> > return -EINVAL;
> >
> > if (edid->version != 1 || edid->revision < 4) {
Re: Re: [PATCH 07/19] video: sunxi: Remove check for ddc-i2c-bus property
Hi! Dne četrtek, 04. marec 2021 ob 02:42:21 CET je Andre Przywara napisal(a): > On Tue, 23 Feb 2021 21:46:19 +0100 > Jernej Skrabec wrote: > > > No Allwinner boards with DW-HDMI controller use separate I2C bus for > > EDID read. Remove that check. > > Apparently the Cubieboard 4 has (as the only Allwinner board I can > find in the dts directories), but that is not supported by this driver, > and possibly doesn't even have a DW controller. Cubieboard 4 uses this property for VGA. A80 really has DW-HDMI but it uses dedicated DDC lines. Best regards, Jernej > > > Signed-off-by: Jernej Skrabec > > Reviewed-by: Andre Przywara > > Cheers, > Andre > > > --- > > drivers/video/sunxi/sunxi_dw_hdmi.c | 3 --- > > 1 file changed, 3 deletions(-) > > > > diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c b/drivers/video/sunxi/ sunxi_dw_hdmi.c > > index 37e78ff24111..6d2bc206fc2c 100644 > > --- a/drivers/video/sunxi/sunxi_dw_hdmi.c > > +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c > > @@ -361,9 +361,6 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev) > > return -1; > > } > > > > - uclass_get_device_by_phandle(UCLASS_I2C, dev, "ddc-i2c-bus", > > ->hdmi.ddc_bus); > > - > > dw_hdmi_init(>hdmi); > > > > return 0; > >
Re: [PATCH 06/19] video: sunxi: Use DW-HDMI hpd function
Dne četrtek, 04. marec 2021 ob 02:42:08 CET je Andre Przywara napisal(a):
> On Tue, 23 Feb 2021 21:46:18 +0100
>
> Jernej Skrabec wrote:
> > It turns out that even though A64, H3 and H5 have custom PHY, standard
> > hot plug detection for DW-HDMI works just fine.
>
> But the generic code looks for a different bit in a different register,
> doesn't it?
Yes.
> I see SUNXI_HDMI_BASE + 0x1 + 56, bit 19 before vs.
> SUNXI_HDMI_BASE + 0x3004, bit 2 in the new code.
>
> Is that duplicated functionality in the AW PHY?
Yes.
Linux driver uses standard way and it works just fine, so there is no real
reason not to use standard way here too.
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > Remove custom hpd method to reduce amount of custom code.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/video/sunxi/sunxi_dw_hdmi.c | 34 +
> > 1 file changed, 6 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
> > b/drivers/video/sunxi/sunxi_dw_hdmi.c index e3811a2ec15f..37e78ff24111
> > 100644
> > --- a/drivers/video/sunxi/sunxi_dw_hdmi.c
> > +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
> > @@ -114,28 +114,6 @@ static void sunxi_dw_hdmi_phy_init(void)
> >
> > writel(0x42494E47, >unscramble);
> >
> > }
> >
> > -static int sunxi_dw_hdmi_get_plug_in_status(void)
> > -{
> > - struct sunxi_hdmi_phy * const phy =
> > - (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE +
HDMI_PHY_OFFS);
> > -
> > - return !!(readl(>status) & (1 << 19));
> > -}
> > -
> > -static int sunxi_dw_hdmi_wait_for_hpd(void)
> > -{
> > - ulong start;
> > -
> > - start = get_timer(0);
> > - do {
> > - if (sunxi_dw_hdmi_get_plug_in_status())
> > - return 0;
> > - udelay(100);
> > - } while (get_timer(start) < 300);
> > -
> > - return -1;
> > -}
> > -
> >
> > static void sunxi_dw_hdmi_phy_set(uint clock, int phy_div)
> > {
> >
> > struct sunxi_hdmi_phy * const phy =
> >
> > @@ -370,12 +348,6 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
> >
> > sunxi_dw_hdmi_phy_init();
> >
> > - ret = sunxi_dw_hdmi_wait_for_hpd();
> > - if (ret < 0) {
> > - debug("hdmi can not get hpd signal\n");
> > - return -1;
> > - }
> > -
> >
> > priv->hdmi.ioaddr = SUNXI_HDMI_BASE;
> > priv->hdmi.i2c_clk_high = 0xd8;
> > priv->hdmi.i2c_clk_low = 0xfe;
> >
> > @@ -383,6 +355,12 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
> >
> > priv->hdmi.phy_set = sunxi_dw_hdmi_phy_cfg;
> > priv->mux = uc_plat->source_id;
> >
> > + ret = dw_hdmi_phy_wait_for_hpd(>hdmi);
> > + if (ret < 0) {
> > + debug("hdmi can not get hpd signal\n");
> > + return -1;
> > + }
> > +
> >
> > uclass_get_device_by_phandle(UCLASS_I2C, dev, "ddc-i2c-bus",
> >
> > >hdmi.ddc_bus);
Re: [linux-sunxi] [PATCH 14/19] video: sunxi: dw-hdmi: rework PHY initialization
Hi! Dne torek, 23. februar 2021 ob 21:46:26 CET je Jernej Skrabec napisal(a): > Now that bit meanings are somewhat known, rework PHY initialization. > This is modelled after Linux driver. > > Signed-off-by: Jernej Skrabec > --- > drivers/video/sunxi/sunxi_dw_hdmi.c | 411 +++- > 1 file changed, 279 insertions(+), 132 deletions(-) If you all agree, I would replace this patch with new, proper PHY driver. This would match DT structure and allow to init clocks and resets based on DT info. Best regards, Jernej
Re: [PATCH v3] video: sunxi_display: Convert to DM_VIDEO
Dne petek, 05. februar 2021 ob 02:07:48 CET je Andre Przywara napisal(a): > From: Jagan Teki > > DM_VIDEO migration deadline is already expired, but around > 80 Allwinner boards are still using video in a legacy way. > > = WARNING == > This board does not use CONFIG_DM_VIDEO Please update > the board to use CONFIG_DM_VIDEO before the v2019.07 release. > Failure to update by the deadline may result in board removal. > See doc/driver-model/migration.rst for more info. > > > Convert the legacy video driver over to the DM_VIDEO framework. This is > a minimal conversion: it doesn't use the DT for finding its resources, > nor does it use DM clocks or DM devices for the outputs (LCD, HDMI, CVBS). > > Tested in Bananapi M1+ Plus 1920x1200 HDMI out. (Jagan) > > Signed-off-by: Jagan Teki > [Andre: rebase and smaller fixes] > Signed-off-by: Andre Przywara > --- > Hi, > > I picked this one up to get rid of the warnings. I dropped the BMP > support for now (v2 1/3 and v2 2/3), I need to have a closer look, as > I am not convinced this was the right solution. > > Cheers, > Andre > > Changelog v2 .. v3: > - rebase against master, fixing up renamed variables and structs > - replace enum with #define > - remove BMP from Kconfig > - fix memory node size calculation in simplefb setup > > arch/arm/mach-sunxi/Kconfig | 9 +- > drivers/video/sunxi/sunxi_display.c | 262 > include/configs/sunxi-common.h | 17 -- > scripts/config_whitelist.txt| 1 - > 4 files changed, 157 insertions(+), 132 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 0135575ca1e..a29d11505aa 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -816,13 +816,14 @@ config VIDEO_SUNXI > depends on !MACH_SUN9I > depends on !MACH_SUN50I > depends on !SUN50I_GEN_H6 > - select VIDEO > + select DM_VIDEO > + select DISPLAY > imply VIDEO_DT_SIMPLEFB > default y > ---help--- > - Say Y here to add support for using a cfb console on the HDMI, LCD > - or VGA output found on most sunxi devices. See doc/README.video for > - info on how to select the video output and mode. > + Say Y here to add support for using a graphical console on the HDMI, > + LCD or VGA output found on older sunxi devices. This will also provide > + a simple_framebuffer device for Linux. > > config VIDEO_HDMI > bool "HDMI output support" > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index 000f3864702..97661329ba4 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -256,23 +256,6 @@ extern int soft_i2c_gpio_scl; > #endif > #endif /* ifdef CONFIG_REQUIRE_SERIAL_CONSOLE */ > > -#ifdef CONFIG_VIDEO_SUNXI > -/* > - * The amount of RAM to keep free at the top of RAM when relocating u-boot, > - * to use as framebuffer. This must be a multiple of 4096. > - */ > -#define CONFIG_SUNXI_MAX_FB_SIZE (16 << 20) > - > -#define CONFIG_VIDEO_LOGO > -#define CONFIG_VIDEO_STD_TIMINGS > -#define CONFIG_I2C_EDID > -#define VIDEO_LINE_LEN (pGD->plnSizeX) > - > -/* allow both serial and cfb console. */ > -/* stop x86 thinking in cfbconsole from trying to init a pc keyboard */ > - > -#endif /* CONFIG_VIDEO_SUNXI */ > - > /* Ethernet support */ > > #ifdef CONFIG_USB_EHCI_HCD This file has another ifdef which can be removed (#ifdef CONFIG_VIDEO). After that, Reviewed-by: Jernej Skrabec Best regards, Jernej > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > index c6a83124956..ed469f74034 100644 > --- a/scripts/config_whitelist.txt > +++ b/scripts/config_whitelist.txt > @@ -1661,7 +1661,6 @@ CONFIG_STV0991 > CONFIG_STV0991_HZ > CONFIG_STV0991_HZ_CLOCK > CONFIG_ST_SMI > -CONFIG_SUNXI_MAX_FB_SIZE > CONFIG_SXNI855T > CONFIG_SYSFLAGS_ADDR > CONFIG_SYSFS > -- > 2.17.5 > >
Re: [PATCH] sunxi: spl: Fix H616 clock initialization
Dne ponedeljek, 01. februar 2021 ob 01:46:22 CET je Andre Przywara napisal(a):
> On Sun, 31 Jan 2021 21:25:39 +0100
> Jernej Skrabec wrote:
>
> Hi Jernej,
>
> > It turns out that there is a magic bit in PRCM region which seemingly
> > makes PLLs work if it's enabled. Sadly, there is no documentation what
> > it does exactly, so we'll just mimick BSP boot0 behaviour and enable it
> > before any clock is set up.
>
> Good job of figuring this out!
>
> > Fixes: b18bd53d6cde ("sunxi: introduce support for H616 clocks")
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/mach-sunxi/clock_sun50i_h6.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > b/arch/arm/mach-sunxi/clock_sun50i_h6.c index 06d84eb158d7..68c8e7f2afbe
> > 100644
> > --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > @@ -9,6 +9,12 @@ void clock_init_safe(void)
> >
> > {
> >
> > struct sunxi_ccm_reg *const ccm =
> >
> > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> >
> > +
> > +#ifdef CONFIG_MACH_SUN50I_H616
>
> Can you change this to: if (IS_ENABLED())?
ok.
>
> > + /* this seems to enable PLLs */
>
> Out of curiosity, what makes you think it's PLL related? At least the
> PERIPH0 and CPU PLLs seem to work without it?
Because I was able to configure TCON TOP -> TCON TV0 -> HDMI chain just fine,
but nothing would be shown on screen, not even test patterns from TCON. HDMI
itself worked ok (EDID could be read). I noticed that vblank interrupts were
not genereted. This and no image is consisted with disabling bus clock to TCON
and HDMI. I checked several times that clock configuration matches to that in
BSP... I also moved both to another PLL without success. Also, this bit was
discovered in function, which does clock initialization.
PLL cpu is always special case, otherwise nothing would work at boot. I have
no real explanation for PLL periph...
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > + setbits_le32(SUNXI_PRCM_BASE + 0x250, 0x10);
> > +#endif
> > +
> >
> > clock_set_pll1(40800);
> >
> > writel(CCM_PLL6_DEFAULT, >pll6_cfg);
Re: [PATCH v2 0/3] sunxi: OrangePi Zero 2: Ethernet support
Dne sreda, 27. januar 2021 ob 02:06:35 CET je Andre Przywara napisal(a): > The first two patches prepare the sun8i-emac driver to deal with the > EMAC as integrated into the H616 SoC. This IP block is compatible with > the A64 version, but the current driver prevents us from using that: > - The EPHY syscon register needs to have a bit cleared to select the > external PHY. On the A64 it is cleared on reset, but we should not > rely on that. The Linux driver does so as well. Fixed in patch 1/3. > - The pinmux setting is tied to the compatible string, but the H616 > requires a different value. Fixed in patch 2/3. > > The final patch enables Ethernet support for the OrangePi Zero 2 board, > which now works without further ado. This is cleaner and works for me, so for the whole series: Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Thanks! Best regards, Jernej > > Cheers, > Andre > > Andre Przywara (3): > net: sun8i-emac: Always clear syscon EPHY register > net: sun8i-emac: Determine pinmux based on SoC, not EMAC type > sunxi: OrangePi Zero 2: Enable Ethernet > > configs/orangepi_zero2_defconfig | 2 ++ > drivers/net/sun8i_emac.c | 59 ++-- > 2 files changed, 35 insertions(+), 26 deletions(-) > > -- > 2.17.5 > >
Re: [linux-sunxi] Re: [RFC PATCH] arm: EFI: Disallow EFI bootmgr when providing PSCI
Dne nedelja, 24. januar 2021 ob 09:33:15 CET je Jernej Škrabec napisal(a):
> Hi!
>
> Dne nedelja, 24. januar 2021 ob 09:27:02 CET je Heinrich Schuchardt
>
> napisal(a):
> > On 1/24/21 3:03 AM, Simon Glass wrote:
> > > On Fri, 22 Jan 2021 at 05:05, Andre Przywara
>
> wrote:
> > >> When "bootefi bootmgr" is run, it switches the CPU into non-secure
> > >> state. This breaks platforms like 32-bit Allwinner boards that rely on
> > >> running in secure state until late in the process, when they install
> > >> the PSCI handler in secure memory and drop into non-secure state.
> > >> They hang just before entering the kernel, after the "Starting the
> > >> kernel" message.
> >
> > Dear Andre,
> >
> > thank you for reporting the issue.
> >
> > I have an Orange Pi PC with a 32 bit Allwinner CPU.
> > orangepi_pc_defconfig has CONFIG_ARMV7_PSCI=y.
> >
> > I use origin/master (e716c9022970dac9b) and the Orange PI boots
> > successfully using GRUB EFI into Linux 5.9.
Just one clarification - issue here is that "bootefi bootmgr" command
when unsuccessful breaks booting with bootm command.
>
> I observed issue on OrangePi Plus2E which has eMMC. At that time, there was
> Android on it. If I disabled eMMC support in U-Boot, boot went just fine.
>
> > But I observe that it takes around 60 seconds between
> > SetVirtualAddressMap() and the first kernel log output.
>
> I guess this is another issue. It never booted in my case. It stopped right
> after "Starting kernel...".
>
> Best regards,
> Jernej
>
> > EFI stub: Exiting boot services and installing virtual address map...
> >
> > EHCI failed to shut down host controller.
> > <<< 60 seconds waiting without output >>>>
> >
> > [0.00] Booting Linux on physical CPU 0x0
> >
> > I have seen this regression since some time last year.
> >
> > Reverting patch f3866909e350 does not solve the problem.
> > Reverting to U-Boot v2020.01 does not solve the problem.
> >
> > Reverting the kernel from v5.9 to 5.4 solves the problem both for U-Boot
> > v2020.01 as well as for U-Boot v2021.01.
> >
> > I have poked around with some pre-built kernels from
> > http://snapshot.debian.org/package/linux:
> >
> > Linux 5.9.11 - 1 minute delay
> > Linux 5.8.14 - 1 minute delay
> > Linux 5.7.17 - no delay
> > Linux 5.6.14 - no delay
> > Linux 5.5.17 - no delay
> > Linux 5.4.19 - no delay
> >
> > It seems that some change in Linux is causing the regression. Could you,
> > please, try to analyze it in more depth.
> >
> > Best regards
> >
> > Heinrich
> >
> > >> Commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without
> > >> having /EFI/boot") changed the order of EFI probing, so the EFI bootmgr
> > >> is now *always* run, resulting in the default distro boot commands now
> > >> *always* failing, even in the total absence of any UEFI directories or
> > >> boot files.
> > >>
> > >> So use the newly added build option to disable the EFI bootmgr, which
> > >> makes those boards boot again using the distro boot commands.
> > >> Explicitly calling "bootefi bootmgr" still breaks the boot, though.
> > >>
> > >> Signed-off-by: Andre Przywara
> > >> Reported-by: Jernej Skrabec
> > >> ---
> > >> Hi,
> > >>
> > >> the above is the result of my analysis, happy to stand corrected in
> > >> case I missed something. I know that this is not a proper solution,
> > >> but it's an effective stop-gap measure to fix all those boards. It
> > >> looks
> > >> like a proper solution would either be:
> > >> - Let the EFI bootmgr run in the current security state.
> > >> - Install the PSCI handlers early in U-Boot.
> > >>
> > >> Both solutions sound rather involved, so probably require more time.
> > >> But we need to fix this breakage now.
> > >>
> > >> Cheers,
> > >> Andre
> > >>
> > >> lib/efi_loader/Kconfig | 1 +
> > >> 1 file changed, 1 insertion(+)
> > >
> > > Reviewed-by: Simon Glass
Re: [RFC PATCH] arm: EFI: Disallow EFI bootmgr when providing PSCI
Hi!
Dne nedelja, 24. januar 2021 ob 09:27:02 CET je Heinrich Schuchardt
napisal(a):
> On 1/24/21 3:03 AM, Simon Glass wrote:
> > On Fri, 22 Jan 2021 at 05:05, Andre Przywara
wrote:
> >> When "bootefi bootmgr" is run, it switches the CPU into non-secure
> >> state. This breaks platforms like 32-bit Allwinner boards that rely on
> >> running in secure state until late in the process, when they install
> >> the PSCI handler in secure memory and drop into non-secure state.
> >> They hang just before entering the kernel, after the "Starting the
> >> kernel" message.
>
> Dear Andre,
>
> thank you for reporting the issue.
>
> I have an Orange Pi PC with a 32 bit Allwinner CPU.
> orangepi_pc_defconfig has CONFIG_ARMV7_PSCI=y.
>
> I use origin/master (e716c9022970dac9b) and the Orange PI boots
> successfully using GRUB EFI into Linux 5.9.
I observed issue on OrangePi Plus2E which has eMMC. At that time, there was
Android on it. If I disabled eMMC support in U-Boot, boot went just fine.
>
> But I observe that it takes around 60 seconds between
> SetVirtualAddressMap() and the first kernel log output.
I guess this is another issue. It never booted in my case. It stopped right
after "Starting kernel...".
Best regards,
Jernej
>
> EFI stub: Exiting boot services and installing virtual address map...
>
> EHCI failed to shut down host controller.
> <<< 60 seconds waiting without output
>
> [0.00] Booting Linux on physical CPU 0x0
>
> I have seen this regression since some time last year.
>
> Reverting patch f3866909e350 does not solve the problem.
> Reverting to U-Boot v2020.01 does not solve the problem.
>
> Reverting the kernel from v5.9 to 5.4 solves the problem both for U-Boot
> v2020.01 as well as for U-Boot v2021.01.
>
> I have poked around with some pre-built kernels from
> http://snapshot.debian.org/package/linux:
>
> Linux 5.9.11 - 1 minute delay
> Linux 5.8.14 - 1 minute delay
> Linux 5.7.17 - no delay
> Linux 5.6.14 - no delay
> Linux 5.5.17 - no delay
> Linux 5.4.19 - no delay
>
> It seems that some change in Linux is causing the regression. Could you,
> please, try to analyze it in more depth.
>
> Best regards
>
> Heinrich
>
> >> Commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without
> >> having /EFI/boot") changed the order of EFI probing, so the EFI bootmgr
> >> is now *always* run, resulting in the default distro boot commands now
> >> *always* failing, even in the total absence of any UEFI directories or
> >> boot files.
> >>
> >> So use the newly added build option to disable the EFI bootmgr, which
> >> makes those boards boot again using the distro boot commands.
> >> Explicitly calling "bootefi bootmgr" still breaks the boot, though.
> >>
> >> Signed-off-by: Andre Przywara
> >> Reported-by: Jernej Skrabec
> >> ---
> >> Hi,
> >>
> >> the above is the result of my analysis, happy to stand corrected in
> >> case I missed something. I know that this is not a proper solution,
> >> but it's an effective stop-gap measure to fix all those boards. It looks
> >> like a proper solution would either be:
> >> - Let the EFI bootmgr run in the current security state.
> >> - Install the PSCI handlers early in U-Boot.
> >>
> >> Both solutions sound rather involved, so probably require more time.
> >> But we need to fix this breakage now.
> >>
> >> Cheers,
> >> Andre
> >>
> >> lib/efi_loader/Kconfig | 1 +
> >> 1 file changed, 1 insertion(+)
> >
> > Reviewed-by: Simon Glass
Re: [PATCH v2 08/21] sunxi: introduce support for H616 clocks
Dne petek, 22. januar 2021 ob 02:17:30 CET je Andre Przywara napisal(a):
> On Mon, 11 Jan 2021 21:11:40 +0100
>
> Jernej Skrabec wrote:
> > H616 has mostly the same clocks as H6 with some small differences. Just
> > reuse H6 clocks for H616 and handle differences with macros.
> >
> > Reviewed-by: Samuel Holland
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > .../include/asm/arch-sunxi/clock_sun50i_h6.h | 18 +-
> > arch/arm/mach-sunxi/clock_sun50i_h6.c | 8 ++--
> > 2 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h index
> > e83e84ab6cab..62abfc4ef6bd 100644
> > --- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > +++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > @@ -230,6 +230,7 @@ struct sunxi_ccm_reg {
> >
> > #define CCM_PLL1_CTRL_EN BIT(31)
> > #define CCM_PLL1_LOCK_EN BIT(29)
> > #define CCM_PLL1_LOCK BIT(28)
> >
> > +#define CCM_PLL1_OUT_ENBIT(27)
> >
> > #define CCM_PLL1_CLOCK_TIME_2 (2 << 24)
> > #define CCM_PLL1_CTRL_P(p) ((p) << 16)
> > #define CCM_PLL1_CTRL_N(n) ((n) << 8)
> >
> > @@ -238,6 +239,7 @@ struct sunxi_ccm_reg {
> >
> > #define CCM_PLL5_CTRL_EN BIT(31)
> > #define CCM_PLL5_LOCK_EN BIT(29)
> > #define CCM_PLL5_LOCK BIT(28)
> >
> > +#define CCM_PLL5_OUT_ENBIT(27)
> >
> > #define CCM_PLL5_CTRL_N(n) ((n) << 8)
> > #define CCM_PLL5_CTRL_DIV1(div1) ((div1) << 0)
> > #define CCM_PLL5_CTRL_DIV2(div0) ((div0) << 1)
> >
> > @@ -252,7 +254,6 @@ struct sunxi_ccm_reg {
> >
> > #define CCM_PLL6_CTRL_DIV1_MASK(0x1 <<
CCM_PLL6_CTRL_DIV1_SHIFT)
> > #define CCM_PLL6_CTRL_DIV2_SHIFT 1
> > #define CCM_PLL6_CTRL_DIV2_MASK(0x1 <<
CCM_PLL6_CTRL_DIV2_SHIFT)
> >
> > -#define CCM_PLL6_DEFAULT 0xa0006300
> >
> > /* cpu_axi bit field*/
> > #define CCM_CPU_AXI_MUX_MASK (0x3 << 24)
> >
> > @@ -262,6 +263,9 @@ struct sunxi_ccm_reg {
> >
> > #define CCM_CPU_AXI_AXI_MASK 0x3
> > #define CCM_CPU_AXI_DEFAULT_FACTORS0x301
> >
> > +#ifdef CONFIG_MACH_SUN50I_H6
> > +#define CCM_PLL6_DEFAULT 0xa0006300
> > +
> >
> > /* psi_ahb1_ahb2 bit field */
> > #define CCM_PSI_AHB1_AHB2_DEFAULT 0x03000102
> >
> > @@ -270,6 +274,18 @@ struct sunxi_ccm_reg {
> >
> > /* apb1 bit field */
> > #define CCM_APB1_DEFAULT 0x03000102
> >
> > +#elif CONFIG_MACH_SUN50I_H616
> > +#define CCM_PLL6_DEFAULT 0xa8003100
> > +
> > +/* psi_ahb1_ahb2 bit field */
> > +#define CCM_PSI_AHB1_AHB2_DEFAULT 0x0302
>
> Why is this twice as fast, compared to the H6? It's based on the same
> PERI0(1X), which should be 600 MHz for both the H6 and H616, right?
>
> Is that the reset config or set up by the BROM? Or is that coming from
> some BSP source?
Actually I just dumped register when Android was running.
Best regards,
Jernej
>
> > +
> > +/* ahb3 bit field */
> > +#define CCM_AHB3_DEFAULT 0x0302
> > +
> > +/* apb1 bit field */
> > +#define CCM_APB1_DEFAULT 0x03000102
> > +#endif
> >
> > /* apb2 bit field */
> > #define APB2_CLK_SRC_OSC24M(0x0 << 24)
> >
> > diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > b/arch/arm/mach-sunxi/clock_sun50i_h6.c index 6bd466915c11..daca02019bab
> > 100644
> > --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > @@ -68,6 +68,9 @@ void clock_set_pll1(unsigned int clk)
> >
> > /* clk = 24*n/p, p is ignored if clock is >288MHz */
> > writel(CCM_PLL1_CTRL_EN | CCM_PLL1_LOCK_EN | CCM_PLL1_CLOCK_TIME_2
|
> >
> > +#ifdef CONFIG_MACH_SUN50I_H616
> > + CCM_PLL1_OUT_EN |
> > +#endif
> >
> >CCM_PLL1_CTRL_N(clk / 2400), >pll1_cfg);
> >
> > while (!(readl(>pll1_cfg) & CCM_PLL1_LOCK)) {}
> >
> > @@ -83,6 +86,7 @@ unsigned int clock_get_pll6(void)
> >
> > {
> >
> > struct sunxi_ccm_reg *const ccm =
> >
> > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> >
> > + int m = IS_ENABLED(CONFIG_MACH_SUN50I_H6) 4 : 2;
>
> This is missing the question mark, but that gets fixed up in a later
> patch, so I assume it's a rebase artifact. Will fix it up while
> committing.
>
> Cheers,
> Andre
>
> > uint32_t rval = readl(>pll6_cfg);
> > int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT);
> >
> > @@ -90,8 +94,8 @@ unsigned int clock_get_pll6(void)
> >
> > CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
> >
> > int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
> >
> > CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
> >
> > - /* The register defines PLL6-4X, not plain PLL6 */
> > - return 2400 / 4 * n / div1 / div2;
> > + /* The register defines
Re: [linux-sunxi] [PATCH] sunxi: Properly check for SATAPWR and MACPWR
Dne torek, 19. januar 2021 ob 02:05:20 CET je Andre Przywara napisal(a): > The #ifdef CONFIG_xxxPWR conditionals were not working as expected, as > string Kconfig symbols are always "defined" from the preprocessor's > perspective. This lead to unnecessary calls to the GPIO routines, but > also always added a half a second delay to wait for a SATA disk to power > up. Many thanks to Peter for pointing this out! > > Fix this by properly comparing the Kconfig symbols against the empty > string. strcmp() would be nicer for this, but GCC does not optimise this > away, probably due to our standalone compiler switches. > > Reported-by: Peter Robinson > Signed-off-by: Andre Przywara Nice find! Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v2 00/21] sunxi: Introduce H616 support
Dne ponedeljek, 11. januar 2021 ob 21:11:32 CET je Jernej Skrabec napisal(a): > This series introduces H616 support. Later patches add also OrangePi > Zero2 support but since H616 DT is not merged into Linux yet, I don't > expect them to land yet. > > Most patches are ready to land, except those which depends on non-upstreamed > DT yet. > > This series is based on u-boot-sunxi repo. Forgot to say that this series was also tested on H6 (OrangePi 3) to make sure it doesn't break anything. Best regards, Jernej > > Please take a look. > > Best regards, > Jernej > > Changes from v1: > - collected tags > - replaced AXP805 magic value with macro > - fixed H6 build (missing symbols after refactoring) > - removed premature SPI boot support > - add missing peripherals to prcm map > - reworked mmc sector calculation > - fixed comment in clock function > - used IS_ENABLED ternary instead of #if #else #endif > - renamed DRAM struct field to more meaningful name > - fixed missing space in Kconfig for DRAM symbol > - removed unused macro from sunxi-u-boot.dtsi > - removed padding definition for H616 > - added FEL support for H616 > - picked patches 1-2 from https://patchwork.ozlabs.org/project/uboot/list/? series=223600 > - added mmc support for H616 > > Andre Przywara (4): > sunxi: support loading with SPL > 32KB > mmc: sunxi: Refactor mod clock register offset > net: sun8i-emac: Always clear syscon EPHY register > net: sun8i-emac: Determine pinmux based on SoC, not EMAC type > > Jernej Skrabec (17): > sunxi: Add support for AXP305 PMIC > sunxi: Introduce common symbol for H6 like SoCs > mmc: sunxi: Replace H6 ifdefs with H6 gen macro > i2c: mvtwsi: sunxi: update macro > sunxi: prcm: Add memory map for H6 like SoCs > sunxi: Add support for I2C on H6 like SoCs > sunxi: introduce support for H616 clocks > sunxi: add support for H616 uart0 > sunxi: add support for R_I2C on H616 > sunxi: Add H616 DRAM support > sunxi: Add support for H616 SoC > mmc: sunxi: Add H616 clock offset > sunxi: Add H616 FEL support > arm: sunxi: add initial H616 DTSI and headers > sunxi: gpio: introduce compatible for H616 > clk: sunxi: Add support for H616 clocks > sunxi: Add support for OrangePi Zero2 > > arch/arm/cpu/armv8/fel_utils.S|5 +- > arch/arm/dts/Makefile |2 + > arch/arm/dts/sun50i-h616-orangepi-zero2.dts | 240 > arch/arm/dts/sun50i-h616.dtsi | 716 > arch/arm/dts/sunxi-u-boot.dtsi|8 + > arch/arm/include/asm/arch-sunxi/boot0.h |2 +- > arch/arm/include/asm/arch-sunxi/clock.h |2 +- > .../include/asm/arch-sunxi/clock_sun50i_h6.h | 19 +- > arch/arm/include/asm/arch-sunxi/cpu.h |2 +- > .../include/asm/arch-sunxi/cpu_sun50i_h6.h|7 + > arch/arm/include/asm/arch-sunxi/dram.h|2 + > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 159 +++ > arch/arm/include/asm/arch-sunxi/gpio.h|2 + > arch/arm/include/asm/arch-sunxi/mmc.h |2 +- > arch/arm/include/asm/arch-sunxi/prcm.h| 249 +--- > arch/arm/include/asm/arch-sunxi/prcm_sun50i.h | 47 + > arch/arm/include/asm/arch-sunxi/prcm_sun6i.h | 247 > arch/arm/include/asm/arch-sunxi/timer.h |2 +- > arch/arm/mach-sunxi/Kconfig | 75 +- > arch/arm/mach-sunxi/Makefile |4 +- > arch/arm/mach-sunxi/board.c | 24 +- > arch/arm/mach-sunxi/clock_sun50i_h6.c | 37 +- > arch/arm/mach-sunxi/cpu_info.c|2 + > arch/arm/mach-sunxi/dram_sun50i_h616.c| 1023 + > arch/arm/mach-sunxi/dram_timings/Makefile |2 + > .../mach-sunxi/dram_timings/h616_ddr3_1333.c | 94 ++ > arch/arm/mach-sunxi/pmic_bus.c|6 + > arch/arm/mach-sunxi/rmr_switch.S |2 +- > board/sunxi/MAINTAINERS |5 + > board/sunxi/board.c | 14 +- > common/spl/Kconfig|7 +- > configs/orangepi_zero2_defconfig | 15 + > drivers/clk/sunxi/Kconfig |7 + > drivers/clk/sunxi/Makefile|1 + > drivers/clk/sunxi/clk_h616.c | 120 ++ > drivers/gpio/sunxi_gpio.c |1 + > drivers/i2c/mvtwsi.c |2 +- > drivers/mmc/sunxi_mmc.c | 97 +- > drivers/net/sun8i_emac.c | 59 +- > drivers/power/Kconfig | 14 +- > drivers/power/Makefile|1 + > drivers/power/axp305.c| 83 ++ > include/axp305.h | 17 + > include/axp_pmic.h|3 + > include/configs/sun50i.h |2 +- > include/configs/sunxi-common.h|7 + >
Re: Re: [PATCH 01/17] sunxi: Add support for AXP305 PMIC
Dne ponedeljek, 11. januar 2021 ob 01:02:07 CET je André Przywara napisal(a): > On 03/01/2021 09:26, Jernej Skrabec wrote: > > This PMIC can be found on H616 boards and it's very similar to AXP805 > > and AXP806. > >> Signed-off-by: Jernej Skrabec > > The existing sunxi PMIC code is the typical U-Boot mess, but I don't > want to block this series on a rework. I put some comments and ideas > below how to improve the whole "framework". > > For this actual patch I checked the bits against the AXP305 datasheet, > it does what we need. > > (reluctantly) > Reviewed-by: Andre Przywara > > Thanks, > Andre > > > --- > > arch/arm/mach-sunxi/pmic_bus.c | 6 +++ > > board/sunxi/board.c| 10 +++-- > > drivers/power/Kconfig | 13 +- > > drivers/power/Makefile | 1 + > > drivers/power/axp305.c | 80 ++ > > include/axp305.h | 17 > > include/axp_pmic.h | 3 ++ > > 7 files changed, 126 insertions(+), 4 deletions(-) > > create mode 100644 drivers/power/axp305.c > > create mode 100644 include/axp305.h > > > > diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/ pmic_bus.c > > index dea42de833f1..0394ce856448 100644 > > --- a/arch/arm/mach-sunxi/pmic_bus.c > > +++ b/arch/arm/mach-sunxi/pmic_bus.c > > @@ -18,6 +18,8 @@ > > > > #define AXP209_I2C_ADDR0x34 > > > > +#define AXP305_I2C_ADDR0x36 > > + > > #define AXP221_CHIP_ADDR 0x68 > > #define AXP221_CTRL_ADDR 0x3e > > #define AXP221_INIT_DATA 0x3e > > @@ -64,6 +66,8 @@ int pmic_bus_read(u8 reg, u8 *data) > > return i2c_read(AXP152_I2C_ADDR, reg, 1, data, 1); > > #elif defined CONFIG_AXP209_POWER > > return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1); > > +#elif defined CONFIG_AXP305_POWER > > + return i2c_read(AXP305_I2C_ADDR, reg, 1, data, 1); > > #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || > > defined CONFIG_AXP818_POWER > > # ifdef CONFIG_MACH_SUN6I > > return p2wi_read(reg, data); > > @@ -81,6 +85,8 @@ int pmic_bus_write(u8 reg, u8 data) > > return i2c_write(AXP152_I2C_ADDR, reg, 1, , 1); > > #elif defined CONFIG_AXP209_POWER > > return i2c_write(AXP209_I2C_ADDR, reg, 1, , 1); > > +#elif defined CONFIG_AXP305_POWER > > + return i2c_write(AXP305_I2C_ADDR, reg, 1, , 1); > > #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || > > defined CONFIG_AXP818_POWER > > # ifdef CONFIG_MACH_SUN6I > > return p2wi_write(reg, data); > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > > index 708a27ed78e9..54ff9bc92396 100644 > > --- a/board/sunxi/board.c > > +++ b/board/sunxi/board.c > > @@ -634,16 +634,18 @@ void sunxi_board_init(void) > > #endif > > This whole function is really a mess, but we can clean this up later. > I wonder if we can guard with the actual CONFIG_AXP_*_VOLT symbols > directly instead of specifying the list of PMICs requiring this rail > (this list is already in Kconfig). > Maybe with some macro magic to avoid the repetitions and move the ifdefs > out of the function? > power_failed |= axp_set_rail(dcdc1, DCDC1); > and assemble the function name and CONFIG_ symbol in that macro, plus > having the guard there? > > > > > #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \ > > - defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \ > > - defined CONFIG_AXP818_POWER > > + defined CONFIG_AXP221_POWER || defined CONFIG_AXP305_POWER || \ > > + defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER > > power_failed = axp_init(); > > > > #if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \ > > defined CONFIG_AXP818_POWER > > power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT); > > #endif > > +#if !defined(CONFIG_AXP305_POWER) > > power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT); > > power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT); > > +#endif > > #if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER) > > power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT); > > #endif > > @@ -656,8 +658,10 @@ void sunxi_board_init(void) > > defined CONFIG_AXP818_POWER > > power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT); > > #endif > > +#if !defined(CONFIG_AXP305_POWER) > > power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT); > > -#if !defined(CONFIG_AXP152_POWER) > > +#endif > > +#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER) > > power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT); > > #endif > > #ifdef CONFIG_AXP209_POWER > > Verified this hunk by playing CPP and removing all non-applicable calls. > This ended up in: > power_failed = axp_init(); > power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT); > > Which looks like the idea behind this patch, but is totally non-obvious > from the diff. Yes, that's correct. I wonder
Re: [PATCH 0/3] sunxi: Refactoring in prepration for H616
Dne ponedeljek, 11. januar 2021 ob 02:03:03 CET je Andre Przywara napisal(a): > Hi, > > I came up with those three patches to prepare for the H616. > Patch 1 simplifies the MMC driver, so the H616 support becomes a > one-liner. > Patch 2 cleans up the Ethernet driver, so we can support the same > compatible strings and fallbacks as Linux. > Patch 3 prepares the EMAC driver for the second EMAC (100MBit + internal > PHY). We need more code to actually use that PHY, but it's a start to > sort out the different syscon register offset. > > Jernej, please feel free to include those in your H616 series, at least > 1/3 and 2/3. Ok, I'll pick patch 1 and 2. Best regards, Jernej > > Cheers, > Andre > > Andre Przywara (3): > mmc: sunxi: Refactor mod clock register offset > net: sun8i-emac: Always clear syscon EPHY register > net: sun8i-emac: Simplify EPHY offset calculation > > drivers/mmc/sunxi_mmc.c | 84 +++- > drivers/net/sun8i_emac.c | 43 ++-- > 2 files changed, 44 insertions(+), 83 deletions(-) > > -- > 2.17.5 > >
Re: Re: [linux-sunxi] [PATCH 07/17] sunxi: support loading with SPL > 32KB
Dne ponedeljek, 04. januar 2021 ob 03:02:03 CET je Samuel Holland napisal(a):
> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> > From: Andre Przywara
> >
> > H616 supports and needs bigger SPL than 32 KiB, mostly due to big DRAM
> > driver and need for PMIC configuration, which pull several drivers which
> > are not needed otherwise.
> >
> > Signed-off-by: Andre Przywara
> > Signed-off-by: Jernej Skrabec
> > ---
> > arch/arm/mach-sunxi/board.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> > index 7a8b303f233c..296efd615769 100644
> > --- a/arch/arm/mach-sunxi/board.c
> > +++ b/arch/arm/mach-sunxi/board.c
> > @@ -277,6 +277,14 @@ uint32_t sunxi_get_boot_device(void)
> > }
> >
> > #ifdef CONFIG_SPL_BUILD
> > +static u32 sunxi_get_spl_size(void)
> > +{
> > + if (!is_boot0_magic(SPL_ADDR + 4)) /* eGON.BT0 */
> > + return 32768;
> In the context of the suggestion below, this case could return 0.
>
> > +
> > + return readl(SPL_ADDR + 0x10);
> > +}
> > +
> > /*
> > * The eGON SPL image can be located at 8KB or at 128KB into an SD card
or
> > * an eMMC device. The boot source has bit 4 set in the latter case.
> > @@ -286,6 +294,7 @@ uint32_t sunxi_get_boot_device(void)
> > unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc)
>
> As a side note, the prototype for this function was changed in commit
> cf0082559698 ("spl: mmc: Fix spl_mmc_get_uboot_raw_sector()
> implementation"), but nobody noticed since it is not in a header.
>
> > {
> > unsigned long sector = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR;
> > + u32 spl_size = sunxi_get_spl_size();
> >
> > switch (sunxi_get_boot_source()) {
> > case SUNXI_BOOTED_FROM_MMC0_HIGH:
> > @@ -294,6 +303,9 @@ unsigned long spl_mmc_get_uboot_raw_sector(struct mmc
*mmc)
> > break;
> > }
> >
> > + if (spl_size > 32768)
> > + sector += (spl_size - 32768) / 512;
> > +
>
> What I would suggest doing instead of this is setting
> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x40,
> SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0x10, and then before the
> switch statement doing:
>
> sector = max(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR,
> spl_size / 512);
>
> Not only does this get rid of the magic 32768 constant (which is
> meaningless on new platforms), but it also works cleanly for eMMC boot
> partitions (where there's no 0x10 sector offset).
Thanks for the suggestion, this is indeed much cleaner.
Best regards,
Jernej
>
> > return sector;
> > }
> >
> >
>
> Cheers,
> Samuel
>
Re: Re: [linux-sunxi] [PATCH 05/17] sunxi: prcm: Add memory map for H6 like SoCs
Dne ponedeljek, 04. januar 2021 ob 01:03:17 CET je Samuel Holland napisal(a): > On 1/3/21 3:26 AM, Jernej Skrabec wrote: > > There was no need to have prcm definitions for H6 and similar SoCs till > > now. However, support R_I2C will be needed soon in SPL. > > > > Move old definitions to prcm_sun6i.h and add new ones in prcm_sun50i.h. > > One of those files will be selected in common prcm.h based on defined > > macros. > > > > This commit doesn't do any functional change. > > > > Signed-off-by: Jernej Skrabec > > --- > > arch/arm/include/asm/arch-sunxi/prcm.h| 249 +- > > arch/arm/include/asm/arch-sunxi/prcm_sun50i.h | 41 +++ > > arch/arm/include/asm/arch-sunxi/prcm_sun6i.h | 247 + > > 3 files changed, 298 insertions(+), 239 deletions(-) > > create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun50i.h > > create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun6i.h > > > > diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h b/arch/arm/include/asm/ arch-sunxi/prcm.h > > index 767d1ff98d74..5106076f5e91 100644 > > --- a/arch/arm/include/asm/arch-sunxi/prcm.h > > +++ b/arch/arm/include/asm/arch-sunxi/prcm.h > > @@ -1,247 +1,18 @@ > > /* SPDX-License-Identifier: GPL-2.0+ */ > > /* > > - * Sunxi A31 Power Management Unit register definition. > > + * (C) Copyright 2020 Jernej Skrabec > > * > > - * (C) Copyright 2013 Oliver Schinagl > > - * http://linux-sunxi.org > > - * Allwinner Technology Co., Ltd. > > - * Berg Xing > > - * Tom Cubie > > + * Sunxi platform prcm register definition. > > */ > > > > #ifndef _SUNXI_PRCM_H > > #define _SUNXI_PRCM_H > > > > -#define __PRCM_CPUS_CFG_PRE(n) (((n) & 0x3) << 4) > > -#define PRCM_CPUS_CFG_PRE_MASK __PRCM_CPUS_CFG_PRE(0x3) > > -#define __PRCM_CPUS_CFG_PRE_DIV(n) (((n) >> 1) - 1) > > -#define PRCM_CPUS_CFG_PRE_DIV(n) \ > > - __PRCM_CPUS_CFG_PRE(__PRCM_CPUS_CFG_CLK_PRE(n)) > > -#define __PRCM_CPUS_CFG_POST(n) (((n) & 0x1f) << 8) > > -#define PRCM_CPUS_CFG_POST_MASK __PRCM_CPUS_CFG_POST(0x1f) > > -#define __PRCM_CPUS_CFG_POST_DIV(n) ((n) - 1) > > -#define PRCM_CPUS_CFG_POST_DIV(n) \ > > - __PRCM_CPUS_CFG_POST_DIV(__PRCM_CPUS_CFG_POST_DIV(n)) > > -#define __PRCM_CPUS_CFG_CLK_SRC(n) (((n) & 0x3) << 16) > > -#define PRCM_CPUS_CFG_CLK_SRC_MASK __PRCM_CPUS_CFG_CLK_SRC(0x3) > > -#define __PRCM_CPUS_CFG_CLK_SRC_LOSC 0x0 > > -#define __PRCM_CPUS_CFG_CLK_SRC_HOSC 0x1 > > -#define __PRCM_CPUS_CFG_CLK_SRC_PLL6 0x2 > > -#define __PRCM_CPUS_CFG_CLK_SRC_PDIV 0x3 > > -#define PRCM_CPUS_CFG_CLK_SRC_LOSC \ > > - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_LOSC) > > -#define PRCM_CPUS_CFG_CLK_SRC_HOSC \ > > - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_HOSC) > > -#define PRCM_CPUS_CFG_CLK_SRC_PLL6 \ > > - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PLL6) > > -#define PRCM_CPUS_CFG_CLK_SRC_PDIV \ > > - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PDIV) > > - > > -#define __PRCM_APB0_RATIO(n) (((n) & 0x3) << 0) > > -#define PRCM_APB0_RATIO_DIV_MASK __PRCM_APB0_RATIO_DIV(0x3) > > -#define __PRCM_APB0_RATIO_DIV(n) (((n) >> 1) - 1) > > -#define PRCM_APB0_RATIO_DIV(n) \ > > - __PRCM_APB0_RATIO(__PRCM_APB0_RATIO_DIV(n)) > > - > > -#define PRCM_CPU_CFG_NEON_CLK_EN (0x1 << 0) > > -#define PRCM_CPU_CFG_CPU_CLK_EN (0x1 << 1) > > - > > -#define PRCM_APB0_GATE_PIO (0x1 << 0) > > -#define PRCM_APB0_GATE_IR (0x1 << 1) > > -#define PRCM_APB0_GATE_TIMER01 (0x1 << 2) > > -#define PRCM_APB0_GATE_P2WI (0x1 << 3) /* sun6i */ > > -#define PRCM_APB0_GATE_RSB (0x1 << 3) /* sun8i */ > > -#define PRCM_APB0_GATE_UART (0x1 << 4) > > -#define PRCM_APB0_GATE_1WIRE (0x1 << 5) > > -#define PRCM_APB0_GATE_I2C (0x1 << 6) > > - > > -#define PRCM_APB0_RESET_PIO (0x1 << 0) > > -#define PRCM_APB0_RESET_IR (0x1 << 1) > > -#define PRCM_APB0_RESET_TIMER01 (0x1 << 2) > > -#define PRCM_APB0_RESET_P2WI (0x1 << 3) > > -#define PRCM_APB0_RESET_UART (0x1 << 4) > > -#define PRCM_APB0_RESET_1WIRE (0x1 << 5) > > -#define PRCM_APB0_RESET_I2C (0x1 << 6) > > - > > -#define PRCM_PLL_CTRL_PLL_BIAS (0x1 << 0) > > -#define PRCM_PLL_CTRL_HOSC_GAIN_ENH (0x1 << 1) > > -#define __PRCM_PLL_CTRL_USB_CLK_SRC(n) (((n) & 0x3) << 4) > > -#define PRCM_PLL_CTRL_USB_CLK_SRC_MASK \ > > - __PRCM_PLL_CTRL_USB_CLK_SRC(0x3) > > -#define __PRCM_PLL_CTRL_USB_CLK_0 0x0 > > -#define __PRCM_PLL_CTRL_USB_CLK_1 0x1 > > -#define __PRCM_PLL_CTRL_USB_CLK_2 0x2 > > -#define __PRCM_PLL_CTRL_USB_CLK_3 0x3 > > -#define PRCM_PLL_CTRL_USB_CLK_0 \ > > - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_0) > > -#define PRCM_PLL_CTRL_USB_CLK_1 \ > > - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_1) > > -#define PRCM_PLL_CTRL_USB_CLK_2 \ > > - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_2) > > -#define PRCM_PLL_CTRL_USB_CLK_3 \ > > - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_3) > > -#define __PRCM_PLL_CTRL_INT_PLL_IN_SEL(n) (((n) & 0x3) << 12) > > -#define PRCM_PLL_CTRL_INT_PLL_IN_SEL_MASK \ > > -
Re: [PATCH v6 3/3] arm64: dts: sun50i: Add support for Orange Pi 3
Dne nedelja, 10. januar 2021 ob 20:29:39 CET je Jernej Skrabec napisal(a):
> From: Andre Heider
>
> dts file is taken from Linux 5.11-rc1 tag.
>
> The Bluetooth controller of this device ships with a default address,
> use the new CONFIG_FIXUP_BDADDR option to fix it up.
>
> akonadi:?collection=30=INBOX
Andre,
This ^ should be your tag. Can you fix it at committing?
Best regard,
Jernej
> Acked-by: Maxime Ripard
> Signed-off-by: Andre Heider
> [Updated OrangePi 3 DT, rebase and config update]
> Signed-off-by: Jernej Skrabec
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/sun50i-h6-orangepi-3.dts | 345 ++
> board/sunxi/MAINTAINERS | 5 +
> configs/orangepi_3_defconfig | 12 +
> 4 files changed, 363 insertions(+)
> create mode 100644 arch/arm/dts/sun50i-h6-orangepi-3.dts
> create mode 100644 configs/orangepi_3_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index e00aed1ec207..607571d04b25 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -605,6 +605,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
> sun50i-h5-orangepi-zero-plus2.dtb
> dtb-$(CONFIG_MACH_SUN50I_H6) += \
> sun50i-h6-beelink-gs1.dtb \
> + sun50i-h6-orangepi-3.dtb \
> sun50i-h6-orangepi-lite2.dtb \
> sun50i-h6-orangepi-one-plus.dtb \
> sun50i-h6-pine-h64.dtb \
> diff --git a/arch/arm/dts/sun50i-h6-orangepi-3.dts b/arch/arm/dts/sun50i-h6-
orangepi-3.dts
> new file mode 100644
> index ..15c9dd8c4479
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h6-orangepi-3.dts
> @@ -0,0 +1,345 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2019 Ondřej Jirman
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +#include "sun50i-h6-cpu-opp.dtsi"
> +
> +#include
> +
> +/ {
> + model = "OrangePi 3";
> + compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
> +
> + aliases {
> + serial0 =
> + serial1 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + connector {
> + compatible = "hdmi-connector";
> + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
> + ext_osc32k: ext_osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "ext_osc32k";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "orangepi:red:power";
> + gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4
*/
> + default-state = "on";
> + };
> +
> + status {
> + label = "orangepi:green:status";
> + gpios = <_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7
*/
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC jack */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +
> + reg_vcc33_wifi: vcc33-wifi {
> + /* Always on 3.3V regulator for WiFi and BT */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc33-wifi";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + vin-supply = <_vcc5v>;
> + };
> +
> + reg_vcc_wifi_io: vcc-wifi-io {
> + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-wifi-io";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + vin-supply = <_vcc33_wifi>;
> + };
> +
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = < 1>;
> + clock-names = "ext_clock";
> + reset-gpios = <_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> + post-power-on-delay-ms = <200>;
> + };
> +};
> +
> + {
> + cpu-supply = <_dcdca>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + mali-supply = <_dcdcc>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_out {
> + hdmi_out_con: endpoint {
> +
Re: Re: [PATCH] sunxi: dram: h6: Improve DDR3 config detection
Dne petek, 08. januar 2021 ob 03:01:42 CET je André Przywara napisal(a):
> On 03/12/2020 17:46, Jernej Skrabec wrote:
> > It turns out that in rare cases, current analytical approach to detect
> > correct DRAM bus width and rank on H6 doesn't work. On some TV boxes
> > with DDR3, incorrect DRAM configuration triggers write leveling error
> > which immediately stops initialization process. Exact reason why this
> > error appears isn't known. However, if correct configuration is used,
> > initalization works without problem.
> >
> > In order to fix this issue, simply try another configuration when any
> > kind of error appears during initialization, not just those related to
> > rank and bus width.
>
> It's a bummer that this auto detection doesn't work, it looked to be the
> right thing.
> But I prefer functionality over pipe dreams ;-)
>
> >
> > Tested-by: Thomas Graichen
> > Signed-off-by: Jernej Skrabec
> > ---
> > arch/arm/mach-sunxi/dram_sun50i_h6.c | 95 +++-
> > 1 file changed, 51 insertions(+), 44 deletions(-)
> >
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c b/arch/arm/mach-sunxi/
dram_sun50i_h6.c
> > index 9e34da474798..1cde6132be2c 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> > @@ -37,9 +37,9 @@
> >
> > static void mctl_sys_init(struct dram_para *para);
> > static void mctl_com_init(struct dram_para *para);
> > -static void mctl_channel_init(struct dram_para *para);
> > +static bool mctl_channel_init(struct dram_para *para);
> >
> > -static void mctl_core_init(struct dram_para *para)
> > +static bool mctl_core_init(struct dram_para *para)
> > {
> > mctl_sys_init(para);
> > mctl_com_init(para);
> > @@ -51,7 +51,7 @@ static void mctl_core_init(struct dram_para *para)
> > default:
> > panic("Unsupported DRAM type!");
> > };
> > - mctl_channel_init(para);
> > + return mctl_channel_init(para);
> > }
> >
> > /* PHY initialisation */
> > @@ -411,7 +411,7 @@ static void mctl_bit_delay_set(struct dram_para *para)
> > }
> > }
> >
> > -static void mctl_channel_init(struct dram_para *para)
> > +static bool mctl_channel_init(struct dram_para *para)
> > {
> > struct sunxi_mctl_com_reg * const mctl_com =
> > (struct sunxi_mctl_com_reg
*)SUNXI_DRAM_COM_BASE;
> > @@ -528,46 +528,15 @@ static void mctl_channel_init(struct dram_para
*para)
> > clrbits_le32(_phy->dx[i].gcr[3], ~0x3);
> > udelay(10);
> >
> > - if (readl(_phy->pgsr[0]) & 0x40)
> > - {
> > - /* Check for single rank and optionally half DQ. */
> > - if ((readl(_phy->dx[0].rsr[0]) & 0x3) == 2 &&
> > - (readl(_phy->dx[1].rsr[0]) & 0x3) == 2) {
> > - para->ranks = 1;
> > -
> > - if ((readl(_phy->dx[2].rsr[0]) & 0x3) !
= 2 ||
> > - (readl(_phy->dx[3].rsr[0]) & 0x3) !
= 2)
> > - para->bus_full_width = 0;
> > -
> > - /* Restart DRAM initialization from scratch.
*/
> > - mctl_core_init(para);
> > - return;
> > - }
> > -
> > - /*
> > -* Check for dual rank and half DQ. NOTE: This
combination
> > -* is highly unlikely and was not tested. Condition is
the
> > -* same as in libdram, though.
> > -*/
> > - if ((readl(_phy->dx[0].rsr[0]) & 0x3) == 0 &&
> > - (readl(_phy->dx[1].rsr[0]) & 0x3) == 0) {
> > - para->bus_full_width = 0;
> > -
> > - /* Restart DRAM initialization from scratch.
*/
> > - mctl_core_init(para);
> > - return;
> > - }
> > -
> > - panic("This DRAM setup is currently not supported.\n");
> > - }
> > -
> > if (readl(_phy->pgsr[0]) & 0xff0) {
> > /* Oops! There's something wrong! */
> > debug("PLL = %x\n", readl(0x3001010));
> > debug("DRAM PHY PGSR0 = %x\n", readl(_phy-
>pgsr[0]));
> > for (i = 0; i < 4; i++)
> > debug("DRAM PHY DX%dRSR0 = %x\n", i,
readl(_phy->dx[i].rsr[0]));
> > - panic("Error while initializing DRAM PHY!\n");
> > + debug("Error while initializing DRAM PHY!\n");
> > +
> > + return false;
> > }
> >
> > if (sunxi_dram_is_lpddr(para->type))
> > @@ -582,13 +551,54 @@ static void mctl_channel_init(struct dram_para
*para)
> > writel(0x, _com->maer0);
> > writel(0x7ff, _com->maer1);
> > writel(0x, _com->maer2);
> > +
> > + return true;
> > +}
> > +
> > +static void mctl_auto_detect_rank_width(struct dram_para *para)
> > +{
> > + /* this is minimum size that it's supported */
> > + para->cols = 8;
> > + para->rows = 13;
> > +
> > + /*
>
> Can you add here that former versions of this code tried to autodetect
> rank and width, but
Re: [linux-sunxi] [PATCH v4 0/3] tools/sunxi: Use mkimage for SPL generation
Dne sreda, 06. januar 2021 ob 10:24:35 CET je Andre Przywara napisal(a): > Hi, > > a small update fixing the strncpy bug and addressing too long DT names > properly. Thanks to Samuel for pointing this out. > == > > So far creating a bootable SPL image for Allwinner based boards uses > the mksunxiboot tool. Most other platforms seemed to have integrated this > kind of functionality into the common mkimage tool. > > Since there is nothing special about the Allwinner image in this respect, > just add support for the so-called "eGON" image type into mkimage. If there > was a particular reason this hasn't been done before, please let me know. > > This will eventually allow us to remove mksunxiboot, but I leave it around > for now in case of regressions and since some people depend on it from > external projects. > > Patch 1/3 splits some existing sunxi specific header file, so we can > share the eGON header definition between the tools and the SPL. > Patch 2/3 adds the actual support to mkimage, patch 3/3 then switches > the Makefile to use mkimage instead of mksunxiboot. > > I tested all 152 Allwinner boards by building each > u-boot-sunxi-with-spl.bin and comparing them against the version created > using mksunxiboot (using SOURCE_DATE_EPOCH and .scmversion to create > reproducible builds, and by reverting just patch 3/3). > All files before and after were identical. > > Cheers, > Andre Whole series is: Reviewed-by: Jernej Skrabec Best regards, Jernej > > Changelog v3 .. v4: > - properly check DT name length before inserting into header > > Changelog v2 .. v3: > - factor out eGON struct into separate header file > - only print extended header information when applicable > - remove redundant alignment > - minor cosmetic fixes > > Changelog v1 .. v2: > - Drop already merged cleanup patch (v1 1/3) > - replace relative include path > - remove already defined ALIGN macro > - rebase against current master > > Andre Przywara (3): > sunxi: Factor out eGON BROM header description > tools: mkimage: Add Allwinner eGON support > sunxi: Use mkimage for SPL boot image generation > > arch/arm/include/asm/arch-sunxi/spl.h | 65 +--- > common/image.c| 1 + > include/image.h | 1 + > include/sunxi_image.h | 82 > scripts/Makefile.spl | 8 +- > tools/Makefile| 1 + > tools/sunxi_egon.c| 136 ++ > 7 files changed, 226 insertions(+), 68 deletions(-) > create mode 100644 include/sunxi_image.h > create mode 100644 tools/sunxi_egon.c > > -- > 2.17.5 > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/msgid/ linux-sunxi/20210106092438.3438-1-andre.przywara%40arm.com. >
Re: Re: [PATCH v2 2/2] sunxi: Add support for Tanix TX6
Dne sreda, 06. januar 2021 ob 16:51:09 CET je André Przywara napisal(a):
> On 03/01/2021 10:00, Jernej Skrabec wrote:
> > This commit adds support for Tanix TX6 TV box, based on H6. It's low end
> > H6 board, with 3 GiB of RAM, eMMC, fast ethernet, USB, IR and other
> > peripherals.
> >
> > DT file is taken from Linux 5.11-rc1 release.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> > arch/arm/dts/Makefile| 3 +-
> > arch/arm/dts/sun50i-h6-tanix-tx6.dts | 124 +++
> > board/sunxi/MAINTAINERS | 6 ++
> > configs/tanix_tx6_defconfig | 11 +++
> > 4 files changed, 143 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/sun50i-h6-tanix-tx6.dts
> > create mode 100644 configs/tanix_tx6_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index fd47e408f826..e00aed1ec207 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -607,7 +607,8 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \
> > sun50i-h6-beelink-gs1.dtb \
> > sun50i-h6-orangepi-lite2.dtb \
> > sun50i-h6-orangepi-one-plus.dtb \
> > - sun50i-h6-pine-h64.dtb
> > + sun50i-h6-pine-h64.dtb \
> > + sun50i-h6-tanix-tx6.dtb
> > dtb-$(CONFIG_MACH_SUN50I) += \
> > sun50i-a64-amarula-relic.dtb \
> > sun50i-a64-bananapi-m64.dtb \
> > diff --git a/arch/arm/dts/sun50i-h6-tanix-tx6.dts b/arch/arm/dts/sun50i-h6-
tanix-tx6.dts
> > new file mode 100644
> > index ..be81330db14f
> > --- /dev/null
> > +++ b/arch/arm/dts/sun50i-h6-tanix-tx6.dts
> > @@ -0,0 +1,124 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (c) 2019 Jernej Skrabec
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h6.dtsi"
> > +#include "sun50i-h6-cpu-opp.dtsi"
> > +
> > +#include
> > +
> > +/ {
> > + model = "Tanix TX6";
> > + compatible = "oranth,tanix-tx6", "allwinner,sun50i-h6";
> > +
> > + aliases {
> > + serial0 =
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + connector {
> > + compatible = "hdmi-connector";
> > + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint =
<_out_con>;
> > + };
> > + };
> > + };
> > +
> > + reg_vcc3v3: vcc3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc3v3";
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> > + };
> > +
> > + reg_vdd_cpu_gpu: vdd-cpu-gpu {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vdd-cpu-gpu";
> > + regulator-min-microvolt = <1135000>;
> > + regulator-max-microvolt = <1135000>;
> > + };
> > +};
> > +
> > + {
> > + cpu-supply = <_vdd_cpu_gpu>;
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + mali-supply = <_vdd_cpu_gpu>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > +_out {
> > + hdmi_out_con: endpoint {
> > + remote-endpoint = <_con_in>;
> > + };
> > +};
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins>;
> > + vmmc-supply = <_vcc3v3>;
> > + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > +_ir {
> > + linux,rc-map-name = "rc-tanix-tx5max";
> > + status = "okay";
> > +};
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_ph_pins>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + dr_mode = "host";
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > index d3755ae41a9d..1b37a9899edd 100644
> > --- a/board/sunxi/MAINTAINERS
> > +++ b/board/sunxi/MAINTAINERS
> > @@ -489,6 +489,12 @@ S: Maintained
> > F: configs/Sunchip_CX-A99_defconfig
> > W: https://linux-sunxi.org/Sunchip_CX-A99
> >
> > +TANIX TX6 BOARD
> > +M: Jernej Skrabec
> > +S: Maintained
> > +F: configs/tanix_tx6_defconfig
> > +W: https://linux-sunxi.org/Tanix_TX6
> > +
> > TBS A711 BOARD
> > M: Maxime Ripard
> > S: Maintained
> > diff --git a/configs/tanix_tx6_defconfig b/configs/tanix_tx6_defconfig
> > new file mode 100644
> > index ..5b93d1c956fe
> > --- /dev/null
> > +++ b/configs/tanix_tx6_defconfig
> > @@ -0,0 +1,11 @@
> > +CONFIG_ARM=y
> > +CONFIG_ARCH_SUNXI=y
> > +CONFIG_SPL=y
> > +CONFIG_MACH_SUN50I_H6=y
> > +CONFIG_SUNXI_DRAM_H6_DDR3_1333=y
> > +CONFIG_DRAM_CLK=648
Re: Re: [PATCH v2 1/2] ARM: dts: sunxi: h6: Update DT files
Dne sreda, 06. januar 2021 ob 16:41:02 CET je André Przywara napisal(a):
> On 03/01/2021 10:00, Jernej Skrabec wrote:
> > Updated H6 DT files are based on Linux 5.11-rc1 release.
> >
> > Signed-off-by: Jernej Skrabec
>
> That looks alright, but it seems like the OrangePi One Plus .dts is not
> updated?
I missed that one.
Best regards,
Jernej
>
> Cheers,
> Andre
>
> > ---
> > arch/arm/dts/sun50i-h6-beelink-gs1.dts| 70 +++-
> > arch/arm/dts/sun50i-h6-cpu-opp.dtsi | 117 +++
> > arch/arm/dts/sun50i-h6-orangepi-lite2.dts | 71 +++-
> > arch/arm/dts/sun50i-h6-orangepi.dtsi | 72 +++-
> > arch/arm/dts/sun50i-h6-pine-h64.dts | 102 --
> > arch/arm/dts/sun50i-h6.dtsi | 394 --
> > 6 files changed, 758 insertions(+), 68 deletions(-)
> > create mode 100644 arch/arm/dts/sun50i-h6-cpu-opp.dtsi
> >
> > diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts b/arch/arm/dts/sun50i-
h6-beelink-gs1.dts
> > index 0dc33c90dd60..7c9dbde645b5 100644
> > --- a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > +++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> > @@ -1,11 +1,10 @@
> > -// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > -/*
> > - * Copyright (C) 2019 Clément Péron
> > - */
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2019 Clément Péron
> >
> > /dts-v1/;
> >
> > #include "sun50i-h6.dtsi"
> > +#include "sun50i-h6-cpu-opp.dtsi"
> >
> > #include
> >
> > @@ -25,6 +24,7 @@
> > connector {
> > compatible = "hdmi-connector";
> > type = "a";
> > + ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> >
> > port {
> > hdmi_con_in: endpoint {
> > @@ -33,6 +33,13 @@
> > };
> > };
> >
> > + ext_osc32k: ext_osc32k_clk {
> > + #clock-cells = <0>;
> > + compatible = "fixed-clock";
> > + clock-frequency = <32768>;
> > + clock-output-names = "ext_osc32k";
> > + };
> > +
> > leds {
> > compatible = "gpio-leds";
> >
> > @@ -51,12 +58,38 @@
> > regulator-max-microvolt = <500>;
> > regulator-always-on;
> > };
> > +
> > + sound-spdif {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,name = "sun50i-h6-spdif";
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <>;
> > + };
> > +
> > + simple-audio-card,codec {
> > + sound-dai = <_out>;
> > + };
> > + };
> > +
> > + spdif_out: spdif-out {
> > + #sound-dai-cells = <0>;
> > + compatible = "linux,spdif-dit";
> > + };
> > +};
> > +
> > + {
> > + cpu-supply = <_dcdca>;
> > };
> >
> > {
> > status = "okay";
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > {
> > status = "okay";
> > };
> > @@ -64,12 +97,17 @@
> > {
> > pinctrl-names = "default";
> > pinctrl-0 = <_rgmii_pins>;
> > - phy-mode = "rgmii";
> > + phy-mode = "rgmii-id";
> > phy-handle = <_rgmii_phy>;
> > phy-supply = <_aldo2>;
> > status = "okay";
> > };
> >
> > + {
> > + mali-supply = <_dcdcc>;
> > + status = "okay";
> > +};
> > +
> > {
> > status = "okay";
> > };
> > @@ -201,13 +239,16 @@
> > reg_dcdca: dcdca {
> > regulator-always-on;
> > regulator-min-microvolt =
<81>;
> > - regulator-max-microvolt =
<108>;
> > + regulator-max-microvolt =
<116>;
> > + regulator-ramp-delay = <2500>;
> > regulator-name = "vdd-cpu";
> > };
> >
> > reg_dcdcc: dcdcc {
> > + regulator-enable-ramp-delay =
<32000>;
> > regulator-min-microvolt =
<81>;
> > regulator-max-microvolt =
<108>;
> > + regulator-ramp-delay = <2500>;
> > regulator-name = "vdd-gpu";
> > };
> >
> > @@ -232,6 +273,11 @@
> > };
> > };
> >
> > +_ir {
> > + linux,rc-map-name = "rc-beelink-gs1";
> > + status = "okay";
> > +};
> > +
> > _pio {
> > /*
> > * PL0 and PL1 are used for PMIC I2C
> > @@ -243,6 +289,14 @@
> > vcc-pm-supply = <_aldo1>;
> > };
> >
> > + {
> > + clocks = <_osc32k>;
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > {
> > pinctrl-names = "default";
> > pinctrl-0 = <_ph_pins>;
> > @@ -258,3 +312,7 @@
> > usb0_vbus-supply = <_vcc5v>;
> > status = "okay";
> > };
> > +
> > + {
> > + status = "okay";
> > +};
> > diff --git a/arch/arm/dts/sun50i-h6-cpu-opp.dtsi b/arch/arm/dts/sun50i-h6-
cpu-opp.dtsi
> > new file mode 100644
> > index ..1a5eddc5a40f
> > --- /dev/null
> > +++
Re: [linux-sunxi] [PATCH 12/17] sunxi: Add support for H616 SoC
Dne ponedeljek, 04. januar 2021 ob 03:47:06 CET je Samuel Holland napisal(a):
> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> > H616 is very similar to H6 so most of the infrastructure can be reused.
> > However, two big differences are that it doesn't have functional SRAM A2
> > which is usually used for TF-A and it doesn't have ARISC co-processor.
> > It also needs bigger SPL size - 48 KiB.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/dts/sunxi-u-boot.dtsi | 9 +
> > arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h | 7 +++
> > arch/arm/mach-sunxi/Kconfig | 11 ++-
> > arch/arm/mach-sunxi/cpu_info.c | 2 ++
> > drivers/power/Kconfig | 1 +
> > include/configs/sunxi-common.h | 10 ++
> > 6 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/sunxi-u-boot.dtsi
> > b/arch/arm/dts/sunxi-u-boot.dtsi index c77cf7cacf0c..7e8644f390a8 100644
> > --- a/arch/arm/dts/sunxi-u-boot.dtsi
> > +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> > @@ -3,6 +3,9 @@
> >
> > #ifdef CONFIG_MACH_SUN50I_H6
> > #define BL31_ADDR 0x104000
> > #define SCP_ADDR 0x114000
> >
> > +#elif defined(CONFIG_MACH_SUN50I_H616)
> > +#define BL31_ADDR 0x40004000
> > +#define SCP_ADDR 0x028000
>
> There should be no SCP_ADDR if there is no SCP firmware.
Nice catch!
>
> > #else
> > #define BL31_ADDR 0x44000
> > #define SCP_ADDR 0x5
> >
> > @@ -61,6 +64,7 @@
> >
> > };
> >
> > };
> >
> > +#ifndef CONFIG_MACH_SUN50I_H616
> >
> > scp {
> >
> > description = "SCP
firmware";
> > type = "firmware";
> >
> > @@ -73,6 +77,7 @@
> >
> > missing-msg
= "scp-sunxi";
> >
> > };
> >
> > };
> >
> > +#endif
> >
> > @fdt-SEQ {
> >
> > description = "NAME";
> >
> > @@ -87,7 +92,11 @@
> >
> > @config-SEQ {
> >
> > description = "NAME";
> > firmware = "atf";
> >
> > +#ifdef CONFIG_MACH_SUN50I_H616
> > + loadables = "uboot";
> > +#else
> >
> > loadables = "scp",
"uboot";
> >
> > +#endif
> >
> > fdt = "fdt-SEQ";
> >
> > };
> >
> > };
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> > b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h index
> > 6392cb07b472..d9cf8ae04288 100644
> > --- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> > +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> > @@ -28,13 +28,20 @@
> >
> > #define SUNXI_GIC400_BASE 0x0302
> > #define SUNXI_IOMMU_BASE 0x030F
> >
> > +#ifdef CONFIG_MACH_SUN50I_H6
> >
> > #define SUNXI_DRAM_COM_BASE0x04002000
> > #define SUNXI_DRAM_CTL0_BASE 0x04003000
> > #define SUNXI_DRAM_PHY0_BASE 0x04005000
> >
> > +#endif
> >
> > #define SUNXI_NFC_BASE 0x04011000
> > #define SUNXI_MMC0_BASE0x0402
> > #define SUNXI_MMC1_BASE0x04021000
> > #define SUNXI_MMC2_BASE0x04022000
> >
> > +#ifdef CONFIG_MACH_SUN50I_H616
> > +#define SUNXI_DRAM_COM_BASE0x047FA000
> > +#define SUNXI_DRAM_CTL0_BASE 0x047FB000
> > +#define SUNXI_DRAM_PHY0_BASE 0x0480
> > +#endif
> >
> > #define SUNXI_UART0_BASE 0x0500
> > #define SUNXI_UART1_BASE 0x05000400
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 1a5497989f04..859b30d74ceb 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -190,9 +190,10 @@ config MACH_SUNXI_H3_H5
> >
> > select SUPPORT_SPL
> >
> > # TODO: try out A80's 8GiB DRAM space
> >
> > +# TODO: H616 supports 4 GiB DRAM space
> >
> > config SUNXI_DRAM_MAX_SIZE
> >
> > hex
> >
> > - default 0xC000 if MACH_SUN50I || MACH_SUN50I_H5 ||
MACH_SUN50I_H6
> > + default 0xC000 if MACH_SUN50I || MACH_SUN50I_H5 ||
MACH_SUN50I_H6 ||
> > MACH_SUN50I_H616>
> > default 0x8000
> >
> > choice
> >
> > @@ -354,6 +355,12 @@ config MACH_SUN50I_H6
> >
> > select PHY_SUN4I_USB
> > select DRAM_SUN50I_H6
> >
> > +config MACH_SUN50I_H616
> > + bool "sun50i
Re: [linux-sunxi] [PATCH 11/17] sunxi: Add H616 DRAM support
Dne ponedeljek, 04. januar 2021 ob 03:39:52 CET je Samuel Holland napisal(a):
> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> > Allwinner H616 supports many types of DRAM. Most notably it supports
> > LPDDR4. However, all commercially available boards at this time use
> > only DDR3, so this commit adds only DDR3 support.
> >
> > Controller and MBUS are very similar to H6 but PHY is completely
> > unknown.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/include/asm/arch-sunxi/dram.h|2 +
> > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 159 +++
> > arch/arm/mach-sunxi/Kconfig | 43 +
> > arch/arm/mach-sunxi/Makefile |2 +
> > arch/arm/mach-sunxi/dram_sun50i_h616.c| 1023 +
> > arch/arm/mach-sunxi/dram_timings/Makefile |2 +
> > .../mach-sunxi/dram_timings/h616_ddr3_1333.c | 94 ++
> > 7 files changed, 1325 insertions(+)
> > create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > create mode 100644 arch/arm/mach-sunxi/dram_sun50i_h616.c
> > create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_ddr3_1333.c
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
> > b/arch/arm/include/asm/arch-sunxi/dram.h index 8002b7efdc19..c3b3e1f512b2
> > 100644
> > --- a/arch/arm/include/asm/arch-sunxi/dram.h
> > +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> > @@ -29,6 +29,8 @@
> >
> > #include
> > #elif defined(CONFIG_MACH_SUN50I_H6)
> > #include
> >
> > +#elif defined(CONFIG_MACH_SUN50I_H616)
> > +#include
> >
> > #else
> > #include
> > #endif
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h new file mode 100644
> > index ..5d105afd6110
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> > @@ -0,0 +1,159 @@
> > +/*
> > + * H616 dram controller register and constant defines
> > + *
> > + * (C) Copyright 2020 Jernej Skrabec
> > + *
> > + * Based on H6 one, which is:
> > + * (C) Copyright 2017 Icenowy Zheng
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#ifndef _SUNXI_DRAM_SUN50I_H616_H
> > +#define _SUNXI_DRAM_SUN50I_H616_H
> > +
> > +#include
> > +#ifndef __ASSEMBLY__
> > +#include
> > +#endif
> > +
> > +enum sunxi_dram_type {
> > + SUNXI_DRAM_TYPE_DDR3 = 3,
> > + SUNXI_DRAM_TYPE_DDR4,
> > + SUNXI_DRAM_TYPE_LPDDR3 = 7,
> > + SUNXI_DRAM_TYPE_LPDDR4
> > +};
> > +
> > +/* MBUS part is largely the same as in H6, except for one special
> > register */ +struct sunxi_mctl_com_reg {
> > + u32 cr; /* 0x000 control register */
> > + u8 reserved_0x004[4]; /* 0x004 */
> > + u32 unk_0x008; /* 0x008 */
> > + u32 tmr;/* 0x00c timer register */
> > + u8 reserved_0x010[4]; /* 0x010 */
> > + u32 unk_0x014; /* 0x014 */
> > + u8 reserved_0x018[8]; /* 0x018 */
> > + u32 maer0; /* 0x020 master enable register 0 */
> > + u32 maer1; /* 0x024 master enable register 1 */
> > + u32 maer2; /* 0x028 master enable register 2 */
> > + u8 reserved_0x02c[468]; /* 0x02c */
> > + u32 bwcr; /* 0x200 bandwidth control register */
> > + u8 reserved_0x204[12]; /* 0x204 */
> > + /*
> > +* The last master configured by BSP libdram is at 0x49x, so the
> > +* size of this struct array is set to 41 (0x29) now.
> > +*/
> > + struct {
> > + u32 cfg0; /* 0x0 */
> > + u32 cfg1; /* 0x4 */
> > + u8 reserved_0x8[8]; /* 0x8 */
> > + } master[41]; /* 0x210 + index * 0x10 */
> > + u8 reserved_0x4a0[96]; /* 0x4a0 */
> > + u32 unk_0x500; /* 0x500 */
> > +};
> > +check_member(sunxi_mctl_com_reg, unk_0x500, 0x500);
> > +
> > +/*
> > + * Controller registers seems to be the same or at least very similar
> > + * to those in H6.
> > + */
> > +struct sunxi_mctl_ctl_reg {
> > + u32 mstr; /* 0x000 */
> > + u32 statr; /* 0x004 unused */
> > + u32 mstr1; /* 0x008 unused */
> > + u32 unk_0x00c; /* 0x00c */
>
> This is clken (and the same on H6). It is obvious when looking at the
> standby power-down sequence.
Where is that sequence? I mostly consulted H6 and Zynq docs where this
register is not explained. I'll update it in next revision.
Best regards,
Jernej
>
> > + u32 mrctrl0;/* 0x010 unused */
> > + u32 mrctrl1;/* 0x014 unused */
> > + u32 mrstatr;/* 0x018 unused */
> > + u32 mrctrl2;/* 0x01c unused */
> > + u32 derateen; /* 0x020 unused */
> > + u32 derateint; /* 0x024 unused */
> > + u8 reserved_0x028[8]; /* 0x028 */
> > + u32 pwrctl; /* 0x030 unused */
> > + u32 pwrtmg; /* 0x034 unused */
> > + u32 hwlpctl;/* 0x038 unused */
> > + u8
