Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote: > On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard > wrote: > > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote: > >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson > >> wrote: > >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard > >> > wrote: > >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote: > >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard > >> >>> wrote: > >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which > >> >>> > makes us > >> >>> > trip across the size limit we've had on the U-Boot binary. > >> >>> > > >> >>> > Since it's not an essential feature, disable it by default for > >> >>> > ARCH_SUNXI > >> >>> > so that we get back some extra room for user customisations. > >> >>> > >> >>> Does this disable it on aarch64 boards by default such as the Pine64? > >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to > >> >>> boot aarch64 devices and this would regress this for all those > >> >>> distros. > >> >> > >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add > >> >> to their defconfig. These are just default configuration, not > >> >> one-size-fits-all configuration. > >> > > >> > So you're making at least three groups of users do more work? It could > >> > also be argued that those that need the smaller space could disable it > >> > if they don't need it in their configuration. > >> > >> Ultimately the problem with the argument about disabling it by default > >> and distros can enable it if they want to is a false one. > > > > If it's a false one, then I guess Red Hat doesn't have any kind of > > custom defconfigs for Fedora or RHEL for the kernel? > > kernel is part of the distro, "firmware" (ie. u-boot or whatever > implements UEFI) should not be.. so this argument is a bit of a red > herring. Then that discussion is entirely moot. If the distros don't care about building the U-Boot binary, why should they care about maintaining the U-Boot's defconfig like Peter was suggesting? > Maybe the solution is a "distro.config" option to separate options > that make sense for distro/EBBR from what people who are doing more > non-standard boot-chains are wanting. It's kind of amazing to see that the usual boot-chain that people have been relying on for more than a decade and is still in use in the immense majority of devices can be seen as "non-standard". But I guess that's a different topic. > For example, for UEFI boot, we can disable all the filesystems other > than FAT if you need to trim some space. And maybe doing a more > simplified (ie. add it to efi_bootmgr.c) alternative to distro > bootcmd could save a bunch of .text space. In fact we don't really > need the scripting env at all. Probably there are other options for > things to disable that I haven't thought of if you *really* needed > to trim down. That's good to know. Hopefully we won't need to trim that space since we got a bit more room to spare by switching to thumb, and if we can move to a filesystem based environment, we won't ever need it. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockchip GRF/PMUGRF/CRU reg access in U-Boot
Kever,
> On 20 Oct 2017, at 03:59, Kever Yang wrote:
>
> Hi Simon and Philipp.
>
> I would like to include Heiko who is maintainer of upstream kernel
> Rockchip SoC for this topic.
>
> For the driver related to grf, which including pinctrl, usb phy, gmac and
> many other modules, we would like to sync with kernel, so that we can re-use
> the dtsi from kernel. The use of grf register have many discuss on upstream
> kernel already, and all modules use grf with a &grf reference and offset in
> dts.
>
> U-Boot coding style says "Use structures for I/O access", in my opinion, this
> is good for most case, but not for registers like Rockchip grf, because it's
> related for many modules, and it's different in different SoC, use "base addr
> + offset" for grf reg in dtsi and decode it in driver is much more reasonable
> for grf related driver setting. Just like the line size 80 is max, we follow
> the rule in most case, but in some case, more than 80 characters is better
> for read, then we use more than 80 characters. We can merge pinctrl driver
> into one file like kernel if we can use this feature, and the same with
> sysreset, soft reset...We are not going to follow the dead rules for all
> cases, we have to use the one which is better for us.
>
> To make it more clear, here is an example:
>
> Looking at drivers/sysreset/sysreset_rk3xxx.c(there are 8 files and more to
> come), the source code are almost the same, the only difference is the reg
> address of glb_srst_snd_value and glb_srst_fst_value in cru, we can very
> easy to decode this from dts in one common driver if we use 'base + offset'.
> If we insist on using structure for this kind of reg access, to merge them
> into one common driver we have to including all different SoC cru definition
> and use different variable for different SoC, there would be many '#ifdef ...
> #else' in the file like this
>
In the sysreset-case there shouldn’t be a change to the DTSI necessary.
The sysreset-drivers are always instantiated from the clock-drivers, as in the
following example:
static int rk3399_clk_bind(struct udevice *dev)
{
int ret;
/* The reset driver does not have a device node, so bind it
here */
ret = device_bind_driver(gd->dm_root, "rk3399_sysreset",
"reset", &dev);
if (ret)
printf("Warning: No RK3399 reset driver: ret=%d\n",
ret);
return 0;
}
Given this, the offset of the sysreset register in the GRF can be easily passed
in during binding the driver by changing this code (the following is just
pseudocode w/o error handling) to:
struct driver *drv = lists_driver_lookup_name(“rk3399_sysreset”);
ulong drv_data = offsetof(grf_struct, sysreset_reg);
device_bind_with_driver_data(parent, drv, dev_name, drv_data,
gd->dm_root, &dev);
And: thank you for getting around to look at the sysreset situation and
starting work on deduplicating this.
> #ifdef CONFIG_ROCKCHIP_RK3036
>
> #include
>
> #else ifdef CONFIG_ROCKCHIP_RK3188
>
> #include
>
> #else ifdef CONFIG_ROCKCHIP_RK322x
>
> #include
>
> #else ifdef CONFIG_ROCKCHIP_RK3288
>
> #include
>
> #else ifdef CONFIG_ROCKCHIP_RK3328
>
> #include
>
> #else ifdef CONFIG_ROCKCHIP_RK3368
>
> #include
>
> ...
> #endif
>
> and also this is need when we define and use the cru variant.
>
>
> I would like to use two dts decode instead like this for all SoCs:
> rphy->grf_base = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> ofnode_read_u32(dev_ofnode(dev), "reg", ®)
> sysreset_reg = rphy->grf_base + reg;
>
> and dts for different SoC like this:
> rockchip,grf = <&grf>;
> reg = <0x017c>;
>
The proper coding style in U-Boot would be to use the syscon-functions to
perform a read/write to an offset.
In other words
regmap_read(grf, reg, &valp)
should be used to read the location for the above example.
Note that his works only, if the layout within these registers is the same
across devices.
> We wish upstream U-Boot can accept this kind of coding, I believe when the
> coding style was made, it does not met the controller reg like Rockchip GRF.
In fact the regmap and syscon device classes have always been intended to work
exactly for such cases.
There is one convenience layer (on top of) regmap missing to write bitfields in
or across symbolically named
registers. However, this may be an intentional omission as such functionality
will most likely need to be
handled by misc-devices (which is the reason why I finally started work to get
our GMAC-related control
offloaded into chip-specific misc device).
> We will follow the coding style requirement in all other normal controller
> like I2C/SPI/USB/SDMMC/DISPLAY and etc.
>
> Thanks,
> - Kever
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/
Re: [U-Boot] [PATCH v3 1/5] arm64: layerscape: Move CONFIG_HAS_FSL_XHCI_USB to Kconfig
Hi Bin > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Thursday, October 12, 2017 2:01 PM > To: Ran Wang > Cc: Albert Aribaud ; Prabhakar Kushwaha > ; Ashish Kumar ; > York Sun ; open list > Subject: Re: [PATCH v3 1/5] arm64: layerscape: Move > CONFIG_HAS_FSL_XHCI_USB to Kconfig > > Hi Ran, > > On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang wrote: > > Use Kconfig to select QE-HDLC and USB pin-mux. > > > > Signed-off-by: Ran Wang > > --- > > Change in v3: > > New patch file. > > > > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 7 +++ > > include/configs/ls1012afrdm.h | 4 > > include/configs/ls1012aqds.h | 4 > > include/configs/ls1012ardb.h | 4 > > include/configs/ls1021aiot.h | 4 > > include/configs/ls1021aqds.h | 4 > > include/configs/ls1021atwr.h | 4 > > include/configs/ls1043aqds.h | 3 --- > > include/configs/ls1043ardb.h | 3 --- > > include/configs/ls1046aqds.h | 3 --- > > include/configs/ls1046ardb.h | 3 --- > > include/configs/ls2080aqds.h | 1 - > > include/configs/ls2080ardb.h | 1 - > > scripts/config_whitelist.txt | 1 - > > 14 files changed, 7 insertions(+), 39 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > index 3518d8601d..9fda8a1e83 100644 > > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > @@ -489,3 +489,10 @@ config SYS_MC_RSV_MEM_ALIGN > > > > config SPL_LDSCRIPT > > default "arch/arm/cpu/armv8/u-boot-spl.lds" if ARCH_LS1043A || > > ARCH_LS1046A || ARCH_LS2080A > > + > > +config HAS_FSL_XHCI_USB > > + bool > > + default y if ARCH_LS1043A || ARCH_LS1046A > > How about LS2080? I see there is modification on 2080 related files in this > patch. > Actually HAS_FSL_XHCI_USB is not necessary to LS2080A, previous code is redundant. > > + help > > + For some SoC(such as LS1043A and LS1046A), USB and QE-HDLC > > + multi-use > > nits: SoCs ( > > What is multi-use? I think you wanted to say: multiplex Yes, will change it > > + the pins, select it when pin assigned to USB. > > nits: when pin is assigned Got it. Will update it and other nits in rest patch files, many thanks. > > diff --git a/include/configs/ls1012afrdm.h > > b/include/configs/ls1012afrdm.h index 6b1ba578e9..2e5af9cc4e 100644 > > --- a/include/configs/ls1012afrdm.h > > +++ b/include/configs/ls1012afrdm.h > > @@ -34,12 +34,8 @@ > > /* > > * USB > > */ > > -#define CONFIG_HAS_FSL_XHCI_USB > > - > > -#ifdef CONFIG_HAS_FSL_XHCI_USB > > #define CONFIG_USB_XHCI_FSL > > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > > -#endif > > > > #define CONFIG_CMD_MEMINFO > > #define CONFIG_CMD_MEMTEST > > diff --git a/include/configs/ls1012aqds.h > > b/include/configs/ls1012aqds.h index b3121d2c21..e0949d0b53 100644 > > --- a/include/configs/ls1012aqds.h > > +++ b/include/configs/ls1012aqds.h > > @@ -119,12 +119,8 @@ > > #endif > > > > /*XHCI Support - enabled by default*/ -#define > > CONFIG_HAS_FSL_XHCI_USB > > - > > -#ifdef CONFIG_HAS_FSL_XHCI_USB > > #define CONFIG_USB_XHCI_FSL > > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > > -#endif > > > > /* MMC */ > > #ifdef CONFIG_MMC > > diff --git a/include/configs/ls1012ardb.h > > b/include/configs/ls1012ardb.h index e9edcd2bc9..66ff004384 100644 > > --- a/include/configs/ls1012ardb.h > > +++ b/include/configs/ls1012ardb.h > > @@ -22,12 +22,8 @@ > > /* > > * USB > > */ > > -#define CONFIG_HAS_FSL_XHCI_USB > > - > > -#ifdef CONFIG_HAS_FSL_XHCI_USB > > #define CONFIG_USB_XHCI_FSL > > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > > -#endif > > > > /* > > * I2C IO expander > > diff --git a/include/configs/ls1021aiot.h > > b/include/configs/ls1021aiot.h index 3fe7b8f44c..2cbea87d95 100644 > > --- a/include/configs/ls1021aiot.h > > +++ b/include/configs/ls1021aiot.h > > @@ -20,12 +20,8 @@ > > #define CONFIG_SYS_INIT_RAM_SIZE OCRAM_SIZE > > > > /* XHCI Support - enabled by default */ -#define > > CONFIG_HAS_FSL_XHCI_USB > > - > > -#ifdef CONFIG_HAS_FSL_XHCI_USB > > #define CONFIG_USB_XHCI_FSL > > #define CONFIG_USB_MAX_CONTROLLER_COUNT1 > > -#endif > > > > #define CONFIG_SYS_CLK_FREQ1 > > #define CONFIG_DDR_CLK_FREQ1 > > diff --git a/include/configs/ls1021aqds.h > > b/include/configs/ls1021aqds.h index f3d3aa2271..0046ded536 100644 > > --- a/include/configs/ls1021aqds.h > > +++ b/include/configs/ls1021aqds.h > > @@ -405,12 +405,8 @@ unsigned long get_board_ddr_clk(void); #endif > > > > /*XHCI Support - enabled by default*/ -#define > > CONFIG_HAS_FSL_XHCI_USB > > - > > -#ifdef CONFIG_HAS_FSL_XHCI_USB > > #define CONFIG_USB_XHCI_FSL > > #define CONFIG_USB_MAX_CONTROLL
[U-Boot] [PATCH v4 1/5] arm64: layerscape: Move CONFIG_HAS_FSL_XHCI_USB to Kconfig
Use Kconfig to select QE-HDLC and USB pin-mux. Signed-off-by: Ran Wang Reviewed-by: Bin Meng --- arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 7 +++ include/configs/ls1012afrdm.h | 4 include/configs/ls1012aqds.h | 4 include/configs/ls1012ardb.h | 4 include/configs/ls1021aiot.h | 4 include/configs/ls1021aqds.h | 4 include/configs/ls1021atwr.h | 4 include/configs/ls1043aqds.h | 3 --- include/configs/ls1043ardb.h | 3 --- include/configs/ls1046aqds.h | 3 --- include/configs/ls1046ardb.h | 3 --- include/configs/ls2080aqds.h | 1 - include/configs/ls2080ardb.h | 1 - scripts/config_whitelist.txt | 1 - 14 files changed, 7 insertions(+), 39 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index 3518d8601d..84e689b6e1 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -489,3 +489,10 @@ config SYS_MC_RSV_MEM_ALIGN config SPL_LDSCRIPT default "arch/arm/cpu/armv8/u-boot-spl.lds" if ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A + +config HAS_FSL_XHCI_USB + bool + default y if ARCH_LS1043A || ARCH_LS1046A + help + For some SoC(such as LS1043A and LS1046A), USB and QE-HDLC multiplex use + pins, select it when the pins are assigned to USB. diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h index 6b1ba578e9..2e5af9cc4e 100644 --- a/include/configs/ls1012afrdm.h +++ b/include/configs/ls1012afrdm.h @@ -34,12 +34,8 @@ /* * USB */ -#define CONFIG_HAS_FSL_XHCI_USB - -#ifdef CONFIG_HAS_FSL_XHCI_USB #define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 -#endif #define CONFIG_CMD_MEMINFO #define CONFIG_CMD_MEMTEST diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h index b3121d2c21..e0949d0b53 100644 --- a/include/configs/ls1012aqds.h +++ b/include/configs/ls1012aqds.h @@ -119,12 +119,8 @@ #endif /*XHCI Support - enabled by default*/ -#define CONFIG_HAS_FSL_XHCI_USB - -#ifdef CONFIG_HAS_FSL_XHCI_USB #define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 -#endif /* MMC */ #ifdef CONFIG_MMC diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h index e9edcd2bc9..66ff004384 100644 --- a/include/configs/ls1012ardb.h +++ b/include/configs/ls1012ardb.h @@ -22,12 +22,8 @@ /* * USB */ -#define CONFIG_HAS_FSL_XHCI_USB - -#ifdef CONFIG_HAS_FSL_XHCI_USB #define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 -#endif /* * I2C IO expander diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h index 3fe7b8f44c..2cbea87d95 100644 --- a/include/configs/ls1021aiot.h +++ b/include/configs/ls1021aiot.h @@ -20,12 +20,8 @@ #define CONFIG_SYS_INIT_RAM_SIZE OCRAM_SIZE /* XHCI Support - enabled by default */ -#define CONFIG_HAS_FSL_XHCI_USB - -#ifdef CONFIG_HAS_FSL_XHCI_USB #define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT1 -#endif #define CONFIG_SYS_CLK_FREQ1 #define CONFIG_DDR_CLK_FREQ1 diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index f3d3aa2271..0046ded536 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -405,12 +405,8 @@ unsigned long get_board_ddr_clk(void); #endif /*XHCI Support - enabled by default*/ -#define CONFIG_HAS_FSL_XHCI_USB - -#ifdef CONFIG_HAS_FSL_XHCI_USB #define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT1 -#endif /* * Video diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 852ff57fb6..0172c9015d 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -45,12 +45,8 @@ #endif /* XHCI Support - enabled by default */ -#define CONFIG_HAS_FSL_XHCI_USB - -#ifdef CONFIG_HAS_FSL_XHCI_USB #define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT1 -#endif #define CONFIG_SYS_CLK_FREQ1 #define CONFIG_DDR_CLK_FREQ1 diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h index 5aadd92efd..607c289d17 100644 --- a/include/configs/ls1043aqds.h +++ b/include/configs/ls1043aqds.h @@ -371,11 +371,8 @@ unsigned long get_board_ddr_clk(void); #endif /* USB */ -#define CONFIG_HAS_FSL_XHCI_USB -#ifdef CONFIG_HAS_FSL_XHCI_USB #define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT3 -#endif /* * Miscellaneous configurable options diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h index ca1d862479..866817d579 100644 --- a/include/configs/ls1043ardb.h +++ b/include/configs/ls1043ardb.h @@ -281,12 +281,9 @@ /* USB */ #ifndef
[U-Boot] [PATCH v4 2/5] usb: host: Move CONFIG_XHCI_FSL to Kconfig
use Kconfig to select xhci accordingly. Signed-off-by: Ran Wang Reviewed-by: Bin Meng --- drivers/usb/host/Kconfig | 6 ++ include/configs/ls1012afrdm.h | 1 - include/configs/ls1012aqds.h | 1 - include/configs/ls1012ardb.h | 1 - include/configs/ls1021aiot.h | 1 - include/configs/ls1021aqds.h | 1 - include/configs/ls1021atwr.h | 1 - include/configs/ls1043aqds.h | 1 - include/configs/ls1043ardb.h | 1 - include/configs/ls1046aqds.h | 1 - include/configs/ls1046ardb.h | 1 - include/configs/ls2080aqds.h | 1 - include/configs/ls2080ardb.h | 1 - scripts/config_whitelist.txt | 1 - 14 files changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index f797a2568c..5da846728a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -71,6 +71,12 @@ config USB_XHCI_DRA7XX_INDEX Select the DRA7XX xHCI USB index. Current supported values: 0, 1. +config USB_XHCI_FSL + bool "Support for NXP Layerscape on-chip xHCI USB controller" + default y if ARCH_LS1021A || FSL_LSCH3 || FSL_LSCH2 + depends on !SPL_NO_USB + help + Enables support for the on-chip xHCI controller on NXP Layerscape SoCs. endif # USB_XHCI_HCD config USB_EHCI_HCD diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h index 2e5af9cc4e..2e9c619bd5 100644 --- a/include/configs/ls1012afrdm.h +++ b/include/configs/ls1012afrdm.h @@ -34,7 +34,6 @@ /* * USB */ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 #define CONFIG_CMD_MEMINFO diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h index e0949d0b53..70bf72c431 100644 --- a/include/configs/ls1012aqds.h +++ b/include/configs/ls1012aqds.h @@ -119,7 +119,6 @@ #endif /*XHCI Support - enabled by default*/ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 /* MMC */ diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h index 66ff004384..110fcc6323 100644 --- a/include/configs/ls1012ardb.h +++ b/include/configs/ls1012ardb.h @@ -22,7 +22,6 @@ /* * USB */ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 /* diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h index 2cbea87d95..dac4a81e2a 100644 --- a/include/configs/ls1021aiot.h +++ b/include/configs/ls1021aiot.h @@ -20,7 +20,6 @@ #define CONFIG_SYS_INIT_RAM_SIZE OCRAM_SIZE /* XHCI Support - enabled by default */ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT1 #define CONFIG_SYS_CLK_FREQ1 diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 0046ded536..8346e3658f 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -405,7 +405,6 @@ unsigned long get_board_ddr_clk(void); #endif /*XHCI Support - enabled by default*/ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT1 /* diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 0172c9015d..8ccc81642d 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -45,7 +45,6 @@ #endif /* XHCI Support - enabled by default */ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT1 #define CONFIG_SYS_CLK_FREQ1 diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h index 607c289d17..641ffc1400 100644 --- a/include/configs/ls1043aqds.h +++ b/include/configs/ls1043aqds.h @@ -371,7 +371,6 @@ unsigned long get_board_ddr_clk(void); #endif /* USB */ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT3 /* diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h index 866817d579..0e02be445a 100644 --- a/include/configs/ls1043ardb.h +++ b/include/configs/ls1043ardb.h @@ -281,7 +281,6 @@ /* USB */ #ifndef SPL_NO_USB -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT3 #endif diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h index d47616f2e7..2f2602f098 100644 --- a/include/configs/ls1046aqds.h +++ b/include/configs/ls1046aqds.h @@ -137,7 +137,6 @@ unsigned long get_board_ddr_clk(void); #endif /* USB */ -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 3 /* SATA */ diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h index 32b08d8229..40ce8ff462 100644 --- a/include/configs/ls1046ardb.h +++ b/include/configs/ls1046ardb.h @@ -211,7 +211,6 @@ /* USB */ #ifndef SPL_NO_USB -#define CONFIG_USB_XHCI_FSL #define CONFIG_USB_MAX_CONTROLLER_COUNT 3 #endif diff --git a/include/configs/ls2080aqds.h b/include/configs/ls2080aqds.h index 74a21ab4e1..5a5debbfc0 100644 --- a/include/configs/ls2080aqds.h +++ b/include/configs/ls2080aqds.h @@ -439,7 +439,6
[U-Boot] [PATCH v4 3/5] arm: layerscape: Remove CONFIG_USB_MAX_CONTROLLER_COUNT
Because COMFIG_DM_USB has been enabled and will not use it anymore. Signed-off-by: Ran Wang Reviewed-by: Bin Meng --- include/configs/ls1012afrdm.h | 5 - include/configs/ls1012aqds.h | 3 --- include/configs/ls1012ardb.h | 4 include/configs/ls1021aiot.h | 3 --- include/configs/ls1021aqds.h | 3 --- include/configs/ls1021atwr.h | 3 --- include/configs/ls1043aqds.h | 3 --- include/configs/ls1043ardb.h | 5 - include/configs/ls1046aqds.h | 3 --- include/configs/ls1046ardb.h | 5 - include/configs/ls2080aqds.h | 5 - include/configs/ls2080ardb.h | 5 - 12 files changed, 47 deletions(-) diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h index 2e9c619bd5..efb4c00cd9 100644 --- a/include/configs/ls1012afrdm.h +++ b/include/configs/ls1012afrdm.h @@ -31,11 +31,6 @@ "kernel_load=0x9600\0" \ "kernel_size=0x280\0" -/* -* USB -*/ -#define CONFIG_USB_MAX_CONTROLLER_COUNT 1 - #define CONFIG_CMD_MEMINFO #define CONFIG_CMD_MEMTEST #define CONFIG_SYS_MEMTEST_START 0x8000 diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h index 70bf72c431..ffb512db45 100644 --- a/include/configs/ls1012aqds.h +++ b/include/configs/ls1012aqds.h @@ -118,9 +118,6 @@ #define CONFIG_EHCI_HCD_INIT_AFTER_RESET #endif -/*XHCI Support - enabled by default*/ -#define CONFIG_USB_MAX_CONTROLLER_COUNT 1 - /* MMC */ #ifdef CONFIG_MMC #define CONFIG_FSL_ESDHC diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h index 110fcc6323..0caa474636 100644 --- a/include/configs/ls1012ardb.h +++ b/include/configs/ls1012ardb.h @@ -19,10 +19,6 @@ #define CONFIG_SYS_MEMTEST_START 0x8000 #define CONFIG_SYS_MEMTEST_END 0x9fff -/* -* USB -*/ -#define CONFIG_USB_MAX_CONTROLLER_COUNT 1 /* * I2C IO expander diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h index dac4a81e2a..c8eb234670 100644 --- a/include/configs/ls1021aiot.h +++ b/include/configs/ls1021aiot.h @@ -19,9 +19,6 @@ #define CONFIG_SYS_INIT_RAM_ADDR OCRAM_BASE_ADDR #define CONFIG_SYS_INIT_RAM_SIZE OCRAM_SIZE -/* XHCI Support - enabled by default */ -#define CONFIG_USB_MAX_CONTROLLER_COUNT1 - #define CONFIG_SYS_CLK_FREQ1 #define CONFIG_DDR_CLK_FREQ1 diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 8346e3658f..6669f2f960 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -404,9 +404,6 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_EHCI_HCD_INIT_AFTER_RESET #endif -/*XHCI Support - enabled by default*/ -#define CONFIG_USB_MAX_CONTROLLER_COUNT1 - /* * Video */ diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 8ccc81642d..0f20e5e2cc 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -44,9 +44,6 @@ #define CONFIG_EHCI_HCD_INIT_AFTER_RESET #endif -/* XHCI Support - enabled by default */ -#define CONFIG_USB_MAX_CONTROLLER_COUNT1 - #define CONFIG_SYS_CLK_FREQ1 #define CONFIG_DDR_CLK_FREQ1 diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h index 641ffc1400..8cc2abb2b6 100644 --- a/include/configs/ls1043aqds.h +++ b/include/configs/ls1043aqds.h @@ -370,9 +370,6 @@ unsigned long get_board_ddr_clk(void); #endif #endif -/* USB */ -#define CONFIG_USB_MAX_CONTROLLER_COUNT3 - /* * Miscellaneous configurable options */ diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h index 0e02be445a..762ecf1f4c 100644 --- a/include/configs/ls1043ardb.h +++ b/include/configs/ls1043ardb.h @@ -279,11 +279,6 @@ #endif #endif -/* USB */ -#ifndef SPL_NO_USB -#define CONFIG_USB_MAX_CONTROLLER_COUNT3 -#endif - /* SATA */ #ifndef SPL_NO_SATA #define CONFIG_LIBATA diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h index 2f2602f098..3ce66ce6f1 100644 --- a/include/configs/ls1046aqds.h +++ b/include/configs/ls1046aqds.h @@ -136,9 +136,6 @@ unsigned long get_board_ddr_clk(void); #define CFG_LPUART_EN 0x2 #endif -/* USB */ -#define CONFIG_USB_MAX_CONTROLLER_COUNT 3 - /* SATA */ #define CONFIG_LIBATA #define CONFIG_SCSI_AHCI diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h index 40ce8ff462..bb27dd058a 100644 --- a/include/configs/ls1046ardb.h +++ b/include/configs/ls1046ardb.h @@ -209,11 +209,6 @@ #endif #endif -/* USB */ -#ifndef SPL_NO_USB -#define CONFIG_USB_MAX_CONTROLLER_COUNT 3 -#endif - /* SATA */ #ifndef SPL_NO_SATA #define CONFIG_LIBATA diff --git a/include/configs/ls2080aqds.h b/include/configs/ls2080aqds.h index 5a5debbfc0..497930dd9a 100644 --- a/include/configs/ls2080aqds.h +++ b/include/configs/ls2080aqds.h @@ -436,11 +436,6 @@ unsigned long get_boa
[U-Boot] [PATCH v4 5/5] ls1088aqds: Enable USB command on QDS for qspi-boot
Signed-off-by: Amrita Kumari Signed-off-by: Ashish Kumar Signed-off-by: Ran Wang Reviewed-by: Bin Meng --- configs/ls1088aqds_qspi_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/ls1088aqds_qspi_defconfig b/configs/ls1088aqds_qspi_defconfig index 4b0d604fa0..a24a6011c9 100644 --- a/configs/ls1088aqds_qspi_defconfig +++ b/configs/ls1088aqds_qspi_defconfig @@ -31,3 +31,11 @@ CONFIG_FSL_DSPI=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_FSL_LS_PPA=y +CONFIG_USB=y +CONFIG_USB_GADGET=y +CONFIG_CMD_USB=y +CONFIG_DM_USB=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_DWC3=y +CONFIG_USB_STORAGE=y -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/5] ls1088ardb: Enable USB command RDB qspi-boot
Signed-off-by: Ashish Kumar
Signed-off-by: Amrita Kumari
Signed-off-by: Ran Wang
Reviewed-by: Bin Meng
---
arch/arm/dts/fsl-ls1088a.dtsi | 14 ++
configs/ls1088ardb_qspi_defconfig | 8
include/linux/usb/xhci-fsl.h | 2 +-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index d943a9efa3..64b4fcf12b 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -76,6 +76,20 @@
num-cs = <4>;
};
+ usb0: usb3@310 {
+ compatible = "fsl,layerscape-dwc3";
+ reg = <0x0 0x310 0x0 0x1>;
+ interrupts = <0 80 0x4>; /* Level high type */
+ dr_mode = "host";
+ };
+
+ usb1: usb3@311 {
+ compatible = "fsl,layerscape-dwc3";
+ reg = <0x0 0x311 0x0 0x1>;
+ interrupts = <0 81 0x4>; /* Level high type */
+ dr_mode = "host";
+ };
+
pcie@340 {
compatible = "fsl,ls-pcie", "snps,dw-pcie";
reg = <0x00 0x0340 0x0 0x8 /* dbi registers */
diff --git a/configs/ls1088ardb_qspi_defconfig
b/configs/ls1088ardb_qspi_defconfig
index 2d5a134261..3034f506e2 100644
--- a/configs/ls1088ardb_qspi_defconfig
+++ b/configs/ls1088ardb_qspi_defconfig
@@ -31,3 +31,11 @@ CONFIG_FSL_DSPI=y
CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_FSL_LS_PPA=y
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
+CONFIG_CMD_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_STORAGE=y
diff --git a/include/linux/usb/xhci-fsl.h b/include/linux/usb/xhci-fsl.h
index bd54089722..a916afb885 100644
--- a/include/linux/usb/xhci-fsl.h
+++ b/include/linux/usb/xhci-fsl.h
@@ -58,7 +58,7 @@ struct fsl_xhci {
#define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR
#define CONFIG_SYS_FSL_XHCI_USB2_ADDR 0
#define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
-#elif defined(CONFIG_ARCH_LS2080A)
+#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A)
#define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR
#define CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_XHCI_USB2_ADDR
#define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] fsl/pci: fix leading whitespace of PCI_LTSSM_L0
Fix the whitespace of PCI_LTSSM_L0 in fsl_pci.h Signed-off-by: Bao Xiaowei --- arch/powerpc/include/asm/fsl_pci.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/fsl_pci.h b/arch/powerpc/include/asm/fsl_pci.h index cad341e72c..970f3a48d5 100644 --- a/arch/powerpc/include/asm/fsl_pci.h +++ b/arch/powerpc/include/asm/fsl_pci.h @@ -23,7 +23,7 @@ #define FSL_PROG_IF_AGENT 0x1 #define PCI_LTSSM 0x404 /* PCIe Link Training, Status State Machine */ -#define PCI_LTSSM_L0 0x16/* L0 state */ +#define PCI_LTSSM_L0 0x16/* L0 state */ int fsl_setup_hose(struct pci_controller *hose, unsigned long addr); int fsl_is_pci_agent(struct pci_controller *hose); -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific
For some special reset times for longer pcie devices, the pcie device
may on polling compliance state, the RC considers the pcie device is
link up, but the pcie device is not link up, only the L0 state is link
up state.
Signed-off-by: Bao Xiaowei
---
arch/powerpc/include/asm/fsl_pci.h | 2 ++
drivers/pci/fsl_pci_init.c | 10 ++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_pci.h
b/arch/powerpc/include/asm/fsl_pci.h
index 70a5461..323b182 100644
--- a/arch/powerpc/include/asm/fsl_pci.h
+++ b/arch/powerpc/include/asm/fsl_pci.h
@@ -25,6 +25,8 @@
#define PCI_LTSSM 0x404 /* PCIe Link Training, Status State Machine */
#define PCI_LTSSM_L0 0x16/* L0 state */
#define PCI_LTSSM_L0_PEX_REV3 0x11/* L0 state for pex rev3*/
+#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state */
+#define LTSSM_PCIE_DETECT_ACTIVE 0x01/* Detect state */
int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);
int fsl_is_pci_agent(struct pci_controller *hose);
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index be57e53..9b5f386 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller *hose,
pci_ltssm_l0 = PCI_LTSSM_L0;
ltssm = fsl_get_ltssm(hose, pci_info);
-
- if (ltssm == pci_ltssm_l0) {
+ if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+ ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
+ enabled = 0;
+ } else if (ltssm == pci_ltssm_l0) {
enabled = 1;
} else {
- for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
+ for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++) {
ltssm = fsl_get_ltssm(hose, pci_info);
udelay(1000);
}
- enabled = ltssm >= pci_ltssm_l0;
+ enabled = (ltssm == pci_ltssm_l0) ? 1 : 0;
}
return enabled;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] Powerpc: pcie: optmize the code of pci init function
Adjust the code structure, detail the function module function,
remove the redundancy code.
Signed-off-by: Bao Xiaowei
---
arch/powerpc/include/asm/fsl_pci.h | 1 +
drivers/pci/fsl_pci_init.c | 150 -
2 files changed, 83 insertions(+), 68 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_pci.h
b/arch/powerpc/include/asm/fsl_pci.h
index 970f3a48d5..70a5461709 100644
--- a/arch/powerpc/include/asm/fsl_pci.h
+++ b/arch/powerpc/include/asm/fsl_pci.h
@@ -24,6 +24,7 @@
#define PCI_LTSSM 0x404 /* PCIe Link Training, Status State Machine */
#define PCI_LTSSM_L0 0x16/* L0 state */
+#define PCI_LTSSM_L0_PEX_REV3 0x11/* L0 state for pex rev3*/
int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);
int fsl_is_pci_agent(struct pci_controller *hose);
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index af20cf0f3e..be57e53811 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -39,6 +39,8 @@ DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_SYS_PCI_64BIT) && !defined(CONFIG_SYS_PCI64_MEMORY_BUS)
#define CONFIG_SYS_PCI64_MEMORY_BUS (64ull*1024*1024*1024)
#endif
+#define PEX_CSR0_LTSSM_MASK0xFC
+#define PEX_CSR0_LTSSM_SHIFT 2
/* Setup one inbound ATMU window.
*
@@ -290,6 +292,80 @@ static void fsl_pcie_boot_master_release_slave(int port)
}
#endif
+static int fsl_is_pex_rev_3(struct fsl_pci_info *pci_info)
+{
+ u32 cfg_addr = (u32)&((ccsr_fsl_pci_t *)pci_info->regs)->cfg_addr;
+ ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)cfg_addr;
+ u32 block_rev;
+
+ block_rev = in_be32(&pci->block_rev1);
+ if (block_rev >= PEX_IP_BLK_REV_3_0)
+ return 1;
+
+ return 0;
+}
+
+static int fsl_get_ltssm(struct pci_controller *hose,
+struct fsl_pci_info *pci_info)
+{
+ u16 ltssm = 0;
+ pci_dev_t dev = PCI_BDF(hose->first_busno, 0, 0);
+ u32 cfg_addr = (u32)&((ccsr_fsl_pci_t *)pci_info->regs)->cfg_addr;
+ ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)cfg_addr;
+
+ if (fsl_is_pex_rev_3(pci_info))
+ ltssm = (in_be32(&pci->pex_csr0)
+ & PEX_CSR0_LTSSM_MASK) >> PEX_CSR0_LTSSM_SHIFT;
+ else
+ pci_hose_read_config_word(hose, dev, PCI_LTSSM, = pci_ltssm_l0;
+ }
+
+ return enabled;
+}
+
+#if defined(CONFIG_FSL_PCIE_RESET) || \
+ defined(CONFIG_SYS_P4080_ERRATUM_PCIE_A003)
+static void fsl_do_pcie_reset(struct fsl_pci_info *pci_info)
+{
+ u32 cfg_addr = (u32)&((ccsr_fsl_pci_t *)pci_info->regs)->cfg_addr;
+ ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)cfg_addr;
+
+ /* assert PCIe reset */
+ setbits_be32(&pci->pdb_stat, 0x0800);
+ (void) in_be32(&pci->pdb_stat);
+ udelay(1000);
+ /* clear PCIe reset */
+ clrbits_be32(&pci->pdb_stat, 0x0800);
+ asm("sync;isync");
+}
+#endif
+
void fsl_pci_init(struct pci_controller *hose, struct fsl_pci_info *pci_info)
{
u32 cfg_addr = (u32)&((ccsr_fsl_pci_t *)pci_info->regs)->cfg_addr;
@@ -298,7 +374,6 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
u32 temp32;
u32 block_rev;
int enabled, r, inbound = 0;
- u16 ltssm;
u8 temp8, pcie_cap;
int pcie_cap_pos;
int pci_dcr;
@@ -438,63 +513,12 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
udelay(1);
#endif
if (pcie_cap == PCI_CAP_ID_EXP) {
- if (block_rev >= PEX_IP_BLK_REV_3_0) {
-#define PEX_CSR0_LTSSM_MASK0xFC
-#define PEX_CSR0_LTSSM_SHIFT 2
- ltssm = (in_be32(&pci->pex_csr0)
- & PEX_CSR0_LTSSM_MASK) >> PEX_CSR0_LTSSM_SHIFT;
- enabled = (ltssm == 0x11) ? 1 : 0;
#ifdef CONFIG_FSL_PCIE_RESET
- int i;
- /* assert PCIe reset */
- setbits_be32(&pci->pdb_stat, 0x0800);
- (void) in_be32(&pci->pdb_stat);
- udelay(1000);
- /* clear PCIe reset */
- clrbits_be32(&pci->pdb_stat, 0x0800);
-
Re: [U-Boot] [PATCH] mtd: nand: fsl-ifc: fix support of multiple NAND devices
On Thu, Oct 19, 2017 at 09:30:09PM -0500, Scott Wood wrote:
> On Tue, Oct 17, 2017 at 10:00:45AM +0200, Kurt Kanzenbach wrote:
> > Currently the chipselect used to identify the corresponding NAND chip is
> > stored
> > at the controller and only set during fsl_ifc_chip_init(). This way, only
> > the
> > last NAND chip is working, as the previous value of cs_nand gets
> > overwritten.
> >
> > In order to solve this issue the chipselect is moved from the controller to
> > the
> > NAND chip structure. Thus, the correct chipselect for each NAND chip
> > operation
> > is used.
> >
> > Tested on hardware with two NAND chips connected to the IFC controller.
> >
> > Signed-off-by: Kurt Kanzenbach
> > ---
> > drivers/mtd/nand/fsl_ifc_nand.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/fsl_ifc_nand.c
> > b/drivers/mtd/nand/fsl_ifc_nand.c
> > index bc6bdc9b2c..57737dbe94 100644
> > --- a/drivers/mtd/nand/fsl_ifc_nand.c
> > +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> > @@ -36,6 +36,7 @@ struct fsl_ifc_mtd {
> >
> > struct device *dev;
> > int bank; /* Chip select bank number*/
> > + unsigned int cs_nand; /* On which chipsel NAND is connected */
>
> This is redundant with "bank" -- just do like the Linux driver does
> and write "priv->bank << IFC_NAND_CSEL_SHIFT" directly to the register
> when needed.
Sure, no problem.
>
> > -static int fsl_ifc_sram_init(uint32_t ver)
> > +static int fsl_ifc_sram_init(struct mtd_info *mtd, uint32_t ver)
> > {
> > + struct nand_chip *chip = mtd_to_nand(mtd);
> > + struct fsl_ifc_mtd *priv = nand_get_controller_data(chip);
>
> Could pass in priv instead of mtd to make it more like the Linux driver.
> It's best to avoid gratuitous differences.
Makes sense. I'll send a v2.
Thanks,
Kurt
>
> -Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] mtd: nand: fsl-ifc: fix support of multiple NAND devices
Currently the chipselect used to identify the corresponding NAND chip is stored
at the controller and only set during fsl_ifc_chip_init(). This way, only the
last NAND chip is working, as the previous value of cs_nand gets overwritten.
In order to solve this issue the chipselect is computed on demand by evaluating
the bank variable. Thus, the correct chipselect for each NAND chip operation is
used.
Tested on hardware with two NAND chips connected to the IFC controller.
Signed-off-by: Kurt Kanzenbach
---
Changes for v2:
- get rid of cs_nand and compute chipselect on demand
- pass priv instead of mtd to fsl_ifc_sram_init()
drivers/mtd/nand/fsl_ifc_nand.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index bc6bdc9b2c..a757a3be44 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -48,7 +48,6 @@ struct fsl_ifc_ctrl {
/* device info */
struct fsl_ifc regs;
void __iomem *addr; /* Address of assigned IFC buffer*/
- unsigned int cs_nand;/* On which chipsel NAND is connected*/
unsigned int page; /* Last page written to / read from */
unsigned int read_bytes; /* Number of bytes read during command */
unsigned int column; /* Saved column from SEQIN */
@@ -296,7 +295,7 @@ static int fsl_ifc_run_command(struct mtd_info *mtd)
int i;
/* set the chip select for NAND Transaction */
- ifc_out32(&ifc->ifc_nand.nand_csel, ifc_ctrl->cs_nand);
+ ifc_out32(&ifc->ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT);
/* start read/write seq */
ifc_out32(&ifc->ifc_nand.nandseq_strt,
@@ -798,7 +797,7 @@ static void fsl_ifc_select_chip(struct mtd_info *mtd, int
chip)
{
}
-static int fsl_ifc_sram_init(uint32_t ver)
+static int fsl_ifc_sram_init(struct fsl_ifc_mtd *priv, uint32_t ver)
{
struct fsl_ifc_runtime *ifc = ifc_ctrl->regs.rregs;
uint32_t cs = 0, csor = 0, csor_8k = 0, csor_ext = 0;
@@ -823,7 +822,7 @@ static int fsl_ifc_sram_init(uint32_t ver)
return 1;
}
- cs = ifc_ctrl->cs_nand >> IFC_NAND_CSEL_SHIFT;
+ cs = priv->bank;
/* Save CSOR and CSOR_ext */
csor = ifc_in32(&ifc_ctrl->regs.gregs->csor_cs[cs].csor);
@@ -850,7 +849,7 @@ static int fsl_ifc_sram_init(uint32_t ver)
ifc_out32(&ifc->ifc_nand.col0, 0x0);
/* set the chip select for NAND Transaction */
- ifc_out32(&ifc->ifc_nand.nand_csel, ifc_ctrl->cs_nand);
+ ifc_out32(&ifc->ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT);
/* start read seq */
ifc_out32(&ifc->ifc_nand.nandseq_strt, IFC_NAND_SEQ_STRT_FIR_STRT);
@@ -911,10 +910,8 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
csor = ifc_in32(&gregs->csor_cs[priv->bank].csor);
if ((cspr & CSPR_V) && (cspr & CSPR_MSEL) == CSPR_MSEL_NAND &&
- (cspr & CSPR_BA) == CSPR_PHYS_ADDR(phys_addr)) {
- ifc_ctrl->cs_nand = priv->bank << IFC_NAND_CSEL_SHIFT;
+ (cspr & CSPR_BA) == CSPR_PHYS_ADDR(phys_addr))
break;
- }
}
if (priv->bank >= MAX_BANKS) {
@@ -1029,7 +1026,7 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
ver = ifc_in32(&gregs->ifc_rev);
if (ver >= FSL_IFC_V1_1_0)
- ret = fsl_ifc_sram_init(ver);
+ ret = fsl_ifc_sram_init(priv, ver);
if (ret)
return ret;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/26] mmc: Add support for HS200 and UHS modes
On 10/14/2017 11:51 PM, Marek Vasut wrote: > On 10/02/2017 11:15 AM, Jean-Jacques Hiblot wrote: >> >> >> On 22/09/2017 16:42, Jaehoon Chung wrote: >>> Dear JJ, >>> >>> On 09/21/2017 11:29 PM, Jean-Jacques Hiblot wrote: This series brings support for HS200 and UHS modes to the mmc core. It has been tested with the hsmmc driver on several platforms (DRA7, AM57x, AM437x, beaglebone black, Atmel SAMA5D3 xplained). Some modifications are required in the host driver to take advantage of this (voltage switching, tuning). The changes to the host driver will be posted a another series as this one is already long enough. The series starts with a small refactoring of th sd/mmc startup. The first 5 commits are mostly moving code around with little or no functionnal change. Then the notion of "mode" is introduced. Until now, this information wasn't kept in struct mmc. Only the clock and a flag for ddr was kept. Later the mode information will be used to select the clock frequency, the ddr flag and the tuning procedure. It will be also be check against the host capabilities. Then comes the big refactoring job in: "mmc: refactor MMC startup to make it easier to support new modes" and "mmc: refactor SD startup to make it easier to support new modes" Since the number of modes is increasing, it makes sense to try them in a more organized way. those commits use a list of supported modes and iterate through them to find the best working one. It also allows to switch more easilly from one mode to another (switching from HS200 to DDR52 to access boot partitions for example) Then there are a couple of new callback added to: - send the initialization stream (74 clock cycles) - wait while the card is busy (used during UHS voltage switching). checking is done on dat0. - select the IO voltage Then Power cycle is added. Without power cycle, if a UHS card fails to enumerate in UHS mode, it can't fall back to high speed mode and card enumeration will fail. Also in case of a reset (as opposed to a power on), it ensures that the SDCard is in clean state before re-doing the initialization. And finally the last commits add the support for HS200 and UHS. With this in place and the required changes in the HSMMC host driver (including DMA), we observe significant improvements in the performances on a DRA72 evm: eMMC HS200: 124 MB/s eMMC DDR52: 78 MB/s sd SDR104: 71 MB/s sd SDR50: 44 MB/s >>> I have one question. >>> >>> Did you test about accessing Boot partition of eMMC? >> >>> As i know, boot partition doesn't support the HS200 mode. >>> >>> When i checked your patches, there is no the function of mode changing >>> for accessing boot partition. >>> If i missed it, let me know, plz. >> Yes I did test the boot partitions. HS200 is not used in this case. >> The key function is mmc_boot_part_access_chk(). It checks if the current >> mode is supported by the partition. If not, it'll reselect a new mode. > > Is anything new happening on the HS200 front ? Will apply this patchset. Thanks! Best Regards, Jaehoon Chung > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/26] mmc: Add support for HS200 and UHS modes
Dear JJ On 09/21/2017 11:29 PM, Jean-Jacques Hiblot wrote: > This series brings support for HS200 and UHS modes to the mmc core. > It has been tested with the hsmmc driver on several platforms (DRA7, > AM57x, AM437x, beaglebone black, Atmel SAMA5D3 xplained). Some modifications > are required in the host driver to take advantage of this (voltage switching, > tuning). The changes to the host driver will be posted a another series as > this > one is already long enough. > > The series starts with a small refactoring of th sd/mmc startup. The first 5 > commits > are mostly moving code around with little or no functionnal change. > > Then the notion of "mode" is introduced. Until now, this information wasn't > kept in struct mmc. Only the clock and a flag for ddr was kept. Later the mode > information will be used to select the clock frequency, the ddr flag and the > tuning procedure. It will be also be check against the host capabilities. > > Then comes the big refactoring job in: > "mmc: refactor MMC startup to make it easier to support new modes" and > "mmc: refactor SD startup to make it easier to support new modes" > Since the number of modes is increasing, it makes sense to try them in a more > organized way. those commits use a list of supported modes and iterate through > them to find the best working one. It also allows to switch more easilly from > one mode to another (switching from HS200 to DDR52 to access boot partitions > for example) > > Then there are a couple of new callback added to: > - send the initialization stream (74 clock cycles) > - wait while the card is busy (used during UHS voltage switching). checking is > done on dat0. > - select the IO voltage > > Then Power cycle is added. Without power cycle, if a UHS card fails to > enumerate in > UHS mode, it can't fall back to high speed mode and card enumeration will > fail. > Also in case of a reset (as opposed to a power on), it ensures that the SDCard > is in clean state before re-doing the initialization. > > And finally the last commits add the support for HS200 and UHS. > > With this in place and the required changes in the HSMMC host driver > (including > DMA), we observe significant improvements in the performances on a DRA72 evm: > eMMC HS200: 124 MB/s > eMMC DDR52: 78 MB/s > sd SDR104: 71 MB/s > sd SDR50: 44 MB/s Applied to u-boot-mmc! Thanks! I will apply the patches relevant to this patchset. Sorry for late applying this. Best Regards, Jaehoon Chung > > cheers, > > Jean-Jacques > > changes since v1: > Changes take in account all the comment made during the first round of review. > But it also include a rework of the handling of the voltage supplies and 2 new > helper functions that can be used by the host driver during tuning and dts > parsing. > > Here is a detailed list: > * rebase on u-boot/master. > * add the description for the new functions/members > * fix the typos found in the reviews > * limit the new features to DM_MMC only > * fix the new checkpatch warnings/errors (is it now more strict ?) > * get the voltage regulators from dts (main and IO-lines) > * remove the set_vdd callback and do the job in the mmc core > * add a send_init_stream callback to perform the 74 clock cycle >sequence after power up > * do a full power cycle (if possible) before the initialization. This ensures >that the sd/MMC is in valid knwon state. Also it allows to check if the > power >cycling works as expected. > * disable the UHS modes is power cycling is not available/working. This > ensures >that we won't be stuck if the UHS initialization fails. > * select the appropriate signal voltage when selecting a mode (MMC only) > * add a helper function to parse the generic dt bindings > * add a helper function to send the tuning command > > Jean-Jacques Hiblot (17): > mmc: dm: get the IO-line and main voltage regulators from the dts > mmc: split mmc_startup() > mmc: move the MMC startup for version above v4.0 in a separate > function > mmc: make ext_csd part of struct mmc > mmc: add a function to read and test the ext csd (mmc >= 4) > mmc: introduce mmc modes > mmc: Add a function to dump the mmc capabilities > mmc: use mmc modes to select the correct bus speed > cmd: mmc: display the mode name and current bus speed in the mmc info > mmc: refactor SD startup to make it easier to support new modes > mmc: refactor MMC startup to make it easier to support new modes > mmc: Add a new callback function to perform the 74 clocks cycle > sequence > mmc: Add support for UHS modes > mmc: disable UHS modes if Vcc cannot be switched on and off > mmc: Change mode when switching to a boot partition > mmc: use the right voltage level for MMC DDR and HS200 modes > mmc: add a library function to send tuning command > > Kishon Vijay Abraham I (9): > mmc: make mmc_set_ios() return status > mmc: Enable signal voltage to be selected from mmc core > mmc: add p
[U-Boot] [PATCH v2] imx: Fix regression with CONFIG_DM_MMC=y
When CONFIG_DM_MMC=y, CONFIG_BLK should be selected, otherwise the SD/eMMC card cannot be used. Also, select CONFIG_DM_USB=y when CONFIG_USB=y to avoid build failure. Tested on mx6slevk, mx7dsabresd and mx6ullevk. Signed-off-by: Fabio Estevam --- Changes since v1: - Cover all imx boards configs/imx6q_logic_defconfig | 1 - configs/imx6qdl_icore_nand_defconfig | 1 - configs/imx6ul_geam_mmc_defconfig | 1 - configs/imx6ul_geam_nand_defconfig| 1 - configs/imx6ul_isiot_emmc_defconfig | 1 - configs/imx6ul_isiot_mmc_defconfig| 1 - configs/imx6ul_isiot_nand_defconfig | 1 - configs/mx6slevk_defconfig| 2 +- configs/mx6slevk_spinor_defconfig | 2 +- configs/mx6sllevk_defconfig | 1 - configs/mx6sllevk_plugin_defconfig| 1 - configs/mx6sxsabreauto_defconfig | 2 +- configs/mx6ull_14x14_evk_defconfig| 1 - configs/mx6ull_14x14_evk_plugin_defconfig | 1 - configs/mx7dsabresd_defconfig | 1 - configs/mx7dsabresd_secure_defconfig | 1 - configs/mx7ulp_evk_defconfig | 1 - configs/mx7ulp_evk_plugin_defconfig | 1 - configs/opos6uldev_defconfig | 1 - 19 files changed, 3 insertions(+), 19 deletions(-) diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig index 8018198..c7d3046 100644 --- a/configs/imx6q_logic_defconfig +++ b/configs/imx6q_logic_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/imx6qdl_icore_nand_defconfig b/configs/imx6qdl_icore_nand_defconfig index c341b17..80a8679 100644 --- a/configs/imx6qdl_icore_nand_defconfig +++ b/configs/imx6qdl_icore_nand_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_UBI=y CONFIG_OF_LIST="imx6q-icore imx6dl-icore" CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/imx6ul_geam_mmc_defconfig b/configs/imx6ul_geam_mmc_defconfig index 7c79873..ce7c288 100644 --- a/configs/imx6ul_geam_mmc_defconfig +++ b/configs/imx6ul_geam_mmc_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y diff --git a/configs/imx6ul_geam_nand_defconfig b/configs/imx6ul_geam_nand_defconfig index d6038c1..8d7eb0d 100644 --- a/configs/imx6ul_geam_nand_defconfig +++ b/configs/imx6ul_geam_nand_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_UBI=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/imx6ul_isiot_emmc_defconfig b/configs/imx6ul_isiot_emmc_defconfig index 67fa9a0..94af53e 100644 --- a/configs/imx6ul_isiot_emmc_defconfig +++ b/configs/imx6ul_isiot_emmc_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y -# CONFIG_BLK is not set CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y CONFIG_FEC_MXC=y diff --git a/configs/imx6ul_isiot_mmc_defconfig b/configs/imx6ul_isiot_mmc_defconfig index c673d93..0a990d7 100644 --- a/configs/imx6ul_isiot_mmc_defconfig +++ b/configs/imx6ul_isiot_mmc_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y diff --git a/configs/imx6ul_isiot_nand_defconfig b/configs/imx6ul_isiot_nand_defconfig index e481151..e806127 100644 --- a/configs/imx6ul_isiot_nand_defconfig +++ b/configs/imx6ul_isiot_nand_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_UBI=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig index 16e2cca..7b1ddac 100644 --- a/configs/mx6slevk_defconfig +++ b/configs/mx6slevk_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_MMC=y CONFIG_DM=y -# CONFIG_BLK is not set CONFIG_DM_GPIO=y CONFIG_DM_I2C=y CONFIG_DM_MMC=y @@ -45,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_THERMAL=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/configs/mx6slevk_spinor_defconfig b/configs/mx6slevk_spinor_defconfig index 020d19f..4b9c04e 100644 --- a/configs/mx6slevk_spinor_defconfig +++ b/configs/mx6slevk_spinor_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_DM=y -# CONFIG_BLK is not set CONFIG_DM_GPIO=y CONFIG_DM_I2C=y CONFIG_DM_MMC=y @@ -45,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_TH
Re: [U-Boot] fsl_esdhc driver is broken with DM
On Fri, Oct 20, 2017 at 12:18 AM, Adam Ford wrote: > Yes it did. Thank you > > I'll submit a patch. Should I indicate it 'fixes' that commit I > referenced, or is there some other commit that I should reference? I have just sent a patch that fixes the issue for all imx boards. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] drivers: mmc: Avoid memory leak in case of failure
On 10/05/2017 03:18 PM, suni...@techveda.org wrote:
> From: Suniel Mahesh
>
> priv pointer should be freed before returning with an error value
> from exynos_dwmci_get_config().
>
> Signed-off-by: Suniel Mahesh
> Signed-off-by: Raghu Bharadwaj
Applied to u-boot-mmc.
Best Regards,
Jaehoon Chung
> ---
> Changes for v2:
> - rebased on latest u-boot tree (2017.11.rc1)
> - patch was accepted long time ago, but not applied to u-boot-mmc,
> please apply.
> ---
> Note:
> Tested on latest u-boot mainline tree, no build issues.
> ---
> drivers/mmc/exynos_dw_mmc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> index 40f7892..84ef2da 100644
> --- a/drivers/mmc/exynos_dw_mmc.c
> +++ b/drivers/mmc/exynos_dw_mmc.c
> @@ -168,6 +168,7 @@ static int exynos_dwmci_get_config(const void *blob, int
> node,
>
> if (host->dev_index > 4) {
> printf("DWMMC%d: Can't get the dev index\n", host->dev_index);
> + free(priv);
> return -EINVAL;
> }
>
> @@ -178,6 +179,7 @@ static int exynos_dwmci_get_config(const void *blob, int
> node,
> base = fdtdec_get_addr(blob, node, "reg");
> if (!base) {
> printf("DWMMC%d: Can't get base address\n", host->dev_index);
> + free(priv);
> return -EINVAL;
> }
> host->ioaddr = (void *)base;
> @@ -187,6 +189,7 @@ static int exynos_dwmci_get_config(const void *blob, int
> node,
> if (err) {
> printf("DWMMC%d: Can't get sdr-timings for devider\n",
> host->dev_index);
> + free(priv);
> return -EINVAL;
> }
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] drivers: mmc: Change buffer type in ALLOC_CACHE_ALIGN_BUFFER macro
On 10/05/2017 03:02 PM, suni...@techveda.org wrote:
> From: Suniel Mahesh
>
> __be32_to_cpu() accepts argument of type __be32. This patch changes
> type of the buffer in ALLOC_CACHE_ALIGN_BUFFER macro to __be32, which
> is then passed to __be32_to_cpu().
> This prevents sparse build warnings.
> drivers/mmc/mmc.c: warning: cast to restricted __be32
>
> Signed-off-by: Suniel Mahesh
> Signed-off-by: Karthik Tummala
Applied to u-boot-mmc!
Best Regards,
Jaehoon Chung
> ---
> Changes for v2:
> - rebased on latest u-boot tree (2017.11.rc1)
> - patch was accepted long time ago, but not applied to u-boot-mmc,
> please apply.
> ---
> Note:
> Tested on latest u-boot mainline tree, no build issues.
> ---
> drivers/mmc/mmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 38d2e07..8716ac7 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -882,8 +882,8 @@ static int sd_change_freq(struct mmc *mmc)
> {
> int err;
> struct mmc_cmd cmd;
> - ALLOC_CACHE_ALIGN_BUFFER(uint, scr, 2);
> - ALLOC_CACHE_ALIGN_BUFFER(uint, switch_status, 16);
> + ALLOC_CACHE_ALIGN_BUFFER(__be32, scr, 2);
> + ALLOC_CACHE_ALIGN_BUFFER(__be32, switch_status, 16);
> struct mmc_data data;
> int timeout;
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: Fix regression with CONFIG_DM_MMC=y
On 10/20/2017 08:41 PM, Fabio Estevam wrote: > When CONFIG_DM_MMC=y, CONFIG_BLK should be selected, otherwise the > SD/eMMC card cannot be used. > > Also, select CONFIG_DM_USB=y when CONFIG_USB=y to avoid build failure. > > Tested on mx6slevk, mx7dsabresd and mx6ullevk. > > Signed-off-by: Fabio Estevam Reviewed-by: Jaehoon Chung > --- > Changes since v1: > - Cover all imx boards > > configs/imx6q_logic_defconfig | 1 - > configs/imx6qdl_icore_nand_defconfig | 1 - > configs/imx6ul_geam_mmc_defconfig | 1 - > configs/imx6ul_geam_nand_defconfig| 1 - > configs/imx6ul_isiot_emmc_defconfig | 1 - > configs/imx6ul_isiot_mmc_defconfig| 1 - > configs/imx6ul_isiot_nand_defconfig | 1 - > configs/mx6slevk_defconfig| 2 +- > configs/mx6slevk_spinor_defconfig | 2 +- > configs/mx6sllevk_defconfig | 1 - > configs/mx6sllevk_plugin_defconfig| 1 - > configs/mx6sxsabreauto_defconfig | 2 +- > configs/mx6ull_14x14_evk_defconfig| 1 - > configs/mx6ull_14x14_evk_plugin_defconfig | 1 - > configs/mx7dsabresd_defconfig | 1 - > configs/mx7dsabresd_secure_defconfig | 1 - > configs/mx7ulp_evk_defconfig | 1 - > configs/mx7ulp_evk_plugin_defconfig | 1 - > configs/opos6uldev_defconfig | 1 - > 19 files changed, 3 insertions(+), 19 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: Fix regression with CONFIG_DM_MMC=y
On Fri, Oct 20, 2017 at 6:51 AM, Jaehoon Chung wrote: > On 10/20/2017 08:41 PM, Fabio Estevam wrote: >> When CONFIG_DM_MMC=y, CONFIG_BLK should be selected, otherwise the >> SD/eMMC card cannot be used. >> >> Also, select CONFIG_DM_USB=y when CONFIG_USB=y to avoid build failure. >> >> Tested on mx6slevk, mx7dsabresd and mx6ullevk. >> >> Signed-off-by: Fabio Estevam > > Reviewed-by: Jaehoon Chung This fixed the Logic PD iMX6 development kit. Tested-by: Adam Ford >> --- >> Changes since v1: >> - Cover all imx boards >> >> configs/imx6q_logic_defconfig | 1 - >> configs/imx6qdl_icore_nand_defconfig | 1 - >> configs/imx6ul_geam_mmc_defconfig | 1 - >> configs/imx6ul_geam_nand_defconfig| 1 - >> configs/imx6ul_isiot_emmc_defconfig | 1 - >> configs/imx6ul_isiot_mmc_defconfig| 1 - >> configs/imx6ul_isiot_nand_defconfig | 1 - >> configs/mx6slevk_defconfig| 2 +- >> configs/mx6slevk_spinor_defconfig | 2 +- >> configs/mx6sllevk_defconfig | 1 - >> configs/mx6sllevk_plugin_defconfig| 1 - >> configs/mx6sxsabreauto_defconfig | 2 +- >> configs/mx6ull_14x14_evk_defconfig| 1 - >> configs/mx6ull_14x14_evk_plugin_defconfig | 1 - >> configs/mx7dsabresd_defconfig | 1 - >> configs/mx7dsabresd_secure_defconfig | 1 - >> configs/mx7ulp_evk_defconfig | 1 - >> configs/mx7ulp_evk_plugin_defconfig | 1 - >> configs/opos6uldev_defconfig | 1 - >> 19 files changed, 3 insertions(+), 19 deletions(-) >> > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] sunxi: Fix boot of Cubietruk and al.
Hi Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09 (the two variants of the Olinuxino-Lime2 and the cubietruck at least, possibly more since then). This is due to a size increase of the binary that will trip us across the size we've been using in our default configuration since forever, and widely distributed through the u-boot-sunxi-with-spl.bin file. We would have several ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move. The second one would be to move the environment to a filesystem file, which would also break all the existing users. This can be envisionned as a long term fix though. Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. However, this will always result in pointless and endless discussions, so let's move away from that. The final one that has been implemented would be to just build U-Boot using thumb2 to push back the issue until hopefully I'm no longer maintainer or the switch to the env filesystem would have been done. I've also added a patch to make sure that the compilation breaks and that we can notice. Maxime Changes from v2: - Reorder the patches - Changed the wording of U-boot to U-Boot - Changed the hardcoded value for CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR Maxime Ripard (2): sunxi: Enable THUMB build for the U-Boot binary sunxi: binman: Add U-Boot binary size check arch/arm/Kconfig | 1 + arch/arm/dts/sunxi-u-boot.dtsi | 12 2 files changed, 13 insertions(+) -- 2.14.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] sunxi: binman: Add U-Boot binary size check
The U-Boot binary may trip over its actual allocated size in the storage.
In such a case, the environment will not be readable anymore (because
corrupted when the new image was flashed), and any attempt at using saveenv
to reconstruct the environment will result in a corrupted U-Boot binary.
Reviewed-by: Andre Przywara
Signed-off-by: Maxime Ripard
---
arch/arm/dts/sunxi-u-boot.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 5adfd9bca2ec..72e95afd780e 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -1,5 +1,14 @@
#include
+/*
+ * This is the maximum size the U-Boot binary can be, which is basically
+ * the start of the environment, minus the start of the U-Boot binary in
+ * the MMC. This makes the assumption that the MMC is using 512-bytes
+ * blocks, but devices using something other than that remains to be
+ * seen.
+ */
+#define UBOOT_MMC_MAX_SIZE (CONFIG_ENV_OFFSET -
(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512))
+
/ {
binman {
filename = "u-boot-sunxi-with-spl.bin";
@@ -8,6 +17,9 @@
filename = "spl/sunxi-spl.bin";
};
u-boot-img {
+#ifdef CONFIG_MMC
+ size = ;
+#endif
pos = ;
};
};
--
2.14.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] sunxi: Enable THUMB build for the U-Boot binary
We start to get to the limit of our main U-Boot binary size (with some boards even crossing it). Enable its build using thumb2 to get some extra room. Suggested-by: Siarhei Siamashka Signed-off-by: Maxime Ripard --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 64e0ee43f112..83b7aa51dc2c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -698,6 +698,7 @@ config ARCH_SUNXI select SPL_SYS_MALLOC_SIMPLE if SPL select SYS_NS16550 select SPL_SYS_THUMB_BUILD if !ARM64 + select SYS_THUMB_BUILD if !ARM64 select USB if DISTRO_DEFAULTS select USB_STORAGE if DISTRO_DEFAULTS select USB_KEYBOARD if DISTRO_DEFAULTS -- 2.14.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard wrote: > On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote: >> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard >> wrote: >> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote: >> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson >> >> wrote: >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard >> >> > wrote: >> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote: >> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard >> >> >>> wrote: >> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which >> >> >>> > makes us >> >> >>> > trip across the size limit we've had on the U-Boot binary. >> >> >>> > >> >> >>> > Since it's not an essential feature, disable it by default for >> >> >>> > ARCH_SUNXI >> >> >>> > so that we get back some extra room for user customisations. >> >> >>> >> >> >>> Does this disable it on aarch64 boards by default such as the Pine64? >> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to >> >> >>> boot aarch64 devices and this would regress this for all those >> >> >>> distros. >> >> >> >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add >> >> >> to their defconfig. These are just default configuration, not >> >> >> one-size-fits-all configuration. >> >> > >> >> > So you're making at least three groups of users do more work? It could >> >> > also be argued that those that need the smaller space could disable it >> >> > if they don't need it in their configuration. >> >> >> >> Ultimately the problem with the argument about disabling it by default >> >> and distros can enable it if they want to is a false one. >> > >> > If it's a false one, then I guess Red Hat doesn't have any kind of >> > custom defconfigs for Fedora or RHEL for the kernel? >> >> kernel is part of the distro, "firmware" (ie. u-boot or whatever >> implements UEFI) should not be.. so this argument is a bit of a red >> herring. > > Then that discussion is entirely moot. If the distros don't care about > building the U-Boot binary, why should they care about maintaining the > U-Boot's defconfig like Peter was suggesting? You're taking that and turning it around wrong, we currently have to care about building it. Ultimately what we'd like is to not have to care. One is the current status quo, the other is future desire! >> Maybe the solution is a "distro.config" option to separate options >> that make sense for distro/EBBR from what people who are doing more >> non-standard boot-chains are wanting. > > It's kind of amazing to see that the usual boot-chain that people have > been relying on for more than a decade and is still in use in the > immense majority of devices can be seen as "non-standard". But I guess > that's a different topic. > >> For example, for UEFI boot, we can disable all the filesystems other >> than FAT if you need to trim some space. And maybe doing a more >> simplified (ie. add it to efi_bootmgr.c) alternative to distro >> bootcmd could save a bunch of .text space. In fact we don't really >> need the scripting env at all. Probably there are other options for >> things to disable that I haven't thought of if you *really* needed >> to trim down. > > That's good to know. Hopefully we won't need to trim that space since > we got a bit more room to spare by switching to thumb, and if we can > move to a filesystem based environment, we won't ever need it. > > Thanks! > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Fri, Oct 20, 2017 at 01:27:36PM +0100, Peter Robinson wrote: > On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard > wrote: > > On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote: > >> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard > >> wrote: > >> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote: > >> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson > >> >> wrote: > >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard > >> >> > wrote: > >> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote: > >> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard > >> >> >>> wrote: > >> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which > >> >> >>> > makes us > >> >> >>> > trip across the size limit we've had on the U-Boot binary. > >> >> >>> > > >> >> >>> > Since it's not an essential feature, disable it by default for > >> >> >>> > ARCH_SUNXI > >> >> >>> > so that we get back some extra room for user customisations. > >> >> >>> > >> >> >>> Does this disable it on aarch64 boards by default such as the > >> >> >>> Pine64? > >> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to > >> >> >>> boot aarch64 devices and this would regress this for all those > >> >> >>> distros. > >> >> >> > >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can > >> >> >> add > >> >> >> to their defconfig. These are just default configuration, not > >> >> >> one-size-fits-all configuration. > >> >> > > >> >> > So you're making at least three groups of users do more work? It could > >> >> > also be argued that those that need the smaller space could disable it > >> >> > if they don't need it in their configuration. > >> >> > >> >> Ultimately the problem with the argument about disabling it by default > >> >> and distros can enable it if they want to is a false one. > >> > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of > >> > custom defconfigs for Fedora or RHEL for the kernel? > >> > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever > >> implements UEFI) should not be.. so this argument is a bit of a red > >> herring. > > > > Then that discussion is entirely moot. If the distros don't care about > > building the U-Boot binary, why should they care about maintaining the > > U-Boot's defconfig like Peter was suggesting? > > You're taking that and turning it around wrong, we currently have to > care about building it. Ultimately what we'd like is to not have to > care. One is the current status quo, the other is future desire! Then we're back to the previous question you didn't answer. If you have to build it, why can't you have a custom defconfig, or a configuration fragment like Rob suggested, like you do for the kernel? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51
Hi Fabio, On 19/10/2017 at 13:57, Fabio Estevam wrote: > > I would be interested to see if you can get an SD card high speed to > work with mainline U-Boot on your board. > > On my tests I need to force it 25MHz operation to be able to use the SD card. With mainline U-Boot on my board, normal-speed SD cards work fine, but not HS ones. Both types of cards work fine at 48 MHz with my custom and older U-Boot. The main difference seems to be the management of SD timeouts. I will try to track the differences until I find the root cause. The test results in PIO mode might also give some clues. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND] imx:display5: Add support for LWN's DISPLAY5 board (for v2017.11-rc2+)
This commit provides support for LWN's IMX6Q based DISPLAY5 board.
Signed-off-by: Lukasz Majewski
---
arch/arm/dts/imx6q-display5.dts | 18 ++
arch/arm/mach-imx/mx6/Kconfig | 7 +
board/liebherr/display5/Kconfig | 18 ++
board/liebherr/display5/MAINTAINERS | 7 +
board/liebherr/display5/Makefile| 11 +
board/liebherr/display5/common.c| 113 +
board/liebherr/display5/common.h| 42
board/liebherr/display5/display5.c | 440
board/liebherr/display5/spl.c | 247
configs/display5_defconfig | 61 +
configs/display5_factory_defconfig | 75 ++
include/configs/display5.h | 423 ++
12 files changed, 1462 insertions(+)
create mode 100644 arch/arm/dts/imx6q-display5.dts
create mode 100644 board/liebherr/display5/Kconfig
create mode 100644 board/liebherr/display5/MAINTAINERS
create mode 100644 board/liebherr/display5/Makefile
create mode 100644 board/liebherr/display5/common.c
create mode 100644 board/liebherr/display5/common.h
create mode 100644 board/liebherr/display5/display5.c
create mode 100644 board/liebherr/display5/spl.c
create mode 100644 configs/display5_defconfig
create mode 100644 configs/display5_factory_defconfig
create mode 100644 include/configs/display5.h
diff --git a/arch/arm/dts/imx6q-display5.dts b/arch/arm/dts/imx6q-display5.dts
new file mode 100644
index 000..50347ff
--- /dev/null
+++ b/arch/arm/dts/imx6q-display5.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright 2017
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+
+/ {
+ model = "Liebherr (LWN) display5 i.MX6 Quad Board";
+ compatible = "lwn,display5", "fsl,imx6q";
+};
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index b82db3a..fd73c67 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -138,6 +138,12 @@ config TARGET_DHCOMIMX6
select DM_THERMAL
imply CMD_SPL
+config TARGET_DISPLAY5
+ bool "LWN DISPLAY5 board"
+ select SUPPORT_SPL
+ select DM
+ select DM_SERIAL
+
config TARGET_EMBESTMX6BOARDS
bool "embestmx6boards"
select BOARD_LATE_INIT
@@ -459,6 +465,7 @@ source "board/phytec/pfla02/Kconfig"
source "board/gateworks/gw_ventana/Kconfig"
source "board/kosagi/novena/Kconfig"
source "board/samtec/vining_2000/Kconfig"
+source "board/liebherr/display5/Kconfig"
source "board/liebherr/mccmon6/Kconfig"
source "board/logicpd/imx6/Kconfig"
source "board/seco/Kconfig"
diff --git a/board/liebherr/display5/Kconfig b/board/liebherr/display5/Kconfig
new file mode 100644
index 000..b096c89
--- /dev/null
+++ b/board/liebherr/display5/Kconfig
@@ -0,0 +1,18 @@
+if TARGET_DISPLAY5
+
+config SYS_CPU
+ default "armv7"
+
+config SYS_BOARD
+ default "display5"
+
+config SYS_VENDOR
+ default "liebherr"
+
+config SYS_SOC
+ default "mx6"
+
+config SYS_CONFIG_NAME
+ default "display5"
+
+endif
diff --git a/board/liebherr/display5/MAINTAINERS
b/board/liebherr/display5/MAINTAINERS
new file mode 100644
index 000..5217831
--- /dev/null
+++ b/board/liebherr/display5/MAINTAINERS
@@ -0,0 +1,7 @@
+DISPLAY5 BOARD
+M: Lukasz Majewski
+S: Maintained
+F: board/liebherr/display5/
+F: include/configs/display5.h
+F: configs/display5_defconfig
+F: configs/display5_factory_defconfig
diff --git a/board/liebherr/display5/Makefile b/board/liebherr/display5/Makefile
new file mode 100644
index 000..f934672
--- /dev/null
+++ b/board/liebherr/display5/Makefile
@@ -0,0 +1,11 @@
+#
+# Copyright (C) 2017, DENX Software Engineering
+# Lukasz Majewski
+#
+# SPDX-License-Identifier:GPL-2.0+
+#
+ifdef CONFIG_SPL_BUILD
+obj-y = common.o spl.o
+else
+obj-y := common.o display5.o
+endif
diff --git a/board/liebherr/display5/common.c b/board/liebherr/display5/common.c
new file mode 100644
index 000..98d3d64
--- /dev/null
+++ b/board/liebherr/display5/common.c
@@ -0,0 +1,113 @@
+/*
+ * Copyright (C) 2017 DENX Software Engineering
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include "common.h"
+
+iomux_v3_cfg_t const uart_pads[] = {
+ /* UART4 */
+ MX6_PAD_CSI0_DAT12__UART4_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6_PAD_CSI0_DAT13__UART4_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6_PAD_CSI0_DAT16__UART4_RTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6_PAD_CSI0_DAT17__UART4_CTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
+};
+
+iomux_v3_cfg_t const uart_console_pads[] = {
+ /* UART5 */
+ MX6_PAD_CSI0_DAT14__UART5_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Fri, Oct 20, 2017 at 02:36:27PM +0200, Maxime Ripard wrote: > On Fri, Oct 20, 2017 at 01:27:36PM +0100, Peter Robinson wrote: > > On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard > > wrote: > > > On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote: > > >> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard > > >> wrote: > > >> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote: > > >> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson > > >> >> wrote: > > >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard > > >> >> > wrote: > > >> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote: > > >> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard > > >> >> >>> wrote: > > >> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, > > >> >> >>> > which makes us > > >> >> >>> > trip across the size limit we've had on the U-Boot binary. > > >> >> >>> > > > >> >> >>> > Since it's not an essential feature, disable it by default for > > >> >> >>> > ARCH_SUNXI > > >> >> >>> > so that we get back some extra room for user customisations. > > >> >> >>> > > >> >> >>> Does this disable it on aarch64 boards by default such as the > > >> >> >>> Pine64? > > >> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI > > >> >> >>> to > > >> >> >>> boot aarch64 devices and this would regress this for all those > > >> >> >>> distros. > > >> >> >> > > >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can > > >> >> >> add > > >> >> >> to their defconfig. These are just default configuration, not > > >> >> >> one-size-fits-all configuration. > > >> >> > > > >> >> > So you're making at least three groups of users do more work? It > > >> >> > could > > >> >> > also be argued that those that need the smaller space could disable > > >> >> > it > > >> >> > if they don't need it in their configuration. > > >> >> > > >> >> Ultimately the problem with the argument about disabling it by default > > >> >> and distros can enable it if they want to is a false one. > > >> > > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of > > >> > custom defconfigs for Fedora or RHEL for the kernel? > > >> > > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever > > >> implements UEFI) should not be.. so this argument is a bit of a red > > >> herring. > > > > > > Then that discussion is entirely moot. If the distros don't care about > > > building the U-Boot binary, why should they care about maintaining the > > > U-Boot's defconfig like Peter was suggesting? > > > > You're taking that and turning it around wrong, we currently have to > > care about building it. Ultimately what we'd like is to not have to > > care. One is the current status quo, the other is future desire! > > Then we're back to the previous question you didn't answer. If you > have to build it, why can't you have a custom defconfig, or a > configuration fragment like Rob suggested, like you do for the kernel? Because the goal is that boards ship from the manufacturer with a firmware that's "good enough". And firmware updates are handled by Someone Else, rather than the distro. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Fri, Oct 20, 2017 at 1:36 PM, Maxime Ripard wrote: > On Fri, Oct 20, 2017 at 01:27:36PM +0100, Peter Robinson wrote: >> On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard >> wrote: >> > On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote: >> >> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard >> >> wrote: >> >> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote: >> >> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson >> >> >> wrote: >> >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard >> >> >> > wrote: >> >> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote: >> >> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard >> >> >> >>> wrote: >> >> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, >> >> >> >>> > which makes us >> >> >> >>> > trip across the size limit we've had on the U-Boot binary. >> >> >> >>> > >> >> >> >>> > Since it's not an essential feature, disable it by default for >> >> >> >>> > ARCH_SUNXI >> >> >> >>> > so that we get back some extra room for user customisations. >> >> >> >>> >> >> >> >>> Does this disable it on aarch64 boards by default such as the >> >> >> >>> Pine64? >> >> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to >> >> >> >>> boot aarch64 devices and this would regress this for all those >> >> >> >>> distros. >> >> >> >> >> >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can >> >> >> >> add >> >> >> >> to their defconfig. These are just default configuration, not >> >> >> >> one-size-fits-all configuration. >> >> >> > >> >> >> > So you're making at least three groups of users do more work? It >> >> >> > could >> >> >> > also be argued that those that need the smaller space could disable >> >> >> > it >> >> >> > if they don't need it in their configuration. >> >> >> >> >> >> Ultimately the problem with the argument about disabling it by default >> >> >> and distros can enable it if they want to is a false one. >> >> > >> >> > If it's a false one, then I guess Red Hat doesn't have any kind of >> >> > custom defconfigs for Fedora or RHEL for the kernel? >> >> >> >> kernel is part of the distro, "firmware" (ie. u-boot or whatever >> >> implements UEFI) should not be.. so this argument is a bit of a red >> >> herring. >> > >> > Then that discussion is entirely moot. If the distros don't care about >> > building the U-Boot binary, why should they care about maintaining the >> > U-Boot's defconfig like Peter was suggesting? >> >> You're taking that and turning it around wrong, we currently have to >> care about building it. Ultimately what we'd like is to not have to >> care. One is the current status quo, the other is future desire! > > Then we're back to the previous question you didn't answer. If you > have to build it, why can't you have a custom defconfig, or a > configuration fragment like Rob suggested, like you do for the kernel? We probably could, but we haven't to date, and we don't do it for any of the other u-boot configs we build. It also doesn't fix the issue for other board vendors that ship them, and yes, despite what you've said previously, we do now get a lot of ARMv7 boards that have the distro defaults enabled for their boards and do just work out of the box for the distros. What is enabled by default upstream does make a difference for what vendors ship. Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific
On Fri, 2017-10-20 at 18:16 +0800, Bao Xiaowei wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> For some special reset times for longer pcie devices, the pcie device
> may on polling compliance state, the RC considers the pcie device is
> link up, but the pcie device is not link up, only the L0 state is link
> up state.
>
> Signed-off-by: Bao Xiaowei
> ---
> arch/powerpc/include/asm/fsl_pci.h | 2 ++
> drivers/pci/fsl_pci_init.c | 10 ++
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/fsl_pci.h
> b/arch/powerpc/include/asm/fsl_pci.h
> index 70a5461..323b182 100644
> --- a/arch/powerpc/include/asm/fsl_pci.h
> +++ b/arch/powerpc/include/asm/fsl_pci.h
> @@ -25,6 +25,8 @@
> #define PCI_LTSSM 0x404 /* PCIe Link Training, Status State Machine */
> #define PCI_LTSSM_L0 0x16/* L0 state */
> #define PCI_LTSSM_L0_PEX_REV3 0x11/* L0 state for pex rev3*/
> +#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state */
> +#define LTSSM_PCIE_DETECT_ACTIVE 0x01/* Detect state */
>
> int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);
> int fsl_is_pci_agent(struct pci_controller *hose);
> diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
> index be57e53..9b5f386 100644
> --- a/drivers/pci/fsl_pci_init.c
> +++ b/drivers/pci/fsl_pci_init.c
> @@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller *hose,
> pci_ltssm_l0 = PCI_LTSSM_L0;
>
> ltssm = fsl_get_ltssm(hose, pci_info);
> -
> - if (ltssm == pci_ltssm_l0) {
> + if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> + ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
> + enabled = 0;
> + } else if (ltssm == pci_ltssm_l0) {
> enabled = 1;
> } else {
> - for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
> + for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++) {
> ltssm = fsl_get_ltssm(hose, pci_info);
> udelay(1000);
Do you really need this long loop here ? It causes a long delay in case the
PCIe device
is in permanent polling
state. Our device is in polling state until clocks is configured
and that will be done from user space in Linux
> }
> - enabled = ltssm >= pci_ltssm_l0;
> + enabled = (ltssm == pci_ltssm_l0) ? 1 : 0;
> }
>
> return enabled;
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: Fix regression with CONFIG_DM_MMC=y
Hello Fabio, On 10/20/2017 01:41 PM, Fabio Estevam wrote: > When CONFIG_DM_MMC=y, CONFIG_BLK should be selected, otherwise the > SD/eMMC card cannot be used. > > Also, select CONFIG_DM_USB=y when CONFIG_USB=y to avoid build failure. > > Tested on mx6slevk, mx7dsabresd and mx6ullevk. > > Signed-off-by: Fabio Estevam > --- > Changes since v1: > - Cover all imx boards > > configs/imx6q_logic_defconfig | 1 - > configs/imx6qdl_icore_nand_defconfig | 1 - > configs/imx6ul_geam_mmc_defconfig | 1 - > configs/imx6ul_geam_nand_defconfig| 1 - > configs/imx6ul_isiot_emmc_defconfig | 1 - > configs/imx6ul_isiot_mmc_defconfig| 1 - > configs/imx6ul_isiot_nand_defconfig | 1 - > configs/mx6slevk_defconfig| 2 +- > configs/mx6slevk_spinor_defconfig | 2 +- > configs/mx6sllevk_defconfig | 1 - > configs/mx6sllevk_plugin_defconfig| 1 - > configs/mx6sxsabreauto_defconfig | 2 +- > configs/mx6ull_14x14_evk_defconfig| 1 - > configs/mx6ull_14x14_evk_plugin_defconfig | 1 - > configs/mx7dsabresd_defconfig | 1 - > configs/mx7dsabresd_secure_defconfig | 1 - > configs/mx7ulp_evk_defconfig | 1 - > configs/mx7ulp_evk_plugin_defconfig | 1 - > configs/opos6uldev_defconfig | 1 - > 19 files changed, 3 insertions(+), 19 deletions(-) > The compilation fails for the opos6uldev board. The following change is needed to fix it: diff --git a/include/configs/opos6uldev.h b/include/configs/opos6uldev.h index d018984..04fc602 100644 --- a/include/configs/opos6uldev.h +++ b/include/configs/opos6uldev.h @@ -17,6 +17,7 @@ #ifdef CONFIG_SPL_BUILD #undef CONFIG_DM_GPIO #undef CONFIG_DM_MMC +#undef CONFIG_BLK #define CONFIG_MXC_UART_BASE UART1_BASE #endif Otherwise, your change fixes the eMMC on the board. Tested-by: Sébastien Szymanski Thanks. Regards, -- Sébastien Szymanski Software engineer, Armadeus Systems Tel: +33 (0)9 72 29 41 44 Fax: +33 (0)9 72 28 79 26 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] power: extend prefix match to regulator-name property
On 10/18/2017 06:39 PM, Felix Brack wrote:
> This patch extends pmic_bind_children prefix matching. In addition to
> the node name the property regulator-name is used while trying to match
> prefixes. This allows assigning different drivers to regulator nodes
> named regulator@1 and regulator@10 for example.
> I have discarded the idea of using other properties then regulator-name
> as I do not see any benefit in using property compatible or even
> regulator-compatible. Of course I am open to change this if there are
> good reasons to do so.
>
> Signed-off-by: Felix Brack
> ---
>
> Changes in v2:
> - add documentation
> - add a regulator to the sandbox for testing
> - extend the test for the new sandbox regulator
>
> arch/sandbox/dts/sandbox_pmic.dtsi | 6 ++
> doc/device-tree-bindings/regulator/regulator.txt | 16 ++--
> drivers/power/pmic/pmic-uclass.c | 15 +--
> include/power/sandbox_pmic.h | 5 -
> test/dm/regulator.c | 2 ++
> 5 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/arch/sandbox/dts/sandbox_pmic.dtsi
> b/arch/sandbox/dts/sandbox_pmic.dtsi
> index ce261b9..acb4799 100644
> --- a/arch/sandbox/dts/sandbox_pmic.dtsi
> +++ b/arch/sandbox/dts/sandbox_pmic.dtsi
> @@ -75,4 +75,10 @@
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> };
> +
> + no_match_by_nodename {
> + regulator-name = "buck_SUPPLY_1.5V";
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <150>;
> + };
> };
> diff --git a/doc/device-tree-bindings/regulator/regulator.txt
> b/doc/device-tree-bindings/regulator/regulator.txt
> index 918711e..65b69c4 100644
> --- a/doc/device-tree-bindings/regulator/regulator.txt
> +++ b/doc/device-tree-bindings/regulator/regulator.txt
> @@ -2,7 +2,8 @@ Voltage/Current regulator
>
> Binding:
> The regulator devices don't use the "compatible" property. The binding is
> done
> -by the prefix of regulator node's name. Usually the pmic I/O driver will
> provide
> +by the prefix of regulator node's name, or, if this fails, by the prefix of
> the
> +regulator's "regulator-name" property. Usually the pmic I/O driver will
> provide
> the array of 'struct pmic_child_info' with the prefixes and compatible
> drivers.
> The bind is done by calling function: pmic_bind_childs().
> Example drivers:
> @@ -15,8 +16,19 @@ For the node name e.g.: "prefix[:alpha:]num { ... }":
>
> Example the prefix "ldo" will pass for: "ldo1", "ldo@1", "ldoreg@1, ...
>
> +Binding by means of the node's name is preferred. However if the node names
> +would produce ambiguous prefixes (like "regulator@1" and "regualtor@11") and
> you
> +can't or do not want to change them then binding against the "regulator-name"
> +property is possible. The syntax for the prefix of the "regulator-name"
> property
> +is the same as the one for the regulator's node name.
> +Use case: a regulator named "regulator@1" to be bound to a driver named
> +"LDO_DRV" and a regulator named "regualator@11" to be bound to an other
> driver
> +named "BOOST_DRV". Using prefix "regualtor@1" for driver matching would load
> +the same driver for both regulators, hence the prefix is ambiguous.
> +
> Optional properties:
> -- regulator-name: a string, required by the regulator uclass
> +- regulator-name: a string, required by the regulator uclass, used for driver
> + binding if binding by node's name prefix fails
> - regulator-min-microvolt: a minimum allowed Voltage value
> - regulator-max-microvolt: a maximum allowed Voltage value
> - regulator-min-microamp: a minimum allowed Current value
> diff --git a/drivers/power/pmic/pmic-uclass.c
> b/drivers/power/pmic/pmic-uclass.c
> index 64964e4..5a034f0 100644
> --- a/drivers/power/pmic/pmic-uclass.c
> +++ b/drivers/power/pmic/pmic-uclass.c
> @@ -26,6 +26,7 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
> struct driver *drv;
> struct udevice *child;
> const char *node_name;
> + const char *reg_name;
> int bind_count = 0;
> ofnode node;
> int prefix_len;
> @@ -44,8 +45,18 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
> debug(" - compatible prefix: '%s'\n", info->prefix);
>
> prefix_len = strlen(info->prefix);
> - if (strncmp(info->prefix, node_name, prefix_len))
> - continue;
> + if (strncmp(info->prefix, node_name, prefix_len)) {
> + reg_name = ofnode_read_string(node,
> + "regulator-name");
> + if (reg_name) {
> + if (strncmp(info->prefix, reg_name,
> +
Re: [U-Boot] [PATCH 2/5] mmc: arm_pl180_mmci: adapt driver to DM usage
On 10/19/2017 11:45 PM, patrice.chot...@st.com wrote:
> From: Patrice Chotard
>
> Convert this driver to driver model.
> This driver is also used by VEXPRESS platforms which doesn't
> use driver model.
>
> Tested on STM32F746 and STM32F769 platforms.
>
> Signed-off-by: Christophe Priouzeau
> Signed-off-by: Patrice Chotard
> ---
> drivers/mmc/Kconfig | 9
> drivers/mmc/arm_pl180_mmci.c | 125
> ++-
> drivers/mmc/arm_pl180_mmci.h | 3 ++
> 3 files changed, 125 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 94050836..62ce0af 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -33,6 +33,15 @@ config SPL_DM_MMC
>
> if MMC
>
> +config ARM_PL180_MMCI
> + bool "ARM AMBA Multimedia Card Interface and compatible support"
> + depends on DM_MMC && OF_CONTROL
> + help
> + This selects the ARM(R) AMBA(R) PrimeCell Multimedia Card
> + Interface (PL180, PL181 and compatible) support.
> + If you have an ARM(R) platform with a Multimedia Card slot,
> + say Y or M here.
> +
> config SPL_MMC_TINY
> bool "Tiny MMC framework in SPL"
> help
> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
> index 7898b0d..61dbbfb 100644
> --- a/drivers/mmc/arm_pl180_mmci.c
> +++ b/drivers/mmc/arm_pl180_mmci.c
> @@ -12,12 +12,24 @@
>
> /* #define DEBUG */
>
> -#include
> #include "common.h"
> #include
> +#include
> #include
> +
> #include "arm_pl180_mmci.h"
> -#include
> +
> +#include
> +
> +#ifdef CONFIG_DM_MMC
> +#include
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct arm_pl180_mmc_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +#endif
>
> static int wait_for_command_end(struct mmc *dev, struct mmc_cmd *cmd)
> {
> @@ -265,16 +277,6 @@ static int host_request(struct mmc *dev,
> return result;
> }
>
> -/* MMC uses open drain drivers in the enumeration phase */
> -static int mmc_host_reset(struct mmc *dev)
> -{
> - struct pl180_mmc_host *host = dev->priv;
> -
> - writel(host->pwr_init, &host->base->power);
> -
> - return 0;
> -}
> -
> static int host_set_ios(struct mmc *dev)
> {
> struct pl180_mmc_host *host = dev->priv;
> @@ -337,11 +339,23 @@ static int host_set_ios(struct mmc *dev)
> return 0;
> }
>
> +#ifndef CONFIG_DM_MMC
> +/* MMC uses open drain drivers in the enumeration phase */
> +static int mmc_host_reset(struct mmc *dev)
> +{
> + struct pl180_mmc_host *host = dev->priv;
> +
> + writel(host->pwr_init, &host->base->power);
> +
> + return 0;
> +}
> +
> static const struct mmc_ops arm_pl180_mmci_ops = {
> .send_cmd = host_request,
> .set_ios = host_set_ios,
> .init = mmc_host_reset,
> };
> +#endif
>
> /*
> * mmc_host_init - initialize the mmc controller.
> @@ -361,7 +375,9 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host,
> struct mmc **mmc)
> writel(sdi_u32, &host->base->mask0);
>
> host->cfg.name = host->name;
> +#ifndef CONFIG_DM_MMC
> host->cfg.ops = &arm_pl180_mmci_ops;
> +#endif
> /* TODO remove the duplicates */
> host->cfg.host_caps = host->caps;
> host->cfg.voltages = host->voltages;
> @@ -381,3 +397,88 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host,
> struct mmc **mmc)
>
> return 0;
> }
> +
> +#ifdef CONFIG_DM_MMC
> +static int arm_pl180_mmc_probe(struct udevice *dev)
> +{
> + struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct mmc *mmc = &pdata->mmc;
> + struct pl180_mmc_host *host = mmc->priv;
> + int ret;
> +
> + strcpy(host->name, "MMC");
> + host->pwr_init = INIT_PWR;
> + host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V1 | SDI_CLKCR_CLKEN |
> + SDI_CLKCR_HWFC_EN;
> + host->voltages = VOLTAGE_WINDOW_SD;
> + host->caps = 0;
> + host->clock_in = 4800;
Use the defined variable instead of 48000.
> + host->clock_min = 40;
Ditto.
> + host->clock_max = dev_read_u32_default(dev, "max-frequency", 4800);
> + host->version2 = dev_get_driver_data(dev);
> + ret = arm_pl180_mmci_init(host, &mmc);
> + if (ret) {
> + dev_err(dev, "arm_pl180_mmci init failed\n");
> + return ret;
> + }
> +
> + mmc->dev = dev;
> + dev->priv = host;
> + upriv->mmc = mmc;
> +
> + return 0;
> +}
> +
> +static int dm_host_request(struct udevice *dev, struct mmc_cmd *cmd,
> +struct mmc_data *data)
> +{
> + struct mmc *mmc = mmc_get_mmc_dev(dev);
> +
> + return host_request(mmc, cmd, data);
> +}
> +
> +static int dm_host_set_ios(struct udevice *dev)
> +{
> + struct mmc *mmc = mmc_get_mmc_dev(dev);
> +
> + return host_set_ios(mmc);
> +}
> +
> +static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
> + .send_cmd = dm_h
Re: [U-Boot] [PATCH 3/5] mmc: arm_pl180_mmci: add bus_width DT property support
On 10/19/2017 11:46 PM, patrice.chot...@st.com wrote:
> From: Patrice Chotard
>
> Allow to get "bus-width" property from device tree
>
> Signed-off-by: Patrice Chotard
> ---
> drivers/mmc/arm_pl180_mmci.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
> index 61dbbfb..6ee77b1 100644
> --- a/drivers/mmc/arm_pl180_mmci.c
> +++ b/drivers/mmc/arm_pl180_mmci.c
> @@ -405,6 +405,7 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> struct mmc *mmc = &pdata->mmc;
> struct pl180_mmc_host *host = mmc->priv;
> + u32 bus_width;
> int ret;
>
> strcpy(host->name, "MMC");
> @@ -417,6 +418,22 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
> host->clock_min = 40;
> host->clock_max = dev_read_u32_default(dev, "max-frequency", 4800);
> host->version2 = dev_get_driver_data(dev);
> +
> + bus_width = dev_read_u32_default(dev, "bus-width", 1);
> + switch (bus_width) {
> + case 8:
> + host->caps |= MMC_MODE_8BIT;
> + /* Hosts capable of 8-bit transfers can also do 4 bits */
> + case 4:
> + host->caps |= MMC_MODE_4BIT;
> + break;
> + case 1:
> + break;
> + default:
> + dev_err(dev, "Invalid bus-width value %u\n", bus_width);
Doesn't need to return -EINVAL..It can be run with 1bit BUSWIDTH.
I think that it's enough to display the error message.
> + return -EINVAL;
> + }
> +
> ret = arm_pl180_mmci_init(host, &mmc);
> if (ret) {
> dev_err(dev, "arm_pl180_mmci init failed\n");
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] imx: Fix regression with CONFIG_DM_MMC=y
When CONFIG_DM_MMC=y, CONFIG_BLK should be selected, otherwise the SD/eMMC card cannot be used. Also, select CONFIG_DM_USB=y when CONFIG_USB=y to avoid build failure. Tested on mx6slevk, mx7dsabresd and mx6ullevk. Signed-off-by: Fabio Estevam Reviewed-by: Jaehoon Chung Tested-by: Adam Ford Tested-by: Sébastien Szymanski --- Changes since v2: - Fix build failure on opos6uldev (Sébastien) configs/imx6q_logic_defconfig | 1 - configs/imx6qdl_icore_nand_defconfig | 1 - configs/imx6ul_geam_mmc_defconfig | 1 - configs/imx6ul_geam_nand_defconfig| 1 - configs/imx6ul_isiot_emmc_defconfig | 1 - configs/imx6ul_isiot_mmc_defconfig| 1 - configs/imx6ul_isiot_nand_defconfig | 1 - configs/mx6slevk_defconfig| 2 +- configs/mx6slevk_spinor_defconfig | 2 +- configs/mx6sllevk_defconfig | 1 - configs/mx6sllevk_plugin_defconfig| 1 - configs/mx6sxsabreauto_defconfig | 2 +- configs/mx6ull_14x14_evk_defconfig| 1 - configs/mx6ull_14x14_evk_plugin_defconfig | 1 - configs/mx7dsabresd_defconfig | 1 - configs/mx7dsabresd_secure_defconfig | 1 - configs/mx7ulp_evk_defconfig | 1 - configs/mx7ulp_evk_plugin_defconfig | 1 - configs/opos6uldev_defconfig | 1 - include/configs/opos6uldev.h | 1 + 20 files changed, 4 insertions(+), 19 deletions(-) diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig index 8018198..c7d3046 100644 --- a/configs/imx6q_logic_defconfig +++ b/configs/imx6q_logic_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/imx6qdl_icore_nand_defconfig b/configs/imx6qdl_icore_nand_defconfig index c341b17..80a8679 100644 --- a/configs/imx6qdl_icore_nand_defconfig +++ b/configs/imx6qdl_icore_nand_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_UBI=y CONFIG_OF_LIST="imx6q-icore imx6dl-icore" CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/imx6ul_geam_mmc_defconfig b/configs/imx6ul_geam_mmc_defconfig index 7c79873..ce7c288 100644 --- a/configs/imx6ul_geam_mmc_defconfig +++ b/configs/imx6ul_geam_mmc_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y diff --git a/configs/imx6ul_geam_nand_defconfig b/configs/imx6ul_geam_nand_defconfig index d6038c1..8d7eb0d 100644 --- a/configs/imx6ul_geam_nand_defconfig +++ b/configs/imx6ul_geam_nand_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_UBI=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/imx6ul_isiot_emmc_defconfig b/configs/imx6ul_isiot_emmc_defconfig index 67fa9a0..94af53e 100644 --- a/configs/imx6ul_isiot_emmc_defconfig +++ b/configs/imx6ul_isiot_emmc_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y -# CONFIG_BLK is not set CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y CONFIG_FEC_MXC=y diff --git a/configs/imx6ul_isiot_mmc_defconfig b/configs/imx6ul_isiot_mmc_defconfig index c673d93..0a990d7 100644 --- a/configs/imx6ul_isiot_mmc_defconfig +++ b/configs/imx6ul_isiot_mmc_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y diff --git a/configs/imx6ul_isiot_nand_defconfig b/configs/imx6ul_isiot_nand_defconfig index e481151..e806127 100644 --- a/configs/imx6ul_isiot_nand_defconfig +++ b/configs/imx6ul_isiot_nand_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_UBI=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig index 16e2cca..7b1ddac 100644 --- a/configs/mx6slevk_defconfig +++ b/configs/mx6slevk_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_MMC=y CONFIG_DM=y -# CONFIG_BLK is not set CONFIG_DM_GPIO=y CONFIG_DM_I2C=y CONFIG_DM_MMC=y @@ -45,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_THERMAL=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/configs/mx6slevk_spinor_defconfig b/configs/mx6slevk_spinor_defconfig index 020d19f..4b9c04e 100644 --- a/configs/mx6slevk_spinor_defconfig +++ b/configs/mx6slevk_spinor_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_DM=y -# CONFIG_
Re: [U-Boot] [PATCH v3 14/20] arm: socfpga: Improve comments for Intel SoCFPGA program header
On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > Adding some details about size in bytes to each section. > > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/include/mach/boot0.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Dinh Nguyen Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 15/20] arm: socfpga: Enhance Intel SoCFPGA program header to support Arria 10
On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > Enhance preloader header with both additional program length and program > entry offset attributes, which offset is relative to the start of program > header. > > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/include/mach/boot0.h | 7 +++ > 1 file changed, 7 insertions(+) > Reviewed-by: Dinh Nguyen Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/20] arm: socfpga: Adding clock frequency info for U-boot
On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > Clock frequency info is required in U-boot. We know this patch is for U-Boot, don't need to state it in the commit message. Also, it's "U-Boot", not "U-boot". > > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/board.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c > index 965f9dc..9a96f52 100644 > --- a/arch/arm/mach-socfpga/board.c > +++ b/arch/arm/mach-socfpga/board.c > @@ -8,7 +8,10 @@ > > #include > #include > +#include > #include > +#include > +#include Is misc.h needed? > #include > > #include > @@ -26,6 +29,11 @@ int board_init(void) > /* Address of boot parameters for ATAG (if ATAG is used) */ > gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; > > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > + /* configuring the clock based on handoff */ > + cm_basic_init(gd->fdt_blob); > +#endif > + Is is the right place this? The usual call is in the SPL. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 17/20] arm: socfpga: Adding SoCFPGA info for both SPL and U-boot
On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > SoC FPGA info is required in both SPL and U-boot. s/SoC FPGA/SocFPGA to be consistent. s/U-boot/U-Boot > > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/board.c| 3 +++ > arch/arm/mach-socfpga/misc_arria10.c | 5 - > arch/arm/mach-socfpga/spl.c | 6 ++ > 3 files changed, 9 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c > index 9a96f52..7beb347 100644 > --- a/arch/arm/mach-socfpga/board.c > +++ b/arch/arm/mach-socfpga/board.c > @@ -32,6 +32,9 @@ int board_init(void) > #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > /* configuring the clock based on handoff */ > cm_basic_init(gd->fdt_blob); > + > + /* Add device descriptor to FPGA device table */ > + socfpga_fpga_add(); > #endif > > return 0; > diff --git a/arch/arm/mach-socfpga/misc_arria10.c > b/arch/arm/mach-socfpga/misc_arria10.c > index 9d751f6..8760ac9 100644 > --- a/arch/arm/mach-socfpga/misc_arria10.c > +++ b/arch/arm/mach-socfpga/misc_arria10.c > @@ -94,11 +94,6 @@ int arch_early_init_r(void) > /* assert reset to all except L4WD0 and L4TIMER0 */ > socfpga_per_reset_all(); > > - /* configuring the clock based on handoff */ > - /* TODO: Add call to cm_basic_init() */ > - > - /* Add device descriptor to FPGA device table */ > - socfpga_fpga_add(); Why remove it from here? > return 0; > } > #else > diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c > index 71bae82..aba116d 100644 > --- a/arch/arm/mach-socfpga/spl.c > +++ b/arch/arm/mach-socfpga/spl.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -208,6 +209,11 @@ void spl_board_init(void) > > /* enable console uart printing */ > preloader_console_init(); > + > + WATCHDOG_RESET(); > + > + /* Add device descriptor to FPGA device table */ > + socfpga_fpga_add(); And add here? Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 18/20] arm: socfpga: Enable function visible to other file
On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > Enable function visible to other file, so it can be used by other > functions from other file. Huh? What function? What other file? Why? Please bear in mind for future patches, when reading the commit message, you should have a good idea of what the patch is doing without even looking at the patch. Need to include more people listed in get_maintainer.pl Maybe Marek has already commented, but this patch can be separated out from the A10 series. Also, the commit header "arm:socfpga: Enable function visible to other file" is horrible and this patch has nothing to do with socfpga. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/20] arm: socfpga: Enable DDR working
Please update your commit header.
On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> SPL configures DDR by programming peripheral raw binary file
> and calibrating DDR.
>
> Signed-off-by: Tien Fong Chee
> ---
> arch/arm/mach-socfpga/spl.c | 56
> +
> 1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
> index aba116d..6c9bf81 100644
> --- a/arch/arm/mach-socfpga/spl.c
> +++ b/arch/arm/mach-socfpga/spl.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -22,6 +23,10 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> #include
> #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> #include
> @@ -29,6 +34,9 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#define BSIZE4096
> +#define PERIPH_RBF 0
> +
> #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> static struct pl310_regs *const pl310 =
> (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> @@ -197,6 +205,12 @@ void board_init_f(ulong dummy)
> #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> void spl_board_init(void)
> {
> + int rval = 0;
> + int len = 0;
> + u32 buffer[BSIZE] __aligned(ARCH_DMA_MINALIGN);
> + struct spl_boot_device bootdev;
> + fpga_fs_info fpga_fsinfo;
> +
> /* configuring the clock based on handoff */
> cm_basic_init(gd->fdt_blob);
> WATCHDOG_RESET();
> @@ -214,6 +228,48 @@ void spl_board_init(void)
>
> /* Add device descriptor to FPGA device table */
> socfpga_fpga_add();
> +
> + bootdev.boot_device = spl_boot_device();
> +
> + if (BOOT_DEVICE_MMC1 == bootdev.boot_device) {
> + struct mmc *mmc = NULL;
> + int err = 0;
> +
> + spl_mmc_find_device(&mmc, bootdev.boot_device);
> +
> + err = mmc_init(mmc);
> +
> + if (err) {
> +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> + printf("spl: mmc init failed with error: %d\n", err);
You should use puts instead of printf. But this case use error()? Why do
you need to wrap this around CONFIG_SPL_LIBCOMMON_SUPPORT?
> +#endif
> + return;
> + }
> +
> + fpga_fsinfo.interface = "mmc";
> + fpga_fsinfo.fstype = FS_TYPE_FAT;
> + }
> +
> + fpga_fsinfo.dev_part = (char *)get_cff_devpart(gd->fdt_blob,
> + &len);
> +
> + fpga_fsinfo.filename = (char *)get_cff_filename(gd->fdt_blob,
> + &len,
> + PERIPH_RBF);
> +
> + /* Program peripheral RBF */
> + if (fpga_fsinfo.filename)
> + rval = fpga_fsload(0, buffer, BSIZE, &fpga_fsinfo);
> + else {
> + printf("Failed to find peripheral RBF file from DTS\n");
Use error()?
Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 20/20] arm: socfpga: Enable SPL booting U-boot
On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee > > Enable SPL successfully boot to U-boot. s/U-boot/U-Boot > > Signed-off-by: Tien Fong Chee > --- > configs/socfpga_arria10_defconfig | 57 > +-- > 1 file changed, 49 insertions(+), 8 deletions(-) > > diff --git a/configs/socfpga_arria10_defconfig > b/configs/socfpga_arria10_defconfig > index 4c73d73..c59d054 100644 > --- a/configs/socfpga_arria10_defconfig > +++ b/configs/socfpga_arria10_defconfig > @@ -1,34 +1,75 @@ > CONFIG_ARM=y > CONFIG_ARCH_SOCFPGA=y > -CONFIG_SYS_MALLOC_F_LEN=0x2000 Why are you removing this? > CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y > CONFIG_IDENT_STRING="socfpga_arria10" > CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" > -CONFIG_USE_BOOTARGS=y > -CONFIG_BOOTARGS="console=ttyS0,115200" Why remove this? Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Build failure in u-boot-mmc/master: undefined reference to error
With the latest content of u-boot-mmc/master, 41dc35a149b3 "drivers: mmc: Avoid memory leak in case of failure", all Tegra boards (perhaps others too; my system only tests Tegra) fail to build with the following error: drivers/built-in.o: In function `mmc_select_mode_and_width': /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/drivers/mmc/mmc.c:1847: undefined reference to `error' drivers/built-in.o: In function `bus_width': /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/drivers/mmc/mmc.c:1436: undefined reference to `error' /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/drivers/mmc/mmc.c:1436: undefined reference to `error' /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/drivers/mmc/mmc.c:1436: undefined reference to `error' drivers/built-in.o: In function `mmc_get_capabilities': /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/drivers/mmc/mmc.c:831: undefined reference to `error' arm-none-eabi-ld.bfd: BFD (2.24-2ubuntu2+4) 2.24 assertion fail ../../binutils-2.24/bfd/elf32-arm.c:7696 arm-none-eabi-ld.bfd: error: required section '.rel.plt' not found in the linker script arm-none-eabi-ld.bfd: final link failed: Invalid operation ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote: > > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of > > > >> > custom defconfigs for Fedora or RHEL for the kernel? > > > >> > > > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever > > > >> implements UEFI) should not be.. so this argument is a bit of a red > > > >> herring. > > > > > > > > Then that discussion is entirely moot. If the distros don't care about > > > > building the U-Boot binary, why should they care about maintaining the > > > > U-Boot's defconfig like Peter was suggesting? > > > > > > You're taking that and turning it around wrong, we currently have to > > > care about building it. Ultimately what we'd like is to not have to > > > care. One is the current status quo, the other is future desire! > > > > Then we're back to the previous question you didn't answer. If you > > have to build it, why can't you have a custom defconfig, or a > > configuration fragment like Rob suggested, like you do for the kernel? > > Because the goal is that boards ship from the manufacturer with a > firmware that's "good enough". And firmware updates are handled by > Someone Else, rather than the distro. We're talking about a vendor that ships today a U-Boot build that either doesn't have DT support, or doesn't start the kernel in the proper execution level which prevents any mainline kernel from running. Maybe it's just me being too pessimistic about this, but do you really expect to see a time where they would ship a bootloader with EFI? Maxmie -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Fri, Oct 20, 2017 at 06:39:18PM +0200, Maxime Ripard wrote: > On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote: > > > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of > > > > >> > custom defconfigs for Fedora or RHEL for the kernel? > > > > >> > > > > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever > > > > >> implements UEFI) should not be.. so this argument is a bit of a red > > > > >> herring. > > > > > > > > > > Then that discussion is entirely moot. If the distros don't care about > > > > > building the U-Boot binary, why should they care about maintaining the > > > > > U-Boot's defconfig like Peter was suggesting? > > > > > > > > You're taking that and turning it around wrong, we currently have to > > > > care about building it. Ultimately what we'd like is to not have to > > > > care. One is the current status quo, the other is future desire! > > > > > > Then we're back to the previous question you didn't answer. If you > > > have to build it, why can't you have a custom defconfig, or a > > > configuration fragment like Rob suggested, like you do for the kernel? > > > > Because the goal is that boards ship from the manufacturer with a > > firmware that's "good enough". And firmware updates are handled by > > Someone Else, rather than the distro. > > We're talking about a vendor that ships today a U-Boot build that > either doesn't have DT support, or doesn't start the kernel in the > proper execution level which prevents any mainline kernel from > running. > > Maybe it's just me being too pessimistic about this, but do you really > expect to see a time where they would ship a bootloader with EFI? There's actually a relative lot of vendor stuff that's based on "only" 2 or so year old U-Boot, and starts to get things right. So yes, once you start to factor in the design->production lag, we will start to see more and more devices that come out with these features enabled and either in-use (because it's relevant to the product) or community-used (because the product can be end-user-used and it's not something that was turned off). And we're starting to see more and wider silicon vendor support coming in and in my experience there's often a lot of "if the vendor defaults work, just add what we need on top" in custom designs. For the kernel and U-Boot both. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51
Hi Benoît, On Fri, Oct 20, 2017 at 10:40 AM, Benoît Thébaudeau wrote: > With mainline U-Boot on my board, normal-speed SD cards work fine, but not HS > ones. Both types of cards work fine at 48 MHz with my custom and older U-Boot. Ok, great! What is the version of your old U-Boot? > > The main difference seems to be the management of SD timeouts. I will try to > track the differences until I find the root cause. The test results in PIO > mode > might also give some clues. Thanks for the investigation! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Fri, Oct 20, 2017 at 5:39 PM, Maxime Ripard wrote: > On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote: >> > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of >> > > >> > custom defconfigs for Fedora or RHEL for the kernel? >> > > >> >> > > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever >> > > >> implements UEFI) should not be.. so this argument is a bit of a red >> > > >> herring. >> > > > >> > > > Then that discussion is entirely moot. If the distros don't care about >> > > > building the U-Boot binary, why should they care about maintaining the >> > > > U-Boot's defconfig like Peter was suggesting? >> > > >> > > You're taking that and turning it around wrong, we currently have to >> > > care about building it. Ultimately what we'd like is to not have to >> > > care. One is the current status quo, the other is future desire! >> > >> > Then we're back to the previous question you didn't answer. If you >> > have to build it, why can't you have a custom defconfig, or a >> > configuration fragment like Rob suggested, like you do for the kernel? >> >> Because the goal is that boards ship from the manufacturer with a >> firmware that's "good enough". And firmware updates are handled by >> Someone Else, rather than the distro. > > We're talking about a vendor that ships today a U-Boot build that > either doesn't have DT support, or doesn't start the kernel in the > proper execution level which prevents any mainline kernel from > running. > > Maybe it's just me being too pessimistic about this, but do you really > expect to see a time where they would ship a bootloader with EFI? Yes, my $dayjob is IoT focused and I'm speaking with vendors about it now, demoing it to them. Also ARM and others are engaged in a EBBR (Embedded Base Boot Requirements) similar to the Server Base Boot Requirements (SBBR) spec so I suspect once that becomes standard which includes a lot of thing you'll find it'll be actively requested by vendors. Plus most of what Tom mentions in his response. When Fedora did the first version of distro boot it took us time to get traction, then nvidia picked it up because they saw the value, now just look at the vendor patches adding that. uEFI is the extension to this, v2 if you like. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5] Convert CONFIG_NAND_OMAP_GPMC et al to Kconfig
On Mon, Oct 16, 2017 at 02:08:26PM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_NAND_OMAP_GPMC >CONFIG_NAND_OMAP_GPMC_PREFETCH >CONFIG_NAND_OMAP_ELM >CONFIG_SPL_NAND_AM33XX_BCH >CONFIG_SPL_NAND_SIMPLE (ARCH_OMAP2PLUS only) > > Signed-off-by: Adam Ford > Reviewed-by: Heiko Schocher With some additions to complete the migration, and then CONFIG_NAND_MXC also, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] omap2: nand: Make NAND_OMAP_GPMC_PREFETCH default
This option provides better performance and should really always be enabled. Make this be default y. Signed-off-by: Tom Rini --- drivers/mtd/nand/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 794410a152fe..ca9819344ecc 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -55,6 +55,7 @@ config NAND_OMAP_GPMC config NAND_OMAP_GPMC_PREFETCH bool "Enable GPMC Prefetch" depends on NAND_OMAP_GPMC + default y help On OMAP platforms that use the GPMC controller (CONFIG_NAND_OMAP_GPMC_PREFETCH), this options enables the code that -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
El jue, 19-10-2017 a las 15:24 +0200, Maxime Ripard escribió: > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > > Hi, > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > Hi, > > > > > > Most featureful boards, such as the Cubietruck, have been broken > > > since > > > the release 2017.09. > > > > > > This is due to a size increase of the binary that will trip us > > > across > > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > > > We would have two ways to work around it. The first one would be > > > to > > > just increase the offset of the environment. However, since it > > > would > > > break all the environments of our users and possibly the custom > > > partition scheme that they would have created, it doesn't really > > > seem > > > like a smart move. > > > > Is that really such a problem? How many people rely on having their > > custom environment preserved over an update? (That's an honest > > question) > > All of them, I guess. In your U-boot upgrade script, do you do a 'env > default -a; saveenv' all the time ? > > I know I don't. I personally do not do anything to the environment ever if I can help it. I rely on u-boot having the smarts to just do the right thing and boot my system for me. if the environment moves, as I use the defaults it will just continue to work. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > > Hi, > > > > On 19/10/17 14:24, Maxime Ripard wrote: > > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > > > > Hi, > > > > > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > > > Hi, > > > > > > > > > > Most featureful boards, such as the Cubietruck, have been > > > > > broken since > > > > > the release 2017.09. > > > > > > > > > > This is due to a size increase of the binary that will trip > > > > > us across > > > > > the size we've been using in the u-boot-sunxi-with-spl.bin > > > > > file. > > > > > > > > > > We would have two ways to work around it. The first one would > > > > > be to > > > > > just increase the offset of the environment. However, since > > > > > it would > > > > > break all the environments of our users and possibly the > > > > > custom > > > > > partition scheme that they would have created, it doesn't > > > > > really seem > > > > > like a smart move. > > > > > > > > Is that really such a problem? How many people rely on having > > > > their > > > > custom environment preserved over an update? (That's an honest > > > > question) > > > > > > All of them, I guess. In your U-boot upgrade script, do you do a > > > 'env > > > default -a; saveenv' all the time ? > > > > > > I know I don't. > > > > Well, I never use the saved environment and always expected some > > user or > > board specific environment to come from some file (boot.scr or > > something > > loaded via TFTP). But that's just my personal use, hence I was > > asking. > > Well, even if you want to boot to tftp, you'll need to have some > setup > to do, even just to use a different server IP, and that will be in > the > environment. I personally just use pxe boot dhcp pxe get pxe boot and pick the right option. nothing needed on the client side. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Convert CONFIG_SMC911X et al to Kconfig
On Mon, Oct 16, 2017 at 03:50:47PM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_SMC911X >CONFIG_SMC911X_BASE >CONFIG_SMC911X_32_BIT > > There are a variety of boards that need some cleanup in their > respective include/configs file, but here is a foundation > for them to begin their transisiton. > > Signed-off-by: Adam Ford > V2: Merge into 1 patch and rebase Note that this was missing the drivers/net/Kconfig part, so I grabbed that again and really merged it in. I've also migrated all users and that meant migrating CONFIG_SMC911X_16_BIT, and it's now applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
