Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property
On 23.10.2017 22:34, Chen-Yu Tsai wrote:
> On Tue, Oct 24, 2017 at 12:36 AM, Felix Brack wrote:
>> On 23.10.2017 16:36, Chen-Yu Tsai wrote:
>>> Hi,
>>>
>>> On Thu, Oct 12, 2017 at 11:40 PM, Felix Brack wrote:
On 12.10.2017 14:53, Chen-Yu Tsai wrote:
> On Thu, Oct 12, 2017 at 8:24 PM, Felix Brack wrote:
>> On 12.10.2017 04:46, Chen-Yu Tsai wrote:
>>> On Mon, Oct 9, 2017 at 6:04 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.
>>>
>>> No. See the regulator bindings:
>>>
>>> Optional properties:
>>> - regulator-name: A string used as a descriptive name for regulator
>>> outputs
>>>
>> The actual regulator.txt states:
>>
>> Optional properties:
>> - regulator-name: a string, required by the regulator uclass
>>
>> This was the reason for choosing the regulator-name property.
>
> Mine was from the Linux Kernel. Are there two sets of bindings?
> Shouldn't there be just one?
>
Mine was from U-Boot as this is the U-Boot mailing list and things do
not seem to be fully synchronized between LINUX and U-Boot.
>>>
>>> That seems to be the underlying problem. They really should be the same.
>>> I'm not sure which platforms really follow through with this though.
>>>
>>> This can vary from board to board. The name should match the power rail
>>> name of the board (which may not be the same as the regulator chip's
>>> output name).
>>>
>> Exactly. I totally agree but as stated in an earlier post: I did not
>> define the names for the regulators and modifying them is almost
>> certainly not the right way to go. Let me explain this briefly. The
>> regulator names I'm trying to match are those from tps65910.dtsi, an
>> include file. The exact same file is part of the LINUX kernel. Therefore
>> I resigned suggesting the modification of the node names.
>
> First, it is an include file. Board files are free to override the
> name. We did that for sunxi at first, have the .dtsi file provide
> some default names, then have board .dts files override them with
> names that make more sense. Later on we just dropped the default
> names altogether.
>
I am definitely confused now, maybe we are using same terms for
different things. When I'm talking about a 'name' I mean the 'node name'
according to DT specification (as for instance returned by
ofnode_get_name). I'm not talking about a property or a node label. The
following code defines a node name 'regulator@2' ore more precisely a
node named 'regulator' having unit-address 2:
vdd1_reg: regulator@2 {
reg = <2>;
regulator-compatible = "vdd1";
};
This is found in tps65910.dtsi include file. You say "board files are
free to override the name". Hence I could include the tps65910.dtsi into
my board dts file and kind of rename node 'regulator@2' by let's say
'buck_vdd1@2'?
The only way of "overriding" I can think of is by not including the dtsi
file and redefining all nodes.
>>>
>>> I'm talking about the "name" as defined in the "regulator-name"
>>> property, which is what you want to match against in your patch.
>>>
>>> So boards are definitely free to override the property by setting
>>> a new value for it. And indeed boards do that.
>>>
>> This is the driving idea behind my patch.
>>
> The same pattern is also seen in tps65910.dtsi and am3517-craneboard.dts.
> And also am335x-evm.dts, which the tps65910.dtsi was tested with.
>
Looking at the am3517-craneboard.dts file I don't see how node names are
getting overwritten. What gets set, changed or overwritten is the node
property regulator-name.
>>>
>>> Yes. That's what I'm referring to. Doesn't this work against your
>>> attempt to bind pmic-uclass against regulator-name properties?
>>>
>> Well, yes, my patch works like charm. I didn't mention that it doesn't
>> work ;-).
>>
> Now I couldn't find the binding document for tps65910, but looking
> at tps65217 instead, it says:
>
> - regulators: list of regulators provided by this controller, must be
> named
> after their hardware counterparts: dcdc[1-3] and ldo[1-4]
>
> And indeed that is what's used in the example.
>
Yes, exactly and correct. Again, this tps65217.txt does only exist in
LINUX and not in U-Boot.
>>>
>>> Device tree bindings are a set of rules, contracts, ABIs, whatever
>>> you call it, between the hardware description that is the device
>>> tree, and software that implement support for the hardware. Having
>>> two or more diverging sets is not an improvement. Comm
Re: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree
On 10/23/2017 01:43 PM, Eugeniy Paltsev wrote: > On Thu, 2017-10-19 at 13:20 -0500, Dinh Nguyen wrote: >> >> On 10/19/2017 10:51 AM, Marek Vasut wrote: >>> On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote: On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote: > On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin > wrote: >> Hi Jagan, >> >>> -Original Message- >>> From: Eugeniy Paltsev [mailto:palt...@synopsys.com] >>> Sent: Tuesday, October 17, 2017 4:33 PM >>> To: jagannadh.t...@gmail.com >>> Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com >>> Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value from >>> Device Tree How hard it is to make others to use clock manager? do you have any list? >>> >>> clock_manager.h is an old (and non-generic) way to deal with different >>> clocks. >>> For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h provides >>> cm_get_spi_controller_clk_hz function to deal with spi controller clock. >>> >>> But today we have another, linux-like alternative: to bind clocks via >>> device tree >>> and manipulate with clocks via generic functions provided by clk.h >>> >>> In this patch I added option to get clock via device tree using >>> standard bindings >>> and restrict clock_manager.h functions usage only to targets which >>> still use it, >>> so new targets can simply bind clock via device tree and they do not >>> need to >>> implement/define something in clock_manager.h >>> >>> So we don't need to make others to use clock manager :) >> >> Maybe it worth trying the other way around and think about switching >> SOCFPGA platforms to >> generic clk framework? > > Yes, ie what exactly I thought of, thanks! I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as it manipulate with real hardware. The only way to do it is to replace SOCFPGA* clock manager functions by real clock driver. And given I don't have mentioned hardware so I barely can help with those improvements on SOCFPGA. That said if there're no short-term plans to switch SOCFPGA to clk framework maybe we'll be OK with my workaround with #ifdefs? >>> >>> Wait for Dinh's reply ... >>> >> >> Honestly, I don't have too much time to work on this right now. So I >> really don't when it can get done. But it'll go on my to-do list. >> >> Dinh > > Yep, thanks for your comments. > > So, Jagan, > given Dinh's reply, could you please apply this patch? I'd really hate it to start seeing soc-specific ifdefs in drivers, that's IMO not acceptable. A __weak override might be a temporary solution I'd be willing to live with though. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] thermal: ti-bandgap: Add support for temperature sensor
On Monday 23 October 2017 04:54 PM, Tom Rini wrote: > On Mon, Oct 23, 2017 at 10:50:15AM +0530, Faiz Abbas wrote: >> Hi Tom, >> >> On Monday 23 October 2017 08:30 AM, Tom Rini wrote: >>> On Mon, Oct 23, 2017 at 08:07:09AM +0530, Lokesh Vutla wrote: On Wednesday 18 October 2017 05:11 PM, Faiz Abbas wrote: > The dra7xx series of SOCs contain a temperature sensor and an > associated analog-to-digital converter (ADC) which produces > an output which is proportional to the SOC temperature. > Add support for this temperature sensor. > > Signed-off-by: Faiz Abbas > Reviewed-by: Simon Glass > --- > v3: > Added Reviewed-by comment > > v2: > 1. Removed extra elements from ti_bandgap > 2. Changed base address to ulong > 3. Changed to udev to dev to maintain consistency > 4. minor format changes > > common/spl/Kconfig | 8 + > configs/dra7xx_evm_defconfig | 3 + > .../thermal/ti_soc_thermal.txt | 35 > drivers/Makefile | 2 +- > drivers/thermal/Kconfig| 6 + > drivers/thermal/Makefile | 1 + > drivers/thermal/ti-bandgap.c | 197 > + > 7 files changed, 251 insertions(+), 1 deletion(-) > create mode 100644 doc/device-tree-bindings/thermal/ti_soc_thermal.txt > create mode 100644 drivers/thermal/ti-bandgap.c > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 0bd8370..0bf3ee3 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -604,6 +604,14 @@ config SPL_SPI_SUPPORT > enable SPI drivers that are needed for other purposes also, such > as a SPI PMIC. > > +config SPL_THERMAL > + bool "Driver support for thermal devices" > + help > + Enable support for temperature-sensing devices. Some SoCs have on-chip > + temperature sensors to permit warnings, speed throttling or even > + automatic power-off when the temperature gets too high or low. Other > + devices may be discrete but connected on a suitable bus. > + > config SPL_USB_HOST_SUPPORT > bool "Support USB host drivers" > help > diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig > index 468c288..447fb89 100644 > --- a/configs/dra7xx_evm_defconfig > +++ b/configs/dra7xx_evm_defconfig > @@ -90,3 +90,6 @@ CONFIG_USB_GADGET=y > CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > CONFIG_USB_GADGET_PRODUCT_NUM=0xd022 > +CONFIG_SPL_THERMAL=y > +CONFIG_DM_THERMAL=y > +CONFIG_TI_DRA7_THERMAL=y Tom, Do you want these options to be implied so that it will take effect for HS board as well. Or enable it in defconfig as is? >>> >>> How important is it that this be enabled? Is this 100% within the SoC? >>> Thanks! >>> >> >> There is an upcoming errata which requires temperature support to >> workaround. This errata will apply to the HS boards as well. Will send a >> new patch with imply added to TARGET_DRA7XX_EVM for these configs. > > Well, can you _not_ have this support enabled, on the dra7xx family? If > it must be always there, please select it. Otherwise imply is OK. > Thanks! > Its not enabled in the latest v4. Have added imply in TARGET_DRA7XX_EVM and TARGET_AM57XX_EVM instead. Thanks, Faiz ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/20] arm: socfpga: Add drivers for programing FPGA from flash
On Isn, 2017-10-16 at 10:33 -0500, Dinh Nguyen wrote: > > On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > These drivers handle FPGA program operation from flash loading > > RBF to memory and then to program FPGA. > > > > Signed-off-by: Tien Fong Chee > > --- > > .../include/mach/fpga_manager_arria10.h| 28 ++ > > drivers/fpga/socfpga_arria10.c | 435 > > - > > include/altera.h | 6 + > > 3 files changed, 467 insertions(+), 2 deletions(-) > Yikes, 467 changes in 1 patch and 2 line commit message? Anyway you > can > split up the patch to smaller parts? And please update the commit > message to be a bit more descriptive? > I can improve the commit messages. This patch serves for one purpose, adding all necessary functions required by fpga loadfs, so that fpga lodfs can support implementation as described above. > Thanks, > 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 Jum, 2017-10-20 at 10:21 -0500, Dinh Nguyen wrote: > > 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? > We using distro boot. Those configs would be defined at extlinux.conf. > 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
On Jum, 2017-10-20 at 10:11 -0500, Dinh Nguyen wrote:
> 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 BSIZE 4096
> > +#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?
>
I copied this block of code from /common/spl_mmc.c, so i keep
everything intact. But, i tried to track back the reason of wrapping
around with CONFIG_SPL_LIBCOMMON_SUPPORT, this is what i found "If we
don't have CONFIG_SPL_LIBCOMMON_SUPPORT defined then stdio
functions are unavailable & calling them will cause a link failure."
https://lists.denx.de/pipermail/u-boot/2013-September/161969.html
> >
> > +#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_RB
> > F);
> > +
> > + /* 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()?
>
Okay.
> 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 Isn, 2017-10-23 at 09:24 -0500, Dinh Nguyen wrote: > > On 10/23/2017 03:19 AM, Chee, Tien Fong wrote: > > > > On Jum, 2017-10-20 at 09:39 -0500, Dinh Nguyen wrote: > > > > > > > > > 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. > > > > > This patch is required by later patches, so this patch can't be > > separated out. This function is static declaration, but this > > function > > is required by the caller from other file(later patches). So, this > > patch is to remove ths static declaration so it is accessible by > > the > > caller from other file. > yes, I know what it means to remove the static declaration. Ok, I > understand the need for this patch in this series. Please fix up the > commit header and message. > Okay. > Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8: sec_firmware: Add support for loadables in FIT
> -Original Message-
> From: York Sun
> Sent: Tuesday, October 24, 2017 2:51 AM
> To: Sumit Garg ; u-boot@lists.denx.de
> Cc: Ruchika Gupta ; Prabhakar Kushwaha
> ; Z.q. Hou ; Pankaj
> Gupta ; Arun Pathak ; Sahil
> Malhotra
> Subject: Re: [PATCH 2/2] armv8: sec_firmware: Add support for loadables in FIT
>
> On 09/01/2017 01:25 AM, Sumit Garg wrote:
> > Enable support for loadables in SEC firmware FIT image. Currently
> > support is added for single loadable image.
> >
> > Brief description of implementation:
> > - Add two more address pointers (loadable_h, loadable_l) as arguments to
> > sec_firmware_init() api.
> > - Create new api: sec_firmware_checks_copy_loadable() to check if
> loadables
> > node is present in SEC firmware FIT image. If present, verify loadable
> > image and copies it to secure DDR memory.
> > - Populate address pointers with secure DDR memory addresses where
> loadable
> > is copied.
> >
> > Example use-case could be trusted OS (tee.bin) as loadables node in
> > SEC firmware FIT image.
> >
> > Signed-off-by: Sumit Garg
> > ---
> > arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 16 +-
> > arch/arm/cpu/armv8/sec_firmware.c | 92
> +--
> > arch/arm/include/asm/armv8/sec_firmware.h | 4 +-
> > 3 files changed, 104 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > index 35c612d..87a0885 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > @@ -35,6 +35,7 @@ int ppa_init(void)
> > unsigned int el = current_el();
> > void *ppa_fit_addr;
> > u32 *boot_loc_ptr_l, *boot_loc_ptr_h;
> > + u32 *loadable_l, *loadable_h;
> > int ret;
> >
> > #ifdef CONFIG_CHAIN_OF_TRUST
> > @@ -252,9 +253,9 @@ int ppa_init(void)
> >PPA_KEY_HASH,
> >&ppa_img_addr);
> > if (ret != 0)
> > - printf("PPA validation failed\n");
> > + printf("SEC firmware(s) validation failed\n");
> > else
> > - printf("PPA validation Successful\n");
> > + printf("SEC firmware(s) validation Successful\n");
> > }
> > #if defined(CONFIG_SYS_LS_PPA_FW_IN_MMC) || \
> > defined(CONFIG_SYS_LS_PPA_FW_IN_NAND)
> > @@ -266,15 +267,24 @@ int ppa_init(void)
> > struct ccsr_gur __iomem *gur = (void
> *)(CONFIG_SYS_FSL_GUTS_ADDR);
> > boot_loc_ptr_l = &gur->bootlocptrl;
> > boot_loc_ptr_h = &gur->bootlocptrh;
> > +
> > + /* Assign addresses to loadable ptrs */
> > + loadable_l = &gur->scratchrw[4];
> > + loadable_h = &gur->scratchrw[5];
> > #elif defined(CONFIG_FSL_LSCH2)
> > struct ccsr_scfg __iomem *scfg = (void
> *)(CONFIG_SYS_FSL_SCFG_ADDR);
> > boot_loc_ptr_l = &scfg->scratchrw[1];
> > boot_loc_ptr_h = &scfg->scratchrw[0];
> > +
> > + /* Assign addresses to loadable ptrs */
> > + loadable_l = &scfg->scratchrw[2];
> > + loadable_h = &scfg->scratchrw[3];
> > #endif
> >
> > debug("fsl-ppa: boot_loc_ptr_l = 0x%p, boot_loc_ptr_h =0x%p\n",
> > boot_loc_ptr_l, boot_loc_ptr_h);
> > - ret = sec_firmware_init(ppa_fit_addr, boot_loc_ptr_l,
> boot_loc_ptr_h);
> > + ret = sec_firmware_init(ppa_fit_addr, boot_loc_ptr_l, boot_loc_ptr_h,
> > + loadable_l, loadable_h);
> >
> > #if defined(CONFIG_SYS_LS_PPA_FW_IN_MMC) || \
> > defined(CONFIG_SYS_LS_PPA_FW_IN_NAND)
> > diff --git a/arch/arm/cpu/armv8/sec_firmware.c
> > b/arch/arm/cpu/armv8/sec_firmware.c
> > index 0e74834..927eae4 100644
> > --- a/arch/arm/cpu/armv8/sec_firmware.c
> > +++ b/arch/arm/cpu/armv8/sec_firmware.c
> > @@ -105,6 +105,74 @@ static int sec_firmware_parse_image(const void
> *sec_firmware_img,
> > return 0;
> > }
> >
> > +/*
> > + * SEC Firmware FIT image parser to check if any loadable is
> > + * present. If present, verify integrity of the loadable and
> > + * copy loadable to address provided in (loadable_h, loadable_l).
> > + *
> > + * Returns 0 on success and a negative errno on error task fail.
> > + */
> > +static int sec_firmware_check_copy_loadable(const void
> *sec_firmware_img,
> > + u32 *loadable_l, u32 *loadable_h) {
> > + phys_addr_t sec_firmware_loadable_addr = 0;
> > + int conf_node_off, ld_node_off;
> > + char *conf_node_name = NULL;
> > + const void *data;
> > + size_t size;
> > + ulong load;
> > +
> > + conf_node_name = SEC_FIRMEWARE_FIT_CNF_NAME;
> > +
> > + conf_node_off = fit_conf_get_node(sec_firmware_img,
> conf_node_name);
> > + if (conf_node_off < 0) {
> > + printf("SEC Firmware: %s: no such config\n",
> conf_node_name);
> > + return -ENOENT;
> > + }
> > +
> > + ld_node_off = fit_conf_get_prop_node(sec_firmware_img,
> conf_node_off,
> > +FIT_LOADABLE_PROP);
> > +
Re: [U-Boot] [PATCH 1/2] armv8: layerscape: Allocate 66 MB DDR for secure memory
> -Original Message- > From: York Sun > Sent: Tuesday, October 24, 2017 2:36 AM > To: Sumit Garg ; u-boot@lists.denx.de > Cc: Ruchika Gupta ; Prabhakar Kushwaha > ; Z.q. Hou ; Pankaj > Gupta ; Arun Pathak ; Sahil > Malhotra > Subject: Re: [PATCH 1/2] armv8: layerscape: Allocate 66 MB DDR for secure > memory > > On 09/01/2017 01:24 AM, Sumit Garg wrote: > > Change DDR allocated for secure memory from 2 MB to 66 MB. This > > additional > > 64 MB secure memory is required for trusted OS running in Trusted > > Execution Environment using ARMv8 TrustZone. > > > > Signed-off-by: Sumit Garg > > --- > > arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h > > b/arch/arm/include/asm/arch-fsl-layerscape/config.h > > index a7098be..95e2791 100644 > > --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h > > +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h > > @@ -16,7 +16,7 @@ > > * Reserve secure memory > > * To be aligned with MMU block size > > */ > > -#define CONFIG_SYS_MEM_RESERVE_SECURE (2048 * 1024) /* 2MB > */ > > +#define CONFIG_SYS_MEM_RESERVE_SECURE (66 * 1024 * 1024) > /* 66MB */ > > #define SPL_TLB_SETBACK0x100 /* 16MB under effective > memory top */ > > > > #ifdef CONFIG_ARCH_LS2080A > > > > Sumit, > > I believe this patch is no longer needed after the merge of > > commit 710d0cd79ede129d5203325c2a188c6f93c61ca3 > Author: Sumit Garg > Date: Wed Oct 4 03:20:49 2017 +0530 > > armv8: fsl-layerscape: Allocate Secure memory from first ddr region > > York No, this patch is needed. The patch you mentioned is just to allocate Secure memory from first ddr region. But this patch is meant to increase Secure memory allocated from 2MB -> 66MB. Sumit ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ZynqMP qspi
Hi Siva, On 23/10/17 01:59 AM, Siva Durga Prasad Paladugu wrote: > Hi Liam, > >> -Original Message- >> From: Liam Beguin [mailto:liambeg...@gmail.com] >> Sent: Saturday, October 21, 2017 11:33 PM >> To: Siva Durga Prasad Paladugu ; Jagan Teki >> >> Cc: u-boot@lists.denx.de; Michal Simek >> Subject: Re: [U-Boot] ZynqMP qspi >> >> Hi Siva, >> >> On 26/09/17 01:28 AM, Siva Durga Prasad Paladugu wrote: >>> Hi, >>> >> ... >>> >>> I am planning to send the new series in 1-2 weeks, probably you can >>> wait till then or you can try with the patch[2] and see if you are >>> able to get it working with those( those are known to be working when >>> I sent ). Also, please note that as of now iam targeting only for qspi >>> single >> mode not the dual modes. >> >> I was wondering if you had a chance to work on this in the last few weeks. I >> initially planned on re-sending your series but I don't currently have the >> hardware to test on. > Sorry for the delay, I am already working on it, need to cleanup and test it. > I will send the > series in a day. > Great, I'll try to test it if I get the hardware in time. Thanks, Liam > Regards, > Siva ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: replace the printf() instead of error()
Hi Jaehoon
2017-10-23 13:49 GMT+09:00 Jaehoon Chung :
> On 10/23/2017 01:46 PM, Jaehoon Chung wrote:
>> Replace the printf() instead of error().
>> It is occurred the compiler error with "undefined reference to 'error'".
>>
>> Fixes: e0079fecd75b ("mmc: refacstor SD startup to make it easier to support
>> new modes")
>>
>> Signed-off-by: Jaehoon Chung
>
> Applied to u-boot-mmc.
>
> Best Regards,
> Jaehoon Chung
>
>> ---
>> drivers/mmc/mmc.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 55a53c2200..a5a521eec3 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -828,7 +828,7 @@ static int mmc_get_capabilities(struct mmc *mmc)
>> return 0;
>>
>> if (!ext_csd) {
>> - error("No ext_csd found!\n"); /* this should enver happen */
>> + printf("No ext_csd found!\n"); /* this should enver happen */
>> return -ENOTSUPP;
>> }
>>
>> @@ -1433,7 +1433,7 @@ static inline int bus_width(uint cap)
>> return 4;
>> if (cap == MMC_MODE_1BIT)
>> return 1;
>> - error("invalid bus witdh capability 0x%x\n", cap);
>> + printf("invalid bus witdh capability 0x%x\n", cap);
>> return 0;
>> }
>>
>> @@ -1638,7 +1638,7 @@ error:
>> }
>> }
>>
>> - error("unable to select a mode\n");
>> + printf("unable to select a mode\n");
>> return -ENOTSUPP;
>> }
>>
>> @@ -1844,7 +1844,7 @@ error:
>> }
>> }
>>
>> - error("unable to select a mode\n");
>> + printf("unable to select a mode\n");
>>
>> return -ENOTSUPP;
>> }
>>
>
No. Please use pr_err().
Why don't you squash this to e0079fecd75b?
This loses bisect'ability.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: SPL: FIT: fix DTC warnings on FIT generation
Hi Andre, 2017-10-24 11:03 GMT+09:00 Lokesh Vutla : > > > On Tuesday 24 October 2017 02:04 AM, Tom Rini wrote: >> On Mon, Oct 23, 2017 at 11:08:57AM +0530, Lokesh Vutla wrote: >>> >>> >>> On Tuesday 17 October 2017 02:43 AM, Tom Rini wrote: On Tue, Oct 17, 2017 at 02:29:14AM +0530, Jagan Teki wrote: > On Mon, Oct 9, 2017 at 10:15 AM, Simon Glass wrote: >> Hi Andre, >> >> On 4 October 2017 at 17:24, Andre Przywara >> wrote: >>> Newer versions of the device tree compiler (rightfully) complain about >>> mismatches between attributed node names (name@) and a missing >>> reg property in that node. >>> Adjust the FIT build script for 64-bit Allwinner boards to remove the >>> bogus addresses from the node names and avoid the warnings. >>> >>> Signed-off-by: Andre Przywara >>> --- >>> board/sunxi/mksunxi_fit_atf.sh | 16 >>> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> It looks like we have this problem all over the place. The >> documentation in doc/uImage now seems to have this problem too. >> >> I wonder if instead we should add reg / #address-cells / #size-cells >> properties? > > If the update on dts, might be an another-overhead to maintain u-boot > dts wrt Linux dts sync. Anything that DTC is warning about in a dts that we get from the kernel, should be fixed in the kernel. The kernel dtc is what we're using, and is/will/can also complain about it. >>> >>> Kernel suppress these warning by default[1] and enables these warnings >>> with W= compiler option. May be this should be included in u-boot as well? >>> >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.lib#n272 >> >> We have slightly different logic for that today in >> scripts/Makefile.extrawarn, perhaps we need to re-sync? >> > > ahh you are right. I do not see these warning with the latest U-Boot. > But I still agree with the $patch as these warnings are meant to be > fixed at some point. Please use "-" instead of "@". Update all the FIT examples. You may need to update some C files. This is the conclusion of Device Tree community. See the following commit of Linux. commit b21569cf1de925e0a42c9964bd7f520cb4a4d875 Author: Viresh Kumar Date: Thu Jun 22 09:15:11 2017 +0530 PM / OPP: Use - instead of @ for DT entries Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by: Masahiro Yamada Suggested-by: Mark Rutland Signed-off-by: Viresh Kumar Acked-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Rafael J. Wysocki -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: SPL: FIT: fix DTC warnings on FIT generation
On Tuesday 24 October 2017 02:04 AM, Tom Rini wrote: > On Mon, Oct 23, 2017 at 11:08:57AM +0530, Lokesh Vutla wrote: >> >> >> On Tuesday 17 October 2017 02:43 AM, Tom Rini wrote: >>> On Tue, Oct 17, 2017 at 02:29:14AM +0530, Jagan Teki wrote: On Mon, Oct 9, 2017 at 10:15 AM, Simon Glass wrote: > Hi Andre, > > On 4 October 2017 at 17:24, Andre Przywara wrote: >> Newer versions of the device tree compiler (rightfully) complain about >> mismatches between attributed node names (name@) and a missing >> reg property in that node. >> Adjust the FIT build script for 64-bit Allwinner boards to remove the >> bogus addresses from the node names and avoid the warnings. >> >> Signed-off-by: Andre Przywara >> --- >> board/sunxi/mksunxi_fit_atf.sh | 16 >> 1 file changed, 8 insertions(+), 8 deletions(-) > > It looks like we have this problem all over the place. The > documentation in doc/uImage now seems to have this problem too. > > I wonder if instead we should add reg / #address-cells / #size-cells > properties? If the update on dts, might be an another-overhead to maintain u-boot dts wrt Linux dts sync. >>> >>> Anything that DTC is warning about in a dts that we get from the kernel, >>> should be fixed in the kernel. The kernel dtc is what we're using, and >>> is/will/can also complain about it. >> >> Kernel suppress these warning by default[1] and enables these warnings >> with W= compiler option. May be this should be included in u-boot as well? >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.lib#n272 > > We have slightly different logic for that today in > scripts/Makefile.extrawarn, perhaps we need to re-sync? > ahh you are right. I do not see these warning with the latest U-Boot. But I still agree with the $patch as these warnings are meant to be fixed at some point. Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v7] cmd: usb: ignore blk, emulation devices in usb tree/info display
Usb tree/info commands iterate over all usb uclass devices recursively.
Blk uclass devices based on struct blk_desc are created for mass storage
device, treating them as usb uclass devices based on struct usb_device
and referencing usb config interface descriptors cause crash.
To fix, ignore blk and usb_emul uclass devices in usb_show_info
and usb_tree_graph. Also avoid addition of preamble for blk uclass
child devices, otherwise tree dump gets messed up.
Signed-off-by: Suneel Garapati
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes v7:
- modify commit description based on review comments
Changes v6:
- re-write commit message with detail
Changes v5:
- add usb_emul to ignore list in usb_show_info
- modify description
Changes v4:
- do not set preamble if child is block device for mass storage
Changes v3:
- remove 'check on parent uclass' in description
Changes v2:
- remove check on parent uclass
Changes v1:
- add separate check on blk uclass
- modify description
- add separate check on parent uclass as usb
cmd/usb.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/cmd/usb.c b/cmd/usb.c
index d95bcf5..907debe 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -349,6 +349,16 @@ static void usb_show_tree_graph(struct usb_device *dev,
char *pre)
printf(" %s", pre);
#ifdef CONFIG_DM_USB
has_child = device_has_active_children(dev->dev);
+ if (device_get_uclass_id(dev->dev) == UCLASS_MASS_STORAGE) {
+ struct udevice *child;
+
+ for (device_find_first_child(dev->dev, &child);
+child;
+device_find_next_child(&child)) {
+ if (device_get_uclass_id(child) == UCLASS_BLK)
+ has_child = 0;
+ }
+ }
#else
/* check if the device has connected children */
int i;
@@ -414,8 +424,12 @@ static void usb_show_tree_graph(struct usb_device *dev,
char *pre)
udev = dev_get_parent_priv(child);
- /* Ignore emulators, we only want real devices */
- if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
+ /*
+* Ignore emulators and block child devices, we only want
+* real devices
+*/
+ if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
+ (device_get_uclass_id(child) != UCLASS_BLK)) {
usb_show_tree_graph(udev, pre);
pre[index] = 0;
}
@@ -605,7 +619,9 @@ static void usb_show_info(struct usb_device *udev)
for (device_find_first_child(udev->dev, &child);
child;
device_find_next_child(&child)) {
- if (device_active(child)) {
+ if (device_active(child) &&
+ (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
+ (device_get_uclass_id(child) != UCLASS_BLK)) {
udev = dev_get_parent_priv(child);
usb_show_info(udev);
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dwc2: usb: Unable to clear channel error
On 10/23/2017 09:03 AM, Minas Harutyunyan wrote: > On 10/19/2017 5:35 PM, Dinh Nguyen wrote: >> >> >> On 10/19/2017 06:55 AM, Grigor Tovmasyan wrote: >>> On 10/18/2017 6:07 PM, Marek Vasut wrote: On 10/18/2017 04:05 PM, Dinh Nguyen wrote: > Hi, > > I'm trying to bringup the DWC2 USB IP version 330A on a new Stratix10 > SoC and have encountered this error in both Linux and U-Boot: > > U-Boot(version v2017.09) > > # usb start > starting USB... > USB0: Core Release: 3.30a > dwc_otg_core_host_init: Timeout! > dwc_otg_core_host_init: Timeout! > > Linux(kernel v4.13) > > [1.299891] dwc2 ffb0.usb: DWC OTG Controller > [1.304628] dwc2 ffb0.usb: new USB bus registered, assigned bus > number 1 > [1.311698] dwc2 ffb0.usb: irq 13, io mem 0xffb0 > [1.318309] dwc2 ffb0.usb: Unable to clear enable on channel 0 > [1.325749] dwc2 ffb0.usb: Unable to clear enable on channel 1 > [1.333187] dwc2 ffb0.usb: Unable to clear enable on channel 2 > [1.340626] dwc2 ffb0.usb: Unable to clear enable on channel 3 > [1.348064] dwc2 ffb0.usb: Unable to clear enable on channel 4 > [1.355503] dwc2 ffb0.usb: Unable to clear enable on channel 5 > [1.362941] dwc2 ffb0.usb: Unable to clear enable on channel 6 > [1.370379] dwc2 ffb0.usb: Unable to clear enable on channel 7 > [1.377818] dwc2 ffb0.usb: Unable to clear enable on channel 8 > [1.385256] dwc2 ffb0.usb: Unable to clear enable on channel 9 > [1.392694] dwc2 ffb0.usb: Unable to clear enable on channel 10 > [1.400218] dwc2 ffb0.usb: Unable to clear enable on channel 11 > [1.407743] dwc2 ffb0.usb: Unable to clear enable on channel 12 > [1.415269] dwc2 ffb0.usb: Unable to clear enable on channel 13 > [1.422794] dwc2 ffb0.usb: Unable to clear enable on channel 14 > > Just wondering if anyone might have an idea on what could be causing > this error? Maybe some clock are not enabled ? >>> >>> Hi , >>> >>> Are you following board/hisilicon/hikey/README file instructions when >>> using U-Boot? Specially paragraph FLASHING point 4, where discussed >>> "dwc_otg_core_host_init: Timeout!" message. >>> >> >> I saw that, but I don't know how that applies to a Stratix10 platform? >> >> Dinh >> >> > Hi, > > Did you able to resolve this issue? If not, please provide verbose debug > log and register dump. > I double-checked the clocks and it looks like all of the necessary clocks are enabled. Here are the log and register dump for U-Boot, I'll follow-up with the Linux log shortly. For U-Boot: SOCFPGA_STRATIX10 # usb start starting USB... USB0: Core Release: 3.30a dwc_otg_core_host_init: Timeout (reg=ffb00500 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00520 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00540 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00560 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00580 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb005a0 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb005c0 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb005e0 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00600 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00620 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00640 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00660 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb00680 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb006a0 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout (reg=ffb006c0 mask=8000 wait_set=0) dwc_otg_core_host_init: Timeout! scanning bus 0 for devices... dwc2_submit_control_msg: dev='usb@ffb0', udev=3fa50380, udev->dev='usb@ffb0', portnr=0 dwc2_submit_control_msg: dev='usb@ffb0', udev=3fa50380, udev->dev='usb@ffb0', portnr=0 dwc2_submit_control_msg: dev='usb@ffb0', udev=3fa50380, udev->dev='usb@ffb0', portnr=0 dwc2_submit_control_msg: dev='usb@ffb0', udev=3fa50380, udev->dev='usb@ffb0', portnr=0 dwc2_submit_control_msg:
Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51
Hi Fabio, On Sat, Oct 21, 2017 at 2:38 PM, Fabio Estevam wrote: > On Sat, Oct 21, 2017 at 10:34 AM, Benoît Thébaudeau > wrote: > >> I already have a mainline version working at HS with changes only in >> fsl_esdhc.c (apart from the port of my board). I still have to narrow >> these changes down to the issue. > > Ok, great! The issue is the timeout in esdhc_setup_data() on line 309. If I revert e978a31b and fb823981, then everything works fine. However, the latest calculation is correct, so reverting these commits is not the fix. Indeed, for HS transfers: mmc->tran_speed = 5000, fls(mmc->tran_speed/4) = 24 mmc->clock = 4800, fls(mmc->clock/2) = 25 I've tested with 26 and 27, and they work fine. Therefore, SYSCTL.DTOCV is broken for 25 - 13 = 12 here, so the i.MX25 has an undocumented erratum, which could just happen to be CONFIG_SYS_FSL_ERRATUM_ESDHC_A001. If it's not exactly this erratum, then a new workaround could be implemented for it, or ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE could be used instead. Can you ask your design team to confirm this? Shouldn't CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 be changed into a quirk to be defined in a SoC header file (such as arch/arm/include/asm/arch-mx25/imx-regs.h) or in drivers/mmc/fsl_esdhc.c if an affected SoC or IP version is detected from the configuration, rather than keeping it as a configuration setting to be defined in a board configuration file (such as include/configs/mx25pdk.h)? Note that it would be possible to go further than fb823981 to optimize this timeout because mmc->clock is also not always the actual SD clock frequency resulting from set_sysctl(). However, timeout cases should normally never occur, so optimizing them is a bit pointless. Note that mainline Linux always uses the maximum timeout regardless of the SD clock frequency. I've also noticed that the PIO mode fails (even with the commits above reverted) for write accesses (read accesses work fine) with "Data Write Failed in PIO Mode.". I have not investigated this issue yet. This is also related to a timeout, but the root cause could be somewhere else, e.g. in the changes introduced in esdhc_setup_data() for the PIO mode. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] usb: storage: error: ‘struct usb_device’ has no member named ‘dev’
On Mon, Oct 23, 2017 at 11:26:31PM +0200, Heinrich Schuchardt wrote: > The appended config leads to: > > common/usb_storage.c: In function ‘usb_stor_probe_device’: > common/usb_storage.c:208:32: error: ‘struct usb_device’ has no member > named ‘dev’; did you mean ‘devnum’? > data = dev_get_platdata(udev->dev); > ^~~ > devnum > common/usb_storage.c:218:34: error: ‘struct usb_device’ has no member > named ‘dev’; did you mean ‘devnum’? >ret = blk_create_devicef(udev->dev, "usb_storage_blk", str, > ^~~ > devnum > > It seems that a dependency on CONFIG_DM_USB is missing. Yes, this is part of the iMX DM_MMC issue. If you have BLK enabled (and you want it), you need DM_USB. But this isn't expressable today because we don't have USB gadget DM, iirc, so it would switch some boards from gadget to host USB. -- 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 v3 1/2] LS1088A_QSPI: SECURE_BOOT: Images validation
On 10/15/2017 10:03 PM, Udit Agarwal wrote:
> Validates PPA, MC, DPC, Bootscript, DPL and Kernel images in ESBC phase
> using esbc_validate command. Add images validation in default environment
> under mcinitcmd prior to MC initialization.
>
> Add header address for PPA to be validated during ESBC phase for LS1088A
> platform based on LAyerscape Chasis 3.
>
> Moves sec_init prior to ppa_init as for validation of PPA sec must
> be initialised before the PPA is initialised.
>
> Signed-off-by: Udit Agarwal
> ---
> Changes in v3:
> Removes CONFIG_FSL_CAAM. Will be enabled via defconfig.
>
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 1 +
> board/freescale/ls1088a/Kconfig | 2 ++
> board/freescale/ls1088a/ls1088a.c | 6 +++---
> include/configs/ls1088a_common.h | 3 ---
> include/configs/ls1088aqds.h | 21 +
> include/configs/ls1088ardb.h | 22 +-
> 6 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index 3518d86..7883623 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -242,6 +242,7 @@ config SYS_LS_PPA_ESBC_ADDR
> default 0x4068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A
> default 0x2068 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT && ARCH_LS2080A
> default 0x58068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A
> + default 0x2068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A
> default 0x68 if SYS_LS_PPA_FW_IN_MMC
> default 0x68 if SYS_LS_PPA_FW_IN_NAND
> help
> diff --git a/board/freescale/ls1088a/Kconfig b/board/freescale/ls1088a/Kconfig
> index 1ada661..4479dd0 100644
> --- a/board/freescale/ls1088a/Kconfig
> +++ b/board/freescale/ls1088a/Kconfig
> @@ -12,6 +12,7 @@ config SYS_SOC
> config SYS_CONFIG_NAME
> default "ls1088aqds"
>
> +source "board/freescale/common/Kconfig"
> endif
>
> if TARGET_LS1088ARDB
> @@ -28,4 +29,5 @@ config SYS_SOC
> config SYS_CONFIG_NAME
> default "ls1088ardb"
>
> +source "board/freescale/common/Kconfig"
> endif
> diff --git a/board/freescale/ls1088a/ls1088a.c
> b/board/freescale/ls1088a/ls1088a.c
> index 96d9ae7..1860f9c 100644
> --- a/board/freescale/ls1088a/ls1088a.c
> +++ b/board/freescale/ls1088a/ls1088a.c
> @@ -315,6 +315,9 @@ int board_init(void)
> out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR105_IRQ_MASK);
> #endif
>
> +#ifdef CONFIG_FSL_CAAM
> + sec_init();
> +#endif
> #ifdef CONFIG_FSL_LS_PPA
> ppa_init();
> #endif
> @@ -337,9 +340,6 @@ void detail_board_ddr_info(void)
> #if defined(CONFIG_ARCH_MISC_INIT)
> int arch_misc_init(void)
> {
> -#ifdef CONFIG_FSL_CAAM
> - sec_init();
> -#endif
> return 0;
> }
> #endif
> diff --git a/include/configs/ls1088a_common.h
> b/include/configs/ls1088a_common.h
> index 84e9b14..6b82ee3 100644
> --- a/include/configs/ls1088a_common.h
> +++ b/include/configs/ls1088a_common.h
> @@ -132,9 +132,6 @@ unsigned long long get_qixis_addr(void);
> #if defined(CONFIG_FSL_MC_ENET)
> #define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (512UL * 1024 * 1024)
> #endif
> -
> -#define CONFIG_FSL_CAAM /* Enable SEC/CAAM */
> -
> /* Command line configuration */
> #define CONFIG_CMD_GREPENV
> #define CONFIG_CMD_CACHE
> diff --git a/include/configs/ls1088aqds.h b/include/configs/ls1088aqds.h
> index 3547b0b..ff0cb7e 100644
> --- a/include/configs/ls1088aqds.h
> +++ b/include/configs/ls1088aqds.h
> @@ -329,6 +329,26 @@ unsigned long get_board_ddr_clk(void);
> QIXIS_SDID_MASK) != QIXIS_ESDHC_NO_ADAPTER)
>
> /* Initial environment variables */
> +#ifdef CONFIG_SECURE_BOOT
> +#undef CONFIG_EXTRA_ENV_SETTINGS
> +#define CONFIG_EXTRA_ENV_SETTINGS\
> + "hwconfig=fsl_ddr:bank_intlv=auto\0"\
> + "loadaddr=0x9010\0" \
> + "kernel_addr=0x10\0"\
> + "ramdisk_addr=0x80\0" \
> + "ramdisk_size=0x200\0" \
> + "fdt_high=0xa000\0" \
> + "initrd_high=0x\0" \
> + "kernel_start=0x100\0" \
> + "kernel_load=0xa000\0" \
> + "kernel_size=0x280\0" \
> + "mcinitcmd=sf probe 0:0;sf read 0xa0a0 0xa0 0x10;" \
> + "sf read 0xa070 0x70 0x4000; esbc_validate 0xa070;" \
> + "sf read 0xa0e0 0xe0 0x10;" \
> + "sf read 0xa074 0x74 0x4000;esbc_validate 0xa074;" \
> + "fsl_mc start mc 0xa0a0 0xa0e0\0" \
> + "mcmemsize=0x7000 \0"
> +#else /* if !(CONFIG_SECURE_BOOT) */
> #if defined(CONFIG_QSPI_BOOT)
> #undef CONFIG_EXTRA_ENV_SETTINGS
> #define CONFIG_EXTRA_ENV_SETTINGS\
> @@ -362,6 +382,7 @@ unsigned long get_board_ddr_clk(void);
> "mcinitcmd=fsl_mc s
[U-Boot] usb: storage: error: ‘struct usb_device’ has no member named ‘dev’
The appended config leads to: common/usb_storage.c: In function ‘usb_stor_probe_device’: common/usb_storage.c:208:32: error: ‘struct usb_device’ has no member named ‘dev’; did you mean ‘devnum’? data = dev_get_platdata(udev->dev); ^~~ devnum common/usb_storage.c:218:34: error: ‘struct usb_device’ has no member named ‘dev’; did you mean ‘devnum’? ret = blk_create_devicef(udev->dev, "usb_storage_blk", str, ^~~ devnum It seems that a dependency on CONFIG_DM_USB is missing. Best regards Heinrich # # Automatically generated file; DO NOT EDIT. # U-Boot 2017.11-rc2 Configuration # CONFIG_CREATE_ARCH_SYMLINK=y # CONFIG_ARC is not set CONFIG_ARM=y # CONFIG_M68K is not set # CONFIG_MICROBLAZE is not set # CONFIG_MIPS is not set # CONFIG_NDS32 is not set # CONFIG_NIOS2 is not set # CONFIG_PPC is not set # CONFIG_SANDBOX is not set # CONFIG_SH is not set # CONFIG_X86 is not set # CONFIG_XTENSA is not set CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv8" CONFIG_SYS_SOC="meson" CONFIG_SYS_VENDOR="amlogic" CONFIG_SYS_BOARD="odroid-c2" CONFIG_SYS_CONFIG_NAME="odroid-c2" # # ARM architecture # CONFIG_ARM64=y CONFIG_DMA_ADDR_T_64BIT=y CONFIG_ARM_ASM_UNIFIED=y CONFIG_SYS_ARM_ARCH=8 CONFIG_SYS_CACHE_SHIFT_6=y CONFIG_SYS_CACHELINE_SIZE=64 # CONFIG_ARM_SMCCC is not set # CONFIG_SEMIHOSTING is not set # CONFIG_SYS_L2CACHE_OFF is not set # CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK is not set # CONFIG_ARM_CORTEX_CPU_IS_UP is not set CONFIG_ARM64_SUPPORT_AARCH32=y # CONFIG_ARCH_AT91 is not set # CONFIG_TARGET_EDB93XX is not set # CONFIG_TARGET_ASPENITE is not set # CONFIG_TARGET_GPLUGD is not set # CONFIG_ARCH_DAVINCI is not set # CONFIG_KIRKWOOD is not set # CONFIG_ARCH_MVEBU is not set # CONFIG_TARGET_DEVKIT3250 is not set # CONFIG_TARGET_WORK_92105 is not set # CONFIG_TARGET_MX25PDK is not set # CONFIG_TARGET_ZMX25 is not set # CONFIG_TARGET_APF27 is not set # CONFIG_TARGET_APX4DEVKIT is not set # CONFIG_TARGET_XFI3 is not set # CONFIG_TARGET_M28EVK is not set # CONFIG_TARGET_MX23EVK is not set # CONFIG_TARGET_MX28EVK is not set # CONFIG_TARGET_MX23_OLINUXINO is not set # CONFIG_TARGET_BG0900 is not set # CONFIG_TARGET_SANSA_FUZE_PLUS is not set # CONFIG_TARGET_SC_SPS_1 is not set # CONFIG_ORION5X is not set # CONFIG_TARGET_SPEAR300 is not set # CONFIG_TARGET_SPEAR310 is not set # CONFIG_TARGET_SPEAR320 is not set # CONFIG_TARGET_SPEAR600 is not set # CONFIG_TARGET_STV0991 is not set # CONFIG_TARGET_X600 is not set # CONFIG_TARGET_IMX31_PHYCORE is not set # CONFIG_TARGET_IMX31_PHYCORE_EET is not set # CONFIG_TARGET_MX31ADS is not set # CONFIG_TARGET_MX31PDK is not set # CONFIG_TARGET_WOODBURN is not set # CONFIG_TARGET_WOODBURN_SD is not set # CONFIG_TARGET_FLEA3 is not set # CONFIG_TARGET_MX35PDK is not set # CONFIG_ARCH_BCM283X is not set # CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set # CONFIG_TARGET_VEXPRESS_CA5X2 is not set # CONFIG_TARGET_VEXPRESS_CA9X4 is not set # CONFIG_TARGET_BCM23550_W1D is not set # CONFIG_TARGET_BCM28155_AP is not set # CONFIG_TARGET_BCMCYGNUS is not set # CONFIG_TARGET_BCMNSP is not set # CONFIG_TARGET_BCMNS2 is not set # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_S5PC1XX is not set # CONFIG_ARCH_HIGHBANK is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_KEYSTONE is not set # CONFIG_ARCH_OMAP2PLUS is not set CONFIG_ARCH_MESON=y # CONFIG_ARCH_MX7ULP is not set # CONFIG_ARCH_MX7 is not set # CONFIG_ARCH_MX6 is not set CONFIG_SPL_LDSCRIPT="arch/arm/cpu/armv8/u-boot-spl.lds" # CONFIG_ARCH_MX5 is not set # CONFIG_ARCH_QEMU is not set # CONFIG_ARCH_RMOBILE is not set # CONFIG_TARGET_S32V234EVB is not set # CONFIG_ARCH_SNAPDRAGON is not set # CONFIG_ARCH_SOCFPGA is not set # CONFIG_ARCH_SUNXI is not set # CONFIG_TARGET_TS4600 is not set # CONFIG_ARCH_VF610 is not set # CONFIG_ARCH_ZYNQ is not set # CONFIG_ARCH_ZYNQMP is not set # CONFIG_TEGRA is not set # CONFIG_TARGET_VEXPRESS64_AEMV8A is not set # CONFIG_TARGET_VEXPRESS64_BASE_FVP is not set # CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM is not set # CONFIG_TARGET_VEXPRESS64_JUNO is not set # CONFIG_TARGET_LS2080A_EMU is not set # CONFIG_TARGET_LS2080A_SIMU is not set # CONFIG_TARGET_LS1088AQDS is not set # CONFIG_TARGET_LS2080AQDS is not set # CONFIG_TARGET_LS2080ARDB is not set # CONFIG_TARGET_LS2081ARDB is not set # CONFIG_TARGET_HIKEY is not set # CONFIG_TARGET_POPLAR is not set # CONFIG_TARGET_LS1012AQDS is not set # CONFIG_TARGET_LS1012ARDB is not set # CONFIG_TARGET_LS1012AFRDM is not set # CONFIG_TARGET_LS1088ARDB is not set # CONFIG_TARGET_LS1021AQDS is not set # CONFIG_TARGET_LS1021ATWR is not set # CONFIG_TARGET_LS1021AIOT is not set # CONFIG_TARGET_LS1043AQDS is not set # CONFIG_TARGET_LS1043ARDB is not set # CONFIG_TARGET_LS1046AQDS is not set # CONFIG_TARGET_LS1046ARDB is not set # CONFIG_TARGET_H2200 is not set # CONFIG_TARGET_ZIPITZ2 is not set # CONFIG_TARGET_COLIBRI_PXA270 is not set # CONFIG_ARCH_UNIPHIER
Re: [U-Boot] [U-Boot,1/2] mtd: replace MTDDEBUG() with pr_debug()
On Wed, Oct 18, 2017 at 12:10:48AM +0900, Masahiro Yamada wrote:
> In old days, the MTD subsystem in Linux had debug facility like
> DEBUG(MTD_DEBUG_LEVEL1, ...).
>
> They were all replaced with pr_debug() until Linux 3.2. See Linux
> commit 289c05222172 ("mtd: replace DEBUG() with pr_debug()").
>
> U-Boot still uses similar macros. Covert all of them for easier sync.
>
> Done with the help of Coccinelle.
>
> The semantic patch I used is as follows:
>
> //
> @@
> expression e1, e2;
> @@
> -MTDDEBUG(e1, e2)
> +pr_debug(e2)
> @@
> expression e1, e2;
> @@
> -MTDDEBUG(e1, e2,
> +pr_debug(e2,
> ...)
> //
>
> Signed-off-by: Masahiro Yamada
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
Re: [U-Boot] [PATCH 2/2] armv8: sec_firmware: Add support for loadables in FIT
On 09/01/2017 01:25 AM, Sumit Garg wrote:
> Enable support for loadables in SEC firmware FIT image. Currently support
> is added for single loadable image.
>
> Brief description of implementation:
> - Add two more address pointers (loadable_h, loadable_l) as arguments to
> sec_firmware_init() api.
> - Create new api: sec_firmware_checks_copy_loadable() to check if loadables
> node is present in SEC firmware FIT image. If present, verify loadable
> image and copies it to secure DDR memory.
> - Populate address pointers with secure DDR memory addresses where loadable
> is copied.
>
> Example use-case could be trusted OS (tee.bin) as loadables node in SEC
> firmware FIT image.
>
> Signed-off-by: Sumit Garg
> ---
> arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 16 +-
> arch/arm/cpu/armv8/sec_firmware.c | 92
> +--
> arch/arm/include/asm/armv8/sec_firmware.h | 4 +-
> 3 files changed, 104 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> index 35c612d..87a0885 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> @@ -35,6 +35,7 @@ int ppa_init(void)
> unsigned int el = current_el();
> void *ppa_fit_addr;
> u32 *boot_loc_ptr_l, *boot_loc_ptr_h;
> + u32 *loadable_l, *loadable_h;
> int ret;
>
> #ifdef CONFIG_CHAIN_OF_TRUST
> @@ -252,9 +253,9 @@ int ppa_init(void)
> PPA_KEY_HASH,
> &ppa_img_addr);
> if (ret != 0)
> - printf("PPA validation failed\n");
> + printf("SEC firmware(s) validation failed\n");
> else
> - printf("PPA validation Successful\n");
> + printf("SEC firmware(s) validation Successful\n");
> }
> #if defined(CONFIG_SYS_LS_PPA_FW_IN_MMC) || \
> defined(CONFIG_SYS_LS_PPA_FW_IN_NAND)
> @@ -266,15 +267,24 @@ int ppa_init(void)
> struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
> boot_loc_ptr_l = &gur->bootlocptrl;
> boot_loc_ptr_h = &gur->bootlocptrh;
> +
> + /* Assign addresses to loadable ptrs */
> + loadable_l = &gur->scratchrw[4];
> + loadable_h = &gur->scratchrw[5];
> #elif defined(CONFIG_FSL_LSCH2)
> struct ccsr_scfg __iomem *scfg = (void *)(CONFIG_SYS_FSL_SCFG_ADDR);
> boot_loc_ptr_l = &scfg->scratchrw[1];
> boot_loc_ptr_h = &scfg->scratchrw[0];
> +
> + /* Assign addresses to loadable ptrs */
> + loadable_l = &scfg->scratchrw[2];
> + loadable_h = &scfg->scratchrw[3];
> #endif
>
> debug("fsl-ppa: boot_loc_ptr_l = 0x%p, boot_loc_ptr_h =0x%p\n",
> boot_loc_ptr_l, boot_loc_ptr_h);
> - ret = sec_firmware_init(ppa_fit_addr, boot_loc_ptr_l, boot_loc_ptr_h);
> + ret = sec_firmware_init(ppa_fit_addr, boot_loc_ptr_l, boot_loc_ptr_h,
> + loadable_l, loadable_h);
>
> #if defined(CONFIG_SYS_LS_PPA_FW_IN_MMC) || \
> defined(CONFIG_SYS_LS_PPA_FW_IN_NAND)
> diff --git a/arch/arm/cpu/armv8/sec_firmware.c
> b/arch/arm/cpu/armv8/sec_firmware.c
> index 0e74834..927eae4 100644
> --- a/arch/arm/cpu/armv8/sec_firmware.c
> +++ b/arch/arm/cpu/armv8/sec_firmware.c
> @@ -105,6 +105,74 @@ static int sec_firmware_parse_image(const void
> *sec_firmware_img,
> return 0;
> }
>
> +/*
> + * SEC Firmware FIT image parser to check if any loadable is
> + * present. If present, verify integrity of the loadable and
> + * copy loadable to address provided in (loadable_h, loadable_l).
> + *
> + * Returns 0 on success and a negative errno on error task fail.
> + */
> +static int sec_firmware_check_copy_loadable(const void *sec_firmware_img,
> + u32 *loadable_l, u32 *loadable_h)
> +{
> + phys_addr_t sec_firmware_loadable_addr = 0;
> + int conf_node_off, ld_node_off;
> + char *conf_node_name = NULL;
> + const void *data;
> + size_t size;
> + ulong load;
> +
> + conf_node_name = SEC_FIRMEWARE_FIT_CNF_NAME;
> +
> + conf_node_off = fit_conf_get_node(sec_firmware_img, conf_node_name);
> + if (conf_node_off < 0) {
> + printf("SEC Firmware: %s: no such config\n", conf_node_name);
> + return -ENOENT;
> + }
> +
> + ld_node_off = fit_conf_get_prop_node(sec_firmware_img, conf_node_off,
> + FIT_LOADABLE_PROP);
> + if (ld_node_off >= 0) {
> + printf("SEC Firmware: '%s' present in config\n",
> +FIT_LOADABLE_PROP);
> +
> + /* Verify secure firmware image */
> + if (!(fit_image_verify(sec_firmware_img, ld_node_off))) {
> + printf("SEC Loadable: Bad loadable image (bad CRC)\n");
> + return -EINVAL;
> + }
> +
> + if (fit_image_get
Re: [U-Boot] [PATCH 1/2] armv8: layerscape: Allocate 66 MB DDR for secure memory
On 09/01/2017 01:24 AM, Sumit Garg wrote: > Change DDR allocated for secure memory from 2 MB to 66 MB. This additional > 64 MB secure memory is required for trusted OS running in Trusted Execution > Environment using ARMv8 TrustZone. > > Signed-off-by: Sumit Garg > --- > arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h > b/arch/arm/include/asm/arch-fsl-layerscape/config.h > index a7098be..95e2791 100644 > --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h > +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h > @@ -16,7 +16,7 @@ > * Reserve secure memory > * To be aligned with MMU block size > */ > -#define CONFIG_SYS_MEM_RESERVE_SECURE(2048 * 1024) /* 2MB */ > +#define CONFIG_SYS_MEM_RESERVE_SECURE(66 * 1024 * 1024) /* 66MB > */ > #define SPL_TLB_SETBACK 0x100 /* 16MB under effective memory > top */ > > #ifdef CONFIG_ARCH_LS2080A > Sumit, I believe this patch is no longer needed after the merge of commit 710d0cd79ede129d5203325c2a188c6f93c61ca3 Author: Sumit Garg Date: Wed Oct 4 03:20:49 2017 +0530 armv8: fsl-layerscape: Allocate Secure memory from first ddr region York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: ls1043ardb: Add sd_bootcmd for distro fallback in case of sdboot
On 09/14/2017 02:26 PM, York Sun wrote: > On 08/30/2017 03:43 AM, Shengzhou Liu wrote: >> Signed-off-by: Shengzhou Liu >> --- >> include/configs/ls1043a_common.h | 11 ++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/include/configs/ls1043a_common.h >> b/include/configs/ls1043a_common.h >> index f064d5c24a..976c031574 100644 >> --- a/include/configs/ls1043a_common.h >> +++ b/include/configs/ls1043a_common.h >> @@ -281,6 +281,8 @@ >> "fdt_addr_r=0x9000\0" \ >> "load_addr=0xa000\0"\ >> "kernel_size=0x280\0" \ >> +"kernel_addr_sd=0x8000\0" \ >> +"kernel_size_sd=0x14000\0" \ >> "console=ttyS0,115200\0"\ >> "mtdparts=" MTDPARTS_DEFAULT "\0" \ >> BOOTENV \ >> @@ -318,12 +320,19 @@ >> "$kernel_addr $kernel_size && bootm $load_addr#$board\0" \ >> "nor_bootcmd=echo Trying load from nor..;" \ >> "cp.b $kernel_addr $load_addr " \ >> -"$kernel_size && bootm $load_addr#$board\0" >> +"$kernel_size && bootm $load_addr#$board\0" \ >> +"sd_bootcmd=echo Trying load from SD ..;" \ >> +"mmcinfo; mmc read $load_addr " \ >> +"$kernel_addr_sd $kernel_size_sd ;" \ >> +" bootm $load_addr#$board\0" >> > > Shouldn't you be using "&&" instead of ";" between commands? > Shengzhou, Are you going to update the patches? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property
On Tue, Oct 24, 2017 at 12:36 AM, Felix Brack wrote:
> On 23.10.2017 16:36, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Oct 12, 2017 at 11:40 PM, Felix Brack wrote:
>>> On 12.10.2017 14:53, Chen-Yu Tsai wrote:
On Thu, Oct 12, 2017 at 8:24 PM, Felix Brack wrote:
> On 12.10.2017 04:46, Chen-Yu Tsai wrote:
>> On Mon, Oct 9, 2017 at 6:04 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.
>>
>> No. See the regulator bindings:
>>
>> Optional properties:
>> - regulator-name: A string used as a descriptive name for regulator
>> outputs
>>
> The actual regulator.txt states:
>
> Optional properties:
> - regulator-name: a string, required by the regulator uclass
>
> This was the reason for choosing the regulator-name property.
Mine was from the Linux Kernel. Are there two sets of bindings?
Shouldn't there be just one?
>>> Mine was from U-Boot as this is the U-Boot mailing list and things do
>>> not seem to be fully synchronized between LINUX and U-Boot.
>>
>> That seems to be the underlying problem. They really should be the same.
>> I'm not sure which platforms really follow through with this though.
>>
>> This can vary from board to board. The name should match the power rail
>> name of the board (which may not be the same as the regulator chip's
>> output name).
>>
> Exactly. I totally agree but as stated in an earlier post: I did not
> define the names for the regulators and modifying them is almost
> certainly not the right way to go. Let me explain this briefly. The
> regulator names I'm trying to match are those from tps65910.dtsi, an
> include file. The exact same file is part of the LINUX kernel. Therefore
> I resigned suggesting the modification of the node names.
First, it is an include file. Board files are free to override the
name. We did that for sunxi at first, have the .dtsi file provide
some default names, then have board .dts files override them with
names that make more sense. Later on we just dropped the default
names altogether.
>>> I am definitely confused now, maybe we are using same terms for
>>> different things. When I'm talking about a 'name' I mean the 'node name'
>>> according to DT specification (as for instance returned by
>>> ofnode_get_name). I'm not talking about a property or a node label. The
>>> following code defines a node name 'regulator@2' ore more precisely a
>>> node named 'regulator' having unit-address 2:
>>>
>>> vdd1_reg: regulator@2 {
>>> reg = <2>;
>>> regulator-compatible = "vdd1";
>>> };
>>>
>>> This is found in tps65910.dtsi include file. You say "board files are
>>> free to override the name". Hence I could include the tps65910.dtsi into
>>> my board dts file and kind of rename node 'regulator@2' by let's say
>>> 'buck_vdd1@2'?
>>> The only way of "overriding" I can think of is by not including the dtsi
>>> file and redefining all nodes.
>>
>> I'm talking about the "name" as defined in the "regulator-name"
>> property, which is what you want to match against in your patch.
>>
>> So boards are definitely free to override the property by setting
>> a new value for it. And indeed boards do that.
>>
> This is the driving idea behind my patch.
>
The same pattern is also seen in tps65910.dtsi and am3517-craneboard.dts.
And also am335x-evm.dts, which the tps65910.dtsi was tested with.
>>> Looking at the am3517-craneboard.dts file I don't see how node names are
>>> getting overwritten. What gets set, changed or overwritten is the node
>>> property regulator-name.
>>
>> Yes. That's what I'm referring to. Doesn't this work against your
>> attempt to bind pmic-uclass against regulator-name properties?
>>
> Well, yes, my patch works like charm. I didn't mention that it doesn't
> work ;-).
>
>>>
Now I couldn't find the binding document for tps65910, but looking
at tps65217 instead, it says:
- regulators: list of regulators provided by this controller, must be named
after their hardware counterparts: dcdc[1-3] and ldo[1-4]
And indeed that is what's used in the example.
>>> Yes, exactly and correct. Again, this tps65217.txt does only exist in
>>> LINUX and not in U-Boot.
>>
>> Device tree bindings are a set of rules, contracts, ABIs, whatever
>> you call it, between the hardware description that is the device
>> tree, and software that implement support for the hardware. Having
>> two or more diverging sets is not an improvement. Communities should
>> work together to have a common set of bindings.
>>
> I totally agree.
>
>> FreeBSD seems to be importing device tree bindings from Linux. Th
Re: [U-Boot] [PATCH] ARM: SPL: FIT: fix DTC warnings on FIT generation
On Mon, Oct 23, 2017 at 11:08:57AM +0530, Lokesh Vutla wrote: > > > On Tuesday 17 October 2017 02:43 AM, Tom Rini wrote: > > On Tue, Oct 17, 2017 at 02:29:14AM +0530, Jagan Teki wrote: > >> On Mon, Oct 9, 2017 at 10:15 AM, Simon Glass wrote: > >>> Hi Andre, > >>> > >>> On 4 October 2017 at 17:24, Andre Przywara wrote: > Newer versions of the device tree compiler (rightfully) complain about > mismatches between attributed node names (name@) and a missing > reg property in that node. > Adjust the FIT build script for 64-bit Allwinner boards to remove the > bogus addresses from the node names and avoid the warnings. > > Signed-off-by: Andre Przywara > --- > board/sunxi/mksunxi_fit_atf.sh | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > >>> > >>> It looks like we have this problem all over the place. The > >>> documentation in doc/uImage now seems to have this problem too. > >>> > >>> I wonder if instead we should add reg / #address-cells / #size-cells > >>> properties? > >> > >> If the update on dts, might be an another-overhead to maintain u-boot > >> dts wrt Linux dts sync. > > > > Anything that DTC is warning about in a dts that we get from the kernel, > > should be fixed in the kernel. The kernel dtc is what we're using, and > > is/will/can also complain about it. > > Kernel suppress these warning by default[1] and enables these warnings > with W= compiler option. May be this should be included in u-boot as well? > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.lib#n272 We have slightly different logic for that today in scripts/Makefile.extrawarn, perhaps we need to re-sync? -- 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] [GIT PULL] u-boot-uniphier/master
On Tue, Oct 24, 2017 at 02:43:00AM +0900, Masahiro Yamada wrote: > Hi Tom, > > 2017-10-24 1:05 GMT+09:00 Tom Rini : > > On Mon, Oct 23, 2017 at 01:14:57AM +0900, Masahiro Yamada wrote: > > > >> Hi Tom, > >> > >> > >> This was late for -rc2 for some reason, but it includes > >> what I intended to include in it. > >> Some fixes, remove unused CONFIG, DT sync, etc. > >> Please pull. > >> > >> > >> > >> The following changes since commit > >> 23d51bef94aacd0ad4dcbdb31e66acd82def13eb: > >> > >> uniphier_ld4_sld8: Re-add SMC911X_BASE address (2017-10-21 10:26:34 > >> -0400) > >> > >> are available in the git repository at: > >> > >> git://git.denx.de/u-boot-uniphier.git master > >> > >> for you to fetch changes up to 624c0954c7be03d92a20170ffc551ca7e9853e16: > >> > >> ARM: uniphier: use pr_*() more where appropriate (2017-10-23 01:09:22 > >> +0900) > >> > > > > Reviewed-by: Tom Rini > > > > May I ask your intention? > Why reviewed-by instead of git-pull? ... I hit the wrong key-combo this morning. It's applied, sorry! -- 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] [GIT PULL] u-boot-uniphier/master
Hi Tom, 2017-10-24 1:05 GMT+09:00 Tom Rini : > On Mon, Oct 23, 2017 at 01:14:57AM +0900, Masahiro Yamada wrote: > >> Hi Tom, >> >> >> This was late for -rc2 for some reason, but it includes >> what I intended to include in it. >> Some fixes, remove unused CONFIG, DT sync, etc. >> Please pull. >> >> >> >> The following changes since commit 23d51bef94aacd0ad4dcbdb31e66acd82def13eb: >> >> uniphier_ld4_sld8: Re-add SMC911X_BASE address (2017-10-21 10:26:34 -0400) >> >> are available in the git repository at: >> >> git://git.denx.de/u-boot-uniphier.git master >> >> for you to fetch changes up to 624c0954c7be03d92a20170ffc551ca7e9853e16: >> >> ARM: uniphier: use pr_*() more where appropriate (2017-10-23 01:09:22 >> +0900) >> > > Reviewed-by: Tom Rini > May I ask your intention? Why reviewed-by instead of git-pull? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property
On 23.10.2017 16:36, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Oct 12, 2017 at 11:40 PM, Felix Brack wrote:
>> On 12.10.2017 14:53, Chen-Yu Tsai wrote:
>>> On Thu, Oct 12, 2017 at 8:24 PM, Felix Brack wrote:
On 12.10.2017 04:46, Chen-Yu Tsai wrote:
> On Mon, Oct 9, 2017 at 6:04 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.
>
> No. See the regulator bindings:
>
> Optional properties:
> - regulator-name: A string used as a descriptive name for regulator
> outputs
>
The actual regulator.txt states:
Optional properties:
- regulator-name: a string, required by the regulator uclass
This was the reason for choosing the regulator-name property.
>>>
>>> Mine was from the Linux Kernel. Are there two sets of bindings?
>>> Shouldn't there be just one?
>>>
>> Mine was from U-Boot as this is the U-Boot mailing list and things do
>> not seem to be fully synchronized between LINUX and U-Boot.
>
> That seems to be the underlying problem. They really should be the same.
> I'm not sure which platforms really follow through with this though.
>
> This can vary from board to board. The name should match the power rail
> name of the board (which may not be the same as the regulator chip's
> output name).
>
Exactly. I totally agree but as stated in an earlier post: I did not
define the names for the regulators and modifying them is almost
certainly not the right way to go. Let me explain this briefly. The
regulator names I'm trying to match are those from tps65910.dtsi, an
include file. The exact same file is part of the LINUX kernel. Therefore
I resigned suggesting the modification of the node names.
>>>
>>> First, it is an include file. Board files are free to override the
>>> name. We did that for sunxi at first, have the .dtsi file provide
>>> some default names, then have board .dts files override them with
>>> names that make more sense. Later on we just dropped the default
>>> names altogether.
>>>
>> I am definitely confused now, maybe we are using same terms for
>> different things. When I'm talking about a 'name' I mean the 'node name'
>> according to DT specification (as for instance returned by
>> ofnode_get_name). I'm not talking about a property or a node label. The
>> following code defines a node name 'regulator@2' ore more precisely a
>> node named 'regulator' having unit-address 2:
>>
>> vdd1_reg: regulator@2 {
>> reg = <2>;
>> regulator-compatible = "vdd1";
>> };
>>
>> This is found in tps65910.dtsi include file. You say "board files are
>> free to override the name". Hence I could include the tps65910.dtsi into
>> my board dts file and kind of rename node 'regulator@2' by let's say
>> 'buck_vdd1@2'?
>> The only way of "overriding" I can think of is by not including the dtsi
>> file and redefining all nodes.
>
> I'm talking about the "name" as defined in the "regulator-name"
> property, which is what you want to match against in your patch.
>
> So boards are definitely free to override the property by setting
> a new value for it. And indeed boards do that.
>
This is the driving idea behind my patch.
>>> The same pattern is also seen in tps65910.dtsi and am3517-craneboard.dts.
>>> And also am335x-evm.dts, which the tps65910.dtsi was tested with.
>>>
>> Looking at the am3517-craneboard.dts file I don't see how node names are
>> getting overwritten. What gets set, changed or overwritten is the node
>> property regulator-name.
>
> Yes. That's what I'm referring to. Doesn't this work against your
> attempt to bind pmic-uclass against regulator-name properties?
>
Well, yes, my patch works like charm. I didn't mention that it doesn't
work ;-).
>>
>>> Now I couldn't find the binding document for tps65910, but looking
>>> at tps65217 instead, it says:
>>>
>>> - regulators: list of regulators provided by this controller, must be named
>>> after their hardware counterparts: dcdc[1-3] and ldo[1-4]
>>>
>>> And indeed that is what's used in the example.
>>>
>> Yes, exactly and correct. Again, this tps65217.txt does only exist in
>> LINUX and not in U-Boot.
>
> Device tree bindings are a set of rules, contracts, ABIs, whatever
> you call it, between the hardware description that is the device
> tree, and software that implement support for the hardware. Having
> two or more diverging sets is not an improvement. Communities should
> work together to have a common set of bindings.
>
I totally agree.
> FreeBSD seems to be importing device tree bindings from Linux. There
> was also talk about importing bindings from other projects that have
> already created and implemented support for bindings that do not
> exist in Linux. This
Re: [U-Boot] [PATCH v4 2/3] ARM: dts: OMAP5+: Add support for bandgap sensor in SPL
On Mon, Oct 23, 2017 at 01:28:06PM +0530, Faiz Abbas wrote: > Mark bandgap node as uboot,dm-spl so that it can be accessed in spl > > Signed-off-by: Faiz Abbas > Reviewed-by: Simon Glass Reviewed-by: Tom Rini -- 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] [GIT PULL] u-boot-uniphier/master
On Mon, Oct 23, 2017 at 01:14:57AM +0900, Masahiro Yamada wrote: > Hi Tom, > > > This was late for -rc2 for some reason, but it includes > what I intended to include in it. > Some fixes, remove unused CONFIG, DT sync, etc. > Please pull. > > > > The following changes since commit 23d51bef94aacd0ad4dcbdb31e66acd82def13eb: > > uniphier_ld4_sld8: Re-add SMC911X_BASE address (2017-10-21 10:26:34 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-uniphier.git master > > for you to fetch changes up to 624c0954c7be03d92a20170ffc551ca7e9853e16: > > ARM: uniphier: use pr_*() more where appropriate (2017-10-23 01:09:22 +0900) > Reviewed-by: Tom Rini -- 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] Build failure in u-boot-mmc/master: undefined reference to error
On 10/22/2017 08:53 PM, Jaehoon Chung wrote: Dear Stephen, On 10/21/2017 12:47 AM, Stephen Warren wrote: 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: I had found the same error at build testing, I will fix it on today. Thanks for noticing it. Thanks. I see that the build failures are fixed now, but the following unit-tests are failing on sandbox: test_ut[ut_dm_blk_base] test_ut[ut_dm_blk_devnum] test_ut[ut_dm_blk_get_from_parent] test_ut[ut_dm_mmc_base] test_ut[ut_dm_mmc_blk] For example: => ut dm blk_base Test: dm_test_blk_base: blk.c unable to select a mode mmc_init: -524, time 6 /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/test/dm/blk.c:40, dm_test_blk_base(): 0 == blk_first_device(IF_TYPE_HOST, &dev): Expected 0, got -524 Test: dm_test_blk_base: blk.c (flat tree) unable to select a mode mmc_init: -524, time 6 /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/test/dm/blk.c:40, dm_test_blk_base(): 0 == blk_first_device(IF_TYPE_HOST, &dev): Expected 0, got -524 Failures: 2 You should be able to reproduce this by running the following from the U-Boot source tree: ./test/py/test.py --bd sandbox --build ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] LS1012A PFE driver patch series
On 10/09/2017 02:09 AM, Calvin Johnson wrote: > Hi, > > This patch series introduces U-Boot support for NXP's LS1012A Packet > Forwarding > Engine (pfe_eth). LS1012A uses hardware packet forwarding engine to provide > high performance Ethernet interfaces. The device includes two Ethernet ports. > > Depends on > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F704305&data=01%7C01%7Cyork.sun%40nxp.com%7C78639ec10c954f60768a08d50ef573c5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=cEXazXptrFnPf30yXCrwOvb%2B3DDekH4BZNmW1JavzO8%3D&reserved=0 > > Regards > Calvin > > Calvin Johnson (9): > drivers: net: pfe_eth: LS1012A PFE driver introduction > drivers: net: pfe_eth: provide pfe commands > drivers: net: pfe_eth: LS1012A PFE headers > board: freescale: ls1012a: enable network support on ls1012a platforms > armv8: fsl-lsch2: initialize pfe gemac > armv8: fsl-lsch2: add pfe macros and update ccsr_scfg structure > armv8: fsl-lsch2: configure pfe's scfg & dcfg registers > fsl: csu: enable ns access for PFE > configs: ls1012a: add pfe configuration for LS1012A Joe, Please review the new net driver proposed when you have a chance. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property
Hi,
On Thu, Oct 12, 2017 at 11:40 PM, Felix Brack wrote:
> On 12.10.2017 14:53, Chen-Yu Tsai wrote:
>> On Thu, Oct 12, 2017 at 8:24 PM, Felix Brack wrote:
>>> On 12.10.2017 04:46, Chen-Yu Tsai wrote:
On Mon, Oct 9, 2017 at 6:04 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.
No. See the regulator bindings:
Optional properties:
- regulator-name: A string used as a descriptive name for regulator outputs
>>> The actual regulator.txt states:
>>>
>>> Optional properties:
>>> - regulator-name: a string, required by the regulator uclass
>>>
>>> This was the reason for choosing the regulator-name property.
>>
>> Mine was from the Linux Kernel. Are there two sets of bindings?
>> Shouldn't there be just one?
>>
> Mine was from U-Boot as this is the U-Boot mailing list and things do
> not seem to be fully synchronized between LINUX and U-Boot.
That seems to be the underlying problem. They really should be the same.
I'm not sure which platforms really follow through with this though.
This can vary from board to board. The name should match the power rail
name of the board (which may not be the same as the regulator chip's
output name).
>>> Exactly. I totally agree but as stated in an earlier post: I did not
>>> define the names for the regulators and modifying them is almost
>>> certainly not the right way to go. Let me explain this briefly. The
>>> regulator names I'm trying to match are those from tps65910.dtsi, an
>>> include file. The exact same file is part of the LINUX kernel. Therefore
>>> I resigned suggesting the modification of the node names.
>>
>> First, it is an include file. Board files are free to override the
>> name. We did that for sunxi at first, have the .dtsi file provide
>> some default names, then have board .dts files override them with
>> names that make more sense. Later on we just dropped the default
>> names altogether.
>>
> I am definitely confused now, maybe we are using same terms for
> different things. When I'm talking about a 'name' I mean the 'node name'
> according to DT specification (as for instance returned by
> ofnode_get_name). I'm not talking about a property or a node label. The
> following code defines a node name 'regulator@2' ore more precisely a
> node named 'regulator' having unit-address 2:
>
> vdd1_reg: regulator@2 {
> reg = <2>;
> regulator-compatible = "vdd1";
> };
>
> This is found in tps65910.dtsi include file. You say "board files are
> free to override the name". Hence I could include the tps65910.dtsi into
> my board dts file and kind of rename node 'regulator@2' by let's say
> 'buck_vdd1@2'?
> The only way of "overriding" I can think of is by not including the dtsi
> file and redefining all nodes.
I'm talking about the "name" as defined in the "regulator-name"
property, which is what you want to match against in your patch.
So boards are definitely free to override the property by setting
a new value for it. And indeed boards do that.
>> The same pattern is also seen in tps65910.dtsi and am3517-craneboard.dts.
>> And also am335x-evm.dts, which the tps65910.dtsi was tested with.
>>
> Looking at the am3517-craneboard.dts file I don't see how node names are
> getting overwritten. What gets set, changed or overwritten is the node
> property regulator-name.
Yes. That's what I'm referring to. Doesn't this work against your
attempt to bind pmic-uclass against regulator-name properties?
>
>> Now I couldn't find the binding document for tps65910, but looking
>> at tps65217 instead, it says:
>>
>> - regulators: list of regulators provided by this controller, must be named
>> after their hardware counterparts: dcdc[1-3] and ldo[1-4]
>>
>> And indeed that is what's used in the example.
>>
> Yes, exactly and correct. Again, this tps65217.txt does only exist in
> LINUX and not in U-Boot.
Device tree bindings are a set of rules, contracts, ABIs, whatever
you call it, between the hardware description that is the device
tree, and software that implement support for the hardware. Having
two or more diverging sets is not an improvement. Communities should
work together to have a common set of bindings.
FreeBSD seems to be importing device tree bindings from Linux. There
was also talk about importing bindings from other projects that have
already created and implemented support for bindings that do not
exist in Linux. This has been raised for the Device Tree Workshop
this Thursday at OSSE/ELCE:
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2017-October/004833.html
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2017-October/004891.html
I've also raised the issue of diverging device trees and bindings:
ht
Re: [U-Boot] [PATCH v3 18/20] arm: socfpga: Enable function visible to other file
On 10/23/2017 03:19 AM, Chee, Tien Fong wrote: > On Jum, 2017-10-20 at 09:39 -0500, Dinh Nguyen wrote: >> >> 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. >> > This patch is required by later patches, so this patch can't be > separated out. This function is static declaration, but this function > is required by the caller from other file(later patches). So, this > patch is to remove ths static declaration so it is accessible by the > caller from other file. yes, I know what it means to remove the static declaration. Ok, I understand the need for this patch in this series. Please fix up the commit header and message. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i350 Ethernet Driver
+Joe On Mon, Oct 23, 2017 at 1:12 PM, Frank-Christian Krügel wrote: > Hi, > > is there an U-Boot driver for the Intel i350 Ethernet Chip? Has anybody > patched the e1000 driver to also work with i350? > No, AFAIK. Regards, Bin ___ 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 10/19/2017 10:43 AM, 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. > > Peter > Debian uses package flash-kernel by default. Flash-kernel generates a new boot.scr script every time you install a new kernel. Packages grub-efi-arm and grub-efi-arm64 are provided for those who prefer to boot their ARM board via EFI. All sunxi boards use SPL=y. So why should there be a size limit crossed? Is there an unsuitable limit built in to the second stage boot loader? Then this should be fixed instead of castrating the configuration. Heinrich >> Signed-off-by: Maxime Ripard >> --- >> lib/efi_loader/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >> index d2b6327119b4..a80a914b2fe8 100644 >> --- a/lib/efi_loader/Kconfig >> +++ b/lib/efi_loader/Kconfig >> @@ -1,7 +1,7 @@ >> config EFI_LOADER >> bool "Support running EFI Applications in U-Boot" >> depends on (ARM || X86) && OF_LIBFDT >> - default y >> + default y if !ARCH_SUNXI >> help >> Select this option if you want to run EFI applications (like grub2) >> on top of U-Boot. If this option is enabled, U-Boot will expose EFI >> -- >> 2.14.2 >> >> ___ >> 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 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 20.10.2017 15:34, Jaehoon Chung wrote:
> 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");
>> +
[U-Boot] JFFS2 for a new User
Hello: I've downloaded and compiled U-boot with buildroot for AT91sam9x35ek using NANDFlash, and managed to get into console (after kernel load) with an *.ubi RFS; but Im working in a project that has a RFS in jffs2 format(old project started at 2011, RFS produced by Tool only in that format with custom libraries i can't touch), basically i must use jffs2. I am trying to make kernel linux4sam_5.6 boot into the same RFS but jffs2 format(also compiled by buildroot), this RFS is for testing, an empty skeleton. I tried changing bootargs several times copying from different websites but I'm failing. Can you please help me hoy can i modify these BOOTARGS for them to work with *.jffs2 NandFlash for AT91sam9x35. Before you ask, i have read U-boot manuals commands, how mtdparts works, i cant find how to address my root="" boot arg clear enough to understand it. I'll paste the ubi bootargs so you can explain me how to change them for jffs2. #define CONFIG_BOOTARGS\ "console=ttyS0,115200 earlyprintk "\ "mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro,"\ "256k(env),256k(env_redundant),256k(spare),"\ "512k(dtb),6M(kernel)ro,-(rootfs) "\ "rootfstype=ubifs ubi.mtd=7 root=ubi0:rootfs rw" #endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree
On Thu, 2017-10-19 at 13:20 -0500, Dinh Nguyen wrote: > > On 10/19/2017 10:51 AM, Marek Vasut wrote: > > On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote: > > > On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote: > > > > On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin > > > > wrote: > > > > > Hi Jagan, > > > > > > > > > > > -Original Message- > > > > > > From: Eugeniy Paltsev [mailto:palt...@synopsys.com] > > > > > > Sent: Tuesday, October 17, 2017 4:33 PM > > > > > > To: jagannadh.t...@gmail.com > > > > > > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com > > > > > > Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value > > > > > > from Device Tree > > > > > > > > > > > > > > How hard it is to make others to use clock manager? do you have > > > > > > > any list? > > > > > > > > > > > > clock_manager.h is an old (and non-generic) way to deal with > > > > > > different clocks. > > > > > > For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h > > > > > > provides > > > > > > cm_get_spi_controller_clk_hz function to deal with spi controller > > > > > > clock. > > > > > > > > > > > > But today we have another, linux-like alternative: to bind clocks > > > > > > via device tree > > > > > > and manipulate with clocks via generic functions provided by clk.h > > > > > > > > > > > > In this patch I added option to get clock via device tree using > > > > > > standard bindings > > > > > > and restrict clock_manager.h functions usage only to targets which > > > > > > still use it, > > > > > > so new targets can simply bind clock via device tree and they do > > > > > > not need to > > > > > > implement/define something in clock_manager.h > > > > > > > > > > > > So we don't need to make others to use clock manager :) > > > > > > > > > > Maybe it worth trying the other way around and think about switching > > > > > SOCFPGA platforms to > > > > > generic clk framework? > > > > > > > > Yes, ie what exactly I thought of, thanks! > > > > > > I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and > > > SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as > > > it > > > manipulate with real hardware. > > > The only way to do it is to replace SOCFPGA* clock manager functions by > > > real > > > clock driver. > > > > > > And given I don't have mentioned hardware so I barely can help with > > > those improvements on SOCFPGA. That said if there're no short-term plans > > > to > > > switch SOCFPGA to clk framework maybe we'll be OK with my workaround with > > > #ifdefs? > > > > Wait for Dinh's reply ... > > > > Honestly, I don't have too much time to work on this right now. So I > really don't when it can get done. But it'll go on my to-do list. > > Dinh Yep, thanks for your comments. So, Jagan, given Dinh's reply, could you please apply this patch? Thanks. -- Eugeniy Paltsev ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] thermal: ti-bandgap: Add support for temperature sensor
On Mon, Oct 23, 2017 at 10:50:15AM +0530, Faiz Abbas wrote: > Hi Tom, > > On Monday 23 October 2017 08:30 AM, Tom Rini wrote: > > On Mon, Oct 23, 2017 at 08:07:09AM +0530, Lokesh Vutla wrote: > >> On Wednesday 18 October 2017 05:11 PM, Faiz Abbas wrote: > >>> The dra7xx series of SOCs contain a temperature sensor and an > >>> associated analog-to-digital converter (ADC) which produces > >>> an output which is proportional to the SOC temperature. > >>> Add support for this temperature sensor. > >>> > >>> Signed-off-by: Faiz Abbas > >>> Reviewed-by: Simon Glass > >>> --- > >>> v3: > >>> Added Reviewed-by comment > >>> > >>> v2: > >>> 1. Removed extra elements from ti_bandgap > >>> 2. Changed base address to ulong > >>> 3. Changed to udev to dev to maintain consistency > >>> 4. minor format changes > >>> > >>> common/spl/Kconfig | 8 + > >>> configs/dra7xx_evm_defconfig | 3 + > >>> .../thermal/ti_soc_thermal.txt | 35 > >>> drivers/Makefile | 2 +- > >>> drivers/thermal/Kconfig| 6 + > >>> drivers/thermal/Makefile | 1 + > >>> drivers/thermal/ti-bandgap.c | 197 > >>> + > >>> 7 files changed, 251 insertions(+), 1 deletion(-) > >>> create mode 100644 doc/device-tree-bindings/thermal/ti_soc_thermal.txt > >>> create mode 100644 drivers/thermal/ti-bandgap.c > >>> > >>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig > >>> index 0bd8370..0bf3ee3 100644 > >>> --- a/common/spl/Kconfig > >>> +++ b/common/spl/Kconfig > >>> @@ -604,6 +604,14 @@ config SPL_SPI_SUPPORT > >>> enable SPI drivers that are needed for other purposes also, such > >>> as a SPI PMIC. > >>> > >>> +config SPL_THERMAL > >>> + bool "Driver support for thermal devices" > >>> + help > >>> + Enable support for temperature-sensing devices. Some SoCs have on-chip > >>> + temperature sensors to permit warnings, speed throttling or even > >>> + automatic power-off when the temperature gets too high or low. Other > >>> + devices may be discrete but connected on a suitable bus. > >>> + > >>> config SPL_USB_HOST_SUPPORT > >>> bool "Support USB host drivers" > >>> help > >>> diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig > >>> index 468c288..447fb89 100644 > >>> --- a/configs/dra7xx_evm_defconfig > >>> +++ b/configs/dra7xx_evm_defconfig > >>> @@ -90,3 +90,6 @@ CONFIG_USB_GADGET=y > >>> CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > >>> CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > >>> CONFIG_USB_GADGET_PRODUCT_NUM=0xd022 > >>> +CONFIG_SPL_THERMAL=y > >>> +CONFIG_DM_THERMAL=y > >>> +CONFIG_TI_DRA7_THERMAL=y > >> > >> Tom, > >>Do you want these options to be implied so that it will take effect for > >> HS board as well. Or enable it in defconfig as is? > > > > How important is it that this be enabled? Is this 100% within the SoC? > > Thanks! > > > > There is an upcoming errata which requires temperature support to > workaround. This errata will apply to the HS boards as well. Will send a > new patch with imply added to TARGET_DRA7XX_EVM for these configs. Well, can you _not_ have this support enabled, on the dra7xx family? If it must be always there, please select it. Otherwise imply is OK. Thanks! -- 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] ZynqMP qspi
Hi Liam, > -Original Message- > From: Liam Beguin [mailto:liambeg...@gmail.com] > Sent: Saturday, October 21, 2017 11:33 PM > To: Siva Durga Prasad Paladugu ; Jagan Teki > > Cc: u-boot@lists.denx.de; Michal Simek > Subject: Re: [U-Boot] ZynqMP qspi > > Hi Siva, > > On 26/09/17 01:28 AM, Siva Durga Prasad Paladugu wrote: > > Hi, > > > ... > > > > I am planning to send the new series in 1-2 weeks, probably you can > > wait till then or you can try with the patch[2] and see if you are > > able to get it working with those( those are known to be working when > > I sent ). Also, please note that as of now iam targeting only for qspi > > single > mode not the dual modes. > > I was wondering if you had a chance to work on this in the last few weeks. I > initially planned on re-sending your series but I don't currently have the > hardware to test on. Sorry for the delay, I am already working on it, need to cleanup and test it. I will send the series in a day. Regards, Siva > > > > > Thanks, > > Siva > > > Thanks, > Liam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] i350 Ethernet Driver
Hi, is there an U-Boot driver for the Intel i350 Ethernet Chip? Has anybody patched the e1000 driver to also work with i350? Best Regards Frank-Christian Kruegel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-boot][SDP] Trigger watchdog before calling usb_gadget_handle_interrupts
This prevents board resets when calling sdp command on boards which have a
watchdog.
Signed-off-by: Vincent Prince
---
drivers/usb/gadget/f_sdp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index 0fae66b..c3eba6d 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#define HID_REPORT_ID_MASK 0x00ff
@@ -602,6 +603,8 @@ int sdp_init(int controller_index)
puts("\rCTRL+C - Operation aborted.\n");
return 1;
}
+
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
}
@@ -712,6 +715,7 @@ void sdp_handle(int controller_index)
return;
}
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
sdp_handle_in_ep();
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-boot][SDP] Trigger watchdog before calling usb_gadget_handle_interrupts
This prevents board resets when calling sdp command on boards which have a
watchdog.
Signed-off-by: Vincent Prince
---
drivers/usb/gadget/f_sdp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index 0fae66b..c3eba6d 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#define HID_REPORT_ID_MASK 0x00ff
@@ -602,6 +603,8 @@ int sdp_init(int controller_index)
puts("\rCTRL+C - Operation aborted.\n");
return 1;
}
+
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
}
@@ -712,6 +715,7 @@ void sdp_handle(int controller_index)
return;
}
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
sdp_handle_in_ep();
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] mmc: arm_pl180_mmci: add .getcd callback
From: Patrice Chotard
Add .getcd callback to check is MMC card is present
Signed-off-by: Patrice Chotard
---
drivers/mmc/arm_pl180_mmci.c | 24 ++--
drivers/mmc/arm_pl180_mmci.h | 4
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 3de6b12..89a7c19 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -18,9 +18,10 @@
#include
#include
-#include "arm_pl180_mmci.h"
-
#include
+#include
+
+#include "arm_pl180_mmci.h"
#ifdef CONFIG_DM_MMC
#include
@@ -435,6 +436,8 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
MMC_CLOCK_MAX);
host->version2 = dev_get_driver_data(dev);
+ gpio_request_by_name(dev, "cd-gpios", 0, &host->cd_gpio, GPIOD_IS_IN);
+
bus_width = dev_read_u32_default(dev, "bus-width", 1);
switch (bus_width) {
case 8:
@@ -477,9 +480,26 @@ static int dm_host_set_ios(struct udevice *dev)
return host_set_ios(mmc);
}
+static int dm_mmc_getcd(struct udevice *dev)
+{
+ struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
+ struct mmc *mmc = &pdata->mmc;
+ struct pl180_mmc_host *host = mmc->priv;
+ int value = 1;
+
+ if (dm_gpio_is_valid(&host->cd_gpio)) {
+ value = dm_gpio_get_value(&host->cd_gpio);
+ if (host->cd_inverted)
+ return !value;
+ }
+
+ return value;
+}
+
static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
.send_cmd = dm_host_request,
.set_ios = dm_host_set_ios,
+ .get_cd = dm_mmc_getcd,
};
static int arm_pl180_mmc_ofdata_to_platdata(struct udevice *dev)
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index b935288..9df4b75 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -191,6 +191,10 @@ struct pl180_mmc_host {
unsigned int pwr_init;
int version2;
struct mmc_config cfg;
+#ifdef CONFIG_DM_MMC
+ struct gpio_desc cd_gpio;
+ bool cd_inverted;
+#endif
};
int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] mmc: arm_pl180_mmci: add bus_width DT property support
From: Patrice Chotard
Allow to get "bus-width" property from device tree
Signed-off-by: Patrice Chotard
---
v2: _ remove useless return in bus_width switch case
drivers/mmc/arm_pl180_mmci.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index b3c1f0d..fd57b55 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -408,6 +408,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");
@@ -421,6 +422,21 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
host->clock_max = dev_read_u32_default(dev, "max-frequency",
MMC_CLOCK_MAX);
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);
+ }
+
ret = arm_pl180_mmci_init(host, &mmc);
if (ret) {
dev_err(dev, "arm_pl180_mmci init failed\n");
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] mmc: arm_pl180_mmci: add clock support
From: Patrice Chotard
Allow to get and enable MMC related clock
Signed-off-by: Patrice Chotard
---
drivers/mmc/arm_pl180_mmci.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index fd57b55..3de6b12 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -13,6 +13,7 @@
/* #define DEBUG */
#include "common.h"
+#include
#include
#include
#include
@@ -408,17 +409,28 @@ 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;
+ struct clk clk;
u32 bus_width;
int ret;
+ ret = clk_get_by_index(dev, 0, &clk);
+ if (ret < 0)
+ return ret;
+
+ ret = clk_enable(&clk);
+ if (ret) {
+ dev_err(dev, "failed to enable clock\n");
+ return 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 = MMC_CLOCK_MAX;
- host->clock_min = MMC_CLOCK_MIN;
+ host->clock_in = clk_get_rate(&clk);
+ host->clock_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
host->clock_max = dev_read_u32_default(dev, "max-frequency",
MMC_CLOCK_MAX);
host->version2 = dev_get_driver_data(dev);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] mmc: arm_pl180_mmci: update arm_pl180_mmci_init() prototype
From: Patrice Chotard
Update arm_pl180_mmci_init() prototype by adding struct mmc**
param. This is needed before converting this driver to driver model
in order to use arm_pl180_mmci_init() in driver model and in none
driver model implementation
Signed-off-by: Patrice Chotard
---
board/armltd/vexpress/vexpress_common.c | 3 ++-
drivers/mmc/arm_pl180_mmci.c| 10 +-
drivers/mmc/arm_pl180_mmci.h| 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/board/armltd/vexpress/vexpress_common.c
b/board/armltd/vexpress/vexpress_common.c
index 89ab8f7..37b8d7f 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -76,6 +76,7 @@ int cpu_mmc_init(bd_t *bis)
(void) bis;
#ifdef CONFIG_ARM_PL180_MMCI
struct pl180_mmc_host *host;
+ struct mmc *mmc;
host = malloc(sizeof(struct pl180_mmc_host));
if (!host)
@@ -91,7 +92,7 @@ int cpu_mmc_init(bd_t *bis)
host->clock_in = ARM_MCLK;
host->clock_min = ARM_MCLK / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
host->clock_max = CONFIG_ARM_PL180_MMCI_CLOCK_FREQ;
- rc = arm_pl180_mmci_init(host);
+ rc = arm_pl180_mmci_init(host, &mmc);
#endif
return rc;
}
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index ddf8383..7898b0d 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -348,9 +348,8 @@ static const struct mmc_ops arm_pl180_mmci_ops = {
* Set initial clock and power for mmc slot.
* Initialize mmc struct and register with mmc framework.
*/
-int arm_pl180_mmci_init(struct pl180_mmc_host *host)
+int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc)
{
- struct mmc *mmc;
u32 sdi_u32;
writel(host->pwr_init, &host->base->power);
@@ -373,11 +372,12 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host)
else
host->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
- mmc = mmc_create(&host->cfg, host);
- if (mmc == NULL)
+ *mmc = mmc_create(&host->cfg, host);
+ if (!*mmc)
return -1;
- debug("registered mmc interface number is:%d\n", mmc->block_dev.devnum);
+ debug("registered mmc interface number is:%d\n",
+ (*mmc)->block_dev.devnum);
return 0;
}
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index f23bd39..6e232f7 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -190,6 +190,6 @@ struct pl180_mmc_host {
struct mmc_config cfg;
};
-int arm_pl180_mmci_init(struct pl180_mmc_host *);
+int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc);
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] mmc: arm_pl180_mmci: adapt driver to DM usage
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
---
v2: _ add defines for clock min and max value
drivers/mmc/Kconfig | 9 +++
drivers/mmc/arm_pl180_mmci.c | 129 +++
drivers/mmc/arm_pl180_mmci.h | 3 +
3 files changed, 129 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..b3c1f0d 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -12,12 +12,27 @@
/* #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;
+
+#define MMC_CLOCK_MAX 4800
+#define MMC_CLOCK_MIN 40
+
+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 +280,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 +342,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 +378,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 +400,89 @@ 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 = MMC_CLOCK_MAX;
+ host->clock_min = MMC_CLOCK_MIN;
+ host->clock_max = dev_read_u32_default(dev, "max-frequency",
+ MMC_CLOCK_MAX);
+ 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_host_request,
+ .set_ios = dm_host_set_ios,
+};
+
+static int arm_pl180_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+ struct arm_pl180_mmc_plat *pdata =
[U-Boot] [PATCH v2 0/5] Extend ARM_PL180_MMCI
From: Patrice Chotard Currently this driver is used by VEXPRESS platform which doesn't support Driver Model. ARM_PL180_MMCI IP is embedded on STM32F4 and F7 platforms. In order to add SD support on these 2 STM32 family SoCs, the following reworks are needed: _ update arm_pl180_mmci_init() prototype to make this driver working with DM and none DM platforms _ addapt driver to driver model _ add bus_width device tree support _ add clock support _ add .get_cd callback support This series has been tested internally on both STM32F4 and STM32F7 SoCs family. Future SD support for these 2 platforms will be added soon. v2: _ add defines for clock min and max value in patch 2 _ remove useless return in bus_width switch case in patch 3 Patrice Chotard (5): mmc: arm_pl180_mmci: update arm_pl180_mmci_init() prototype mmc: arm_pl180_mmci: adapt driver to DM usage mmc: arm_pl180_mmci: add bus_width DT property support mmc: arm_pl180_mmci: add clock support mmc: arm_pl180_mmci: add .getcd callback board/armltd/vexpress/vexpress_common.c | 3 +- drivers/mmc/Kconfig | 9 ++ drivers/mmc/arm_pl180_mmci.c| 187 +--- drivers/mmc/arm_pl180_mmci.h| 9 +- 4 files changed, 189 insertions(+), 19 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] mmc: arm_pl180_mmci: add bus_width DT property support
Hi Jaehoon
On 10/20/2017 03:44 PM, Jaehoon Chung wrote:
> 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.
Right, i will remove the return here.
Thanks
Patrice
>
>> +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
Re: [U-Boot] [PATCH v3 18/20] arm: socfpga: Enable function visible to other file
On Jum, 2017-10-20 at 09:39 -0500, Dinh Nguyen wrote: > > 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. > This patch is required by later patches, so this patch can't be separated out. This function is static declaration, but this function is required by the caller from other file(later patches). So, this patch is to remove ths static declaration so it is accessible by the caller from other file. > 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 Jum, 2017-10-20 at 09:33 -0500, Dinh Nguyen wrote: > > 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 > Okay. > > > > > > 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? > Initially, this is only created for SPL. Until U-Boot enable development phase, i realized this also required by U-boot. So i duplicated socfpga_fpga_add in both SPL(spl.c - below) and U- Boot(board.c - above). > > > > 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? > Refer to my comment above. > Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] mmc: arm_pl180_mmci: adapt driver to DM usage
Hi Jaehoon
On 10/20/2017 03:44 PM, Jaehoon Chung wrote:
> 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.
OK
>
>> +host->clock_min = 40;
>
> Ditto.
OK
>
>> +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 d
Re: [U-Boot] [PATCH v3 16/20] arm: socfpga: Adding clock frequency info for U-boot
On Jum, 2017-10-20 at 09:29 -0500, Dinh Nguyen wrote: > > 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". > Both SPL and U-Boot need to know the clock freq info. SPL already has one, and this patch is for creating the clock freq info for 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? > I believe can remove mish.h . I will verify again. > > > > #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. > SPL has one. This is for U-Boot. Clock freq info which is stored in SPL memory will gone after moving to U-Boot. > Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/3] ARM: dts: OMAP5+: Add support for bandgap sensor in SPL
Mark bandgap node as uboot,dm-spl so that it can be accessed in spl
Signed-off-by: Faiz Abbas
Reviewed-by: Simon Glass
---
v3:
Added Reviewed-by comment.
arch/arm/dts/omap5-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/omap5-u-boot.dtsi b/arch/arm/dts/omap5-u-boot.dtsi
index fdaa692..bf2684c 100644
--- a/arch/arm/dts/omap5-u-boot.dtsi
+++ b/arch/arm/dts/omap5-u-boot.dtsi
@@ -18,6 +18,10 @@
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp", "simple-bus";
};
+
+ bandgap@4a0021e0 {
+ u-boot,dm-spl;
+ };
};
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/3] ARM: dra7: Kconfig: Add thermal configs for dra7xx and am57xx
Configure thermal configs to remain set by default for dra7xx and am57xx targets. Signed-off-by: Faiz Abbas --- arch/arm/mach-omap2/omap5/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-omap2/omap5/Kconfig b/arch/arm/mach-omap2/omap5/Kconfig index 8f58235..8c1730a 100644 --- a/arch/arm/mach-omap2/omap5/Kconfig +++ b/arch/arm/mach-omap2/omap5/Kconfig @@ -30,6 +30,9 @@ config TARGET_DRA7XX_EVM imply PMIC_LP87565 imply DM_REGULATOR imply DM_REGULATOR_LP87565 + imply SPL_THERMAL + imply DM_THERMAL + imply TI_DRA7_THERMAL config TARGET_AM57XX_EVM bool "AM57XX" @@ -37,6 +40,9 @@ config TARGET_AM57XX_EVM select DRA7XX select TI_I2C_BOARD_DETECT imply SCSI + imply SPL_THERMAL + imply DM_THERMAL + imply TI_DRA7_THERMAL endchoice -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/3] Support for TI bandgap temperature sensor
Adding support for TI bandgap temperature sensor. Also add dt support for bandgap sensor in spl. v4: 1. Added configs enabled by default in dra7xx and am57xx SOCs 2. Split config enabling in a separate commit v3: Missed adding Reviewed-by in v2. Faiz Abbas (3): thermal: ti-bandgap: Add support for temperature sensor ARM: dts: OMAP5+: Add support for bandgap sensor in SPL arm: Kconfig: Add thermal config options for dra7xx and am57xx arch/arm/dts/omap5-u-boot.dtsi | 4 + arch/arm/mach-omap2/omap5/Kconfig | 6 + common/spl/Kconfig | 8 + configs/am57xx_evm_defconfig | 3 + configs/dra7xx_evm_defconfig | 3 + .../thermal/ti_soc_thermal.txt | 35 drivers/Makefile | 2 +- drivers/thermal/Kconfig| 6 + drivers/thermal/Makefile | 1 + drivers/thermal/ti-bandgap.c | 197 + 10 files changed, 264 insertions(+), 1 deletion(-) create mode 100644 doc/device-tree-bindings/thermal/ti_soc_thermal.txt create mode 100644 drivers/thermal/ti-bandgap.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] thermal: ti-bandgap: Add support for temperature sensor
The dra7xx series of SOCs contain a temperature sensor and an
associated analog-to-digital converter (ADC) which produces
an output which is proportional to the SOC temperature.
Add support for this temperature sensor.
Signed-off-by: Faiz Abbas
Reviewed-by: Simon Glass
---
v3:
Added Reviewed-by comment
v2:
1. Removed extra elements from ti_bandgap
2. Changed base address to ulong
3. Changed to udev to dev to maintain consistency
4. minor format changes
common/spl/Kconfig | 8 +
.../thermal/ti_soc_thermal.txt | 35
drivers/Makefile | 2 +-
drivers/thermal/Kconfig| 6 +
drivers/thermal/Makefile | 1 +
drivers/thermal/ti-bandgap.c | 197 +
6 files changed, 248 insertions(+), 1 deletion(-)
create mode 100644 doc/device-tree-bindings/thermal/ti_soc_thermal.txt
create mode 100644 drivers/thermal/ti-bandgap.c
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0bd8370..0bf3ee3 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -604,6 +604,14 @@ config SPL_SPI_SUPPORT
enable SPI drivers that are needed for other purposes also, such
as a SPI PMIC.
+config SPL_THERMAL
+ bool "Driver support for thermal devices"
+ help
+ Enable support for temperature-sensing devices. Some SoCs have on-chip
+ temperature sensors to permit warnings, speed throttling or even
+ automatic power-off when the temperature gets too high or low. Other
+ devices may be discrete but connected on a suitable bus.
+
config SPL_USB_HOST_SUPPORT
bool "Support USB host drivers"
help
diff --git a/doc/device-tree-bindings/thermal/ti_soc_thermal.txt
b/doc/device-tree-bindings/thermal/ti_soc_thermal.txt
new file mode 100644
index 000..b4e88c2
--- /dev/null
+++ b/doc/device-tree-bindings/thermal/ti_soc_thermal.txt
@@ -0,0 +1,35 @@
+* Texas Instrument dra7xx SCM bandgap bindings
+
+In the System Control Module, SoC supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+
+Required properties:
+- compatible : Should be:
+ - "ti,dra752-bandgap"
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+- regs : this is specific to each bandgap version, because
+the mapping may change from soc to soc, apart from depending
+on available features.
+
+Optional:
+- gpios : this entry should be used to inform which GPIO
+line the tshut signal is routed to. The informed GPIO will
+be treated as an IRQ;
+
+Example:
+bandgap {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c
+ 0x4a002564 0x8
+ 0x4a002574 0x50>;
+ compatible = "ti,dra752-bandgap";
+ interrupts = <0 126 4>; /* talert */
+};
diff --git a/drivers/Makefile b/drivers/Makefile
index dab5c18..35510ca 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,7 +50,7 @@ obj-$(CONFIG_SPL_SATA_SUPPORT) += ata/ scsi/
obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
obj-$(CONFIG_SPL_FPGA_SUPPORT) += fpga/
-
+obj-$(CONFIG_SPL_THERMAL) += thermal/
endif
endif
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 886f5fa..a71b9be 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -17,4 +17,10 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config TI_DRA7_THERMAL
+bool "Temperature sensor driver for TI dra7xx SOCs"
+help
+Enable thermal support for for the Texas Instruments DRA752 SoC family.
+The driver supports reading CPU temperature.
+
endif # if DM_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index d768f5e..f6271a5 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,3 +7,4 @@
obj-$(CONFIG_DM_THERMAL) += thermal-uclass.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_TI_DRA7_THERMAL) += ti-bandgap.o
diff --git a/drivers/thermal/ti-bandgap.c b/drivers/thermal/ti-bandgap.c
new file mode 100644
index 000..6db9f54
--- /dev/null
+++ b/drivers/thermal/ti-bandgap.c
@@ -0,0 +1,197 @@
+/*
+ * TI Bandgap temperature sensor driver
+ *
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation vers
[U-Boot] [PATCH 5/5] tpm: st33zp24: fix STMicroelectronics copyright
From: Patrice Chotard Uniformize STMicroelectronics copyrights header Signed-off-by: Patrice Chotard --- drivers/tpm/tpm_tis_st33zp24_i2c.c | 3 ++- drivers/tpm/tpm_tis_st33zp24_spi.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/tpm/tpm_tis_st33zp24_i2c.c b/drivers/tpm/tpm_tis_st33zp24_i2c.c index 9e4829f..c8d0125 100644 --- a/drivers/tpm/tpm_tis_st33zp24_i2c.c +++ b/drivers/tpm/tpm_tis_st33zp24_i2c.c @@ -1,7 +1,8 @@ /* * STMicroelectronics TPM ST33ZP24 I2C UBOOT driver * - * Copyright (C) 2016 STMicroelectronics + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved + * Author(s): Christophe Ricard for STMicroelectronics. * * Description: Device driver for ST33ZP24 I2C TPM TCG. * diff --git a/drivers/tpm/tpm_tis_st33zp24_spi.c b/drivers/tpm/tpm_tis_st33zp24_spi.c index 417bbf1..dcf55ee 100644 --- a/drivers/tpm/tpm_tis_st33zp24_spi.c +++ b/drivers/tpm/tpm_tis_st33zp24_spi.c @@ -1,7 +1,8 @@ /* * STMicroelectronics TPM ST33ZP24 SPI UBOOT driver * - * Copyright (C) 2016 STMicroelectronics + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved + * Author(s): Christophe Ricard for STMicroelectronics. * * Description: Device driver for ST33ZP24 SPI TPM TCG. * -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/5] stm32: fix STMicroelectronics copyright
From: Patrice Chotard Uniformize STMicroelectronics copyrights headers for STM32 related code. Signed-off-by: Patrice Chotard --- arch/arm/cpu/armv7/stv0991/pinmux.c | 4 ++-- arch/arm/cpu/armv7m/cache.c | 4 ++-- arch/arm/cpu/armv7m/mpu.c| 4 ++-- arch/arm/include/asm/arch-stm32f4/stm32_defs.h | 4 ++-- arch/arm/include/asm/arch-stm32f4/stm32_periph.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/gpio.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/gpt.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/rcc.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/stm32.h| 4 ++-- arch/arm/include/asm/arch-stm32f7/stm32_defs.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 4 ++-- arch/arm/include/asm/arch-stm32h7/gpio.h | 4 ++-- arch/arm/include/asm/arch-stm32h7/stm32.h| 4 ++-- arch/arm/include/asm/armv7m_mpu.h| 4 ++-- arch/arm/mach-stm32/stm32f7/Makefile | 4 ++-- arch/arm/mach-stm32/stm32f7/timer.c | 4 ++-- arch/arm/mach-stm32/stm32h7/Makefile | 4 ++-- arch/arm/mach-stm32/stm32h7/soc.c| 4 ++-- board/st/stm32f746-disco/Makefile| 4 ++-- board/st/stm32f746-disco/stm32f746-disco.c | 4 ++-- board/st/stm32h743-disco/Makefile| 4 ++-- board/st/stm32h743-disco/stm32h743-disco.c | 4 ++-- board/st/stm32h743-eval/Makefile | 4 ++-- board/st/stm32h743-eval/stm32h743-eval.c | 4 ++-- common/spl/spl_xip.c | 3 ++- drivers/clk/clk_stm32f7.c| 5 +++-- drivers/clk/clk_stm32h7.c| 4 ++-- drivers/gpio/stm32f7_gpio.c | 4 ++-- drivers/misc/stm32_rcc.c | 4 ++-- drivers/mmc/stm32_sdmmc2.c | 4 ++-- drivers/ram/stm32_sdram.c| 4 ++-- drivers/reset/stm32-reset.c | 4 ++-- drivers/serial/serial_stm32x7.c | 4 ++-- drivers/serial/serial_stm32x7.h | 4 ++-- include/configs/stm32f746-disco.h| 4 ++-- include/configs/stm32h743-disco.h| 4 ++-- include/configs/stm32h743-eval.h | 4 ++-- 37 files changed, 75 insertions(+), 73 deletions(-) diff --git a/arch/arm/cpu/armv7/stv0991/pinmux.c b/arch/arm/cpu/armv7/stv0991/pinmux.c index 24c67fa..9edc1b2 100644 --- a/arch/arm/cpu/armv7/stv0991/pinmux.c +++ b/arch/arm/cpu/armv7/stv0991/pinmux.c @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/cpu/armv7m/cache.c b/arch/arm/cpu/armv7m/cache.c index e8f8642..a46d4b5 100644 --- a/arch/arm/cpu/armv7m/cache.c +++ b/arch/arm/cpu/armv7m/cache.c @@ -1,6 +1,6 @@ /* - * (C) Copyright 2017 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/cpu/armv7m/mpu.c b/arch/arm/cpu/armv7m/mpu.c index 4622aa4..8e92a33 100644 --- a/arch/arm/cpu/armv7m/mpu.c +++ b/arch/arm/cpu/armv7m/mpu.c @@ -1,6 +1,6 @@ /* - * (C) Copyright 2017 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stm32f4/stm32_defs.h b/arch/arm/include/asm/arch-stm32f4/stm32_defs.h index 29b98ae..9a967ac 100644 --- a/arch/arm/include/asm/arch-stm32f4/stm32_defs.h +++ b/arch/arm/include/asm/arch-stm32f4/stm32_defs.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2016 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stm32f4/stm32_periph.h b/arch/arm/include/asm/arch-stm32f4/stm32_periph.h index 38adc4e..fa45a5c 100644 --- a/arch/arm/include/asm/arch-stm32f4/stm32_periph.h +++ b/arch/arm/include/asm/arch-stm32f4/stm32_periph.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2016 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stm32f7/gpio.h b/arch/arm/include/asm/arch-stm32f7/gpio.h index 56e469e..68ecdc8 100644 --- a/arch/arm/include/asm/arch-stm32f7/gpio.h +++ b/arch/arm/include/asm/arch-stm32f7/gpio.h @@ -
[U-Boot] [PATCH 4/5] spear: fix STMicroelectronics copyright
From: Patrice Chotard Uniformize STMicroelectronics copyrights headers for SPEAR related code. Signed-off-by: Patrice Chotard --- arch/arm/include/asm/arch-spear/clk.h | 4 ++-- arch/arm/include/asm/arch-spear/hardware.h | 4 ++-- include/configs/x600.h | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/arch-spear/clk.h b/arch/arm/include/asm/arch-spear/clk.h index a07d0d5..5c16524 100644 --- a/arch/arm/include/asm/arch-spear/clk.h +++ b/arch/arm/include/asm/arch-spear/clk.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2010 - * Vipin Kumar, STMicroelectronics, + * Copyright (C) 2010, STMicroelectronics - All Rights Reserved + * Author(s): Vipin Kumar, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-spear/hardware.h b/arch/arm/include/asm/arch-spear/hardware.h index 065360a..14b7be4 100644 --- a/arch/arm/include/asm/arch-spear/hardware.h +++ b/arch/arm/include/asm/arch-spear/hardware.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2009 - * Vipin Kumar, STMicroelectronics, + * Copyright (C) 2009, STMicroelectronics - All Rights Reserved + * Author(s): Vipin Kumar, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/include/configs/x600.h b/include/configs/x600.h index dc8ec36..48e8cfe 100644 --- a/include/configs/x600.h +++ b/include/configs/x600.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2009 - * Vipin Kumar, STMicroelectronics, + * Copyright (C) 2009, STMicroelectronics - All Rights Reserved + * Author(s): Vipin Kumar, for STMicroelectronics. * * Copyright (C) 2012, 2015 Stefan Roese * -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] stv0991: fix STMicroelectronics copyright
From: Patrice Chotard Uniformize STMicroelectronics copyrights headers for STV0991 related code. Signed-off-by: Patrice Chotard --- arch/arm/cpu/armv7/stv0991/Makefile| 4 ++-- arch/arm/cpu/armv7/stv0991/clock.c | 4 ++-- arch/arm/cpu/armv7/stv0991/reset.c | 4 ++-- arch/arm/cpu/armv7/stv0991/timer.c | 4 ++-- arch/arm/include/asm/arch-stv0991/gpio.h | 4 ++-- arch/arm/include/asm/arch-stv0991/hardware.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_creg.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_defs.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_gpt.h| 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_periph.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_wdru.h | 4 ++-- board/st/stv0991/Makefile | 4 ++-- board/st/stv0991/stv0991.c | 4 ++-- include/configs/stv0991.h | 4 ++-- 15 files changed, 30 insertions(+), 30 deletions(-) diff --git a/arch/arm/cpu/armv7/stv0991/Makefile b/arch/arm/cpu/armv7/stv0991/Makefile index 95641d3..046b240 100644 --- a/arch/arm/cpu/armv7/stv0991/Makefile +++ b/arch/arm/cpu/armv7/stv0991/Makefile @@ -1,6 +1,6 @@ # -# (C) Copyright 2014 -# Vikas Manocha, ST Microelectronics, vikas.manocha@stcom +# Copyright (C) 2014, STMicroelectronics - All Rights Reserved +# Author(s): Vikas Manocha, for STMicroelectronics. # # SPDX-License-Identifier: GPL-2.0+ # diff --git a/arch/arm/cpu/armv7/stv0991/clock.c b/arch/arm/cpu/armv7/stv0991/clock.c index 26c0d36..c54168e 100644 --- a/arch/arm/cpu/armv7/stv0991/clock.c +++ b/arch/arm/cpu/armv7/stv0991/clock.c @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/cpu/armv7/stv0991/reset.c b/arch/arm/cpu/armv7/stv0991/reset.c index 3384b32..68939a2 100644 --- a/arch/arm/cpu/armv7/stv0991/reset.c +++ b/arch/arm/cpu/armv7/stv0991/reset.c @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/cpu/armv7/stv0991/timer.c b/arch/arm/cpu/armv7/stv0991/timer.c index 8654b8b..bd3401a 100644 --- a/arch/arm/cpu/armv7/stv0991/timer.c +++ b/arch/arm/cpu/armv7/stv0991/timer.c @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stv0991/gpio.h b/arch/arm/include/asm/arch-stv0991/gpio.h index 9131ded..f66fa60 100644 --- a/arch/arm/include/asm/arch-stv0991/gpio.h +++ b/arch/arm/include/asm/arch-stv0991/gpio.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stv0991/hardware.h b/arch/arm/include/asm/arch-stv0991/hardware.h index 3f6bcaf..13b682d 100644 --- a/arch/arm/include/asm/arch-stv0991/hardware.h +++ b/arch/arm/include/asm/arch-stv0991/hardware.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, STMicroelectronics, + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h b/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h index f0045f3..45f3c90 100644 --- a/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h +++ b/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stv0991/stv0991_creg.h b/arch/arm/include/asm/arch-stv0991/stv0991_creg.h index 737c952..2c279b1 100644 --- a/arch/arm/include/asm/arch-stv0991/stv0991_creg.h +++ b/arch/arm/include/asm/arch-stv0991/stv0991_creg.h @@ -1,6 +1,6 @@ /* - * (C) Copyright 2014 - * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com + * Copyright (C) 2014, STMicroelectronics - All Rights Reserved + * Author(s): Vikas Manocha, for STMicroelectronics. * * SPDX-License-Iden
[U-Boot] [PATCH 1/5] sti: fix STMicroelectronics copyright
From: Patrice Chotard Uniformize all STMicroelectronics copyrights headers for STi related code. Signed-off-by: Patrice Chotard --- arch/arm/include/asm/arch-stih410/sdhci.h | 3 ++- arch/arm/include/asm/arch-stih410/sys_proto.h | 4 ++-- board/st/stih410-b2260/Makefile | 4 ++-- board/st/stih410-b2260/board.c| 5 ++--- drivers/mmc/sti_sdhci.c | 6 +++--- drivers/phy/sti_usb_phy.c | 4 ++-- drivers/pinctrl/pinctrl-sti.c | 6 +++--- drivers/reset/sti-reset.c | 4 ++-- drivers/serial/serial_sti_asc.c | 6 +++--- drivers/sysreset/sysreset_sti.c | 3 ++- drivers/timer/sti-timer.c | 3 ++- drivers/usb/host/dwc3-sti-glue.c | 4 ++-- include/configs/stih410-b2260.h | 4 ++-- include/dwc3-sti-glue.h | 4 ++-- 14 files changed, 31 insertions(+), 29 deletions(-) diff --git a/arch/arm/include/asm/arch-stih410/sdhci.h b/arch/arm/include/asm/arch-stih410/sdhci.h index 8cd77fc..9286143 100644 --- a/arch/arm/include/asm/arch-stih410/sdhci.h +++ b/arch/arm/include/asm/arch-stih410/sdhci.h @@ -1,5 +1,6 @@ /* - * (C) Copyright 2017 Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/arch/arm/include/asm/arch-stih410/sys_proto.h b/arch/arm/include/asm/arch-stih410/sys_proto.h index 5c40d3b..524f22c 100644 --- a/arch/arm/include/asm/arch-stih410/sys_proto.h +++ b/arch/arm/include/asm/arch-stih410/sys_proto.h @@ -1,6 +1,6 @@ /* - * Copyright (c) 2017 - * Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/board/st/stih410-b2260/Makefile b/board/st/stih410-b2260/Makefile index 68a7903..8293ae9 100644 --- a/board/st/stih410-b2260/Makefile +++ b/board/st/stih410-b2260/Makefile @@ -1,6 +1,6 @@ # -# (C) Copyright 2017 -# Patrice Chotard, +# Copyright (C) 2017, STMicroelectronics - All Rights Reserved +# Author(s): Patrice CHOTARD, for STMicroelectronics. # # SPDX-License-Identifier: GPL-2.0+ # diff --git a/board/st/stih410-b2260/board.c b/board/st/stih410-b2260/board.c index d6cbbb8..fe639dc 100644 --- a/board/st/stih410-b2260/board.c +++ b/board/st/stih410-b2260/board.c @@ -1,7 +1,6 @@ /* - * Board init file for STiH410-B2260 - * - * (C) Copyright 2017 Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/drivers/mmc/sti_sdhci.c b/drivers/mmc/sti_sdhci.c index a98c1eb..1c92bb2 100644 --- a/drivers/mmc/sti_sdhci.c +++ b/drivers/mmc/sti_sdhci.c @@ -1,8 +1,8 @@ /* - * Copyright (c) 2017 - * Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * - * SPDX-License-Identifier:GPL-2.0 + * SPDX-License-Identifier:GPL-2.0+ */ #include diff --git a/drivers/phy/sti_usb_phy.c b/drivers/phy/sti_usb_phy.c index 88fcfbb..c671ac6 100644 --- a/drivers/phy/sti_usb_phy.c +++ b/drivers/phy/sti_usb_phy.c @@ -1,6 +1,6 @@ /* - * Copyright (c) 2017 - * Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/drivers/pinctrl/pinctrl-sti.c b/drivers/pinctrl/pinctrl-sti.c index 735e412..a9c1495 100644 --- a/drivers/pinctrl/pinctrl-sti.c +++ b/drivers/pinctrl/pinctrl-sti.c @@ -1,10 +1,10 @@ /* * Pinctrl driver for STMicroelectronics STi SoCs * - * Copyright (c) 2017 - * Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * - * SPDX-License-Identifier:GPL-2.0 + * SPDX-License-Identifier:GPL-2.0+ */ #include diff --git a/drivers/reset/sti-reset.c b/drivers/reset/sti-reset.c index 024b996..17786f9 100644 --- a/drivers/reset/sti-reset.c +++ b/drivers/reset/sti-reset.c @@ -1,6 +1,6 @@ /* - * Copyright (c) 2017 - * Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * * SPDX-License-Identifier:GPL-2.0+ */ diff --git a/drivers/serial/serial_sti_asc.c b/drivers/serial/serial_sti_asc.c index 8dcd4f8..00773cc 100644 --- a/drivers/serial/serial_sti_asc.c +++ b/drivers/serial/serial_sti_asc.c @@ -1,10 +1,10 @@ /* * Support for Serial I/O using STMicroelectronics' on-chip ASC. * - * Copyright (c) 2017 - * Patrice Chotard + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. * - *
[U-Boot] [PATCH 0/5] Fix STMicroelectronics Copyright
From: Patrice Chotard This series fixes STMicroelectronics copyright with correct format. All code related to STI, STM32, SPEAR, STV0991 machine and TMP driver developped by STMicrolectronics's employee have now an uniform header. Patrice Chotard (5): sti: fix STMicroelectronics copyright stm32: fix STMicroelectronics copyright stv0991: fix STMicroelectronics copyright spear: fix STMicroelectronics copyright tpm: st33zp24: fix STMicroelectronics copyright arch/arm/cpu/armv7/stv0991/Makefile| 4 ++-- arch/arm/cpu/armv7/stv0991/clock.c | 4 ++-- arch/arm/cpu/armv7/stv0991/pinmux.c| 4 ++-- arch/arm/cpu/armv7/stv0991/reset.c | 4 ++-- arch/arm/cpu/armv7/stv0991/timer.c | 4 ++-- arch/arm/cpu/armv7m/cache.c| 4 ++-- arch/arm/cpu/armv7m/mpu.c | 4 ++-- arch/arm/include/asm/arch-spear/clk.h | 4 ++-- arch/arm/include/asm/arch-spear/hardware.h | 4 ++-- arch/arm/include/asm/arch-stih410/sdhci.h | 3 ++- arch/arm/include/asm/arch-stih410/sys_proto.h | 4 ++-- arch/arm/include/asm/arch-stm32f4/stm32_defs.h | 4 ++-- arch/arm/include/asm/arch-stm32f4/stm32_periph.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/gpio.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/gpt.h| 4 ++-- arch/arm/include/asm/arch-stm32f7/rcc.h| 4 ++-- arch/arm/include/asm/arch-stm32f7/stm32.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/stm32_defs.h | 4 ++-- arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 4 ++-- arch/arm/include/asm/arch-stm32h7/gpio.h | 4 ++-- arch/arm/include/asm/arch-stm32h7/stm32.h | 4 ++-- arch/arm/include/asm/arch-stv0991/gpio.h | 4 ++-- arch/arm/include/asm/arch-stv0991/hardware.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_creg.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_defs.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_gpt.h| 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_periph.h | 4 ++-- arch/arm/include/asm/arch-stv0991/stv0991_wdru.h | 4 ++-- arch/arm/include/asm/armv7m_mpu.h | 4 ++-- arch/arm/mach-stm32/stm32f7/Makefile | 4 ++-- arch/arm/mach-stm32/stm32f7/timer.c| 4 ++-- arch/arm/mach-stm32/stm32h7/Makefile | 4 ++-- arch/arm/mach-stm32/stm32h7/soc.c | 4 ++-- board/st/stih410-b2260/Makefile| 4 ++-- board/st/stih410-b2260/board.c | 5 ++--- board/st/stm32f746-disco/Makefile | 4 ++-- board/st/stm32f746-disco/stm32f746-disco.c | 4 ++-- board/st/stm32h743-disco/Makefile | 4 ++-- board/st/stm32h743-disco/stm32h743-disco.c | 4 ++-- board/st/stm32h743-eval/Makefile | 4 ++-- board/st/stm32h743-eval/stm32h743-eval.c | 4 ++-- board/st/stv0991/Makefile | 4 ++-- board/st/stv0991/stv0991.c | 4 ++-- common/spl/spl_xip.c | 3 ++- drivers/clk/clk_stm32f7.c | 5 +++-- drivers/clk/clk_stm32h7.c | 4 ++-- drivers/gpio/stm32f7_gpio.c| 4 ++-- drivers/misc/stm32_rcc.c | 4 ++-- drivers/mmc/sti_sdhci.c| 6 +++--- drivers/mmc/stm32_sdmmc2.c | 4 ++-- drivers/phy/sti_usb_phy.c | 4 ++-- drivers/pinctrl/pinctrl-sti.c | 6 +++--- drivers/ram/stm32_sdram.c | 4 ++-- drivers/reset/sti-reset.c | 4 ++-- drivers/reset/stm32-reset.c| 4 ++-- drivers/serial/serial_sti_asc.c| 6 +++--- drivers/serial/serial_stm32x7.c| 4 ++-- drivers/serial/serial_stm32x7.h| 4 ++-- drivers/sysreset/sysreset_sti.c| 3 ++- drivers/timer/sti-timer.c | 3 ++- drivers/tpm/tpm_tis_st33zp24_i2c.c | 3 ++- drivers/tpm/tpm_tis_st33zp24_spi.c | 3 ++- drivers/usb/host/dwc3-sti-glue.c | 4 ++-- include/configs/stih410-b2260.h| 4 ++-- include/configs/stm32f746-disco.h | 4 ++-- include/configs/stm32h743-disco.h | 4 ++-- include/configs/stm32h743-eval.h | 4 ++-- include/configs/stv0991.h | 4 ++-- include/configs/x600.h | 4 ++-- include/dwc3-sti-glue.h| 4 ++-- 71 files changed, 146 insertions(+), 140 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-bo
Re: [U-Boot] [PATCH v3 11/20] arm: socfpga: Add DDR driver for Arria 10
On Isn, 2017-10-16 at 22:08 -0500, Dinh Nguyen wrote:
>
> On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote:
> >
> > From: Tien Fong Chee
> >
> > Add DDR driver suppport for Arria 10.
> s/suppport/support
>
Okay.
> >
> >
> > Signed-off-by: Tien Fong Chee
> > ---
> > arch/arm/mach-socfpga/include/mach/sdram.h | 2 +
> > arch/arm/mach-socfpga/include/mach/sdram_arria10.h | 2 +
> > drivers/ddr/altera/Makefile| 1 +
> > drivers/ddr/altera/sdram_arria10.c | 736
> > +
> > 4 files changed, 741 insertions(+)
> > create mode 100644 drivers/ddr/altera/sdram_arria10.c
> >
> > diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h
> > b/arch/arm/mach-socfpga/include/mach/sdram.h
> > index 137e073..33f830b 100644
> > --- a/arch/arm/mach-socfpga/include/mach/sdram.h
> > +++ b/arch/arm/mach-socfpga/include/mach/sdram.h
> > @@ -10,6 +10,8 @@
> >
> > #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > #include
> > +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > +#include
> > #endif
> >
> > #endif
> > diff --git a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
> > b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
> > index 1d7b7c1..e7a2503 100644
> > --- a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h
> > @@ -8,6 +8,7 @@
> > #define _SOCFPGA_SDRAM_ARRIA10_H_
> >
> > #ifndef __ASSEMBLY__
> > +int ddr_calibration_sequence(void);
> >
> > struct socfpga_ecc_hmc {
> > u32 ip_rev_id;
> > @@ -204,6 +205,7 @@ struct socfpga_io48_mmr {
> > u32 niosreserve1;
> > u32 niosreserve2;
> > };
> > +
> > #endif /*__ASSEMBLY__*/
> >
> > #define IO48_MMR_CTRLCFG0_DB2_BURST_LENGTH_MASK0x1
> > F00
> > diff --git a/drivers/ddr/altera/Makefile
> > b/drivers/ddr/altera/Makefile
> > index ac4ab85..02f8b7c 100644
> > --- a/drivers/ddr/altera/Makefile
> > +++ b/drivers/ddr/altera/Makefile
> > @@ -10,4 +10,5 @@
> >
> > ifdef CONFIG_ALTERA_SDRAM
> > obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o
> > +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o
> > endif
> > diff --git a/drivers/ddr/altera/sdram_arria10.c
> > b/drivers/ddr/altera/sdram_arria10.c
> > new file mode 100644
> > index 000..be8aff3
> > --- /dev/null
> > +++ b/drivers/ddr/altera/sdram_arria10.c
> > @@ -0,0 +1,736 @@
> > +/*
> > + * Copyright (C) 2017 Intel Corporation
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static void sdram_mmr_init(void);
> > +static unsigned long long sdram_size_calc(void);
> Use uint64_t
>
Okay.
> >
> > +
> > +/* FAWBANK - Number of Bank of a given device involved in the FAW
> > period. */
> > +#define ARRIA10_SDR_ACTIVATE_FAWBANK (0x1)
> > +
> > +#define ARRIA_DDR_CONFIG(A, B, C, R) \
> > + (((A) << 24) | ((B) << 16) | ((C) << 8) | (R))
> > +#define DDR_CONFIG_ELEMENTSARRAY_SIZE(ddr_config)
> > +#define DDR_REG_SEQ2CORE0xFFD0507C
> > +#define DDR_REG_CORE2SEQ0xFFD05078
> > +#define DDR_READ_LATENCY_DELAY 40
> > +#define DDR_SIZE_2GB_HEX 0x8000
> > +#define DDR_MAX_TRIES 0x0010
> > +
> > +#define IO48_MMR_DRAMSTS 0xFFCFA0EC
> > +#define IO48_MMR_NIOS2_RESERVE00xFFCFA110
> > +#define IO48_MMR_NIOS2_RESERVE10xFFCFA114
> > +#define IO48_MMR_NIOS2_RESERVE20xFFCFA118
> > +
> > +#define SEQ2CORE_MASK 0xF
> > +#define CORE2SEQ_INT_REQ 0xF
> > +#define SEQ2CORE_INT_RESP_BIT 3
> > +
> > +static const struct socfpga_ecc_hmc *socfpga_ecc_hmc_base =
> > + (void *)SOCFPGA_SDR_ADDRESS;
> > +static const struct socfpga_noc_ddr_scheduler
> > *socfpga_noc_ddr_scheduler_base =
> > + (void *)SOCFPGA_SDR_SCHEDULER_ADDRESS;
> > +static const struct socfpga_noc_fw_ddr_mpu_fpga2sdram
> > + *socfpga_noc_fw_ddr_mpu_fpga2sdram_base =
> > + (void *)SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS;
> > +static const struct socfpga_noc_fw_ddr_l3
> > *socfpga_noc_fw_ddr_l3_base =
> > + (void *)SOCFPGA_SDR_FIREWALL_L3_ADDRESS;
> > +static const struct socfpga_io48_mmr *socfpga_io48_mmr_base =
> > + (void *)SOCFPGA_HMC_MMR_IO48_ADDRESS;
> > +
> > +/* The followring are the supported configurations */
> s/followring/following
>
Okay.
> >
> > +static u32 ddr_config[] = {
> > + /* Chip - Row - Bank - Column Style */
> > + /* All Types */
> > + ARRIA_DDR_CONFIG(0, 3, 10, 12),
> > + ARRIA_DDR_CONFIG(0, 3, 10, 13),
> > + ARRIA_DDR_CONFIG(0, 3, 10, 14),
> > + ARRIA_DDR_CONFIG(0, 3, 10, 15),
> > + ARRIA_DDR_CONFIG(0, 3, 10, 16),
> > + ARRIA_DDR_CONFIG(0, 3, 10, 17),
> > + /* LPDDR x16 */
> > + ARRIA_DDR_CONFIG(0, 3, 11, 14),
> > + ARRIA_DDR_CONFIG(0, 3, 11,
Re: [U-Boot] Rockchip GRF/PMUGRF/CRU reg access in U-Boot
Philipp,
On 10/20/2017 05:00 PM, Dr. Philipp Tomsich wrote:
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);
Yes, this can be resolved by the API you mentioned, but this is one of a
typical case if grf reg if there we have to add one dts node for
sysreset driver.
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.
Well, great, that means we can re-use the driver and dts definition from
kernel for grf regs.
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).
I'm not clear about your 'chip-specific misc-devices', some of grf reg
setting for
Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: > 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 It's not really about what personally you use, but what any user can use. > dhcp > pxe get > pxe boot > and pick the right option. nothing needed on the client side. It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server option being there and valid. 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] [PATCH v3 03/20] arm: socfpga: Add Arria 10 SoCFPGA programming interface
On Jum, 2017-10-13 at 16:08 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Add code necessary into the FPGA driver framework in U-Boot
> so it can be used via the 'fpga' command for programing Arria 10
> SoCFPGA.
>
> Signed-off-by: Tien Fong Chee
> ---
> cmd/fpga.c| 2 +-
> drivers/fpga/altera.c | 40
> drivers/fpga/fpga.c | 8
> include/fpga.h| 2 ++
> 4 files changed, 43 insertions(+), 9 deletions(-)
>
> diff --git a/cmd/fpga.c b/cmd/fpga.c
> index ac6f504..3cb0bcd 100644
> --- a/cmd/fpga.c
> +++ b/cmd/fpga.c
Add more reviewers.
> @@ -363,7 +363,7 @@ U_BOOT_CMD(fpga, 6, 1, do_fpga,
> "(Xilinx only)\n"
> #endif
> #if defined(CONFIG_CMD_FPGA_LOADFS)
> - "Load device from filesystem (FAT by default) (Xilinx
> only)\n"
> + "Load device from filesystem (FAT by default)\n"
> " loadfs [dev] [address] [image size] [blocksize]
> \n"
> "[] \n"
> #endif
> diff --git a/drivers/fpga/altera.c b/drivers/fpga/altera.c
> index 135a357..a03e835 100644
> --- a/drivers/fpga/altera.c
> +++ b/drivers/fpga/altera.c
> @@ -23,25 +23,31 @@ static const struct altera_fpga {
> enum altera_family family;
> const char *name;
> int (*load)(Altera_desc *, const void
> *, size_t);
> + int (*loadfs)(Altera_desc *, const void *, size_t,
> fpga_fs_info *);
> int (*dump)(Altera_desc *, const void
> *, size_t);
> int (*info)(Altera_desc *);
> } altera_fpga[] = {
> #if defined(CONFIG_FPGA_ACEX1K)
> - { Altera_ACEX1K, "ACEX1K", ACEX1K_load, ACEX1K_dump,
> ACEX1K_info },
> - { Altera_CYC2, "ACEX1K", ACEX1K_load, ACEX1K_dump,
> ACEX1K_info },
> + { Altera_ACEX1K, "ACEX1K", ACEX1K_load, NULL, ACEX1K_dump,
> + ACEX1K_info },
> + { Altera_CYC2, "ACEX1K", ACEX1K_load, NULL, ACEX1K_dump,
> + ACEX1K_info },
> #elif defined(CONFIG_FPGA_CYCLON2)
> - { Altera_ACEX1K, "CycloneII", CYC2_load, CYC2_dump,
> CYC2_info },
> - { Altera_CYC2, "CycloneII", CYC2_load, CYC2_dump,
> CYC2_info },
> + { Altera_ACEX1K, "CycloneII", CYC2_load, NULL, CYC2_dump,
> CYC2_info },
> + { Altera_CYC2, "CycloneII", CYC2_load, NULL, CYC2_dump,
> CYC2_info },
> #endif
> #if defined(CONFIG_FPGA_STRATIX_II)
> - { Altera_StratixII, "StratixII", StratixII_load,
> + { Altera_StratixII, "StratixII", StratixII_load, NULL,
> StratixII_dump, StratixII_info },
> #endif
> #if defined(CONFIG_FPGA_STRATIX_V)
> - { Altera_StratixV, "StratixV", stratixv_load, NULL, NULL },
> + { Altera_StratixV, "StratixV", stratixv_load, NULL, NULL,
> NULL },
> #endif
> -#if defined(CONFIG_FPGA_SOCFPGA)
> - { Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL },
> +#if defined(CONFIG_FPGA_SOCFPGA) && defined(CONFIG_CMD_FPGA_LOADFS)
> + { Altera_SoCFPGA, "SoC FPGA", socfpga_load, socfpga_loadfs,
> NULL,
> + NULL },
> +#elif defined(CONFIG_FPGA_SOCFPGA)
> + { Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL, NULL
> },
> #endif
> };
>
> @@ -174,3 +180,21 @@ int altera_info(Altera_desc *desc)
>
> return FPGA_SUCCESS;
> }
> +
> +#if defined(CONFIG_CMD_FPGA_LOADFS)
> +int altera_loadfs(Altera_desc *desc, const void *buf, size_t bsize,
> + fpga_fs_info *fpga_fsinfo)
> +{
> + const struct altera_fpga *fpga = altera_desc_to_fpga(desc,
> __func__);
> +
> + if (!fpga)
> + return FPGA_FAIL;
> +
> + debug_cond(FPGA_DEBUG, "%s: Launching the %s FS
> Loader...\n",
> + __func__, fpga->name);
> + if (fpga->loadfs)
> + return fpga->loadfs(desc, buf, bsize, fpga_fsinfo);
> +
> + return -EINVAL;
> +}
> +#endif
> diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
> index e0fb1b4..42e901e 100644
> --- a/drivers/fpga/fpga.c
> +++ b/drivers/fpga/fpga.c
> @@ -198,6 +198,14 @@ int fpga_fsload(int devnum, const void *buf,
> size_t size,
> fpga_no_sup((char *)__func__, "Xilinx
> devices");
> #endif
> break;
> +#if defined(CONFIG_FPGA_ALTERA)
> + case fpga_altera:
> + ret_val = altera_loadfs(desc->devdesc, buf,
> size,
> + fpga_fsinfo);
> +#else
> + fpga_no_sup((char *)__func__, "Altera
> devices");
> +#endif
> + break;
> default:
> printf("%s: Invalid or unsupported device
> type %d\n",
> __func__, desc->devtype);
> diff --git a/include/fpga.h b/include/fpga.h
> index d768fb1..8920016 100644
> --- a/include/fpga.h
> +++ b/include/fpga.h
> @@ -56,8 +56,10 @@ int fpga_count(void);
> const fpga_desc *const fpga_get_desc(int devnum);
> int fpga_load(int devnum, const void *buf, size_t bsize,
> bitstream_type bstype);
> +#if defined(CONFIG_CMD_FPGA_LOADFS
Re: [U-Boot] i.MX6: Prealloc pinctrl make U-Boot hang at relocation (data abort)
+Heiko On Tuesday 17 October 2017 04:14 AM, Jagan Teki wrote: > Hi, > > I'm trying to use SPL_OF_CONTROL with u-boot,dm-spl So I've marked > u-boot,dm-spl with pinctrl since MMC used the pinconfig. > > The issue observed here is SPL handover to U-Boot proper and before > relocation U-Boot probed imx_thermal dm-driver through device_probe. > But the same time device_probe unnecessary probing all u-boot,dm-spl This statement is not entirely true. device_probe() tries to get pinctrl for every device. So pinctrl is being probed as part of imx_thermal probe. > marked nodes(which are strictly related for SPL) Since pinctrl marked > as u-boot, dm-spl the same probed and this might be the show-stopper. But then, u-boot,dm-spl marked nodes should not be probed in u-boot proper. IMHO, this needs to be fixed. Heiko, what is this expected behavior here? > > Based on the data abort, the code hang at relocation code, relocate.S, > eventually stop calling uclass_get_device( was called in > arch/arm/mach-imx/cpu.c) during board_f or unmark u-boot,dm-spl make > U-Boot boots. So, I looked at drivers/pinctrl/nxp/pinctrl-imx6.c and observed that there is an uninitialized global variable[1]. Before re location, BSS is overlapped with DT area. IIUC, your dtb is being corrupted in this case. Can you try initializing imx6_pinctrl_soc_info with some non-zero values and see if it helps? [1] http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/pinctrl/nxp/pinctrl-imx6.c;h=0f767d90790a0dbeb974029a7d88cac6c03ae23f;hb=HEAD#l14 Thanks and regards, Lokesh > > Below are relocation code hang point and Log dump, request for any inputs. > > Relocation code: > -- > > /* relative fix: increase location by offset */ > add r0, r0, r4 > 87800ac4: e084add r0, r0, r4 > ldr r1, [r0] > 87800ac8: e5901000ldr r1, [r0] /* HANG */ > add r1, r1, r4 > 87800acc: e0811004add r1, r1, r4 > str r1, [r0] > 87800ad0: e5801000str r1, [r0] > > 87800ad4 : > > Log: > - > U-Boot SPL 2017.11-rc1-00165-g7340683-dirty (Oct 17 2017 - 04:00:01) > Trying to boot from MMC1 > > device_probe: Process pinctrl for soc > > device_probe: Process pinctrl for aips-bus@0200 > initialized IMX pinctrl driver > > device_probe: Process pinctrl for aips-bus@0210 > > device_probe: Process pinctrl for usdhc@0219 > > device_probe: Process pinctrl for usdhc1grp > > device_probe: Process pinctrl for gpio@0209c000 > Expected Linux image is not found. Trying to start U-boot > > > U-Boot 2017.11-rc1-00165-g7340683-dirty (Oct 17 2017 - 04:00:01 +0530) > > U-Boot code: 8780 -> 8783FB38 BSS: -> 87857338 > CPU: Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz) > CPU: Industrial temperature grade (-40C to 105C) > device_probe: Process pinctrl for imx_thermal > > device_probe: Process pinctrl for soc > > device_probe: Process pinctrl for aips-bus@0200 > initialized IMX pinctrl driver > at 31C > Reset cause: POR > Model: Engicam Is.IoT MX6UL MMC Starterkit > DRAM: Monitor len: 00057338 > Ram size: 0800 > Ram top: 8800 > TLB table from 87ff to 87ff4000 > Reserving 348k for U-Boot at: 87f98000 > Reserving 16384k for malloc() at: 86f98000 > Reserving 80 Bytes for Board Info at: 86f97fb0 > Reserving 240 Bytes for Global Data at: 86f97ec0 > Reserving 24448 Bytes for FDT at: 86f91f40 > > RAM Configuration: > Bank #0: 8000 > DRAM: 128 MiB > New Stack Pointer is: 86f91f20 > Relocation Offset is: 00798000 > Relocating to 87f98000, new gd at 86f97ec0, sp at 86f91f20 > data abort > pc : [<87800ac8>] lr : [<87f986ac>] > sp : 86f91f20 ip : 001c fp : 0017 > r10: 8783fa98 r9 : 86f97ec0 r8 : 00913b18 > r7 : deadbeef r6 : 0091de88 r5 : 87800320 r4 : 00798000 > r3 : 87848848 r2 : 87843820 r1 : 0017 r0 : 02878000 > Flags: nZCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > resetting ... > > thanks! > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
