[linux-sunxi] Re: [PATCH 1/2] sunxi: support asymmetric dual rank DRAM on A64/R40
On Thu, Feb 25, 2021 at 4:14 PM Icenowy Zheng wrote: > > Previously we have known that R40 has a configuration register for its > rank 1, which allows different configuration than rank 0. Reverse > engineering of newest libdram of A64 from Allwinner shows that A64 has > this register too. It's bit 0 (which enables dual rank in rank 0 > configuration register) means a dedicated rank size setup is used for > rank 1. > > Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB > rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank > DRAM support necessary. > > Add this support. The code could support both A64 and R40, but because > dual rank detection is broken on R40 now, we cannot really use it on R40 > currently. > > Signed-off-by: Icenowy Zheng Tested-by: Peter Robinson Tested on Pinephone Braveheart and 3Gb variants plus a Pine64 and all work as expected. > --- > .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 ++- > arch/arm/mach-sunxi/dram_sunxi_dw.c | 94 +++ > 2 files changed, 82 insertions(+), 23 deletions(-) > > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h > b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h > index a5a7ebde44..e843c14202 100644 > --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h > +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h > @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg { > #define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE) > /* The eight data lines (DQn) plus DM, DQS and DQSN */ > #define LINES_PER_BYTE_LANE(BITS_PER_BYTE + 3) > -struct dram_para { > + > +struct rank_para { > u16 page_size; > - u8 bus_full_width; > - u8 dual_rank; > u8 row_bits; > u8 bank_bits; > +}; > + > +struct dram_para { > + u8 dual_rank; > + u8 bus_full_width; > + struct rank_para ranks[2]; > const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE]; > const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE]; > const u8 ac_delays[31]; > diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c > b/arch/arm/mach-sunxi/dram_sunxi_dw.c > index d0600011ff..2b9d631d49 100644 > --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c > +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c > @@ -399,11 +399,19 @@ static void mctl_set_cr(uint16_t socid, struct > dram_para *para) > #else > #error Unsupported DRAM type! > #endif > - (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : > MCTL_CR_FOUR_BANKS) | > + (para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : > MCTL_CR_FOUR_BANKS) | >MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) | >(para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) | > - MCTL_CR_PAGE_SIZE(para->page_size) | > - MCTL_CR_ROW_BITS(para->row_bits), &mctl_com->cr); > + MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) | > + MCTL_CR_ROW_BITS(para->ranks[0].row_bits), &mctl_com->cr); > + > + if (para->dual_rank && (socid == SOCID_A64 || socid == SOCID_R40)) { > + writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : > MCTL_CR_FOUR_BANKS) | > + MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) | > + MCTL_CR_DUAL_RANK | > + MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) | > + MCTL_CR_ROW_BITS(para->ranks[1].row_bits), > &mctl_com->cr_r1); > + } > > if (socid == SOCID_R40) { > if (para->dual_rank) > @@ -646,35 +654,63 @@ static int mctl_channel_init(uint16_t socid, struct > dram_para *para) > return 0; > } > > -static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para > *para) > +/* > + * Test if memory at offset offset matches memory at a certain base > + */ > +static bool mctl_mem_matches_base(u32 offset, ulong base) > +{ > + /* Try to write different values to RAM at two addresses */ > + writel(0, base); > + writel(0xaa55aa55, base + offset); > + dsb(); > + /* Check if the same value is actually observed when reading back */ > + return readl(base) == > + readl(base + offset); > +} > + > +static void mctl_auto_detect_dram_size_rank(uint16_t socid, struct dram_para > *para, ulong base, struct rank_para *rank) > { > /* detect row address bits */ > - para->page_size = 512; > - para->row_bits = 16; > - para->bank_bits = 2; > + rank->page_size = 512; > + rank->row_bits
[linux-sunxi] Re: [PATCH 20/20] Enable led on boot to notify user of boot status
On Thu, Feb 25, 2021 at 3:17 PM André Przywara wrote: > > On 20/02/2021 12:14, Nicolas Boulenguez wrote: > > From: Marius Gripsgard > > Hi, > > This is not really Pinephone specific, actually not even sunxi specific. > I see two better ways of solving this: > > - We introduce some generic code to find "gpio-leds" subnodes in the DT, > which have a default-state = "on" property. This could be either added > to drivers/led/led_gpio.c, or in some higher level. > > - We introduce a generic boot LED GPIO config symbol. Maybe there is > already something, that sounds like a generally useful feature? That > would have the advantage of being already enabled in the SPL (admittedly > a sunxi specific problem). > > Any opinions? I believe there's already a way to use LEDs for status during the boot process using the CONFIG_LED_STATUS selection of config options. A grep of the defconfig already shows a number of boards using this. I wonder why the already existing infrastructure isn't useful. Peter > Cheers, > Andre > > > --- > > arch/arm/mach-sunxi/Kconfig | 5 + > > board/sunxi/board.c | 4 ++-- > > configs/pinephone_defconfig | 1 + > > 3 files changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > > index 8421f3b685..2bfdf7738b 100644 > > --- a/arch/arm/mach-sunxi/Kconfig > > +++ b/arch/arm/mach-sunxi/Kconfig > > @@ -1,5 +1,10 @@ > > if ARCH_SUNXI > > > > +config PINEPHONE_LEDS > > + bool "Notify boot status via LEDs on PinePhone" > > + ---help--- > > + LED boot notification. > > + > > config SPL_LDSCRIPT > > default "arch/arm/cpu/armv7/sunxi/u-boot-spl.lds" if !ARM64 > > > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > > index abd7e390b2..a117b89ba2 100644 > > --- a/board/sunxi/board.c > > +++ b/board/sunxi/board.c > > @@ -637,6 +638,12 @@ void sunxi_board_init(void) > > { > > int power_failed = 0; > > > > +#ifdef CONFIG_PINEPHONE_LEDS > > + /* PD18:G PD19:R PD20:B */ > > + gpio_request(SUNXI_GPD(18), "led:green"); > > + gpio_direction_output(SUNXI_GPD(18), 1); > > +#endif > > + > > #ifdef CONFIG_SY8106A_POWER > > power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT); > > #endif > > diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig > > index ff5da42ce0..9de6ab2316 100644 > > --- a/configs/pinephone_defconfig > > +++ b/configs/pinephone_defconfig > > @@ -1,6 +21,7 @@ > > CONFIG_ARM=y > > CONFIG_ARCH_SUNXI=y > > CONFIG_SPL=y > > +CONFIG_PINEPHONE_LEDS=y > > CONFIG_MACH_SUN50I=y > > CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y > > CONFIG_DRAM_CLK=552 > > > -- 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/CALeDE9PwOZuGz1dxN87UqCZf1Weker6%3DW4gJ-_p3rX%2BWgME8Cg%40mail.gmail.com.
[linux-sunxi] Re: [PATCH] sunxi: Properly check for SATAPWR and MACPWR
On Tue, Jan 19, 2021 at 1:06 AM Andre Przywara wrote: > > 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 Tested-by: Peter Robinson Tested on Pine64, Cubietruck with root fs on SATA SSD, and an orangepi_pc > --- > board/sunxi/board.c | 34 ++ > 1 file changed, 22 insertions(+), 12 deletions(-) > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > index 4f058952b5b..a0b5778b3bc 100644 > --- a/board/sunxi/board.c > +++ b/board/sunxi/board.c > @@ -265,18 +265,28 @@ int board_init(void) > if (ret) > return ret; > > -#ifdef CONFIG_SATAPWR > - satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR); > - gpio_request(satapwr_pin, "satapwr"); > - gpio_direction_output(satapwr_pin, 1); > - /* Give attached sata device time to power-up to avoid link timeouts > */ > - mdelay(500); > -#endif > -#ifdef CONFIG_MACPWR > - macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR); > - gpio_request(macpwr_pin, "macpwr"); > - gpio_direction_output(macpwr_pin, 1); > -#endif > + /* strcmp() would look better, but doesn't get optimised away. */ > + if (CONFIG_SATAPWR[0]) { > + satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR); > + if (satapwr_pin >= 0) { > + gpio_request(satapwr_pin, "satapwr"); > + gpio_direction_output(satapwr_pin, 1); > + > + /* > +* Give the attached SATA device time to power-up > +* to avoid link timeouts > +*/ > + mdelay(500); > + } > + } > + > + if (CONFIG_MACPWR[0]) { > + macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR); > + if (macpwr_pin >= 0) { > + gpio_request(macpwr_pin, "macpwr"); > + gpio_direction_output(macpwr_pin, 1); > + } > + } > > #ifdef CONFIG_DM_I2C > /* > -- > 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/CALeDE9O%2BBgOrU%3DAcCGqhggH4zTaYX4SwadvGBHOcL3qJOca5JA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support
On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara wrote: > > The eMMC standard describes the concept of boot partitions, consisting > of two storage areas separate from the main user data partition. > The Allwinner BootROM supports loading SPL/Boot0 from such a boot > partition, if that is configured in the eMMC device [1]. > > To load U-Boot proper along with the SPL from there, currently this > requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this > build won't boot from the normal eMMC user partition anymore. > Also the raw MMC sector offset needs to be adjusted manually, preventing > a boot from an SD card. > > This series introduces automatic detection of eMMC boot partition boot. > Patch 3/5 automates the raw MMC sector offset decision, allowing such > a build to also boot from an SD card. > Unfortunately the BootROM does not mark an eMMC boot partition boot > differently from the normal eMMC user data partition boot, so patch 4/5 > introduces a function that repeats the BootROM algorithm, so that the SPL > comes to the same conclusion as the BootROM. This allows to build one > single image that boots from everywhere: eMMC user data, eMMC boot, > SD card, SPI flash. > Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5 > extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible. > > Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by > 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size > goes up by 444 bytes (AArch64) and 260 bytes (ARMv7). > Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5 > enables this new mechanism for some boards I could test this on. > > Please have a look and test this if you have a board with eMMC. > I put installation instructions into the linux-sunxi Wiki: > http://linux-sunxi.org/Bootable_eMMC It would probably be good to put that link in the local Allwinner docs so it's easier for people to find. Peter > Cheers, > Andre > > [1] http://linux-sunxi.org/Bootable_eMMC#The_BROM_implementation_details > > Andre Przywara (5): > sunxi: Fix is_boot0_magic macro > spl: mmc: extend spl_mmc_boot_mode() to take mmc argument > sunxi: Simplify eMMC boot partition booting > sunxi: eMMC: Add automatic boot detection > sunxi: defconfig: enable eMMC boot partition support > > arch/arm/include/asm/arch-sunxi/spl.h | 2 +- > arch/arm/mach-imx/spl.c| 2 +- > arch/arm/mach-k3/am6_init.c| 2 +- > arch/arm/mach-k3/j721e_init.c | 2 +- > arch/arm/mach-omap2/boot-common.c | 2 +- > arch/arm/mach-rockchip/spl.c | 2 +- > arch/arm/mach-socfpga/spl_a10.c| 2 +- > arch/arm/mach-socfpga/spl_agilex.c | 2 +- > arch/arm/mach-socfpga/spl_gen5.c | 2 +- > arch/arm/mach-socfpga/spl_s10.c| 2 +- > arch/arm/mach-stm32mp/spl.c| 2 +- > arch/arm/mach-sunxi/board.c| 94 +- > arch/arm/mach-uniphier/mmc-boot-mode.c | 5 +- > common/spl/spl_mmc.c | 4 +- > configs/bananapi_m64_defconfig | 1 + > configs/emlid_neutis_n5_devboard_defconfig | 1 + > configs/pine64-lts_defconfig | 1 + > configs/pine_h64_defconfig | 1 + > include/spl.h | 3 +- > 19 files changed, 113 insertions(+), 19 deletions(-) > > -- > 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/CALeDE9Oo8vvwADE5M%2BDz17d5Zf7mTmerC3Lid9%2B-9iTX1nMVdg%40mail.gmail.com.
[linux-sunxi] Re: [U-Boot] [PATCH 2/2] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
On Thu, May 16, 2019 at 1:47 AM Andre Przywara wrote: > > The first USB controller on the A64 SoC shares a PHY with the OTG > controller. Reportedly to avoid problems with the VBUS regulator under > Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file. > > However on boards which can't use peripheral mode (because they have an > always-on VBUS supply on an USB-A socket) we don't need this trick, and > can properly connect host controller 0 to the PHY 0. > > Amend the Pine64 and SoPine/LTS .dts to reflect this. This enables the > upper USB port in U-Boot on those boards. > > Signed-off-by: Andre Przywara > --- > arch/arm/dts/sun50i-a64-pine64.dts | 5 - > arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 - > 2 files changed, 8 insertions(+), 2 deletions(-) Are these changes going to go upstream to Linux too? If not it's probably best to add it to a u-boot.dtsi so the changes don't get lost when the DT files are re-synced from Linux. Same with the similar patches for the H6 boards. Peter > diff --git a/arch/arm/dts/sun50i-a64-pine64.dts > b/arch/arm/dts/sun50i-a64-pine64.dts > index c077b6c1f4..523a4d5bff 100644 > --- a/arch/arm/dts/sun50i-a64-pine64.dts > +++ b/arch/arm/dts/sun50i-a64-pine64.dts > @@ -80,6 +80,8 @@ > }; > > &ehci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -136,6 +138,8 @@ > }; > > &ohci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -301,7 +305,6 @@ > > &usb_otg { > dr_mode = "host"; > - status = "okay"; > }; > > &usbphy { > diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > index 53fcc9098d..1986897177 100644 > --- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > @@ -85,6 +85,8 @@ > }; > > &ehci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -131,6 +133,8 @@ > }; > > &ohci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -172,7 +176,6 @@ > > &usb_otg { > dr_mode = "host"; > - status = "okay"; > }; > > &usbphy { > -- > 2.14.5 > > ___ > U-Boot mailing list > u-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- 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/CALeDE9PQ4XGUeSr2D0rY%3D4ueBtYJHHV2mnz0WotQPCXvhtTeUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v6 0/7] sunxi: sync H3, H5, A64 DTs from mainline Linux
On Wed, May 16, 2018 at 9:00 AM, Andre Przywara wrote: > This is an updated version of the series which brings the exact mainline > Linux device tree files for various Allwinner boards into U-Boot. > Apart from using the usually more correct reference DT files, this offers > the big benefit of being able to use U-Boot's DT copy for directly passing > it to the kernel. This avoids to actually load a .dtb file from somewhere, > and allows seamless and automatic UEFI booting, so distribution installer > images should just work (TM). > > This cover the ARMv8 SoCs (H5, A64), but also all boards with the H3, as > this is somewhat married to the H5 and can only be updated together. > The H3 and H5 DT files have diverged quite a bit, but as U-Boot's own > usage of the DT is (yet) quite limited, there should be no regressions. > The patches are split to first update the SoC .dtsi file, then the board > .dts files in a second patch. They are grouped to handle the A64 first, > then the H5 and H3. I put the respective kernel commit IDs in the commit > messages. > Patch 6 brings in the mainline DT for the SoPine baseboard, for which we > didn't have a separate .dts in U-Boot so far. > Patch 7 adds a separate .dts file for the Pine64-LTS board, which is > virtually identical to the SoPine baseboard, but, due to the SoC being > named differently, deserves a separate file. > > This is based on origin/master (ca70cbabdcd1). > > Maxime, I kept you Acked-by: from the previous posts, as I literally > just updated to the latest Linux master, which went through your review > anyway. Hope that's OK for you. > > Cheers, > Andre. > > Changelog v5 .. v6: > - bring back DT update patches > - update to Linux v4.17-rc5 Are these based purely on 4.17rc5 because I don't see sun50i-a64-pine64-lts.dts in Linus's upstream. Peter > Changelog v4 .. v5: > - drop Linux DT update patches for now > - fix minor checkpatch complaints > > Changelog v3 .. v4: > - remove MMC environment for all Allwinner boards (including 32 bit ones) > - keep MMC environment offset to the old values > - drop DT adjustments to use fixed MMC regulator > > Changelog v2 .. v3: > 01: added, was on the list before > 02: drop redundant H5 line > 03-08: unchanged > 09-20: added > > Changelog v1 .. v2: > 01, 02, 03: unchanged > 04, 05, 06, 07: added > > Andre Przywara (7): > sunxi: DT: A64: update device tree file for Allwinner A64 SoC > sunxi: DT: A64: update board .dts files from Linux > sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs > sunxi: DT: H5: update board .dts files from Linux > sunxi: DT: H3: update board .dts files from Linux > sunxi: DT: A64: add proper SoPine baseboard device tree > sunxi: DT: A64: add Pine64-LTS support > > arch/arm/dts/Makefile | 4 +- > arch/arm/dts/axp803.dtsi| 150 + > arch/arm/dts/sun50i-a64-bananapi-m64.dts| 200 +- > arch/arm/dts/sun50i-a64-nanopi-a64.dts | 111 +++- > arch/arm/dts/sun50i-a64-olinuxino.dts | 153 - > arch/arm/dts/sun50i-a64-orangepi-win.dts| 135 +++- > arch/arm/dts/sun50i-a64-pine64-lts.dts | 13 + > arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 59 -- > arch/arm/dts/sun50i-a64-pine64-plus.dts | 17 +- > arch/arm/dts/sun50i-a64-pine64.dts | 186 +- > arch/arm/dts/sun50i-a64-sopine-baseboard.dts| 150 + > arch/arm/dts/sun50i-a64-sopine.dtsi | 142 > arch/arm/dts/sun50i-a64.dtsi| 303 - > arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 122 +++- > arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 91 ++- > arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 186 +- > arch/arm/dts/sun50i-h5-orangepi-prime.dts | 189 +- > arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts | 64 +- > arch/arm/dts/sun50i-h5.dtsi | 36 +- > arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts| 55 +- > arch/arm/dts/sun8i-h3-bananapi-m2-plus.dts | 109 ++- > arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts| 78 +++ > arch/arm/dts/sun8i-h3-nanopi-m1.dts | 42 ++ > arch/arm/dts/sun8i-h3-nanopi-neo-air.dts| 28 +- > arch/arm/dts/sun8i-h3-nanopi-neo.dts| 17 + > arch/arm/dts/sun8i-h3-nanopi.dtsi | 13 +- > arch/arm/dts/sun8i-h3-orangepi-2.dts| 92 ++- > arch/arm/dts/sun8i-h3-orangepi-lite.dts | 57 +- > arch/arm/dts/sun8i-h3-orangepi-one.dts | 94 ++- > arch/arm/dts/sun8i-h3-orangepi-pc-plus.dts | 11 +- > arch/arm/dts/sun8i-h3-orangepi-pc.dts | 113 +++- > arch/arm/dts/sun8i-h3-orangepi-plus.dts | 29 +- > arch/arm/dts/sun8i-h3-orangepi-plus2e.dts | 15 +- > arch/arm/dts/sun8i-h3.dtsi | 544 ++- > arch/arm/dts/sunxi-h3-h5.dtsi | 842 > > arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi | 2 - > c
[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK
On Mon, Apr 2, 2018 at 3:56 AM, Simon Glass wrote: > Hi Peter, > > On 2 April 2018 at 10:45, Peter Robinson wrote: >> On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass wrote: >>> Hi Andre, >>> >>> On 2 April 2018 at 09:43, André Przywara wrote: >>>> Hi, >>>> >>>> On 01/04/18 14:19, Tom Rini wrote: >>>>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote: >>>>>> On Mon, Sep 4, 2017 at 9:57 PM, wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> On 7 August 2017 at 09:39, Tom Rini wrote: >>>>>>>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote: >>>>>>>> >>>>>>>>> The CONFIG_BLK conversion involves quite invasive changes in the >>>>>>>>> U-Boot >>>>>>>>> code, with #ifdefs and different code paths. We should try to move >>>>>>>>> over to >>>>>>>>> this soon so we can drop the old code. >>>>>> >>>>>> I hope this will applicable to SPL too? >>>>>> >>>>>> If so, we are having SPL size issues with few Allwinner families, if >>>>>> enable SPL_DM any suggestions? >>>>> >>>>> How close, and have you looked at the u-boot-spl.map to see what you can >>>>> maybe trim? Or areas to look at reducing in code complexity? >>>> >>>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64 >>>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map >>>> and picked most low hanging fruits already. >>>> So far we discussed several mitigations, but mostly to cover the >>>> "natural" SPL code size grow over time: >>>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of >>>> padding (for a 2KB architectural alignment). Given that the vectors are >>>> used only for debugging purposes, we could scrap them entirely or >>>> construct them on the fly in some other SRAM. So would free about 2.5KB, >>>> ideally. Lowest hanging fruit so far. >>>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2 >>>> encoding. This reduces the size significantly, to about 20KB. The >>>> disadvantage is using a second cross-compiler or even a additional >>>> cross-compiler for native builds, complicating the build process. >>>> I maintain a branch for enabling FEL booting here [1], which provides >>>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper). >>>> There are no technical disadvantages in running the SPL in 32-bit, so >>>> this is mostly a build issue. >>> >>> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with >>> ARMv7. It should be fairly easy to do, >> >> ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in >> the case of Allwinner A64 > > Yes, but that is just a matter of compiler or compiler flags. My point > was we should be able to use different build for each without too much > work. It's a lot more work for the way most distros build u-boot, but TBH the sooner I don't need to the better ;-) -- 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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK
On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass wrote: > Hi Andre, > > On 2 April 2018 at 09:43, André Przywara wrote: >> Hi, >> >> On 01/04/18 14:19, Tom Rini wrote: >>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote: On Mon, Sep 4, 2017 at 9:57 PM, wrote: > Hi Tom, > > On 7 August 2017 at 09:39, Tom Rini wrote: >> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote: >> >>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot >>> code, with #ifdefs and different code paths. We should try to move over >>> to >>> this soon so we can drop the old code. I hope this will applicable to SPL too? If so, we are having SPL size issues with few Allwinner families, if enable SPL_DM any suggestions? >>> >>> How close, and have you looked at the u-boot-spl.map to see what you can >>> maybe trim? Or areas to look at reducing in code complexity? >> >> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64 >> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map >> and picked most low hanging fruits already. >> So far we discussed several mitigations, but mostly to cover the >> "natural" SPL code size grow over time: >> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of >> padding (for a 2KB architectural alignment). Given that the vectors are >> used only for debugging purposes, we could scrap them entirely or >> construct them on the fly in some other SRAM. So would free about 2.5KB, >> ideally. Lowest hanging fruit so far. >> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2 >> encoding. This reduces the size significantly, to about 20KB. The >> disadvantage is using a second cross-compiler or even a additional >> cross-compiler for native builds, complicating the build process. >> I maintain a branch for enabling FEL booting here [1], which provides >> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper). >> There are no technical disadvantages in running the SPL in 32-bit, so >> this is mostly a build issue. > > FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with > ARMv7. It should be fairly easy to do, ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in the case of Allwinner A64 -- 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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v4 0/3] Allwinner DE2 HDMI SimpleFB support
On Fri, Sep 15, 2017 at 2:59 AM, Icenowy Zheng wrote: > This patchset is for Allwinner DE2 HDMI SimpleFB support. > > The framebuffer initialized by the Allwinner DE2 driver can be > passed by to the kernel as simplefb, and this can enable the > kernel to display graphics without having full DE2 driver. > > Add the suppot of simplefb in DE2 code. > > The code to find a simplefb with sunxi extension and a suitable > pipeline is extracted to a new source file in video/sunxi/. > > An option is added for device tree simplefb, and furtherly > other simplefb support code should also be converted to it. There was a generic simplefb driver recently added [1], is it worth basing it on that? [1] https://lists.denx.de/pipermail/u-boot/2017-September/306273.html -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [fedora-arm] [linux-sunxi] cpufreq scaling broken on cubietruck
>> > This is already fixed by this patch: >> > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com >> > mit/drivers/regulator/axp20x >> > -regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec >> >> I've pulled this patch into the F-23/4.2.x kernel, it'll be in the >> 4.2.2 build, it's already in rawhide. > > Thanks, Peter. > > One other thing to think about. Although the cpufreq-dt module will > autoload from dt ref, it needs to be in the initramfs image created by > dracut. This doesn't happen automatically. Currently have created a > /etc/dracut.conf.d/sunxi.conf with... Weird, it appears to load and work post initrd with the BeagleBone. In /sys/devices/system/cpu/cpu0/cpufreq I get all the bits I would expect with cur/max/mon freqs etc. I'll have a look when I get a spare moment on a A20 device. Peter -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [fedora-arm] [linux-sunxi] cpufreq scaling broken on cubietruck
>>> On Sun, 2015-09-27 at 12:37 +0200, Hans de Goede wrote: >>> This is likely a problem with your kernel config, make sure that you've the axp209 mfd and regulator drivers enabled and loaded. >>> >>> >>> Thanks, Hans. I really should have figured that out on my own! >>> >>> Do you think it's worth asking PeterR if he will change the default >>> Fedora armv7 config to CONFIG_REGULATOR_AXP20X=y rather than the >>> current CONFIG_REGULATOR_AXP20X=m? (I suspect that request might >>> carry more weight if it comes from you rather than me. ;) >>> >> >> Hans, >> >> Do you have an opinion, (or anyone else for that matter), on what would be >> the upstream preferred way of getting the axp20x regulator driver to >> auto-load, from a DT reference, assuming it is built as a module? >> Something >> like the attached patch? (Not tested, just thinking out loud.) > > > This is already fixed by this patch: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/axp20x-regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec I've pulled this patch into the F-23/4.2.x kernel, it'll be in the 4.2.2 build, it's already in rawhide. Peter -- 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. For more options, visit https://groups.google.com/d/optout.