Re: [U-Boot] [PATCH 6/7] kc1: Proper reboot mode and boot reason validation
On Tue, Mar 29, 2016 at 02:14:34PM +0200, Paul Kocialkowski wrote: > Le lundi 28 mars 2016 à 10:06 -0400, Tom Rini a écrit : > > On Mon, Mar 28, 2016 at 02:07:13PM +0200, Paul Kocialkowski wrote: > > > With the previous implementation, rebooting without registering a > > > recognized > > > reboot mode would end up with U-Boot checking for a valid power-on reason, > > > which > > > might result in the device turning off (e.g. with no USB cable attached > > > and > > > no > > > buttons pressed). > > > > > > Since this approach is not viable (breaks reboot in most cases), the > > > validity of > > > the reboot reason is checked (in turn, by checking that a warm reset > > > happened, > > > as there is no magic) to detect a reboot and the 'o' char is recognized to > > > indicate that power-off is required. Still, that might be overridden by > > > the > > > detection of usual power-on reasons, on purpose. > > > > > > Signed-off-by: Paul Kocialkowski > > Reviewed-by: Tom Rini > > > > ... but since Sniper and KC1 are doing the same thing, and other OMAP > > devices that are also Android devices will also be in the same camp, can > > we perhaps include some of the above information in a comment, make > > android_omap_reboot_mode (or something along those lines) in > > arch/arm/cpu/armv7/omap-common/something-appropriate.c ? > > The way things are done now, a few distinct aspects are tied together in my > approach: > * reboot mode storage, which is Android-specific and also involves the boot > command > * valid power-on reason checking, which relies on twl code, that I'm not > comfortable making part of the omap arch code > * device-specific reboot mode setting (overriding omap reboot mode), e.g. from > buttons > > So I think we could go with the following: > * Making the twl code common on each twl power driver > * Making the Android aspects common through functions dealing with the reboot- > mode env variable and associated boot command, with their own Kconfig option > * Keeping the global coordination between these in each board file, to handle > device-specific input and quirks > > I'd rather make a clean new series to support that. > > What do you think? Since mutt is telling me I forgot to reply, sorry, yes, a follow-up sounds good, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with sf write on Arria 5.
On 04/09/2016 01:07 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Marek, Hi! >>> Just check if the mainline SPL generated from this branch works on your >>> platform please. > > I tested U-boot generated from the branch you specified: > U-Boot 2016.03-11349-g5d09125-dirty (Apr 09 2016 - 00:42:24 +0200) > > Works pretty well. Great, thanks. > All needed functionality works for me. I tested: > 1. Mounting ubi partition. > 2. Booting kernel from ubi partition. > 3. Fpga configuration. > 4. Ethernet. > > For two more weeks I will have access to the hardware so you can ask for > another test if you wish. > But in the end of April I will move to another project, so I'm afraid I will > not be able to help then. > > Best regards, > Denis Bakhvalov > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with sf write on Arria 5.
Hi Marek, >> Just check if the mainline SPL generated from this branch works on your >> platform please. I tested U-boot generated from the branch you specified: U-Boot 2016.03-11349-g5d09125-dirty (Apr 09 2016 - 00:42:24 +0200) Works pretty well. All needed functionality works for me. I tested: 1. Mounting ubi partition. 2. Booting kernel from ubi partition. 3. Fpga configuration. 4. Ethernet. For two more weeks I will have access to the hardware so you can ask for another test if you wish. But in the end of April I will move to another project, so I'm afraid I will not be able to help then. Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/1] mpc85xx: Enable pre-relocation malloc for MPC85xx
On 04/05/2016 06:06 AM, Mario Six wrote: > To enable DM on MPC85xx, we need pre-relocation malloc, which is > implemented in this patch. > > We also make sure that the IVORs are always 4-aligned on e500 to prevent > alignment exceptions caused by code changes in start.S. > > Signed-off-by: Mario Six > Cc: York Sun > Cc: Simon Glass > --- > > v3: > - Add comment regarding gd zeroing > - Unconditionally zero out initial RAM during startup > > v2: > - Correct IVOR alignment and remove nop hack > - Add sanity check for length of malloc area > > > arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 8 +--- > arch/powerpc/cpu/mpc85xx/start.S | 30 ++ > include/ppc_asm.tmpl | 3 +++ > 3 files changed, 34 insertions(+), 7 deletions(-) > Minor change in subject and minor fix in cpu_init_early.c. Applied to u-boot-mpc85xx master. Awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: Replace CONFIG_SYS_INIT_RAM_END with CONFIG_SYS_INIT_RAM_SIZE
On 04/06/2016 01:52 PM, York Sun wrote: > CONFIG_SYS_INIT_RAM_SIZE may be used out of the board header file. > Some boards use CONFIG_SYS_INIT_RAM_END for the same purpose. To > unify the macros, use CONFIG_SYS_INIT_RAM_SIZE for all. > > Signed-off-by: York Sun > CC: Mario Six > > --- > > include/configs/BSC9131RDB.h |4 ++-- > include/configs/BSC9132QDS.h |4 ++-- > include/configs/C29XPCIE.h |4 ++-- > include/configs/P1010RDB.h |4 ++-- > include/configs/a3m071.h |4 ++-- > include/configs/ac14xx.h |4 ++-- > include/configs/dlvision-10g.h |4 ++-- > include/configs/io.h |4 ++-- > include/configs/iocon.h|4 ++-- > include/configs/o2dnt-common.h |6 +++--- > 10 files changed, 21 insertions(+), 21 deletions(-) Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: t1040qds: Use generic ethsw commands
On 03/14/2016 04:47 AM, Codrin Ciubotariu wrote: > The commands for the VSC9953 l2 switch from T1040 became generic in > patch https://patchwork.ozlabs.org/patch/499748/ and the define > was renamed. > > Signed-off-by: Codrin Ciubotariu > --- > include/configs/T1040QDS.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-mpc85xx master. Awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx master
Tom, The following changes since commit 46a16bd895144617575c788d9c2554aeef76ac44: kirkwood_nand: claim MPP pins on the fly (2016-04-06 15:40:33 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to 50689461205e0125759eb1a43787383a3fa09b48: powerpc: mpc85xx: Enable pre-relocation malloc for MPC85xx (2016-04-08 15:42:10 -0700) Codrin Ciubotariu (1): powerpc: t1040qds: Use generic ethsw commands York Sun (1): powerpc: Replace CONFIG_SYS_INIT_RAM_END with CONFIG_SYS_INIT_RAM_SIZE mario@gdsys.cc (1): powerpc: mpc85xx: Enable pre-relocation malloc for MPC85xx arch/powerpc/cpu/mpc85xx/cpu_init_early.c |9 ++--- arch/powerpc/cpu/mpc85xx/start.S | 30 + include/configs/BSC9131RDB.h |4 ++-- include/configs/BSC9132QDS.h |4 ++-- include/configs/C29XPCIE.h|4 ++-- include/configs/P1010RDB.h|4 ++-- include/configs/T1040QDS.h|2 +- include/configs/a3m071.h |4 ++-- include/configs/ac14xx.h |4 ++-- include/configs/dlvision-10g.h|4 ++-- include/configs/io.h |4 ++-- include/configs/iocon.h |4 ++-- include/configs/o2dnt-common.h|6 +++--- include/ppc_asm.tmpl |3 +++ 14 files changed, 57 insertions(+), 29 deletions(-) Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Newbie SPL question for socfpga_sockit
On 8 April 2016 at 05:36, Marek Vasut wrote: > On 04/08/2016 07:16 AM, Stefan Roese wrote: >> On 08.04.2016 01:51, George Broz wrote: >> >> >> >> Try with the attached patch (and probably with dcache off) > > The patch applied cleanly. The behavior is unchanged with both > dcache on and off. The "good" sticks still work, and "bad" sticks still > don't. OK. Then I should probably go hunting for Kingston DataTraveler SE9, right ? Can you give me a link to the stick you have, so I know what crappy device to look for ? Thanks! >>> >>> Here it is [1] - I have the 8GB version. >>> >>> I think there will always be crappy sticks that don't work... but do you >>> have any advice as to what properties will/might generally cause a problem? >>> >>> [1] >>> http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG >> >> I have exactly this stick here (16GiB) version. And it is detected just >> fine in both, current mainline Armada XP (theadorable) and x86 boards >> (conga-qeval20-qa3-e3845). Here my lsusb output: > > I bought the kingston stick and it's not detected on SoCFPGA SoCkit at > all. Ouch :-( > > [...] > Best regards, > Marek Vasut For what it's worth - here is the marking on the OTG chip on the de0_nano_soc: SMSC 3300-EZK A1515AC13 515AR3A ASETV Best regards, --George ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] ddr: altera: Repair DQ window centering code
On 6 April 2016 at 19:04, Marek Vasut wrote:
> The code uses a lot of signed numbers, which ended up in variables
> of unsigned type, which resulted in all sorts of underflows. This
> in turn caused incorrect calibration on certain boards. Moreover,
> repair the readout of the DQ delay, which was being pulled from
> wrong register.
>
> Signed-off-by: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> ---
> drivers/ddr/altera/sequencer.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
> index 5ea53ad..6c6bd90 100644
> --- a/drivers/ddr/altera/sequencer.c
> +++ b/drivers/ddr/altera/sequencer.c
> @@ -2316,15 +2316,15 @@ static void center_dq_windows(const int write, int
> *left_edge, int *right_edge,
> const int min_index, const int test_bgn,
> int *dq_margin, int *dqs_margin)
> {
> - const u32 delay_max = write ? iocfg->io_out1_delay_max :
> + const s32 delay_max = write ? iocfg->io_out1_delay_max :
> iocfg->io_in_delay_max;
> - const u32 per_dqs = write ? rwcfg->mem_dq_per_write_dqs :
> + const s32 per_dqs = write ? rwcfg->mem_dq_per_write_dqs :
> rwcfg->mem_dq_per_read_dqs;
> - const u32 delay_off = write ? SCC_MGR_IO_OUT1_DELAY_OFFSET :
> + const s32 delay_off = write ? SCC_MGR_IO_OUT1_DELAY_OFFSET :
> SCC_MGR_IO_IN_DELAY_OFFSET;
> - const u32 addr = SDR_PHYGRP_SCCGRP_ADDRESS | delay_off;
> + const s32 addr = SDR_PHYGRP_SCCGRP_ADDRESS | delay_off;
>
> - u32 temp_dq_io_delay1, temp_dq_io_delay2;
> + s32 temp_dq_io_delay1;
> int shift_dq, i, p;
>
> /* Initialize data for export structures */
> @@ -2342,11 +2342,10 @@ static void center_dq_windows(const int write, int
> *left_edge, int *right_edge,
>"vfifo_center: before: shift_dq[%u]=%d\n",
>i, shift_dq);
>
> - temp_dq_io_delay1 = readl(addr + (p << 2));
> - temp_dq_io_delay2 = readl(addr + (i << 2));
> + temp_dq_io_delay1 = readl(addr + (i << 2));
>
> if (shift_dq + temp_dq_io_delay1 > delay_max)
> - shift_dq = delay_max - temp_dq_io_delay2;
> + shift_dq = delay_max - temp_dq_io_delay1;
> else if (shift_dq + temp_dq_io_delay1 < 0)
> shift_dq = -temp_dq_io_delay1;
>
> --
> 2.7.0
>
Tested on: SoCKit, DE0_Nano_SoC
Tested-by: George Broz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10] ddr: altera: Staticize global variables
On 6 April 2016 at 19:04, Marek Vasut wrote: > Just staticize global variables in sequencer, since there is no > point in having these symbols available outside of the DDR code. > > Signed-off-by: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > --- > drivers/ddr/altera/sequencer.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c > index c41555f..5ea53ad 100644 > --- a/drivers/ddr/altera/sequencer.c > +++ b/drivers/ddr/altera/sequencer.c > @@ -57,7 +57,7 @@ const struct socfpga_sdram_misc_config *misccfg; > STATIC_SKIP_DELAY_LOOPS) > > /* calibration steps requested by the rtl */ > -u16 dyn_calib_steps; > +static u16 dyn_calib_steps; > > /* > * To make CALIB_SKIP_DELAY_LOOPS a dynamic conditional option > @@ -68,13 +68,13 @@ u16 dyn_calib_steps; > * zero when skipping > */ > > -u16 skip_delay_mask; /* mask off bits when skipping/not-skipping */ > +static u16 skip_delay_mask;/* mask off bits when skipping/not-skipping */ > > #define SKIP_DELAY_LOOP_VALUE_OR_ZERO(non_skip_value) \ > ((non_skip_value) & skip_delay_mask) > > -struct gbl_type *gbl; > -struct param_type *param; > +static struct gbl_type *gbl; > +static struct param_type *param; > > static void set_failing_group_stage(u32 group, u32 stage, > u32 substage) > -- > 2.7.0 > Tested on: SoCKit, DE0_Nano_SoC Tested-by: George Broz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] ddr: altera: Make DLEVEL behavior inclusive
On 6 April 2016 at 19:04, Marek Vasut wrote:
> Originally, the DLEVEL selects the debug level within the sequencer code,
> but only displays the messages on that particular debug level. Tweak the
> handling such that for particular debug level, debug messages on that
> level and lower are displayed. This allows better regulation of debug
> message verbosity.
>
> Signed-off-by: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> ---
> drivers/ddr/altera/sequencer.c | 132
> -
> 1 file changed, 66 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
> index 0321e3b..c41555f 100644
> --- a/drivers/ddr/altera/sequencer.c
> +++ b/drivers/ddr/altera/sequencer.c
> @@ -277,7 +277,7 @@ static void scc_mgr_initialize(void)
> int i;
>
> for (i = 0; i < 16; i++) {
> - debug_cond(DLEVEL == 1, "%s:%d: Clearing SCC RFILE index
> %u\n",
> + debug_cond(DLEVEL >= 1, "%s:%d: Clearing SCC RFILE index
> %u\n",
>__func__, __LINE__, i);
> scc_mgr_set(SCC_MGR_HHP_RFILE_OFFSET, i, 0);
> }
> @@ -479,10 +479,10 @@ static void scc_mgr_set_hhp_extras(void)
> SCC_MGR_HHP_GLOBALS_OFFSET |
> SCC_MGR_HHP_EXTRAS_OFFSET;
>
> - debug_cond(DLEVEL == 1, "%s:%d Setting HHP Extras\n",
> + debug_cond(DLEVEL >= 1, "%s:%d Setting HHP Extras\n",
>__func__, __LINE__);
> writel(value, addr);
> - debug_cond(DLEVEL == 1, "%s:%d Done Setting HHP Extras\n",
> + debug_cond(DLEVEL >= 1, "%s:%d Done Setting HHP Extras\n",
>__func__, __LINE__);
> }
>
> @@ -693,7 +693,7 @@ static void scc_mgr_apply_group_all_out_delay_add(const
> u32 write_group,
> /* DQS shift */
> new_delay = READ_SCC_DQS_IO_OUT2_DELAY + delay;
> if (new_delay > iocfg->io_out2_delay_max) {
> - debug_cond(DLEVEL == 1,
> + debug_cond(DLEVEL >= 1,
>"%s:%d (%u, %u) DQS: %u > %d; adding %u to OUT1\n",
>__func__, __LINE__, write_group, delay, new_delay,
>iocfg->io_out2_delay_max,
> @@ -707,7 +707,7 @@ static void scc_mgr_apply_group_all_out_delay_add(const
> u32 write_group,
> /* OCT shift */
> new_delay = READ_SCC_OCT_OUT2_DELAY + delay;
> if (new_delay > iocfg->io_out2_delay_max) {
> - debug_cond(DLEVEL == 1,
> + debug_cond(DLEVEL >= 1,
>"%s:%d (%u, %u) DQS: %u > %d; adding %u to OUT1\n",
>__func__, __LINE__, write_group, delay,
>new_delay, iocfg->io_out2_delay_max,
> @@ -1210,14 +1210,14 @@ rw_mgr_mem_calibrate_write_test(const u32 rank_bgn,
> const u32 write_group,
>
> set_rank_and_odt_mask(0, RW_MGR_ODT_MODE_OFF);
> if (all_correct) {
> - debug_cond(DLEVEL == 2,
> + debug_cond(DLEVEL >= 2,
>"write_test(%u,%u,ALL) : %u == %u => %i\n",
>write_group, use_dm, *bit_chk,
>param->write_correct_mask,
>*bit_chk == param->write_correct_mask);
> return *bit_chk == param->write_correct_mask;
> } else {
> - debug_cond(DLEVEL == 2,
> + debug_cond(DLEVEL >= 2,
>"write_test(%u,%u,ONE) : %u != %i => %i\n",
>write_group, use_dm, *bit_chk, 0, *bit_chk != 0);
> return *bit_chk != 0x00;
> @@ -1292,7 +1292,7 @@ rw_mgr_mem_calibrate_read_test_patterns(const u32
> rank_bgn, const u32 group,
> if (bit_chk != param->read_correct_mask)
> ret = -EIO;
>
> - debug_cond(DLEVEL == 1,
> + debug_cond(DLEVEL >= 1,
>"%s:%d test_load_patterns(%u,ALL) => (%u == %u) => %i\n",
>__func__, __LINE__, group, bit_chk,
>param->read_correct_mask, ret);
> @@ -1453,13 +1453,13 @@ rw_mgr_mem_calibrate_read_test(const u32 rank_bgn,
> const u32 group,
>
> if (all_correct) {
> ret = (*bit_chk == param->read_correct_mask);
> - debug_cond(DLEVEL == 2,
> + debug_cond(DLEVEL >= 2,
>"%s:%d read_test(%u,ALL,%u) => (%u == %u) => %i\n",
>__func__, __LINE__, group, all_groups, *bit_chk,
>param->read_correct_mask, ret);
> } else {
> ret = (*bit_chk != 0x00);
> - debug_cond(DLEVEL == 2,
> + debug_cond(DLEVEL >= 2,
>"%s:%d read_test(%u,ONE,%u) => (%u != %u) => %i\n",
>__func__, __LINE__, group, all_groups, *bit_chk,
>0, ret);
>
Re: [U-Boot] [PATCH 07/10] ddr: altera: Zero DM IN delay in scc_mgr_zero_group()
On 6 April 2016 at 19:04, Marek Vasut wrote:
> This one last set of delay configuration registers was not properly
> zeroed out originally, fix it and zero them out.
>
> Signed-off-by: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> ---
> drivers/ddr/altera/sequencer.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
> index 254b130..0321e3b 100644
> --- a/drivers/ddr/altera/sequencer.c
> +++ b/drivers/ddr/altera/sequencer.c
> @@ -303,15 +303,22 @@ static void scc_mgr_set_dqs_en_delay(u32 read_group,
> u32 delay)
> scc_mgr_set(SCC_MGR_DQS_EN_DELAY_OFFSET, read_group, delay);
> }
>
> +static void scc_mgr_set_dq_in_delay(u32 dq_in_group, u32 delay)
> +{
> + scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET, dq_in_group, delay);
> +}
> +
> static void scc_mgr_set_dqs_io_in_delay(u32 delay)
> {
> scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET, rwcfg->mem_dq_per_write_dqs,
> delay);
> }
>
> -static void scc_mgr_set_dq_in_delay(u32 dq_in_group, u32 delay)
> +static void scc_mgr_set_dm_in_delay(u32 dm, u32 delay)
> {
> - scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET, dq_in_group, delay);
> + scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET,
> + rwcfg->mem_dq_per_write_dqs + 1 + dm,
> + delay);
> }
>
> static void scc_mgr_set_dq_out1_delay(u32 dq_in_group, u32 delay)
> @@ -584,8 +591,11 @@ static void scc_mgr_zero_group(const u32 write_group,
> const int out_only)
> writel(0xff, &sdr_scc_mgr->dq_ena);
>
> /* Zero all DM config settings. */
> - for (i = 0; i < RW_MGR_NUM_DM_PER_WRITE_GROUP; i++)
> + for (i = 0; i < RW_MGR_NUM_DM_PER_WRITE_GROUP; i++) {
> + if (!out_only)
> + scc_mgr_set_dm_in_delay(i, 0);
> scc_mgr_set_dm_out1_delay(i, 0);
> + }
>
> /* Multicast to all DM enables. */
> writel(0xff, &sdr_scc_mgr->dm_ena);
> --
> 2.7.0
>
Tested on: SoCKit, DE0_Nano_SoC
Tested-by: George Broz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10] ddr: altera: Remove unnecessary ODT mode config
On 6 April 2016 at 19:04, Marek Vasut wrote:
> There is no point in resetting the ODT setting if the write test
> failed, since the code will always retry the calibration and thus
> reconfigure the ODT anyway OR the code will fail calibration and
> halt.
>
> Signed-off-by: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> ---
> drivers/ddr/altera/sequencer.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
> index 6bf75ba..254b130 100644
> --- a/drivers/ddr/altera/sequencer.c
> +++ b/drivers/ddr/altera/sequencer.c
> @@ -1207,7 +1207,6 @@ rw_mgr_mem_calibrate_write_test(const u32 rank_bgn,
> const u32 write_group,
>*bit_chk == param->write_correct_mask);
> return *bit_chk == param->write_correct_mask;
> } else {
> - set_rank_and_odt_mask(0, RW_MGR_ODT_MODE_OFF);
> debug_cond(DLEVEL == 2,
>"write_test(%u,%u,ONE) : %u != %i => %i\n",
>write_group, use_dm, *bit_chk, 0, *bit_chk != 0);
> --
> 2.7.0
>
Tested on: SoCKit, DE0_Nano_SoC
Tested-by: George Broz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] ddr: altera: Remove unnecessary update of the SCC
On 6 April 2016 at 19:04, Marek Vasut wrote: > Every invocation of the scc_mgr_set_dqs_en_delay_all_ranks() is > followed by SCC manager update. Moreover, only this function > triggers the SCC manager update internally. Thus, remove the > internal invocation to avoid triggering the update twice. > > Signed-off-by: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > --- > drivers/ddr/altera/sequencer.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c > index 3859e66..6bf75ba 100644 > --- a/drivers/ddr/altera/sequencer.c > +++ b/drivers/ddr/altera/sequencer.c > @@ -424,7 +424,6 @@ static void scc_mgr_set_dqs_en_delay_all_ranks(u32 > read_group, > */ > scc_mgr_set_all_ranks(SCC_MGR_DQS_EN_DELAY_OFFSET, > read_group, delay, 1); > - writel(0, &sdr_scc_mgr->update); > } > > /** > -- > 2.7.0 > Tested on: SoCKit, DE0_Nano_SoC Tested-by: George Broz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] ddr: altera: Fix scc_mgr_set() argument order
On 6 April 2016 at 19:03, Marek Vasut wrote:
> The code should be setting registers to zero, not one register to value.
> Swap the order of arguments to correct the behavior. The behavior is now
> in-line with code generated by Quartus 15.1 .
>
> Signed-off-by: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> ---
> drivers/ddr/altera/sequencer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
> index bf74b4e..3859e66 100644
> --- a/drivers/ddr/altera/sequencer.c
> +++ b/drivers/ddr/altera/sequencer.c
> @@ -279,7 +279,7 @@ static void scc_mgr_initialize(void)
> for (i = 0; i < 16; i++) {
> debug_cond(DLEVEL == 1, "%s:%d: Clearing SCC RFILE index
> %u\n",
>__func__, __LINE__, i);
> - scc_mgr_set(SCC_MGR_HHP_RFILE_OFFSET, 0, i);
> + scc_mgr_set(SCC_MGR_HHP_RFILE_OFFSET, i, 0);
> }
> }
>
> --
> 2.7.0
>
Tested on: SoCKit, DE0_Nano_SoC
Tested-by: George Broz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] ddr: altera: Fix DRAM end value in protection rule
On 6 April 2016 at 19:04, Marek Vasut wrote:
> The hi address bitfield in the protection rule must be set to
> the last address in the region which the rule represents. The
> behavior is now in-line with code generated by Quartus 15.1 .
>
> Signed-off-by: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> ---
> drivers/ddr/altera/sdram.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/ddr/altera/sdram.c b/drivers/ddr/altera/sdram.c
> index 2996942..7e4606d 100644
> --- a/drivers/ddr/altera/sdram.c
> +++ b/drivers/ddr/altera/sdram.c
> @@ -118,7 +118,7 @@ static void sdram_set_rule(struct sdram_prot_rule *prule)
>
> /* Obtain the address bits */
> lo_addr_bits = prule->sdram_start >> 20ULL;
> - hi_addr_bits = prule->sdram_end >> 20ULL;
> + hi_addr_bits = (prule->sdram_end - 1) >> 20ULL;
>
> debug("sdram set rule start %x, %d\n", lo_addr_bits,
> prule->sdram_start);
> --
> 2.7.0
>
Tested on: SoCKit, DE0_Nano_SoC
Tested-by: George Broz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] ddr: altera: Tweak DQS tracking enable handling
On 6 April 2016 at 19:03, Marek Vasut wrote:
> In the most unlikely case the DQS tracking was to be disabled,
> make sure we do not errornously re-enable it. Note that DQS
> tracking is enabled on all systems observed thus far.
>
> Signed-off-by: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> ---
> drivers/ddr/altera/sequencer.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
> index 34b1aa7..bf74b4e 100644
> --- a/drivers/ddr/altera/sequencer.c
> +++ b/drivers/ddr/altera/sequencer.c
> @@ -3479,6 +3479,7 @@ grp_failed: /* A group failed, increment
> the counter. */
> static int run_mem_calibrate(void)
> {
> int pass;
> + u32 ctrl_cfg;
>
> debug("%s:%d\n", __func__, __LINE__);
>
> @@ -3486,7 +3487,9 @@ static int run_mem_calibrate(void)
> writel(PHY_MGR_CAL_RESET, &phy_mgr_cfg->cal_status);
>
> /* Stop tracking manager. */
> - clrbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK);
> + ctrl_cfg = readl(&sdr_ctrl->ctrl_cfg);
> + writel(ctrl_cfg & ~SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK,
> + &sdr_ctrl->ctrl_cfg);
>
> phy_mgr_initialize();
> rw_mgr_mem_initialize();
> @@ -3507,7 +3510,7 @@ static int run_mem_calibrate(void)
> writel(0x2, &phy_mgr_cfg->mux_sel);
>
> /* Start tracking manager. */
> - setbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK);
> + writel(ctrl_cfg, &sdr_ctrl->ctrl_cfg);
>
> return pass;
> }
> --
> 2.7.0
>
Tested on: SoCKit, DE0_Nano_SoC
Tested-by: George Broz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] ddr: altera: Replace ad-hoc constant with macro
On 6 April 2016 at 19:03, Marek Vasut wrote: > The bit 22 is in fact DQS tracking enable bit (dqstrken) and there > is a macro for this bit already, so use it. > > Signed-off-by: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > --- > drivers/ddr/altera/sequencer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c > index 79c265f..34b1aa7 100644 > --- a/drivers/ddr/altera/sequencer.c > +++ b/drivers/ddr/altera/sequencer.c > @@ -3486,7 +3486,7 @@ static int run_mem_calibrate(void) > writel(PHY_MGR_CAL_RESET, &phy_mgr_cfg->cal_status); > > /* Stop tracking manager. */ > - clrbits_le32(&sdr_ctrl->ctrl_cfg, 1 << 22); > + clrbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK); > > phy_mgr_initialize(); > rw_mgr_mem_initialize(); > @@ -3507,7 +3507,7 @@ static int run_mem_calibrate(void) > writel(0x2, &phy_mgr_cfg->mux_sel); > > /* Start tracking manager. */ > - setbits_le32(&sdr_ctrl->ctrl_cfg, 1 << 22); > + setbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK); > > return pass; > } > -- > 2.7.0 > Tested on: SoCKit, DE0_Nano_SoC Tested-by: George Broz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: ti: am57xx: Add support for am572x idk in SPL
From: Steve Kipisz
The AM572x-IDK board (Industrial Dev Kit) is a board based on TI's AM5728x
SOC which has a dual core 1.5GHz A15 processor. This board is a development
platform for the Industrial market with:
- 2GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI,
- PRU-ICSS
- uSD
- 16GB eMMC
- CAN
- RS-485
- PCIe
- USB3.0
- Video Input Port
- Industrial IO port and expansion connector
The link to the data sheet and TRM can be found here:
http://www.ti.com/product/AM5728
NOTE: DT support is still pending upstream kernel acceptance but we
should be able to get the base system support with this patch.
Signed-off-by: Schuyler Patton
Signed-off-by: Steve Kipisz
Signed-off-by: Nishanth Menon
---
Boot Log: http://pastebin.ubuntu.com/15699618/
board/ti/am57xx/board.c| 32 +-
board/ti/am57xx/mux_data.h | 268 -
2 files changed, 295 insertions(+), 5 deletions(-)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 18416ef64ad9..11eb524980be 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -35,6 +35,7 @@
#define board_is_x15() board_ti_is("BBRDX15_")
#define board_is_am572x_evm() board_ti_is("AM572PM_")
+#define board_is_am572x_idk() board_ti_is("AM572IDK")
#ifdef CONFIG_DRIVER_TI_CPSW
#include
@@ -278,6 +279,8 @@ void do_board_detect(void)
bname = "BeagleBoard X15";
else if (board_is_am572x_evm())
bname = "AM572x EVM";
+ else if (board_is_am572x_idk())
+ bname = "AM572x IDK";
if (bname)
snprintf(sysinfo.board_string, SYSINFO_BOARD_NAME_MAX_LEN,
@@ -296,6 +299,8 @@ static void setup_board_eeprom_env(void)
if (board_is_am572x_evm())
name = "am57xx_evm";
+ else if (board_is_am572x_idk())
+ name = "am572x_idk";
else
printf("Unidentified board claims %s in eeprom header\n",
board_ti_get_name());
@@ -344,9 +349,24 @@ void set_muxconf_regs(void)
#ifdef CONFIG_IODELAY_RECALIBRATION
void recalibrate_iodelay(void)
{
- __recalibrate_iodelay(core_padconf_array_essential,
- ARRAY_SIZE(core_padconf_array_essential),
- iodelay_cfg_array, ARRAY_SIZE(iodelay_cfg_array));
+ const struct pad_conf_entry *pconf;
+ const struct iodelay_cfg_entry *iod;
+ int pconf_sz, iod_sz;
+
+ if (board_is_am572x_idk()) {
+ pconf = core_padconf_array_essential_am572x_idk;
+ pconf_sz = ARRAY_SIZE(core_padconf_array_essential_am572x_idk);
+ iod = iodelay_cfg_array_am572x_idk;
+ iod_sz = ARRAY_SIZE(iodelay_cfg_array_am572x_idk);
+ } else {
+ /* Common for X15/GPEVM */
+ pconf = core_padconf_array_essential_x15;
+ pconf_sz = ARRAY_SIZE(core_padconf_array_essential_x15);
+ iod = iodelay_cfg_array_x15;
+ iod_sz = ARRAY_SIZE(iodelay_cfg_array_x15);
+ }
+
+ __recalibrate_iodelay(pconf, pconf_sz, iod, iod_sz);
}
#endif
@@ -606,6 +626,12 @@ int board_eth_init(bd_t *bis)
ctrl_val |= 0x22;
writel(ctrl_val, (*ctrl)->control_core_control_io1);
+ /* The phy address for the AM572x IDK are different than x15 */
+ if (board_is_am572x_idk()) {
+ cpsw_data.slave_data[0].phy_addr = 0;
+ cpsw_data.slave_data[1].phy_addr = 1;
+ }
+
ret = cpsw_register(&cpsw_data);
if (ret < 0)
printf("Error %d registering CPSW switch\n", ret);
diff --git a/board/ti/am57xx/mux_data.h b/board/ti/am57xx/mux_data.h
index 3c007b76dd5b..b5ea8ad7c852 100644
--- a/board/ti/am57xx/mux_data.h
+++ b/board/ti/am57xx/mux_data.h
@@ -12,7 +12,7 @@
#include
-const struct pad_conf_entry core_padconf_array_essential[] = {
+const struct pad_conf_entry core_padconf_array_essential_x15[] = {
{GPMC_AD0, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/*
gpmc_ad0.vin3a_d0 */
{GPMC_AD1, (M2 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /*
gpmc_ad1.vin3a_d1 */
{GPMC_AD2, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/*
gpmc_ad2.vin3a_d2 */
@@ -264,6 +264,222 @@ const struct pad_conf_entry
core_padconf_array_essential[] = {
{RTCK, (M0 | PIN_INPUT_PULLDOWN)}, /* rtck.rtck */
};
+const struct pad_conf_entry core_padconf_array_essential_am572x_idk[] = {
+ {GPMC_A0, (M6 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /*
gpmc_a0.vin4b_d0 */
+ {GPMC_A1, (M6 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /*
gpmc_a1.vin4b_d1 */
+ {GPMC_A2, (M6 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /*
gpmc_a2.vin4b_d2 */
+ {GPMC_A3, (M6 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /*
gpmc_a3.vin4b_d3 */
+ {GPMC_A4, (M6 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /*
gpmc_a4.vin4b_d4 */
+ {GPMC_A5, (M6 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /*
gpmc_a5.vin4b_d
[U-Boot] [PATCH] board: ti: am57xx: Update EMIF SDRAM 1 and 3 Timings
From: Schuyler Patton
Update EMIF data based on recommendations from the now standard TI
EMIF tool version 1.1.1 based on 256MBx16 DDR3L Kingston D2516EC4BXGGB
data sheet
Update T_RRD from 5 to 6 based on AM57xx TRM -
Minimum number of DDR cycles from activate to ativate for a different
bank, minus 1.
Update T_CKESR from 4 to 3 based on AM57xx TRM - Minimum number of DDR
clocks cycles for which SDRAM must remain in self refresh, minus 1.
Signed-off-by: Schuyler Patton
Signed-off-by: Nishanth Menon
---
X15 BOM:
https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2B_BOM.xlsx
AM5728 Data sheet: http://www.ti.com/product/AM5728/datasheet
board/ti/am57xx/board.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 18416ef64ad9..fda0ed59c6b7 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -131,9 +131,9 @@ static const struct emif_regs
beagle_x15_emif2_ddr3_532mhz_emif_regs = {
.sdram_config2 = 0x0800,
.ref_ctrl = 0x40F1,
.ref_ctrl_final = 0x1035,
- .sdram_tim1 = 0xcccf36ab,
+ .sdram_tim1 = 0xcccf36b3,
.sdram_tim2 = 0x308f7fda,
- .sdram_tim3 = 0x409f88a8,
+ .sdram_tim3 = 0x407f88a8,
.read_idle_ctrl = 0x0005,
.zq_config = 0x5007190b,
.temp_alert_config = 0x,
--
2.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 2/2] cmd: fdt: add fdt overlay application subcommand
On Tue, Apr 5, 2016 at 5:03 PM, Pantelis Antoniou wrote: > Hi Maxime, > >> On Apr 4, 2016, at 11:25 , Maxime Ripard >> wrote: >> >> The device tree overlays are a good way to deal with user-modifyable >> boards or boards with some kind of an expansion mechanism where we can >> easily plug new board in (like the BBB or the raspberry pi). >> >> However, so far, the usual mechanism to deal with it was to have in Linux >> some driver detecting the expansion boards plugged in and then request >> these overlays using the firmware interface. >> >> That works in most cases, but in some cases, you might want to have the >> overlays applied before the userspace comes in. Either because the new >> board requires some kind of an early initialization, or because your root >> filesystem is accessed through that expansion board. >> >> The easiest solution in such a case is to simply have the component before >> Linux applying that overlay, removing all these drawbacks. >> [...] >> diff --git a/cmd/fdt_overlay.c b/cmd/fdt_overlay.c > > This looks it’s general libfdt code. > It should end up in libfdt/ so that others can use it, and eventually > be pushed upstream. +1. It really needs to go into libfdt first to avoid any re-licensing issues. Another option which Grant has suggested would be to extend the FDT format to include overlays as a whole. Then the kernel can apply them during unflattening. This would simplify things on the bootloader side. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: g_dnl: Change device class
On Fri, 8 Apr 2016 08:41:14 -0700
John Tobias wrote:
> Hi Lukas,
>
>
> On Fri, Apr 8, 2016 at 2:19 AM, Lukasz Majewski
> wrote:
>
> > Hi John,
> >
> > > The USB Mass Storage (ums) works in Windows, Linux and OS X (EL
> > > Capitan). But, not in OS X (Yosemite). By applying the said
> > > patch, it extends the ums support.
> > >
> > > Signed-off-by: John Tobias
> > > ---
> > > drivers/usb/gadget/g_dnl.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/usb/gadget/g_dnl.c
> > > b/drivers/usb/gadget/g_dnl.c index 2fa6da4..bd3aad9 100644
> > > --- a/drivers/usb/gadget/g_dnl.c
> > > +++ b/drivers/usb/gadget/g_dnl.c
> > > @@ -58,8 +58,8 @@ static struct usb_device_descriptor device_desc
> > > = { .bDescriptorType = USB_DT_DEVICE,
> > >
> > > .bcdUSB = __constant_cpu_to_le16(0x0200),
> > > - .bDeviceClass = USB_CLASS_COMM,
> > > - .bDeviceSubClass = 0x02, /*0x02:CDC-modem ,
> > > 0x00:CDC-serial*/
> > > + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> > > + .bDeviceSubClass = 0, /*0x02:CDC-modem , 0x00:CDC-serial*/
> >
> > Have you tested if this patch is not introducing any regression on
> > Linux and Windows?
> >
>
> The test what I did is like this:
>
> Linux:
> - Run ums to expose all my eMMC partition - shows all correctly
> - Run ums to expose only 1 partition of my eMMC - show correctly
>
> Windows:
> - Run ums to expose all my eMMC partition - it detects but it
> prompts, if I want to format it (due to a non windows partition)
> - Run ums to expose only the FAT32 partition - it show the
> partition correctly.
>
Ok, I see. Thanks for your effort on testing. I do appreciate it.
>
> Note: I have a patch to expose only 1 partition:
> e.g: ums 0 mmc 1:8
Yes, I've just received it. I will provide feedback shortly.
>
>
> >
> > >
> > > .idVendor = __constant_cpu_to_le16(CONFIG_G_DNL_VENDOR_NUM),
> > > .idProduct =
> > > __constant_cpu_to_le16(CONFIG_G_DNL_PRODUCT_NUM),
> >
> >
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> >
>
> Regards,
>
> John
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
pgpDtrYl2z6re.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tests: py: dfu: Add functionality to set different u-boot's dfu env variable
On Fri, 8 Apr 2016 10:29:31 -0600 Stephen Warren wrote: > On 04/08/2016 09:44 AM, Lukasz Majewski wrote: > > By default (on almost all systems) the dfu env variable, which > > defines available alt settings, is named as "dfu_alt_info". > > > > However on some platforms (i.e. Odroid XU3), the 'dfu_alt_info' is > > concatenated from other variables - namely 'dfu_alt_boot' and > > 'dfu_alt_system' at run time (when one types 'dfu 0 mmc 0' for > > first time). > > > > 'dfu_alt_boot' describes alt settings which depend on boot medium - > > for example boot loader's LBA sectors which are different on eMMC > > and SD card because of e.g. MBR/GPT. > > > > 'dfu_alt_system' describes board agnostic alt settings - like > > rootfs, kernel. On such system we can only append/modify this env > > variable. > > > > Because of the above, we must have way to modify other than > > "dfu_ale_info" variable to perform tests. > > > diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py > > > +# Optional values. > > +# Those values are necessary on boards like Odroid XU3, > > where > > +# - dfu alt info env variable is concatenated from boot > > medium dependent > > +# (dfu_alt_boot) and user defined (dfu_alt_system) > > variables > > +"alt_info_env_name": "dfu_alt_system", > > The previous value is also optional. I'd suggest simply prefixing > each optional value with the same text as already used: > > # This value is optional. > Ok, no problem. Best regards, Łukasz Majewski pgpHvzA8MSJsP.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tests: py: dfu: Add functionality to set different u-boot's dfu env variable
On Fri, 8 Apr 2016 10:28:06 -0600
Stephen Warren wrote:
> On 04/08/2016 09:44 AM, Lukasz Majewski wrote:
> > By default (on almost all systems) the dfu env variable, which
> > defines available alt settings, is named as "dfu_alt_info".
> >
> > However on some platforms (i.e. Odroid XU3), the 'dfu_alt_info' is
> > concatenated from other variables - namely 'dfu_alt_boot' and
> > 'dfu_alt_system' at run time (when one types 'dfu 0 mmc 0' for
> > first time).
> >
> > 'dfu_alt_boot' describes alt settings which depend on boot medium -
> > for example boot loader's LBA sectors which are different on eMMC
> > and SD card because of e.g. MBR/GPT.
> >
> > 'dfu_alt_system' describes board agnostic alt settings - like
> > rootfs, kernel. On such system we can only append/modify this env
> > variable.
> >
> > Because of the above, we must have way to modify other than
> > "dfu_ale_info" variable to perform tests.
>
> Uggh. That's a pretty nasty user-experience since it prevents the
> user from controlling what happens. U-Boot should never over-ride
> what the user requests for alt_info, but rather simply provide help
> to the user allowing them to make use of the system-supplied
> information if they want. I.e. dfu_alt_boot should be set at boot
> time based on code. The user should then be free to define
> dfu_alt_info as they see fit; either hard-coded, or including the
> value of $dfu_alt_boot /if/ they want.
>
> Anyway, I suppose since this feature exists, we have no choice but to
> support it.
This indeed could be done a bit differently.
>
> > diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py
> > index df3b561..1ed6020 100644
> > --- a/test/py/tests/test_dfu.py
> > +++ b/test/py/tests/test_dfu.py
> > @@ -44,6 +44,11 @@ env__dfu_configs = (
> > # configurations, but don't want to test every single
> > transfer size # on each, to avoid bloating the overall time taken
> > by testing. "test_sizes": (63, 64, 65),
> > +# Optional values.
> > +# Those values are necessary on boards like Odroid XU3,
> > where
> > +# - dfu alt info env variable is concatenated from boot
> > medium dependent
> > +# (dfu_alt_boot) and user defined (dfu_alt_system)
> > variables
> > +"alt_info_env_name": "dfu_alt_system",
>
> I think the "- " and leading space should be dropped; this isn't a
> list of items. I'd suggest re-phrasing this as:
>
> # The name of the environment variable that the the dfu command reads
> # alt info from. If unspecified, this defaults to dfu_alt_info, which
> is # valid for most systems. Some systems use a different variable
> name. # One example is the Odroid XU3, which automatically generates
> # $dfu_alt_info, each time the dfu command is run, by concatenating
> # $dfu_alt_boot and $dfu_alt_system.
+1
>
> > },
> > )
> >
> > @@ -124,7 +129,12 @@ def test_dfu(u_boot_console,
> > env__usb_dev_port, env__dfu_config): u_boot_console.log.action(
> > 'Starting long-running U-Boot dfu shell command')
> >
> > -cmd = 'setenv dfu_alt_info "%s"' %
> > env__dfu_config['alt_info']
> > +dfu_alt_info_env = "dfu_alt_info"
> > +if "alt_info_env_name" in env__dfu_config:
> > + dfu_alt_info_env =
> > env__dfu_config['alt_info_env_name']
>
> That can be just:
> dfu_alt_info_env = env__dfu_config.get('alt_info_env_name', \
> 'dfu_alt_info')
This is the idiom which I was looking for :-). Thanks for hint.
I will rewrite it in such way.
>
> > +
> > +cmd = 'setenv "%s" "%s"' % (dfu_alt_info_env,
> > +env__dfu_config['alt_info'])
> > u_boot_console.run_command(cmd)
> >
> > cmd = 'dfu 0 ' + env__dfu_config['cmd_params']
>
>
pgpCdHK7WHav9.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ums - expose selected partition/s
By applying this patch, it will give us some flexibility to expose
a selected partition/s.
e.g:
1. To expose several partitions
ums 0 mmc 0:1,0:6
2. To expose the all partitions
ums 0 mmc 0:0
3. To expose multiple partititions on several devices
ums 0 mmc 0:1,1:6
Signed-off-by: John Tobias
---
cmd/usb_mass_storage.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c
index 0415591..3e6ec50 100644
--- a/cmd/usb_mass_storage.c
+++ b/cmd/usb_mass_storage.c
@@ -50,14 +50,16 @@ static void ums_fini(void)
#define UMS_NAME_LEN 16
-static int ums_init(const char *devtype, const char *devnums)
+static int ums_init(const char *devtype, const char *devnums_part)
{
- char *s, *t, *devnum, *name;
+ char *s, *t, *devnum_part, *name;
block_dev_desc_t *block_dev;
+ disk_partition_t info;
+ int partnum;
int ret;
struct ums *ums_new;
- s = strdup(devnums);
+ s = strdup(devnums_part);
if (!s)
return -1;
@@ -65,12 +67,14 @@ static int ums_init(const char *devtype, const char
*devnums)
ums_count = 0;
for (;;) {
- devnum = strsep(&t, ",");
- if (!devnum)
+ devnum_part = strsep(&t, ",");
+ if (!devnum_part)
break;
- ret = get_device(devtype, devnum, &block_dev);
- if (ret < 0)
+ partnum = get_device_and_partition(devtype, devnum_part,
+&block_dev, &info, 1);
+
+ if (partnum < 0)
goto cleanup;
/* f_mass_storage.c assumes SECTOR_SIZE sectors */
@@ -86,10 +90,18 @@ static int ums_init(const char *devtype, const char
*devnums)
}
ums = ums_new;
+ /* if partnum = 0, expose the whole device */
+ if (partnum == 0) {
+ ums[ums_count].start_sector = 0;
+ ums[ums_count].num_sectors = block_dev->lba;
+ } else {
+ ums[ums_count].start_sector = info.start;
+ ums[ums_count].num_sectors = info.size;
+ }
+
ums[ums_count].read_sector = ums_read_sector;
ums[ums_count].write_sector = ums_write_sector;
- ums[ums_count].start_sector = 0;
- ums[ums_count].num_sectors = block_dev->lba;
+
name = malloc(UMS_NAME_LEN);
if (!name) {
ret = -1;
@@ -230,6 +242,6 @@ cleanup_ums_init:
U_BOOT_CMD(ums, 4, 1, do_usb_mass_storage,
"Use the UMS [USB Mass Storage]",
- " [] e.g. ums 0 mmc 0\n"
+ " [] e.g. ums 0 mmc 0:0\n"
"devtype defaults to mmc"
);
--
2.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] spl: Support loading a FIT from FAT FS
On Tue, Apr 05, 2016 at 10:00:55AM +0530, Lokesh Vutla wrote: > Detect a FIT when loading from a FAT File system and handle it using the > new FIT SPL support. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Tue, Apr 05, 2016 at 02:07:46PM +0530, Mugunthan V N wrote: > Scott/Tom > > On Saturday 02 April 2016 05:55 AM, Tom Rini wrote: > > On Fri, Apr 01, 2016 at 06:45:03PM -0500, Scott Wood wrote: > >> On Fri, 2016-04-01 at 19:41 -0400, Tom Rini wrote: > >>> On Fri, Apr 01, 2016 at 06:07:18PM -0500, Scott Wood wrote: > >>> > On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > >> Add CONFIG_NAND as a Kconfig option so that it can be selected > >> using menuconfig or defconfig. > >> > >> Signed-off-by: Mugunthan V N > > > > Good but you need to update configs/ to remove NAND from > > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > NACK > > That CONFIG_NAND is a target-local option used by some boards to indicate > boot > source. It is not equivalent to CONFIG_CMD_NAND which is what enables > the > NAND subsystem. > >>> > >>> Exactly! We need to have 'NAND' moved from CONFIG_SYS_EXTRA_OPTIONS and > >>> into a real Kconfig entry. That said, I think this might have forgotten > >>> to enable it in other places too but just 'NAND' needs to migrate out of > >>> where it is. > >> > >> If we must start using NAND rather than CMD_NAND to enable the NAND > >> subsystem > >> (which is what this patch does), then a lot more than that needs to > >> change. > >> We'll need a new name for the boot source selection, and we'll need to > >> kconfigize all the boards that enable CONFIG_CMD_NAND via the board config > >> header. > > > > OK, I see your point now too. Yes, we need to tackle NAND/CMD_NAND > > Kconfig stuff (including the tangled web of CMD_NAND being how we toggle > > NAND the functionality) as a pre-patch series to this. But it needs > > doing :) > > Should I be moving back NAND to "CONFIG_SYS_EXTRA_OPTIONS"? > > Since CONFIG_CMD_NAND is used to enable NAND subsystem, so move > CONFIG_CMD_NAND to drivers/mtd/nand/Kconfig? > > or am I missing something? I would like to see, but I want to hear Scott's opinion, move to CONFIG_NAND is what enables NAND support for everyone (so yes, lots of defconfigs will need an update) so that we can move it all over to Kconfig. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: spi: Read default speed, mode values from DT
On Thu, Apr 07, 2016 at 09:02:26PM +0530, Vignesh R wrote:
> In case of DT boot, don't read default speed and mode for SPI from
> CONFIG_*, instead read from DT node. This will make sure that boards
> with multiple SPI/QSPI controllers can be probed at different
> bus frequencies and modes.
>
> Signed-off-by: Vignesh R
> ---
> cmd/sf.c | 2 ++
> drivers/spi/spi-uclass.c | 8 ++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/sf.c b/cmd/sf.c
> index 42862d9d921a..4c40d5104422 100644
> --- a/cmd/sf.c
> +++ b/cmd/sf.c
> @@ -88,6 +88,8 @@ static int do_spi_flash_probe(int argc, char * const argv[])
> #ifdef CONFIG_DM_SPI_FLASH
> struct udevice *new, *bus_dev;
> int ret;
> + /* In DM mode defaults wiil be taken from DT */
> + speed = -1, mode = -1;
> #else
> struct spi_flash *new;
> #endif
> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> index 5561f36762f9..55ebb5ef19b7 100644
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -264,6 +264,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int
> mode,
> struct udevice **busp, struct spi_slave **devp)
> {
> struct udevice *bus, *dev;
> + struct dm_spi_slave_platdata *plat;
> bool created = false;
> int ret;
>
> @@ -280,8 +281,6 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int
> mode,
>* SPI flash chip - we will bind to the correct driver.
>*/
> if (ret == -ENODEV && drv_name) {
> - struct dm_spi_slave_platdata *plat;
> -
> debug("%s: Binding new device '%s', busnum=%d, cs=%d,
> driver=%s\n",
> __func__, dev_name, busnum, cs, drv_name);
> ret = device_bind_driver(bus, drv_name, dev_name, &dev);
> @@ -308,6 +307,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed,
> int mode,
> slave->dev = dev;
> }
>
> + plat = dev_get_parent_platdata(dev);
> + if (speed == -1)
> + speed = plat->max_hz;
> + if (mode == -1)
> + mode = plat->mode;
> ret = spi_set_speed_mode(bus, speed, mode);
> if (ret)
> goto err;
I like the concept but if it can fail, passing -1 for speed/mode seems
like a bad idea and we should just fail.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: README: link to example hook scripts
On Wed, Apr 06, 2016 at 11:46:59AM -0600, Stephen Warren wrote: > From: Stephen Warren > > When implementing test/py hook scripts, it's helpful to read some working > examples. Provide a link to some. The link was mentioned in the commit > message which first added test/py, but not in any documentation file. > > Suggested-by: Lukasz Majewski > Signed-off-by: Stephen Warren Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2] spl: Add an option to load a FIT containing U-Boot from FS
On Tue, Apr 05, 2016 at 10:00:54AM +0530, Lokesh Vutla wrote: > This provides a way to load a FIT containing U-Boot and a selection of device > tree files from a File system. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: mmc: omap_hsmmc: Fix conversion of address to a pointer
On Mon, Apr 04, 2016 at 03:22:49PM +0530, Mugunthan V N wrote:
> omap_hsmmc driver directly typecasts fdt_addr_t to a pointer.
> This is not strictly correct, as it gives a build warning when
> fdt_addr_t is u64. So, use map_physmem for a proper typecasts.
>
> This is inspired by commit 167efe01bc5a9 ("dm: ns16550: Use an address
> instead of a pointer for the uart base")
>
> drivers/mmc/omap_hsmmc.c: In function ‘omap_hsmmc_ofdata_to_platdata’:
> drivers/mmc/omap_hsmmc.c:776:20: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
> priv->base_addr = (struct hsmmc *)dev_get_addr(dev);
> ^
>
> Signed-off-by: Mugunthan V N
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] common: env: support sata device
On Sun, Apr 03, 2016 at 09:52:13PM +0800, Peng Fan wrote: > Introduce env support for sata device. > 1. Implement write_env/read_env/env_relocate_spec/saveenv/sata_get_env_dev > 2. If want to enable this feature, define CONFIG_ENV_IS_IN_SATA, and >define CONFIG_SYS_SATA_ENV_DEV or implement your own sata_get_ev_dev. > > Signed-off-by: Peng Fan > Cc: Simon Glass > Cc: Joe Hershberger > Cc: Bin Meng > Cc: Stefan Roese > Cc: Heiko Schocher > Cc: Stuart Longland > Cc: Maxime Ripard > Cc: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am57x: Move CONS_INDEX to Kconfig
On Wed, Apr 06, 2016 at 09:59:34PM -0500, Daniel Allred wrote: > - Move the CONS_INDEX selection out of CONFIG_SYS_EXTRA_OPTIONS and > into Kconfig proper. > - Edit the relevant am57x configs to remove the now unneeded > CONFIG_SYS_EXTRA_OPTIONS. > > Signed-off-by: Daniel Allred Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spl: Support loading a FIT from SPI
On Wed, Apr 06, 2016 at 05:33:00PM +0530, Lokesh Vutla wrote: > Detect a FIT when loading from SPI and handle it using the > new FIT SPL support. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/10] driver model bring-up of dwc3 usb peripheral
On Wed, Apr 06, 2016 at 05:16:02PM -0600, Simon Glass wrote: > Hi, > > On 31 March 2016 at 09:24, Marek Vasut wrote: > > On 03/31/2016 05:11 PM, Tom Rini wrote: > >> On Thu, Mar 31, 2016 at 04:10:49PM +0200, Michal Simek wrote: > >>> Hi Tom, > >>> > >>> On 15.3.2016 13:14, Mugunthan V N wrote: > This patch series enables dwc3 usb driver to adopt driver model. > This has been tested on AM437x evm sk (logs [1]) by loading > kernel through usb ether > > Also pushed a branch for testing [2] > > [1] - http://pastebin.ubuntu.com/15391169/ > [2] - git://git.ti.com/~mugunthanvnm/ti-u-boot/mugunth-ti-u-boot.git > dm-dwc3 > > Kishon Vijay Abraham I (1): > configs: am43xx: Add am43xx_evm_usbspl_defconfig > > Mugunthan V N (8): > drivers: usb: dwc3: remove devm_zalloc from linux_compact > drivers: usb: dwc3-omap: move usb_gadget_handle_interrupts from board > files to drivers > am437x: board: do not register usb devices when CONFIG_DM_USB is > defined > dra7xx: board: do not register usb devices when CONFIG_DM_USB is > defined > drivers: usb: dwc3: add ti dwc3 misc driver for wrapper > drivers: usb: common: add support to get maximum speed from dt > drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model > support > defconfig: am437x_sk_evm: enable usb driver model > > Tom Rini (1): > am43xx: Add USB device boot support to SPL > > board/ti/am43xx/MAINTAINERS | 1 + > board/ti/am43xx/board.c | 52 +--- > board/ti/am57xx/board.c | 11 -- > board/ti/dra7xx/evm.c | 13 +- > configs/am437x_sk_evm_defconfig | 4 + > configs/am43xx_evm_usbspl_defconfig | 9 ++ > drivers/Makefile| 2 + > drivers/usb/common/common.c | 29 + > drivers/usb/dwc3/core.c | 64 +- > drivers/usb/dwc3/core.h | 6 + > drivers/usb/dwc3/dwc3-omap.c| 230 > +++- > drivers/usb/dwc3/gadget.c | 2 +- > drivers/usb/dwc3/linux-compat.h | 5 - > drivers/usb/dwc3/ti_usb_phy.c | 1 + > drivers/usb/gadget/gadget_chips.h | 2 + > include/configs/am43xx_evm.h| 13 ++ > include/linux/usb/otg.h | 9 ++ > 17 files changed, 406 insertions(+), 47 deletions(-) > create mode 100644 configs/am43xx_evm_usbspl_defconfig > > >>> > >>> Are you going to take this directly or this should go via USB tree? > >> > >> Marek, do you want this? Or want me to? > >> > > That is Lukasz. > > This series has ended up in my patchwork queue, but there seem to be > quite a few unapplied, dependent patches. Tom please let me know what > you'd like me to do here. ... I didn't think it depended on stuff but I do need to do another go-round from the queue and apply stuff. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] spl: Make sure destination address is dma aligned when loading fit
On Wed, Apr 06, 2016 at 05:32:59PM +0530, Lokesh Vutla wrote: > Peripherals like spi etc. uses DMA for transfers. So, when loading the fit > image the destination address should be dma aligned. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fsl-qoriq master
On Wed, Apr 06, 2016 at 10:35:25AM -0700, York Sun wrote: > Tom, > > The following changes since commit 4ed6ed3c27a069a00c8a557d606a05276cc4653e: > > Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2016-04-04 > 14:34:09 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-fsl-qoriq.git master > > for you to fetch changes up to 3c1d218a1d3048fb576677c47eab43049d0b7778: > > armv8: LS2080A: Consolidate LS2080A and LS2085A (2016-04-06 10:26:46 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fastboot: OUT transaction length must be aligned to wMaxPacketSize
On Fri, Apr 08, 2016 at 02:11:48AM +0300, Sam Protsenko wrote: [snip] > The only actual documentation for fastboot protocol I found is [1], > and I don't see any mention of alignment there at all. So it wouldn't > surprise me if that patch was done just out of of empiric > observations. Which doesn't make it any less significant. [snip] > [1] > https://android.googlesource.com/platform/system/core/+/master/fastboot/fastboot_protocol.txt So, the protocol says "Max packet size must be 64 bytes for full-speed, 512 bytes for high-speed and 1024 bytes for Super Speed USB.". What are wMaxPacketSize and ep->maxpacket in these cases, both the TI+DWC3 ones, Broadcom+DWC2 and if someone can grab one, TI+MUSB. And then, what exactly does everyone failure logs look like, perhaps with some annotations where it fails? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A problem about 'sf probe' using DM_SPI
Hi Qianyu,
On 25 March 2016 at 03:34, Qianyu Gong wrote:
> Hi Simon,
>
>
>
> I think I’m not very clear with this code in common/cmd_sf.c:
>
> “
>
> # ifdef CONFIG_DM_SPI_FLASH
>
>/* Remove the old device, otherwise probe will just be a nop */
>
>ret = spi_find_bus_and_cs(bus, cs, &bus_dev, &new);
>
>if (!ret) {
>
> device_remove(new);
>
> device_unbind(new);
>
> }
>
> ”
>
> I may understand the remove but why need to unbind the device?
This is because otherwise 'sf probe' would be a nop if the device
already existed. The spi_flash_probe_bus_cs() call will simply return
the existing device. If something has changed on the bus, it would be
ignored.
>
> The unbind would cause a series of free operations on the device list,
> correct?
Yes
>
>
>
> Then if I probe a flash twice, at the second time the driver model will
> create
>
> a new flash named ‘spi_flash@xx:xx’ using default settings because it
> doesn’t
>
> find such a device in the device list and never probes it from the board’s
> fdt again.
Yes.
>
>
>
> => dm tree
>
> Class Probed Name
>
>
>
> root[ + ]root_driver
>
> simple_bus [ + ]`-- soc
>
> spi [ + ] |-- dspi@210
>
> spi_flash [ ]||-- n25q128a
>
> spi_flash [ + ]| |-- spi_flash@1:1
>
> spi_flash [ + ]| `-- spi_flash@1:2
>
>
>
> Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it doesn’t
> cause
>
> issues on our boards. But if an SPI flash which only supports SPI_MODE_0 is
> used,
>
> I think it wouldn’t work properly from the second probe.
>
>
>
>
>
> Sorry if there is something wrong with my understandings.
>
> Just because I found my flash’s name was changed to spi-flash@xx:xx in dm
> tree
>
> after several probes, I began to read something about driver model.J
Yes I think removing the unbind would be OK, except that we need a way
to show the messages at the end of spi_flash_scan().
Probably these messages should move out of the uclass and into a
separate call. We could add a function like spi_flash_show(struct
udevice *dev) and call it from do_spi_flash_probe() and perhaps
saveenv().
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8/ls2080a: configure PMU's PCTBENR to enable WDT
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Yunhui
> Cui
> Sent: Friday, April 08, 2016 3:57 PM
> To: york sun
> Cc: Yunhui Cui; u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH] armv8/ls2080a: configure PMU's PCTBENR to
> enable WDT
>
> From: Yunhui Cui
>
> The SP805-WDT module on LS2080A and LS2085A, requires configuration of
> PMU's PCTBENR register to enable watchdog counter decrement and reset
> signal generation. In order not to affect the sp805wdt driver frame, we
> enable the watchdog clk in advance.
>
> Signed-off-by: Yunhui Cui
> ---
> arch/arm/cpu/armv8/fsl-layerscape/soc.c| 18 ++
> arch/arm/include/asm/arch-fsl-layerscape/soc.h | 1 +
> board/freescale/ls2080aqds/ls2080aqds.c| 2 ++
> board/freescale/ls2080ardb/ls2080ardb.c| 2 ++
> 4 files changed, 23 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index a76447e..06c950f 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -17,6 +17,24 @@
> #endif
>
> DECLARE_GLOBAL_DATA_PTR;
> +#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> +/*
> + * Set the bit corresponding to our watchDog-id in the
> + * PMU-Physical Core Time Base Enable Register (PCTBENR)
> + * to allow the WDT counter to decrement and raise a reset
> + * request (if configured in the WDTCONTROL register).
> + */
This comment does not describe correctly the flow you are using in the function
below.
> +void enable_watchdog_clk(void)
> +{
> + #define FSL_PMU_REG_BASE0x1E3
> + #define FSL_PMU_PCTBENR_OFFSET 0x8A0
Can we move the #define into a proper header file
'arch/arm/include/asm/arch-fsl-layerscape/config.h':
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-fsl-layerscape/config.h;h=ceefe431fdcbd6aa3a176bc3631338c62d4bb976;hb=HEAD
Regards,
Bhupesh
> + u32 pmu_val;
> +
> + pmu_val = *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET);
> + *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET) = pmu_val |
> 0xff;
> +} #endif
> +
>
> #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> /*
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> index 56989e1..32c9185 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> @@ -91,6 +91,7 @@ void fsl_lsch2_early_init_f(void); #endif
>
> void cpu_name(char *name);
> +void enable_watchdog_clk(void);
> #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
> void erratum_a009635(void);
> #endif
> diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
> b/board/freescale/ls2080aqds/ls2080aqds.c
> index e1a521d..8ebc96a 100644
> --- a/board/freescale/ls2080aqds/ls2080aqds.c
> +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> @@ -213,6 +213,8 @@ int board_init(void)
> select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
> rtc_enable_32khz_output();
>
> + enable_watchdog_clk();
> +
> return 0;
> }
>
> diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
> b/board/freescale/ls2080ardb/ls2080ardb.c
> index 8201048..ad8324a 100644
> --- a/board/freescale/ls2080ardb/ls2080ardb.c
> +++ b/board/freescale/ls2080ardb/ls2080ardb.c
> @@ -181,6 +181,8 @@ int board_init(void)
> /* invert AQR405 IRQ pins polarity */
> out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR405_IRQ_MASK);
>
> + enable_watchdog_clk();
> +
> return 0;
> }
>
> --
> 2.1.0.27.g96db324
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arc: Add virt_to_phys() stub
Hi Marek,
On Fri, 2016-04-08 at 19:23 +0200, Marek Vasut wrote:
> On 04/08/2016 07:08 PM, Alexey Brodkin wrote:
> >
> > Hi Marek,
> >
> > On Fri, 2016-04-08 at 19:05 +0200, Marek Vasut wrote:
> > >
> > > On 04/08/2016 07:00 PM, Alexey Brodkin wrote:
> > > >
> > > >
> > > > Commit cf7c93cdd755 "usb: ehci: Implement V2P mapping"
> > > > introduced usage of virt_to_phys() in ehci-hcd.
> > > >
> > > > Since there was no implementation of virt_to_phys() for ARC
> > > > compilation of the ehci-generic driver failed.
> > > >
> > > > This change adds virt_to_phys() stub for ARC so now
> > > > USB driver for AXS101 board could be built again.
> > > >
> > > > Signed-off-by: Alexey Brodkin
> > > > Cc: Marek Vasut
> > > > Cc: Daniel Schwierzeck
> > > > Cc: Hans de Goede
> > > > ---
> > > > arch/arc/include/asm/io.h | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
> > > > index 281682c..b6f7724 100644
> > > > --- a/arch/arc/include/asm/io.h
> > > > +++ b/arch/arc/include/asm/io.h
> > > > @@ -239,4 +239,9 @@ static inline int __raw_writesl(unsigned int addr,
> > > > void *data, int longlen)
> > > > #define setbits_8(addr, set) setbits(8, addr, set)
> > > > #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
> > > >
> > > > +static inline phys_addr_t virt_to_phys(void *vaddr)
> > > > +{
> > > > + return (phys_addr_t)((unsigned long)vaddr);
> > > > +}
> > > > +
> > > > #endif /* __ASM_ARC_IO_H */
> > > >
> > > Sorry for breaking your arch.
> > That happens. No problem.
> > Real problem though is we still don't have autobuilder that
> > catches these kinds of trivial flaws.
> Synopsys can sponsor one , anytime ;-)
Ok I'll discuss this with my manager :)
> > I don't build for all arches as well before submitting patches so
> > before autobuilder is there we'll see more issues of that kind :)
> buildman can help you here.
Oh cool... I didn't know about it. Do you really use it? (kidding)
For the record could you please ack this change so I may go forward
and apply it to my tree?
-Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8 v2] usb: gadget: Move CONFIG_USB_GADGET_VBUS_DRAW to Kconfig
On Fri, Apr 8, 2016 at 7:37 PM, Stephen Warren wrote: > On 04/07/2016 09:13 AM, Semen Protsenko wrote: >> >> From: Sam Protsenko >> >> The description was borrowed from kernel. Definitions were added to >> defconfig files in a way that "make savedefconfig" generates exactly >> the same file as used defconfig. >> >> Boards using 0 mA as CONFIG_USB_GADGET_VBUS_DRAW value were moved to use >> 2 mA (as minimal allowed by Kconfig). > > > Acked-by: Stephen Warren > > (although I only got patch 1/8 and not patches 2-8 this time around) > Thanks. I will resend others too, soon enough. Just continue working on other patch v2 right now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8 v2] usb: gadget: Move CONFIG_USB_GADGET_VBUS_DRAW to Kconfig
On 04/08/2016 07:23 PM, Sam Protsenko wrote: > On Fri, Apr 8, 2016 at 7:37 PM, Stephen Warren wrote: >> On 04/07/2016 09:13 AM, Semen Protsenko wrote: >>> >>> From: Sam Protsenko >>> >>> The description was borrowed from kernel. Definitions were added to >>> defconfig files in a way that "make savedefconfig" generates exactly >>> the same file as used defconfig. >>> >>> Boards using 0 mA as CONFIG_USB_GADGET_VBUS_DRAW value were moved to use >>> 2 mA (as minimal allowed by Kconfig). >> >> >> Acked-by: Stephen Warren >> >> (although I only got patch 1/8 and not patches 2-8 this time around) >> > > Thanks. I will resend others too, soon enough. Just continue working > on other patch v2 right now. > OK, send the whole series please -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arc: Add virt_to_phys() stub
On 04/08/2016 07:00 PM, Alexey Brodkin wrote:
> Commit cf7c93cdd755 "usb: ehci: Implement V2P mapping"
> introduced usage of virt_to_phys() in ehci-hcd.
>
> Since there was no implementation of virt_to_phys() for ARC
> compilation of the ehci-generic driver failed.
>
> This change adds virt_to_phys() stub for ARC so now
> USB driver for AXS101 board could be built again.
>
> Signed-off-by: Alexey Brodkin
> Cc: Marek Vasut
> Cc: Daniel Schwierzeck
> Cc: Hans de Goede
> ---
> arch/arc/include/asm/io.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
> index 281682c..b6f7724 100644
> --- a/arch/arc/include/asm/io.h
> +++ b/arch/arc/include/asm/io.h
> @@ -239,4 +239,9 @@ static inline int __raw_writesl(unsigned int addr, void
> *data, int longlen)
> #define setbits_8(addr, set) setbits(8, addr, set)
> #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
>
> +static inline phys_addr_t virt_to_phys(void *vaddr)
> +{
> + return (phys_addr_t)((unsigned long)vaddr);
> +}
> +
> #endif /* __ASM_ARC_IO_H */
Acked-by: Marek Vasut
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arc: Add virt_to_phys() stub
On 04/08/2016 07:08 PM, Alexey Brodkin wrote:
> Hi Marek,
>
> On Fri, 2016-04-08 at 19:05 +0200, Marek Vasut wrote:
>> On 04/08/2016 07:00 PM, Alexey Brodkin wrote:
>>>
>>> Commit cf7c93cdd755 "usb: ehci: Implement V2P mapping"
>>> introduced usage of virt_to_phys() in ehci-hcd.
>>>
>>> Since there was no implementation of virt_to_phys() for ARC
>>> compilation of the ehci-generic driver failed.
>>>
>>> This change adds virt_to_phys() stub for ARC so now
>>> USB driver for AXS101 board could be built again.
>>>
>>> Signed-off-by: Alexey Brodkin
>>> Cc: Marek Vasut
>>> Cc: Daniel Schwierzeck
>>> Cc: Hans de Goede
>>> ---
>>> arch/arc/include/asm/io.h | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
>>> index 281682c..b6f7724 100644
>>> --- a/arch/arc/include/asm/io.h
>>> +++ b/arch/arc/include/asm/io.h
>>> @@ -239,4 +239,9 @@ static inline int __raw_writesl(unsigned int addr, void
>>> *data, int longlen)
>>> #define setbits_8(addr, set) setbits(8, addr, set)
>>> #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
>>>
>>> +static inline phys_addr_t virt_to_phys(void *vaddr)
>>> +{
>>> + return (phys_addr_t)((unsigned long)vaddr);
>>> +}
>>> +
>>> #endif /* __ASM_ARC_IO_H */
>>>
>> Sorry for breaking your arch.
>
> That happens. No problem.
> Real problem though is we still don't have autobuilder that
> catches these kinds of trivial flaws.
Synopsys can sponsor one , anytime ;-)
> I don't build for all arches as well before submitting patches so
> before autobuilder is there we'll see more issues of that kind :)
buildman can help you here.
> -Alexey
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arc: Add virt_to_phys() stub
Hi Marek,
On Fri, 2016-04-08 at 19:05 +0200, Marek Vasut wrote:
> On 04/08/2016 07:00 PM, Alexey Brodkin wrote:
> >
> > Commit cf7c93cdd755 "usb: ehci: Implement V2P mapping"
> > introduced usage of virt_to_phys() in ehci-hcd.
> >
> > Since there was no implementation of virt_to_phys() for ARC
> > compilation of the ehci-generic driver failed.
> >
> > This change adds virt_to_phys() stub for ARC so now
> > USB driver for AXS101 board could be built again.
> >
> > Signed-off-by: Alexey Brodkin
> > Cc: Marek Vasut
> > Cc: Daniel Schwierzeck
> > Cc: Hans de Goede
> > ---
> > arch/arc/include/asm/io.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
> > index 281682c..b6f7724 100644
> > --- a/arch/arc/include/asm/io.h
> > +++ b/arch/arc/include/asm/io.h
> > @@ -239,4 +239,9 @@ static inline int __raw_writesl(unsigned int addr, void
> > *data, int longlen)
> > #define setbits_8(addr, set) setbits(8, addr, set)
> > #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
> >
> > +static inline phys_addr_t virt_to_phys(void *vaddr)
> > +{
> > + return (phys_addr_t)((unsigned long)vaddr);
> > +}
> > +
> > #endif /* __ASM_ARC_IO_H */
> >
> Sorry for breaking your arch.
That happens. No problem.
Real problem though is we still don't have autobuilder that
catches these kinds of trivial flaws.
I don't build for all arches as well before submitting patches so
before autobuilder is there we'll see more issues of that kind :)
-Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arc: Add virt_to_phys() stub
Commit cf7c93cdd755 "usb: ehci: Implement V2P mapping"
introduced usage of virt_to_phys() in ehci-hcd.
Since there was no implementation of virt_to_phys() for ARC
compilation of the ehci-generic driver failed.
This change adds virt_to_phys() stub for ARC so now
USB driver for AXS101 board could be built again.
Signed-off-by: Alexey Brodkin
Cc: Marek Vasut
Cc: Daniel Schwierzeck
Cc: Hans de Goede
---
arch/arc/include/asm/io.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 281682c..b6f7724 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -239,4 +239,9 @@ static inline int __raw_writesl(unsigned int addr, void
*data, int longlen)
#define setbits_8(addr, set) setbits(8, addr, set)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+static inline phys_addr_t virt_to_phys(void *vaddr)
+{
+ return (phys_addr_t)((unsigned long)vaddr);
+}
+
#endif /* __ASM_ARC_IO_H */
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arc: Add virt_to_phys() stub
On 04/08/2016 07:00 PM, Alexey Brodkin wrote:
> Commit cf7c93cdd755 "usb: ehci: Implement V2P mapping"
> introduced usage of virt_to_phys() in ehci-hcd.
>
> Since there was no implementation of virt_to_phys() for ARC
> compilation of the ehci-generic driver failed.
>
> This change adds virt_to_phys() stub for ARC so now
> USB driver for AXS101 board could be built again.
>
> Signed-off-by: Alexey Brodkin
> Cc: Marek Vasut
> Cc: Daniel Schwierzeck
> Cc: Hans de Goede
> ---
> arch/arc/include/asm/io.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
> index 281682c..b6f7724 100644
> --- a/arch/arc/include/asm/io.h
> +++ b/arch/arc/include/asm/io.h
> @@ -239,4 +239,9 @@ static inline int __raw_writesl(unsigned int addr, void
> *data, int longlen)
> #define setbits_8(addr, set) setbits(8, addr, set)
> #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
>
> +static inline phys_addr_t virt_to_phys(void *vaddr)
> +{
> + return (phys_addr_t)((unsigned long)vaddr);
> +}
> +
> #endif /* __ASM_ARC_IO_H */
>
Sorry for breaking your arch.
Acked-by: Marek Vasut
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ITEAD Board (A20) fails to communicate on boot unless UART is connected
I'm trying to resolve a strange networking issue with the ITEAD Core EVB + AW2041 module. If I connect all 3 UART wires (GND, RCV & TX) between the board and a USB UART device: I get an IP 100% of the time. If I connect only TX & RCV: I get an IP 100%. If I connect TX & GND, I get an IP 100%. But, if I only connect RCV and GND... I do not get an IP. Using WireShark on the DHCP server, I see no traffic is generated by the device. If I connect the UART after booting, it will not work, even if I send DHCPCD commands, or reboot. The only thing that seems to work is if I apply power while the UART is connected. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8 v2] usb: gadget: Move CONFIG_USB_GADGET_VBUS_DRAW to Kconfig
On 04/07/2016 09:13 AM, Semen Protsenko wrote: From: Sam Protsenko The description was borrowed from kernel. Definitions were added to defconfig files in a way that "make savedefconfig" generates exactly the same file as used defconfig. Boards using 0 mA as CONFIG_USB_GADGET_VBUS_DRAW value were moved to use 2 mA (as minimal allowed by Kconfig). Acked-by: Stephen Warren (although I only got patch 1/8 and not patches 2-8 this time around) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] tests: py: dfu: Provide functionality to set test and dummy files alt settings
On 04/08/2016 09:44 AM, Lukasz Majewski wrote: After concatenation of "dfu_alt_info" variable from "dfu_alt_boot" and "dfu_alt_system" it may happen that test and dummy files alt settings are different than default 0 and 1. This patch provides ability to set different values for them. It was the simplest possible solution - akin to the one from original bash dfu tests. diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py +# - after concatenation dfu alt settings for test and dummy files are +# moved from 0 and 1 to other values Similar formatting comments to the previous patch. I'd also re-word this to be much more generic, and simply state the it allows different alt settings to be used, rather than tieing the description to one possible reason why you might want to do that. +"alt_num_test_file": "5", +"alt_num_dummy_file": "6", This feels fragile. What if $dfu_alt_boot changes length? Does it make more sense to: (a) Set alt_info_env_name to dfu_alt_boot instead, so that the settings specified by the test are always at a known position in the list, so we can always use alt setting 0 and 1. or: (b) Use names rather than numbers for the alt setting? Those should be position-independent. Presumably this would require a slightly large code change, since we'd need to move from %d to %s conversions when constructing the dfu command string, but that should be very easy. If you take this approach, I'd suggest making the configuration file name (alt_num_*_file above) match the Python variable name (alt_setting_*_file) for consistency. (c) Provide a way for the user to turn off the auto-concatenation feature. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: Replace CONFIG_SYS_INIT_RAM_END with CONFIG_SYS_INIT_RAM_SIZE
Hi York, On Wed, 6 Apr 2016 13:51:57 -0700 York Sun york@nxp.com wrote: > CONFIG_SYS_INIT_RAM_SIZE may be used out of the board header file. > Some boards use CONFIG_SYS_INIT_RAM_END for the same purpose. To > unify the macros, use CONFIG_SYS_INIT_RAM_SIZE for all. > > Signed-off-by: York Sun > CC: Mario Six > > --- > > include/configs/BSC9131RDB.h |4 ++-- > include/configs/BSC9132QDS.h |4 ++-- > include/configs/C29XPCIE.h |4 ++-- > include/configs/P1010RDB.h |4 ++-- > include/configs/a3m071.h |4 ++-- > include/configs/ac14xx.h |4 ++-- > include/configs/dlvision-10g.h |4 ++-- > include/configs/io.h |4 ++-- > include/configs/iocon.h|4 ++-- > include/configs/o2dnt-common.h |6 +++--- > 10 files changed, 21 insertions(+), 21 deletions(-) Acked-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tests: py: dfu: Add functionality to set different u-boot's dfu env variable
On 04/08/2016 09:44 AM, Lukasz Majewski wrote: By default (on almost all systems) the dfu env variable, which defines available alt settings, is named as "dfu_alt_info". However on some platforms (i.e. Odroid XU3), the 'dfu_alt_info' is concatenated from other variables - namely 'dfu_alt_boot' and 'dfu_alt_system' at run time (when one types 'dfu 0 mmc 0' for first time). 'dfu_alt_boot' describes alt settings which depend on boot medium - for example boot loader's LBA sectors which are different on eMMC and SD card because of e.g. MBR/GPT. 'dfu_alt_system' describes board agnostic alt settings - like rootfs, kernel. On such system we can only append/modify this env variable. Because of the above, we must have way to modify other than "dfu_ale_info" variable to perform tests. diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py +# Optional values. +# Those values are necessary on boards like Odroid XU3, where +# - dfu alt info env variable is concatenated from boot medium dependent +# (dfu_alt_boot) and user defined (dfu_alt_system) variables +"alt_info_env_name": "dfu_alt_system", The previous value is also optional. I'd suggest simply prefixing each optional value with the same text as already used: # This value is optional. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tests: py: dfu: Add functionality to set different u-boot's dfu env variable
On 04/08/2016 09:44 AM, Lukasz Majewski wrote:
By default (on almost all systems) the dfu env variable, which defines
available alt settings, is named as "dfu_alt_info".
However on some platforms (i.e. Odroid XU3), the 'dfu_alt_info' is concatenated
from other variables - namely 'dfu_alt_boot' and 'dfu_alt_system' at run time
(when one types 'dfu 0 mmc 0' for first time).
'dfu_alt_boot' describes alt settings which depend on boot medium - for example
boot loader's LBA sectors which are different on eMMC and SD card because of
e.g.
MBR/GPT.
'dfu_alt_system' describes board agnostic alt settings - like rootfs, kernel.
On such system we can only append/modify this env variable.
Because of the above, we must have way to modify other than "dfu_ale_info"
variable to perform tests.
Uggh. That's a pretty nasty user-experience since it prevents the user
from controlling what happens. U-Boot should never over-ride what the
user requests for alt_info, but rather simply provide help to the user
allowing them to make use of the system-supplied information if they
want. I.e. dfu_alt_boot should be set at boot time based on code. The
user should then be free to define dfu_alt_info as they see fit; either
hard-coded, or including the value of $dfu_alt_boot /if/ they want.
Anyway, I suppose since this feature exists, we have no choice but to
support it.
diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py
index df3b561..1ed6020 100644
--- a/test/py/tests/test_dfu.py
+++ b/test/py/tests/test_dfu.py
@@ -44,6 +44,11 @@ env__dfu_configs = (
# configurations, but don't want to test every single transfer size
# on each, to avoid bloating the overall time taken by testing.
"test_sizes": (63, 64, 65),
+# Optional values.
+# Those values are necessary on boards like Odroid XU3, where
+# - dfu alt info env variable is concatenated from boot medium
dependent
+# (dfu_alt_boot) and user defined (dfu_alt_system) variables
+"alt_info_env_name": "dfu_alt_system",
I think the "- " and leading space should be dropped; this isn't a list
of items. I'd suggest re-phrasing this as:
# The name of the environment variable that the the dfu command reads
# alt info from. If unspecified, this defaults to dfu_alt_info, which is
# valid for most systems. Some systems use a different variable name.
# One example is the Odroid XU3, which automatically generates
# $dfu_alt_info, each time the dfu command is run, by concatenating
# $dfu_alt_boot and $dfu_alt_system.
},
)
@@ -124,7 +129,12 @@ def test_dfu(u_boot_console, env__usb_dev_port,
env__dfu_config):
u_boot_console.log.action(
'Starting long-running U-Boot dfu shell command')
-cmd = 'setenv dfu_alt_info "%s"' % env__dfu_config['alt_info']
+dfu_alt_info_env = "dfu_alt_info"
+if "alt_info_env_name" in env__dfu_config:
+ dfu_alt_info_env = env__dfu_config['alt_info_env_name']
That can be just:
dfu_alt_info_env = env__dfu_config.get('alt_info_env_name', \
'dfu_alt_info')
+
+cmd = 'setenv "%s" "%s"' % (dfu_alt_info_env,
+env__dfu_config['alt_info'])
u_boot_console.run_command(cmd)
cmd = 'dfu 0 ' + env__dfu_config['cmd_params']
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [uboot] [PATCH v4 4/7] net: phy: ti: Allow the driver to be more configurable
Not all devices use the same internal delay or fifo depth.
Add the ability to set the internal delay for rx or tx and the
fifo depth via the devicetree. If the value is not set in the
devicetree then set the delay to the default.
If devicetree is not used then use the default defines within the
driver.
Signed-off-by: Dan Murphy
---
v4 - Rebased the driver and changed default values to -1
drivers/net/phy/ti.c | 85 +---
1 file changed, 75 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 937426b..922f0a4 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -6,6 +6,14 @@
*/
#include
#include
+#include
+#include
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
/* TI DP83867 */
#define DP83867_DEVADDR0x1f
@@ -71,6 +79,17 @@
#define MII_MMD_CTRL_INCR_RDWT 0x8000 /* post increment on reads & writes */
#define MII_MMD_CTRL_INCR_ON_WT0xC000 /* post increment on writes only
*/
+/* User setting - can be taken from DTS */
+#define DEFAULT_RX_ID_DELAYDP83867_RGMIIDCTL_2_25_NS
+#define DEFAULT_TX_ID_DELAYDP83867_RGMIIDCTL_2_75_NS
+#define DEFAULT_FIFO_DEPTH DP83867_PHYCR_FIFO_DEPTH_4_B_NIB
+
+struct dp83867_private {
+ int rx_id_delay;
+ int tx_id_delay;
+ int fifo_depth;
+};
+
/**
* phy_read_mmd_indirect - reads data from the MMD registers
* @phydev: The PHY device bus
@@ -148,16 +167,58 @@ static inline bool phy_interface_is_rgmii(struct
phy_device *phydev)
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
}
-/* User setting - can be taken from DTS */
-#define RX_ID_DELAY8
-#define TX_ID_DELAY0xa
-#define FIFO_DEPTH 1
+#if defined(CONFIG_DM_ETH)
+/**
+ * dp83867_data_init - Convenience function for setting PHY specific data
+ *
+ * @phydev: the phy_device struct
+ */
+static int dp83867_of_init(struct phy_device *phydev)
+{
+ struct dp83867_private *dp83867 = phydev->priv;
+ struct udevice *dev = phydev->dev;
+
+ dp83867->rx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,rx_internal_delay", -1);
+
+ dp83867->tx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,tx_internal_delay", -1);
+
+ dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,fifo_depth", -1);
+
+ return 0;
+}
+#else
+static int dp83867_of_init(struct phy_device *phydev)
+{
+ dp83867->rx_id_delay = DEFAULT_RX_ID_DELAY;
+ dp83867->tx_id_delay = DEFAULT_TX_ID_DELAY;
+ dp83867->fifo_depth = DEFAULT_FIFO_DEPTH;
+
+ return 0;
+}
+#endif
static int dp83867_config(struct phy_device *phydev)
{
+ struct dp83867_private *dp83867;
unsigned int val, delay, cfg2;
int ret;
+ if (!phydev->priv) {
+ dp83867 = kzalloc(sizeof(*dp83867), GFP_KERNEL);
+ if (!dp83867)
+ return -ENOMEM;
+
+ phydev->priv = dp83867;
+ ret = dp83867_of_init(phydev);
+ if (ret)
+ goto err_out;
+ } else {
+ dp83867 = (struct dp83867_private *)phydev->priv;
+ }
+
/* Restart the PHY. */
val = phy_read(phydev, MDIO_DEVAD_NONE, DP83867_CTRL);
phy_write(phydev, MDIO_DEVAD_NONE, DP83867_CTRL,
@@ -166,9 +227,9 @@ static int dp83867_config(struct phy_device *phydev)
if (phy_interface_is_rgmii(phydev)) {
ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
(DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
- (FIFO_DEPTH << DP83867_PHYCR_FIFO_DEPTH_SHIFT));
+ (dp83867->fifo_depth <<
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
if (ret)
- return ret;
+ goto err_out;
} else {
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
(BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
@@ -189,8 +250,8 @@ static int dp83867_config(struct phy_device *phydev)
DP83867_PHYCTRL_SGMIIEN |
(DP83867_MDI_CROSSOVER_MDIX <<
DP83867_MDI_CROSSOVER) |
- (FIFO_DEPTH << DP83867_PHYCTRL_RXFIFO_SHIFT) |
- (FIFO_DEPTH << DP83867_PHYCTRL_TXFIFO_SHIFT));
+ (dp83867->fifo_depth << DP83867_PHYCTRL_RXFIFO_SHIFT)
|
+ (dp83867->fifo_depth <<
DP83867_PHYCTRL_TXFIFO_SHIFT));
phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_BISCR, 0x0);
}
@@ -212,8 +273,8 @@ static int dp83867_config(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIICTL,
DP83867_DEVADD
[U-Boot] [uboot] [PATCH 2/7] net: zynq_gem: Add the passing of the phy-handle node
Add the ability to pass the phy-handle node offset
to the phy driver. This allows the phy driver
to access the DT subnode's data and parse accordingly.
Signed-off-by: Dan Murphy
---
drivers/net/zynq_gem.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index aec8077..722927a 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -179,6 +179,7 @@ struct zynq_gem_priv {
struct zynq_gem_regs *iobase;
phy_interface_t interface;
struct phy_device *phydev;
+ int phy_of_handle;
struct mii_dev *bus;
};
@@ -352,6 +353,10 @@ static int zynq_phy_init(struct udevice *dev)
priv->phydev->supported = supported | ADVERTISED_Pause |
ADVERTISED_Asym_Pause;
priv->phydev->advertising = priv->phydev->supported;
+
+ if (priv->phy_of_handle > 0)
+ priv->phydev->dev->of_offset = priv->phy_of_handle;
+
phy_config(priv->phydev);
return 0;
@@ -684,10 +689,11 @@ static int zynq_gem_ofdata_to_platdata(struct udevice
*dev)
priv->emio = 0;
priv->phyaddr = -1;
- offset = fdtdec_lookup_phandle(gd->fdt_blob, dev->of_offset,
+ priv->phy_of_handle = fdtdec_lookup_phandle(gd->fdt_blob,
dev->of_offset,
"phy-handle");
- if (offset > 0)
- priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
+ if (priv->phy_of_handle > 0)
+ priv->phyaddr = fdtdec_get_int(gd->fdt_blob,
+ priv->phy_of_handle, "reg", -1);
phy_mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "phy-mode", NULL);
if (phy_mode)
--
2.8.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: Replace CONFIG_SYS_INIT_RAM_END with CONFIG_SYS_INIT_RAM_SIZE
On 08.04.2016 18:08, York Sun wrote: On 04/06/2016 01:52 PM, York Sun wrote: CONFIG_SYS_INIT_RAM_SIZE may be used out of the board header file. Some boards use CONFIG_SYS_INIT_RAM_END for the same purpose. To unify the macros, use CONFIG_SYS_INIT_RAM_SIZE for all. Signed-off-by: York Sun CC: Mario Six --- include/configs/BSC9131RDB.h |4 ++-- include/configs/BSC9132QDS.h |4 ++-- include/configs/C29XPCIE.h |4 ++-- include/configs/P1010RDB.h |4 ++-- include/configs/a3m071.h |4 ++-- include/configs/ac14xx.h |4 ++-- include/configs/dlvision-10g.h |4 ++-- include/configs/io.h |4 ++-- include/configs/iocon.h|4 ++-- include/configs/o2dnt-common.h |6 +++--- 10 files changed, 21 insertions(+), 21 deletions(-) Stefan, Anatolij, Dirk, Do you have any objection/comment on the proposed changes? I plan to merge it soon. Looks good to me (not tested on real hardware), so: Acked-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: Replace CONFIG_SYS_INIT_RAM_END with CONFIG_SYS_INIT_RAM_SIZE
On 04/06/2016 01:52 PM, York Sun wrote: > CONFIG_SYS_INIT_RAM_SIZE may be used out of the board header file. > Some boards use CONFIG_SYS_INIT_RAM_END for the same purpose. To > unify the macros, use CONFIG_SYS_INIT_RAM_SIZE for all. > > Signed-off-by: York Sun > CC: Mario Six > > --- > > include/configs/BSC9131RDB.h |4 ++-- > include/configs/BSC9132QDS.h |4 ++-- > include/configs/C29XPCIE.h |4 ++-- > include/configs/P1010RDB.h |4 ++-- > include/configs/a3m071.h |4 ++-- > include/configs/ac14xx.h |4 ++-- > include/configs/dlvision-10g.h |4 ++-- > include/configs/io.h |4 ++-- > include/configs/iocon.h|4 ++-- > include/configs/o2dnt-common.h |6 +++--- > 10 files changed, 21 insertions(+), 21 deletions(-) > Stefan, Anatolij, Dirk, Do you have any objection/comment on the proposed changes? I plan to merge it soon. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [uboot] [PATCH 6/7] net: phy: Add phy_interface_is_sgmii to phy.h
Add a helper to phy.h to identify whether the
phy is configured for SGMII all variables.
Signed-off-by: Dan Murphy
---
include/phy.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/phy.h b/include/phy.h
index 7b2d1ff..ef3eb51 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -288,6 +288,17 @@ static inline bool phy_interface_is_rgmii(struct
phy_device *phydev)
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
}
+/**
+ * phy_interface_is_sgmii - Convenience function for testing if a PHY interface
+ * is SGMII (all variants)
+ * @phydev: the phy_device struct
+ */
+static inline bool phy_interface_is_sgmii(struct phy_device *phydev)
+{
+ return phydev->interface >= PHY_INTERFACE_MODE_SGMII &&
+ phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
+}
+
/* PHY UIDs for various PHYs that are referenced in external code */
#define PHY_UID_CS4340 0x13e51002
#define PHY_UID_TN2020 0x00a19410
--
2.8.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [uboot] [PATCH 7/7] net: phy: dp83867: Add SGMII helper for configuration
The code assumed that if the interface is not RGMII configured
then it must be SGMII configured. This device has the ability
to support most of the MII interfaces. Therefore add the
helper for SGMII and only configure the device if the interface is
configured for SGMII.
Signed-off-by: Dan Murphy
---
drivers/net/phy/ti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index d503eef..4402c52 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -219,7 +219,7 @@ static int dp83867_config(struct phy_device *phydev)
(dp83867->fifo_depth <<
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
if (ret)
goto err_out;
- } else {
+ } else if (phy_interface_is_sgmii(phydev)) {
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
(BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
--
2.8.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [uboot] [PATCH v4 3/7] net: phy: dp83867: Add device tree bindings and documentation
Add the device tree bindings and the accompanying documentation
for the TI DP83867 Giga bit ethernet phy driver.
The original document was from:
[commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux kernel]
Signed-off-by: Dan Murphy
---
v3- Update the bindings to the reflect the implementation
doc/device-tree-bindings/net/ti,dp83867.txt | 25 +
include/dt-bindings/net/ti-dp83867.h| 35 +
2 files changed, 60 insertions(+)
create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
create mode 100644 include/dt-bindings/net/ti-dp83867.h
diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt
b/doc/device-tree-bindings/net/ti,dp83867.txt
new file mode 100644
index 000..cb77fdf
--- /dev/null
+++ b/doc/device-tree-bindings/net/ti,dp83867.txt
@@ -0,0 +1,25 @@
+* Texas Instruments - dp83867 Giga bit ethernet phy
+
+Required properties:
+ - reg - The ID number for the phy, usually a small integer
+ - ti,rx-internal-delay - RGMII Recieve Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,tx-internal-delay - RGMII Transmit Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
+ for applicable values
+
+Default child nodes are standard Ethernet PHY device
+nodes as described in doc/devicetree/bindings/net/ethernet.txt
+
+Example:
+
+ ethernet-phy@0 {
+ reg = <0>;
+ ti,rx-internal-delay = ;
+ ti,tx-internal-delay = ;
+ ti,fifo-depth = ;
+ };
+
+Datasheet can be found:
+http://www.ti.com/product/DP83867IR/datasheet
diff --git a/include/dt-bindings/net/ti-dp83867.h
b/include/dt-bindings/net/ti-dp83867.h
new file mode 100644
index 000..5c592fb
--- /dev/null
+++ b/include/dt-bindings/net/ti-dp83867.h
@@ -0,0 +1,35 @@
+/*
+ * TI DP83867 PHY drivers
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ *
+ */
+
+#ifndef _DT_BINDINGS_TI_DP83867_H
+#define _DT_BINDINGS_TI_DP83867_H
+
+/* PHY CTRL bits */
+#define DP83867_PHYCR_FIFO_DEPTH_3_B_NIB 0x00
+#define DP83867_PHYCR_FIFO_DEPTH_4_B_NIB 0x01
+#define DP83867_PHYCR_FIFO_DEPTH_6_B_NIB 0x02
+#define DP83867_PHYCR_FIFO_DEPTH_8_B_NIB 0x03
+
+/* RGMIIDCTL internal delay for rx and tx */
+#defineDP83867_RGMIIDCTL_250_PS0x0
+#defineDP83867_RGMIIDCTL_500_PS0x1
+#defineDP83867_RGMIIDCTL_750_PS0x2
+#defineDP83867_RGMIIDCTL_1_NS 0x3
+#defineDP83867_RGMIIDCTL_1_25_NS 0x4
+#defineDP83867_RGMIIDCTL_1_50_NS 0x5
+#defineDP83867_RGMIIDCTL_1_75_NS 0x6
+#defineDP83867_RGMIIDCTL_2_00_NS 0x7
+#defineDP83867_RGMIIDCTL_2_25_NS 0x8
+#defineDP83867_RGMIIDCTL_2_50_NS 0x9
+#defineDP83867_RGMIIDCTL_2_75_NS 0xa
+#defineDP83867_RGMIIDCTL_3_00_NS 0xb
+#defineDP83867_RGMIIDCTL_3_25_NS 0xc
+#defineDP83867_RGMIIDCTL_3_50_NS 0xd
+#defineDP83867_RGMIIDCTL_3_75_NS 0xe
+#defineDP83867_RGMIIDCTL_4_00_NS 0xf
+
+#endif
--
2.8.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [uboot] [PATCH 5/7] net: phy: Move is_rgmii helper to phy.h
Move the phy_interface_is_rgmii to the phy.h
file for all phy's to be able to use the API.
This now aligns with the Linux kernel based on
commit e463d88c36d42211aa72ed76d32fb8bf37820ef1
Signed-off-by: Dan Murphy
---
drivers/net/phy/ti.c | 11 ---
include/phy.h| 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 922f0a4..d503eef 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -156,17 +156,6 @@ void phy_write_mmd_indirect(struct phy_device *phydev, int
prtad,
phy_write(phydev, addr, MII_MMD_DATA, data);
}
-/**
- * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
- * is RGMII (all variants)
- * @phydev: the phy_device struct
- */
-static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
-{
- return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
- phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
-}
-
#if defined(CONFIG_DM_ETH)
/**
* dp83867_data_init - Convenience function for setting PHY specific data
diff --git a/include/phy.h b/include/phy.h
index 21459a8..7b2d1ff 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -277,6 +277,17 @@ int get_phy_id(struct mii_dev *bus, int addr, int devad,
u32 *phy_id);
*/
int phy_get_interface_by_name(const char *str);
+/**
+ * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
+ * is RGMII (all variants)
+ * @phydev: the phy_device struct
+ */
+static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
+{
+ return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
+ phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
+}
+
/* PHY UIDs for various PHYs that are referenced in external code */
#define PHY_UID_CS4340 0x13e51002
#define PHY_UID_TN2020 0x00a19410
--
2.8.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [uboot] [PATCH 1/7] drivers: net: cpsw: Add readinf of DT phy-handle node
Add the ability to read the phy-handle node of the
cpsw slave. Upon reading this handle the phy-id
can be stored based on the reg node in the DT.
The phy-handle also needs to be stored and passed
to the phy to access any phy data that is available.
Signed-off-by: Dan Murphy
---
drivers/net/cpsw.c | 18 --
include/cpsw.h | 1 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 7104754..8ee33a6 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -965,6 +965,9 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct
cpsw_slave *slave)
phydev->supported &= supported;
phydev->advertising = phydev->supported;
+ if (slave->data->phy_of_handle)
+ phydev->dev->of_offset = slave->data->phy_of_handle;
+
priv->phydev = phydev;
phy_config(phydev);
@@ -1217,8 +1220,19 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice
*dev)
if (phy_mode)
priv->data.slave_data[slave_index].phy_if =
phy_get_interface_by_name(phy_mode);
- fdtdec_get_int_array(fdt, subnode, "phy_id", phy_id, 2);
- priv->data.slave_data[slave_index].phy_addr = phy_id[1];
+
+ priv->data.slave_data[slave_index].phy_of_handle =
+ fdtdec_lookup_phandle(fdt, subnode,
"phy-handle");
+
+ if (priv->data.slave_data[slave_index].phy_of_handle) {
+ priv->data.slave_data[slave_index].phy_addr =
+ fdtdec_get_int(gd->fdt_blob,
+
priv->data.slave_data[slave_index].phy_of_handle,
+ "reg", -1);
+ } else {
+ fdtdec_get_int_array(fdt, subnode, "phy_id",
phy_id, 2);
+ priv->data.slave_data[slave_index].phy_addr =
phy_id[1];
+ }
slave_index++;
}
diff --git a/include/cpsw.h b/include/cpsw.h
index cf1d30b..ba9d068 100644
--- a/include/cpsw.h
+++ b/include/cpsw.h
@@ -21,6 +21,7 @@ struct cpsw_slave_data {
u32 sliver_reg_ofs;
int phy_addr;
int phy_if;
+ int phy_of_handle;
};
enum {
--
2.8.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] tests: py: dfu: Add functionality to set different u-boot's dfu env variable
By default (on almost all systems) the dfu env variable, which defines available alt settings, is named as "dfu_alt_info". However on some platforms (i.e. Odroid XU3), the 'dfu_alt_info' is concatenated from other variables - namely 'dfu_alt_boot' and 'dfu_alt_system' at run time (when one types 'dfu 0 mmc 0' for first time). 'dfu_alt_boot' describes alt settings which depend on boot medium - for example boot loader's LBA sectors which are different on eMMC and SD card because of e.g. MBR/GPT. 'dfu_alt_system' describes board agnostic alt settings - like rootfs, kernel. On such system we can only append/modify this env variable. Because of the above, we must have way to modify other than "dfu_ale_info" variable to perform tests. Signed-off-by: Lukasz Majewski --- test/py/tests/test_dfu.py | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py index df3b561..1ed6020 100644 --- a/test/py/tests/test_dfu.py +++ b/test/py/tests/test_dfu.py @@ -44,6 +44,11 @@ env__dfu_configs = ( # configurations, but don't want to test every single transfer size # on each, to avoid bloating the overall time taken by testing. "test_sizes": (63, 64, 65), +# Optional values. +# Those values are necessary on boards like Odroid XU3, where +# - dfu alt info env variable is concatenated from boot medium dependent +# (dfu_alt_boot) and user defined (dfu_alt_system) variables +"alt_info_env_name": "dfu_alt_system", }, ) @@ -124,7 +129,12 @@ def test_dfu(u_boot_console, env__usb_dev_port, env__dfu_config): u_boot_console.log.action( 'Starting long-running U-Boot dfu shell command') -cmd = 'setenv dfu_alt_info "%s"' % env__dfu_config['alt_info'] +dfu_alt_info_env = "dfu_alt_info" +if "alt_info_env_name" in env__dfu_config: + dfu_alt_info_env = env__dfu_config['alt_info_env_name'] + +cmd = 'setenv "%s" "%s"' % (dfu_alt_info_env, +env__dfu_config['alt_info']) u_boot_console.run_command(cmd) cmd = 'dfu 0 ' + env__dfu_config['cmd_params'] -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] tests: py: dfu: Add global variables to store dfu alt numbers for test and dummy files
This patch replaces hardcoded (i.e. 0 and 1) values passed to dfu_{read|write}
with global variables.
Signed-off-by: Lukasz Majewski
---
test/py/tests/test_dfu.py | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py
index 093e8d0..df3b561 100644
--- a/test/py/tests/test_dfu.py
+++ b/test/py/tests/test_dfu.py
@@ -80,6 +80,10 @@ test_sizes_default = (
first_usb_dev_port = None
+# Default alt settings for test and dummy files
+alt_setting_test_file = 0
+alt_setting_dummy_file = 1
+
@pytest.mark.buildconfigspec('cmd_dfu')
def test_dfu(u_boot_console, env__usb_dev_port, env__dfu_config):
"""Test the "dfu" command; the host system must be able to enumerate a USB
@@ -229,15 +233,15 @@ def test_dfu(u_boot_console, env__usb_dev_port,
env__dfu_config):
u_boot_console.log.action('Writing test data to DFU primary ' +
'altsetting')
-dfu_write(0, test_f.abs_fn)
+dfu_write(alt_setting_test_file, test_f.abs_fn)
u_boot_console.log.action('Writing dummy data to DFU secondary ' +
'altsetting to clear DFU buffers')
-dfu_write(1, dummy_f.abs_fn)
+dfu_write(alt_setting_dummy_file, dummy_f.abs_fn)
u_boot_console.log.action('Reading DFU primary altsetting for ' +
'comparison')
-dfu_read(0, readback_fn)
+dfu_read(alt_setting_test_file, readback_fn)
u_boot_console.log.action('Comparing written and read data')
written_hash = test_f.content_hash
@@ -266,7 +270,7 @@ def test_dfu(u_boot_console, env__usb_dev_port,
env__dfu_config):
u_boot_console.log.action(
'Overwriting DFU primary altsetting with dummy data')
-dfu_write(0, dummy_f.abs_fn)
+dfu_write(alt_setting_test_file, dummy_f.abs_fn)
for size in sizes:
with u_boot_console.log.section('Data size %d' % size):
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] tests: py: dfu: Provide functionality to set test and dummy files alt settings
After concatenation of "dfu_alt_info" variable from "dfu_alt_boot" and "dfu_alt_system" it may happen that test and dummy files alt settings are different than default 0 and 1. This patch provides ability to set different values for them. It was the simplest possible solution - akin to the one from original bash dfu tests. Signed-off-by: Lukasz Majewski --- test/py/tests/test_dfu.py | 12 1 file changed, 12 insertions(+) diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py index 1ed6020..af9073b 100644 --- a/test/py/tests/test_dfu.py +++ b/test/py/tests/test_dfu.py @@ -49,6 +49,10 @@ env__dfu_configs = ( # - dfu alt info env variable is concatenated from boot medium dependent # (dfu_alt_boot) and user defined (dfu_alt_system) variables "alt_info_env_name": "dfu_alt_system", +# - after concatenation dfu alt settings for test and dummy files are +# moved from 0 and 1 to other values +"alt_num_test_file": "5", +"alt_num_dummy_file": "6", }, ) @@ -119,6 +123,8 @@ def test_dfu(u_boot_console, env__usb_dev_port, env__dfu_config): Returns: Nothing. """ +global alt_setting_test_file +global alt_setting_dummy_file fh = u_boot_utils.attempt_to_open_file( env__usb_dev_port['host_usb_dev_node']) @@ -129,6 +135,12 @@ def test_dfu(u_boot_console, env__usb_dev_port, env__dfu_config): u_boot_console.log.action( 'Starting long-running U-Boot dfu shell command') +if "alt_num_test_file" in env__dfu_config: + alt_setting_test_file = env__dfu_config['alt_num_test_file'] + +if "alt_num_dummy_file" in env__dfu_config: + alt_setting_dummy_file = env__dfu_config['alt_num_dummy_file'] + dfu_alt_info_env = "dfu_alt_info" if "alt_info_env_name" in env__dfu_config: dfu_alt_info_env = env__dfu_config['alt_info_env_name'] -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: g_dnl: Change device class
Hi Lukas,
On Fri, Apr 8, 2016 at 2:19 AM, Lukasz Majewski
wrote:
> Hi John,
>
> > The USB Mass Storage (ums) works in Windows, Linux and OS X (EL
> > Capitan). But, not in OS X (Yosemite). By applying the said patch, it
> > extends the ums support.
> >
> > Signed-off-by: John Tobias
> > ---
> > drivers/usb/gadget/g_dnl.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
> > index 2fa6da4..bd3aad9 100644
> > --- a/drivers/usb/gadget/g_dnl.c
> > +++ b/drivers/usb/gadget/g_dnl.c
> > @@ -58,8 +58,8 @@ static struct usb_device_descriptor device_desc = {
> > .bDescriptorType = USB_DT_DEVICE,
> >
> > .bcdUSB = __constant_cpu_to_le16(0x0200),
> > - .bDeviceClass = USB_CLASS_COMM,
> > - .bDeviceSubClass = 0x02, /*0x02:CDC-modem , 0x00:CDC-serial*/
> > + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> > + .bDeviceSubClass = 0, /*0x02:CDC-modem , 0x00:CDC-serial*/
>
> Have you tested if this patch is not introducing any regression on
> Linux and Windows?
>
The test what I did is like this:
Linux:
- Run ums to expose all my eMMC partition - shows all correctly
- Run ums to expose only 1 partition of my eMMC - show correctly
Windows:
- Run ums to expose all my eMMC partition - it detects but it prompts,
if I want to format it (due to a non windows partition)
- Run ums to expose only the FAT32 partition - it show the partition
correctly.
Note: I have a patch to expose only 1 partition:
e.g: ums 0 mmc 1:8
>
> >
> > .idVendor = __constant_cpu_to_le16(CONFIG_G_DNL_VENDOR_NUM),
> > .idProduct =
> > __constant_cpu_to_le16(CONFIG_G_DNL_PRODUCT_NUM),
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>
Regards,
John
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot][PATCH v3 1/2] net: phy: dp83867: Add device tree bindings and documentation
On 04/08/2016 07:29 AM, Michal Simek wrote:
> On 8.4.2016 14:05, Dan Murphy wrote:
>> On 04/08/2016 04:25 AM, Michal Simek wrote:
>>> On 7.4.2016 18:02, Dan Murphy wrote:
Mugunthan
On 04/06/2016 11:45 PM, Mugunthan V N wrote:
> On Wednesday 06 April 2016 05:07 PM, Dan Murphy wrote:
>> Add the device tree bindings and the accompanying documentation
>> for the TI DP83867 Giga bit ethernet phy driver.
>>
>> The original document was from:
>> [commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux
>> kernel]
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v3 - Modify the binding to the kernel changed int -> internal for the
>> delay - https://patchwork.ozlabs.org/patch/606595/
>>
>> doc/device-tree-bindings/net/ti,dp83867.txt | 29
>>
>> include/dt-bindings/net/ti-dp83867.h| 35
>> +
>> 2 files changed, 64 insertions(+)
>> create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
>> create mode 100644 include/dt-bindings/net/ti-dp83867.h
>>
>> diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt
>> b/doc/device-tree-bindings/net/ti,dp83867.txt
>> new file mode 100644
>> index 000..0ec009c
>> --- /dev/null
>> +++ b/doc/device-tree-bindings/net/ti,dp83867.txt
>> @@ -0,0 +1,29 @@
>> +* Texas Instruments - dp83867 Giga bit ethernet phy
>> +
>> +Required properties:
>> +- ti,rx-internal-delay - RGMII Recieve Clock Delay - see
>> dt-bindings/net/ti-dp83867.h
>> +for applicable values
>> +- ti,tx-internal-delay - RGMII Transmit Clock Delay - see
>> dt-bindings/net/ti-dp83867.h
>> +for applicable values
>> +- ti,fifo-depth - Transmitt FIFO depth- see
>> dt-bindings/net/ti-dp83867.h
>> +for applicable values
>> +
>> +Default child nodes are standard Ethernet PHY device
>> +nodes as described in doc/devicetree/bindings/net/ethernet.txt
>> +
>> +Example:
>> +
>> +&mac {
>> +pinctrl-0 = <&davinci_mdio_default>;
>> +pinctrl-1 = <&davinci_mdio_sleep>;
>> +status = "okay";
>> +
>> +ti,rx_internal_delay = ;
>> +ti,tx_internal_delay = ;
>> +ti,fifo_depth = ;
>> +
>> +};
> This example should in phy node and not in mac node as per the linux
> commmit mentioned above?
Are you saying that the code should look like this
&mac {
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
phy-handle = <ðernet_phy>;
ethernet_phy: ethernet-phy@0 {
reg = <0>;
ti,rx_int_delay = ;
ti,tx_int_delay = ;
ti,fifo_depth = ;
};
This is the way it is in the kernel.
>>> First of all. Please rebase your 2/2 on the top of current branch.
>>> sgmii support was added recently.
>> Yeah I had a feeling that I was going to need to do that.
>>
>>> Here is what I use on zynqmp.
>>> http://lists.denx.de/pipermail/u-boot/2016-April/250866.html
>>> And it reflects the description above.
>> OK the zync_gem supports phy-handle. cpsw does not. Looks like I have
>> to add a patch to cpsw.
> yep but again your patch is failing on zynqmp. Because I don't think
> there is hook to read that values from DT.
> I didn't look at details but definitely please check it.
Actually this is a problem in the zynqmp mac driver.
zynqmp reads the phy-handle and then dumps the information so
the dp83867 or any phy driver for that matter is not getting the data.
I will send a patch in to fix the zynqmp driver as well
Dan
>
> Thanks,
> Michal
>
>
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: mvebu_gpio: Add missing out value set to gpio_direction_output()
On 04/07/2016 12:41 AM, Stefan Roese wrote: > This patch adds the missing configuration of the output value to the > gpio_direction_output() function. Without this, calling > gpio_direction_output() does not set the out-value at all and only > configures the gpio as output. > > Signed-off-by: Stefan Roese > Cc: Kevin Smith > --- > drivers/gpio/mvebu_gpio.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpio/mvebu_gpio.c b/drivers/gpio/mvebu_gpio.c > index 9564ce2..75dc73e 100644 > --- a/drivers/gpio/mvebu_gpio.c > +++ b/drivers/gpio/mvebu_gpio.c > @@ -43,6 +43,10 @@ static int mvebu_gpio_direction_output(struct udevice > *dev, unsigned gpio, > struct mvebu_gpio_priv *priv = dev_get_priv(dev); > struct mvebu_gpio_regs *regs = priv->regs; > > + if (value) > + setbits_le32(®s->data_out, BIT(gpio)); > + else > + clrbits_le32(®s->data_out, BIT(gpio)); > clrbits_le32(®s->io_conf, BIT(gpio)); > > return 0; Reviewed-by: Kevin Smith ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Newbie SPL question for socfpga_sockit
On 04/08/2016 07:16 AM, Stefan Roese wrote: > On 08.04.2016 01:51, George Broz wrote: > > > > Try with the attached patch (and probably with dcache off) The patch applied cleanly. The behavior is unchanged with both dcache on and off. The "good" sticks still work, and "bad" sticks still don't. >>> >>> OK. Then I should probably go hunting for Kingston DataTraveler SE9, >>> right ? Can you give me a link to the stick you have, so I know what >>> crappy device to look for ? Thanks! >> >> Here it is [1] - I have the 8GB version. >> >> I think there will always be crappy sticks that don't work... but do you >> have any advice as to what properties will/might generally cause a problem? >> >> [1] >> http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG > > I have exactly this stick here (16GiB) version. And it is detected just > fine in both, current mainline Armada XP (theadorable) and x86 boards > (conga-qeval20-qa3-e3845). Here my lsusb output: I bought the kingston stick and it's not detected on SoCFPGA SoCkit at all. Ouch :-( [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] odroid: Update README with correct firmware link and XU4 support
Hi Shawn, On 8 April 2016 at 08:36, Shawn Guo wrote: > The firmware from link [1] only works with U-Boot image that is no > bigger than 328KiB. Using it with the default mainline U-Boot today > which is already around 500KiB is just not working. Correct the link > to be hardkernel_1mb_uboot one [2], so that users can get mainline > U-Boot work out of box. > > While at it, the README is updated to include XU4 support, like DTB file > name. > > [1] > https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel > [2] > https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot > > Signed-off-by: Shawn Guo > --- > doc/README.odroid | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/doc/README.odroid b/doc/README.odroid > index ef243d1bde36..c088ec4cb08f 100644 > --- a/doc/README.odroid > +++ b/doc/README.odroid > @@ -1,11 +1,11 @@ > - U-Boot for Odroid X2/U3/XU3 > + U-Boot for Odroid X2/U3/XU3/XU4 > > > 1. Summary > == > This is a quick instruction for setup Odroid boards. > Board config: odroid_config for X2/U3 > -Board config: odroid-xu3_config for XU3 > +Board config: odroid-xu3_config for XU3/XU4 > > 2. Supported devices > > @@ -14,6 +14,7 @@ This U-BOOT config can be used on three boards: > - Odroid X2 > with CPU Exynos 4412 rev 2.0 and 2GB of RAM > - Odroid XU3 > +- Odroid XU4 > with CPU Exynos5422 and 2GB of RAM > > 3. Boot sequence > @@ -29,9 +30,9 @@ > http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download&value=boo > or here: > http://odroid.in/guides/ubuntu-lfs/boot.tar.gz > > -<< XU3 >> > +<< XU3/XU4 >> > It can be downloaded from: > -https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel > +https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot > > > 4. Boot media layout > @@ -120,6 +121,7 @@ Supported fdt files are: > - exynos4412-odroidx2.dtb > - exynos4412-odroidu3.dtb > - exynos5422-odroidxu3.dtb > +- exynos5422-odroidxu4.dtb > > Supported kernel files are: > - Image.itb > -- > 1.9.1 > Reviewed-by: Anand Moon Best Regards. -Anand Moon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] armv8/ls2080a: configure PMU's PCTBENR to enable WDT
From: Yunhui Cui
The SP805-WDT module on LS2080A and LS2085A, requires configuration
of PMU's PCTBENR register to enable watchdog counter decrement and
reset signal generation. In order not to affect the sp805wdt driver
frame, we enable the watchdog clk in advance.
Signed-off-by: Yunhui Cui
---
arch/arm/cpu/armv8/fsl-layerscape/soc.c| 18 ++
arch/arm/include/asm/arch-fsl-layerscape/soc.h | 1 +
board/freescale/ls2080aqds/ls2080aqds.c| 2 ++
board/freescale/ls2080ardb/ls2080ardb.c| 2 ++
4 files changed, 23 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index a76447e..06c950f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -17,6 +17,24 @@
#endif
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+/*
+ * Set the bit corresponding to our watchDog-id in the
+ * PMU-Physical Core Time Base Enable Register (PCTBENR)
+ * to allow the WDT counter to decrement and raise a reset
+ * request (if configured in the WDTCONTROL register).
+ */
+void enable_watchdog_clk(void)
+{
+ #define FSL_PMU_REG_BASE0x1E3
+ #define FSL_PMU_PCTBENR_OFFSET 0x8A0
+ u32 pmu_val;
+
+ pmu_val = *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET);
+ *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET) = pmu_val | 0xff;
+}
+#endif
+
#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
/*
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
index 56989e1..32c9185 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -91,6 +91,7 @@ void fsl_lsch2_early_init_f(void);
#endif
void cpu_name(char *name);
+void enable_watchdog_clk(void);
#ifdef CONFIG_SYS_FSL_ERRATUM_A009635
void erratum_a009635(void);
#endif
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
b/board/freescale/ls2080aqds/ls2080aqds.c
index e1a521d..8ebc96a 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -213,6 +213,8 @@ int board_init(void)
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
rtc_enable_32khz_output();
+ enable_watchdog_clk();
+
return 0;
}
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
b/board/freescale/ls2080ardb/ls2080ardb.c
index 8201048..ad8324a 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -181,6 +181,8 @@ int board_init(void)
/* invert AQR405 IRQ pins polarity */
out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR405_IRQ_MASK);
+ enable_watchdog_clk();
+
return 0;
}
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: theadorable: Remove Board name output in checkboard
This line is not needed, as the board supports DT based probing. And
here the "Model:" is already printed:
Model: Marvell Armada XP theadorable
Board: theadorable
One line for the board name is enough.
Signed-off-by: Stefan Roese
---
board/theadorable/theadorable.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/board/theadorable/theadorable.c b/board/theadorable/theadorable.c
index 5836bf7..9c0f120 100644
--- a/board/theadorable/theadorable.c
+++ b/board/theadorable/theadorable.c
@@ -193,8 +193,6 @@ int board_init(void)
int checkboard(void)
{
- puts("Board: theadorable\n");
-
board_fpga_add();
--
2.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lib/crc8: Add crc start value
To make the usage of this function more flexible, lets add the CRC start
value as parameter to this function. This way it can be used by other
functions requiring different start values than 0 as well.
For non-zero CRC start values to work, I've reworked the function a bit.
The new implementation is copied from the Linux version in
drivers/i2c/i2c-core.c / i2c_smbus_pec(). Which supports non-zero
CRC stating values.
I've double-checked that the results for zero starting values are
identical to the results from the original version of this function.
Signed-off-by: Stefan Roese
Cc: Simon Glass
---
drivers/tpm/tpm_tis_sandbox.c | 2 +-
include/linux/crc8.h | 3 ++-
lib/crc8.c| 33 -
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/tpm/tpm_tis_sandbox.c b/drivers/tpm/tpm_tis_sandbox.c
index 9ea9807..4aade56 100644
--- a/drivers/tpm/tpm_tis_sandbox.c
+++ b/drivers/tpm/tpm_tis_sandbox.c
@@ -217,7 +217,7 @@ static int sandbox_tpm_xfer(struct udevice *dev, const
uint8_t *sendbuf,
rsk.struct_version = 2;
rsk.uid = ROLLBACK_SPACE_KERNEL_UID;
rsk.kernel_versions = 0;
- rsk.crc8 = crc8((unsigned char *)&rsk,
+ rsk.crc8 = crc8(0, (unsigned char *)&rsk,
offsetof(struct rollback_space_kernel,
crc8));
memcpy(data, &rsk, sizeof(rsk));
diff --git a/include/linux/crc8.h b/include/linux/crc8.h
index b5fd2ac..f7c300a 100644
--- a/include/linux/crc8.h
+++ b/include/linux/crc8.h
@@ -14,10 +14,11 @@
* This uses an x^8 + x^2 + x + 1 polynomial. A table-based algorithm would
* be faster, but for only a few bytes it isn't worth the code size
*
+ * @crc_start: CRC8 start value
* @vptr: Buffer to checksum
* @len: Length of buffer in bytes
* @return CRC8 checksum
*/
-unsigned int crc8(const unsigned char *vptr, int len);
+unsigned int crc8(unsigned int crc_start, const unsigned char *vptr, int len);
#endif
diff --git a/lib/crc8.c b/lib/crc8.c
index 8b68a29..51d540f 100644
--- a/lib/crc8.c
+++ b/lib/crc8.c
@@ -6,20 +6,27 @@
#include "linux/crc8.h"
-unsigned int crc8(const unsigned char *vptr, int len)
+#define POLY (0x1070U << 3)
+
+static unsigned char _crc8(unsigned short data)
{
- const unsigned char *data = vptr;
- unsigned int crc = 0;
- int i, j;
-
- for (j = len; j; j--, data++) {
- crc ^= (*data << 8);
- for (i = 8; i; i--) {
- if (crc & 0x8000)
- crc ^= (0x1070 << 3);
- crc <<= 1;
- }
+ int i;
+
+ for (i = 0; i < 8; i++) {
+ if (data & 0x8000)
+ data = data ^ POLY;
+ data = data << 1;
}
- return (crc >> 8) & 0xff;
+ return (unsigned char)(data >> 8);
+}
+
+unsigned int crc8(unsigned int crc, const unsigned char *vptr, int len)
+{
+ int i;
+
+ for (i = 0; i < len; i++)
+ crc = _crc8((crc ^ vptr[i]) << 8);
+
+ return crc;
}
--
2.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] arm: mvebu: theadorable: Enable 2nd I2C controller
This patch enables the 2nd I2C controller on the Armada XP theadorable board. Signed-off-by: Stefan Roese --- include/configs/theadorable.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/theadorable.h b/include/configs/theadorable.h index 20a44c9..05a248e 100644 --- a/include/configs/theadorable.h +++ b/include/configs/theadorable.h @@ -51,6 +51,7 @@ #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI #define CONFIG_I2C_MVTWSI_BASE0MVEBU_TWSI_BASE +#define CONFIG_I2C_MVTWSI_BASE1MVEBU_TWSI1_BASE #define CONFIG_SYS_I2C_SLAVE 0x0 #define CONFIG_SYS_I2C_SPEED 10 -- 2.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] arm: mvebu: Add base address for 2nd I2C controller
Add MVEBU_TWSI1_BASE define so that the 2nd I2C controller on e.g. AXP can be used. Signed-off-by: Stefan Roese --- arch/arm/mach-mvebu/include/mach/soc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index a12be2a..13c9f29 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -55,6 +55,7 @@ #define MVEBU_L2_CACHE_BASE(MVEBU_REGISTER(0x08000)) #define CONFIG_SYS_PL310_BASE MVEBU_L2_CACHE_BASE #define MVEBU_TWSI_BASE(MVEBU_REGISTER(0x11000)) +#define MVEBU_TWSI1_BASE (MVEBU_REGISTER(0x11100)) #define MVEBU_MPP_BASE (MVEBU_REGISTER(0x18000)) #define MVEBU_GPIO0_BASE (MVEBU_REGISTER(0x18100)) #define MVEBU_GPIO1_BASE (MVEBU_REGISTER(0x18140)) -- 2.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm: mvebu: theadorable: Add PEX-switch detection and reset code
Sometimes the PCIe link for the PEX-switch will not come-up. In this case,
the board is not in a usable state. This patch makes sure that in this
case a soft-reset is issued. If this soft-reset does not result in the
PEX-switch being detected after some soft-reset cycles, an I2C message
is sent to the uC to issue a complete power-cycle of the board.
Signed-off-by: Stefan Roese
---
board/theadorable/theadorable.c | 69 +
include/configs/theadorable.h | 1 +
2 files changed, 70 insertions(+)
diff --git a/board/theadorable/theadorable.c b/board/theadorable/theadorable.c
index 9c3b97c..5836bf7 100644
--- a/board/theadorable/theadorable.c
+++ b/board/theadorable/theadorable.c
@@ -5,10 +5,13 @@
*/
#include
+#include
+#include
#include
#include
#include
#include
+#include
#include
#ifdef CONFIG_NET
#include
@@ -35,6 +38,12 @@ DECLARE_GLOBAL_DATA_PTR;
#define GPIO_USB0_PWR_ON 18
#define GPIO_USB1_PWR_ON 19
+#define PEX_SWITCH_NOT_FOUNT_LIMIT 3
+
+#define STM_I2C_BUS1
+#define STM_I2C_ADDR 0x27
+#define REBOOT_DELAY 1000/* reboot-delay in ms */
+
/* DDR3 static configuration */
static MV_DRAM_MC_INIT ddr3_theadorable[MV_MAX_DDR3_STATIC_SIZE] = {
{0x1400, 0x7301ca28}, /* DDR SDRAM Configuration Register */
@@ -218,3 +227,63 @@ int board_video_init(void)
return mvebu_lcd_register_init(&lcd_info);
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ pci_dev_t bdf;
+ ulong bootcount;
+
+ /*
+* Check if the PEX switch is detected (somtimes its not available
+* on the PCIe bus). In this case, try to recover by issuing a
+* soft-reset or even a power-cycle, depending on the bootcounter
+* value.
+*/
+ bdf = pci_find_device(PCI_VENDOR_ID_PLX, 0x8619, 0);
+ if (bdf == -1) {
+ u8 i2c_buf[8];
+ int ret;
+
+ /* PEX switch not found! */
+ bootcount = bootcount_load();
+ printf("Failed to find PLX PEX-switch (bootcount=%ld)\n",
+ bootcount);
+ if (bootcount > PEX_SWITCH_NOT_FOUNT_LIMIT) {
+ printf("Issuing power-switch via uC!\n");
+
+ printf("Issuing power-switch via uC!\n");
+ i2c_set_bus_num(STM_I2C_BUS);
+ i2c_buf[0] = STM_I2C_ADDR << 1;
+ i2c_buf[1] = 0xc5; /* cmd */
+ i2c_buf[2] = 0x01; /* enable */
+ /* Delay before reboot */
+ i2c_buf[3] = REBOOT_DELAY & 0x00ff;
+ i2c_buf[4] = (REBOOT_DELAY & 0xff00) >> 8;
+ /* Delay before shutdown */
+ i2c_buf[5] = 0x00;
+ i2c_buf[6] = 0x00;
+ i2c_buf[7] = crc8(0x72, &i2c_buf[0], 7);
+
+ ret = i2c_write(STM_I2C_ADDR, 0, 0, &i2c_buf[1], 7);
+ if (ret) {
+ printf("I2C write error (ret=%d)\n", ret);
+ printf("Issuing soft-reset...\n");
+ /* default handling: SOFT reset */
+ do_reset(NULL, 0, 0, NULL);
+ }
+
+ /* Wait for power-cycle to occur... */
+ printf("Waiting for power-cycle via uC...\n");
+ while (1)
+ ;
+ } else {
+ printf("Issuing soft-reset...\n");
+ /* default handling: SOFT reset */
+ do_reset(NULL, 0, 0, NULL);
+ }
+ }
+
+ return 0;
+}
+#endif
diff --git a/include/configs/theadorable.h b/include/configs/theadorable.h
index 05a248e..5864f27 100644
--- a/include/configs/theadorable.h
+++ b/include/configs/theadorable.h
@@ -104,6 +104,7 @@
#define CONFIG_PCI
#define CONFIG_PCI_MVEBU
#define CONFIG_PCI_PNP
+#define CONFIG_BOARD_LATE_INIT /* for PEX switch test */
#endif
#endif
--
2.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot][PATCH v3 1/2] net: phy: dp83867: Add device tree bindings and documentation
On 8.4.2016 14:05, Dan Murphy wrote:
> On 04/08/2016 04:25 AM, Michal Simek wrote:
>> On 7.4.2016 18:02, Dan Murphy wrote:
>>> Mugunthan
>>>
>>> On 04/06/2016 11:45 PM, Mugunthan V N wrote:
On Wednesday 06 April 2016 05:07 PM, Dan Murphy wrote:
> Add the device tree bindings and the accompanying documentation
> for the TI DP83867 Giga bit ethernet phy driver.
>
> The original document was from:
> [commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux
> kernel]
>
> Signed-off-by: Dan Murphy
> ---
>
> v3 - Modify the binding to the kernel changed int -> internal for the
> delay - https://patchwork.ozlabs.org/patch/606595/
>
> doc/device-tree-bindings/net/ti,dp83867.txt | 29
> include/dt-bindings/net/ti-dp83867.h| 35
> +
> 2 files changed, 64 insertions(+)
> create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
> create mode 100644 include/dt-bindings/net/ti-dp83867.h
>
> diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt
> b/doc/device-tree-bindings/net/ti,dp83867.txt
> new file mode 100644
> index 000..0ec009c
> --- /dev/null
> +++ b/doc/device-tree-bindings/net/ti,dp83867.txt
> @@ -0,0 +1,29 @@
> +* Texas Instruments - dp83867 Giga bit ethernet phy
> +
> +Required properties:
> + - ti,rx-internal-delay - RGMII Recieve Clock Delay - see
> dt-bindings/net/ti-dp83867.h
> + for applicable values
> + - ti,tx-internal-delay - RGMII Transmit Clock Delay - see
> dt-bindings/net/ti-dp83867.h
> + for applicable values
> + - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
> + for applicable values
> +
> +Default child nodes are standard Ethernet PHY device
> +nodes as described in doc/devicetree/bindings/net/ethernet.txt
> +
> +Example:
> +
> +&mac {
> + pinctrl-0 = <&davinci_mdio_default>;
> + pinctrl-1 = <&davinci_mdio_sleep>;
> + status = "okay";
> +
> + ti,rx_internal_delay = ;
> + ti,tx_internal_delay = ;
> + ti,fifo_depth = ;
> +
> +};
This example should in phy node and not in mac node as per the linux
commmit mentioned above?
>>> Are you saying that the code should look like this
>>>
>>> &mac {
>>> pinctrl-0 = <&davinci_mdio_default>;
>>> pinctrl-1 = <&davinci_mdio_sleep>;
>>> status = "okay";
>>> phy-handle = <ðernet_phy>;
>>>
>>> ethernet_phy: ethernet-phy@0 {
>>> reg = <0>;
>>> ti,rx_int_delay = ;
>>> ti,tx_int_delay = ;
>>> ti,fifo_depth = ;
>>> };
>>>
>>> This is the way it is in the kernel.
>> First of all. Please rebase your 2/2 on the top of current branch.
>> sgmii support was added recently.
>
> Yeah I had a feeling that I was going to need to do that.
>
>>
>> Here is what I use on zynqmp.
>> http://lists.denx.de/pipermail/u-boot/2016-April/250866.html
>> And it reflects the description above.
>
> OK the zync_gem supports phy-handle. cpsw does not. Looks like I have
> to add a patch to cpsw.
yep but again your patch is failing on zynqmp. Because I don't think
there is hook to read that values from DT.
I didn't look at details but definitely please check it.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: move platform specific NAND configs to platform specific header
On Fri, Apr 08, 2016 at 03:10:13PM +0530, Lokesh Vutla wrote: > From: Roger Quadros > > Not all keystone 2 devices use Davinci NAND controller. Move the platform > specific NAND configurations into platform specific headers. > > Reported-by: Nishanth Menon > Signed-off-by: Roger Quadros > Signed-off-by: Mugunthan V N > Signed-off-by: Lokesh Vutla > --- > - This fixes the asynchronous abort generated in kernel. > Without this patch: http://pastebin.ubuntu.com/15683902/ > With this patch: http://pastebin.ubuntu.com/15683889/ OK, so this seems important to get in. But can we Kconfig this please? Thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot][PATCH v3 1/2] net: phy: dp83867: Add device tree bindings and documentation
On 04/08/2016 04:25 AM, Michal Simek wrote:
> On 7.4.2016 18:02, Dan Murphy wrote:
>> Mugunthan
>>
>> On 04/06/2016 11:45 PM, Mugunthan V N wrote:
>>> On Wednesday 06 April 2016 05:07 PM, Dan Murphy wrote:
Add the device tree bindings and the accompanying documentation
for the TI DP83867 Giga bit ethernet phy driver.
The original document was from:
[commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux kernel]
Signed-off-by: Dan Murphy
---
v3 - Modify the binding to the kernel changed int -> internal for the
delay - https://patchwork.ozlabs.org/patch/606595/
doc/device-tree-bindings/net/ti,dp83867.txt | 29
include/dt-bindings/net/ti-dp83867.h| 35
+
2 files changed, 64 insertions(+)
create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
create mode 100644 include/dt-bindings/net/ti-dp83867.h
diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt
b/doc/device-tree-bindings/net/ti,dp83867.txt
new file mode 100644
index 000..0ec009c
--- /dev/null
+++ b/doc/device-tree-bindings/net/ti,dp83867.txt
@@ -0,0 +1,29 @@
+* Texas Instruments - dp83867 Giga bit ethernet phy
+
+Required properties:
+ - ti,rx-internal-delay - RGMII Recieve Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,tx-internal-delay - RGMII Transmit Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
+ for applicable values
+
+Default child nodes are standard Ethernet PHY device
+nodes as described in doc/devicetree/bindings/net/ethernet.txt
+
+Example:
+
+&mac {
+ pinctrl-0 = <&davinci_mdio_default>;
+ pinctrl-1 = <&davinci_mdio_sleep>;
+ status = "okay";
+
+ ti,rx_internal_delay = ;
+ ti,tx_internal_delay = ;
+ ti,fifo_depth = ;
+
+};
>>> This example should in phy node and not in mac node as per the linux
>>> commmit mentioned above?
>> Are you saying that the code should look like this
>>
>> &mac {
>> pinctrl-0 = <&davinci_mdio_default>;
>> pinctrl-1 = <&davinci_mdio_sleep>;
>> status = "okay";
>> phy-handle = <ðernet_phy>;
>>
>> ethernet_phy: ethernet-phy@0 {
>> reg = <0>;
>> ti,rx_int_delay = ;
>> ti,tx_int_delay = ;
>> ti,fifo_depth = ;
>> };
>>
>> This is the way it is in the kernel.
> First of all. Please rebase your 2/2 on the top of current branch.
> sgmii support was added recently.
Yeah I had a feeling that I was going to need to do that.
>
> Here is what I use on zynqmp.
> http://lists.denx.de/pipermail/u-boot/2016-April/250866.html
> And it reflects the description above.
OK the zync_gem supports phy-handle. cpsw does not. Looks like I have
to add a patch to cpsw.
Dan
>
> Thanks,
> Michal
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] keystone2: move platform specific NAND configs to platform specific header
From: Roger Quadros
Not all keystone 2 devices use Davinci NAND controller. Move the platform
specific NAND configurations into platform specific headers.
Reported-by: Nishanth Menon
Signed-off-by: Roger Quadros
Signed-off-by: Mugunthan V N
Signed-off-by: Lokesh Vutla
---
- This fixes the asynchronous abort generated in kernel.
Without this patch: http://pastebin.ubuntu.com/15683902/
With this patch: http://pastebin.ubuntu.com/15683889/
board/ti/ks2_evm/board.c | 5 +
include/configs/k2e_evm.h| 21 ++---
include/configs/k2hk_evm.h | 21 ++---
include/configs/k2l_evm.h| 21 ++---
include/configs/ti_armv7_keystone2.h | 16
5 files changed, 59 insertions(+), 25 deletions(-)
diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index e16669d..9e8ad93 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -20,6 +20,7 @@
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_TI_AEMIF)
static struct aemif_config aemif_configs[] = {
{ /* CS0 */
.mode = AEMIF_MODE_NAND,
@@ -33,6 +34,7 @@ static struct aemif_config aemif_configs[] = {
.width = AEMIF_WIDTH_8,
},
};
+#endif
int dram_init(void)
{
@@ -42,7 +44,10 @@ int dram_init(void)
gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
CONFIG_MAX_RAM_BANK_SIZE);
+#if defined(CONFIG_TI_AEMIF)
aemif_init(ARRAY_SIZE(aemif_configs), aemif_configs);
+#endif
+
if (ddr3_size)
ddr3_init_ecc(KS2_DDR3A_EMIF_CTRL_BASE, ddr3_size);
return 0;
diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h
index 07f975b..8c0f20e 100644
--- a/include/configs/k2e_evm.h
+++ b/include/configs/k2e_evm.h
@@ -27,14 +27,29 @@
"name_uboot=u-boot-spi-k2e-evm.gph\0" \
"name_fs=arago-console-image-k2e-evm.cpio.gz\0"
+/* NAND Configuration */
+#define CONFIG_SYS_NAND_PAGE_2K
+#define CONFIG_NAND_DAVINCI
+#define CONFIG_KEYSTONE_RBL_NAND
+#define CONFIG_KEYSTONE_NAND_MAX_RBL_SIZE CONFIG_ENV_OFFSET
+#define CONFIG_SYS_NAND_MASK_CLE 0x4000
+#define CONFIG_SYS_NAND_MASK_ALE 0x2000
+#define CONFIG_SYS_NAND_CS 2
+#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_LARGEPAGE
+#define CONFIG_CMD_NAND
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+
+/* AEMIF */
+#define CONFIG_TI_AEMIF
+#define CONFIG_AEMIF_CNTRL_BASEKS2_AEMIF_CNTRL_BASE
+
#include
/* SPL SPI Loader Configuration */
#define CONFIG_SPL_TEXT_BASE 0x0c10
-/* NAND Configuration */
-#define CONFIG_SYS_NAND_PAGE_2K
-
/* Network */
#define CONFIG_KSNET_NETCP_V1_5
#define CONFIG_KSNET_CPSW_NUM_PORTS9
diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h
index a268a86..a23e41d 100644
--- a/include/configs/k2hk_evm.h
+++ b/include/configs/k2hk_evm.h
@@ -27,14 +27,29 @@
"name_uboot=u-boot-spi-k2hk-evm.gph\0" \
"name_fs=arago-console-image-k2hk-evm.cpio.gz\0"
+/* NAND Configuration */
+#define CONFIG_SYS_NAND_PAGE_2K
+#define CONFIG_NAND_DAVINCI
+#define CONFIG_KEYSTONE_RBL_NAND
+#define CONFIG_KEYSTONE_NAND_MAX_RBL_SIZE CONFIG_ENV_OFFSET
+#define CONFIG_SYS_NAND_MASK_CLE 0x4000
+#define CONFIG_SYS_NAND_MASK_ALE 0x2000
+#define CONFIG_SYS_NAND_CS 2
+#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_LARGEPAGE
+#define CONFIG_CMD_NAND
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+
+/* AEMIF */
+#define CONFIG_TI_AEMIF
+#define CONFIG_AEMIF_CNTRL_BASEKS2_AEMIF_CNTRL_BASE
+
#include
/* SPL SPI Loader Configuration */
#define CONFIG_SPL_TEXT_BASE 0x0c20
-/* NAND Configuration */
-#define CONFIG_SYS_NAND_PAGE_2K
-
/* Network */
#define CONFIG_KSNET_NETCP_V1_0
#define CONFIG_KSNET_CPSW_NUM_PORTS5
diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h
index f366e67..c1100a1 100644
--- a/include/configs/k2l_evm.h
+++ b/include/configs/k2l_evm.h
@@ -27,14 +27,29 @@
"name_uboot=u-boot-spi-k2l-evm.gph\0" \
"name_fs=arago-console-image-k2l-evm.cpio.gz\0"
+/* NAND Configuration */
+#define CONFIG_SYS_NAND_PAGE_4K
+#define CONFIG_NAND_DAVINCI
+#define CONFIG_KEYSTONE_RBL_NAND
+#define CONFIG_KEYSTONE_NAND_MAX_RBL_SIZE CONFIG_ENV_OFFSET
+#define CONFIG_SYS_NAND_MASK_CLE 0x4000
+#define CONFIG_SYS_NAND_MASK_ALE 0x2000
+#define CONFIG_SYS_NAND_CS 2
+#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_LARGEPAGE
+#define CONFIG_CMD_NAND
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+
+/* AEMIF */
+#define CONFIG_TI_AEMIF
+#define CONFIG_AEMIF_CNTRL_BASE
Re: [U-Boot] [uboot][PATCH v3 1/2] net: phy: dp83867: Add device tree bindings and documentation
On 7.4.2016 18:02, Dan Murphy wrote:
> Mugunthan
>
> On 04/06/2016 11:45 PM, Mugunthan V N wrote:
>> On Wednesday 06 April 2016 05:07 PM, Dan Murphy wrote:
>>> Add the device tree bindings and the accompanying documentation
>>> for the TI DP83867 Giga bit ethernet phy driver.
>>>
>>> The original document was from:
>>> [commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux kernel]
>>>
>>> Signed-off-by: Dan Murphy
>>> ---
>>>
>>> v3 - Modify the binding to the kernel changed int -> internal for the delay
>>> - https://patchwork.ozlabs.org/patch/606595/
>>>
>>> doc/device-tree-bindings/net/ti,dp83867.txt | 29
>>> include/dt-bindings/net/ti-dp83867.h| 35
>>> +
>>> 2 files changed, 64 insertions(+)
>>> create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
>>> create mode 100644 include/dt-bindings/net/ti-dp83867.h
>>>
>>> diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt
>>> b/doc/device-tree-bindings/net/ti,dp83867.txt
>>> new file mode 100644
>>> index 000..0ec009c
>>> --- /dev/null
>>> +++ b/doc/device-tree-bindings/net/ti,dp83867.txt
>>> @@ -0,0 +1,29 @@
>>> +* Texas Instruments - dp83867 Giga bit ethernet phy
>>> +
>>> +Required properties:
>>> + - ti,rx-internal-delay - RGMII Recieve Clock Delay - see
>>> dt-bindings/net/ti-dp83867.h
>>> + for applicable values
>>> + - ti,tx-internal-delay - RGMII Transmit Clock Delay - see
>>> dt-bindings/net/ti-dp83867.h
>>> + for applicable values
>>> + - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
>>> + for applicable values
>>> +
>>> +Default child nodes are standard Ethernet PHY device
>>> +nodes as described in doc/devicetree/bindings/net/ethernet.txt
>>> +
>>> +Example:
>>> +
>>> +&mac {
>>> + pinctrl-0 = <&davinci_mdio_default>;
>>> + pinctrl-1 = <&davinci_mdio_sleep>;
>>> + status = "okay";
>>> +
>>> + ti,rx_internal_delay = ;
>>> + ti,tx_internal_delay = ;
>>> + ti,fifo_depth = ;
>>> +
>>> +};
>> This example should in phy node and not in mac node as per the linux
>> commmit mentioned above?
>
> Are you saying that the code should look like this
>
> &mac {
> pinctrl-0 = <&davinci_mdio_default>;
> pinctrl-1 = <&davinci_mdio_sleep>;
> status = "okay";
> phy-handle = <ðernet_phy>;
>
> ethernet_phy: ethernet-phy@0 {
> reg = <0>;
> ti,rx_int_delay = ;
> ti,tx_int_delay = ;
> ti,fifo_depth = ;
> };
>
> This is the way it is in the kernel.
First of all. Please rebase your 2/2 on the top of current branch.
sgmii support was added recently.
Here is what I use on zynqmp.
http://lists.denx.de/pipermail/u-boot/2016-April/250866.html
And it reflects the description above.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: g_dnl: Change device class
Hi John,
> The USB Mass Storage (ums) works in Windows, Linux and OS X (EL
> Capitan). But, not in OS X (Yosemite). By applying the said patch, it
> extends the ums support.
>
> Signed-off-by: John Tobias
> ---
> drivers/usb/gadget/g_dnl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
> index 2fa6da4..bd3aad9 100644
> --- a/drivers/usb/gadget/g_dnl.c
> +++ b/drivers/usb/gadget/g_dnl.c
> @@ -58,8 +58,8 @@ static struct usb_device_descriptor device_desc = {
> .bDescriptorType = USB_DT_DEVICE,
>
> .bcdUSB = __constant_cpu_to_le16(0x0200),
> - .bDeviceClass = USB_CLASS_COMM,
> - .bDeviceSubClass = 0x02, /*0x02:CDC-modem , 0x00:CDC-serial*/
> + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> + .bDeviceSubClass = 0, /*0x02:CDC-modem , 0x00:CDC-serial*/
Have you tested if this patch is not introducing any regression on
Linux and Windows?
>
> .idVendor = __constant_cpu_to_le16(CONFIG_G_DNL_VENDOR_NUM),
> .idProduct =
> __constant_cpu_to_le16(CONFIG_G_DNL_PRODUCT_NUM),
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Potential memory corruption in drivers/net/sh_eth.c ?
Dear Heiko, [Nobuhiro's mail address fixed] In message <57076c13.50...@denx.de> you wrote: > > > I recommend to make this restriction more visible in the code and in > > the comment, and/or even add a compile time test to guarantee this > > requirement is met. > > Maybe you try the following patch on your hardware: I think this is not needed. I reviewed the code, and if I'm not wrong the code adds exactly the needed padding to make the structure size a power of 2. My complaint is that this requirement is not visible in the code, and there is no explanation for the magic numbers. The comment just says The size of the tx descriptor is determined by how much padding is used. 4, 20, or 52 bytes of padding can be used When you look closer, you will see that the currently used struct size is 12 bytes, so adding 4, 20, or 52 bytes of padding will result in total sizes of 12+4=16, 12+20=32 resp. 12+52=64 bytes, i. e. all will result in proper sizes. But this is not obvious to the reader who does not happen to realize that this size is used as argument to memalign(), and that memalign() has such a mandatory requirement() without checking for it, and with potentially fatal consequences. [And yes, I think we shoudl augment the memalign() implementation with a compile time test for proper alignment size... Any volunteers?] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die Jahre hinterlassen vielleicht Falten auf der Haut, aber die Begeisterung zu verlieren hinterlässt Falten auf der Seele. - Samuel Ullmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Potential memory corruption in drivers/net/sh_eth.c ?
Hello Nobuhiro,
Am 07.04.2016 um 22:31 schrieb Wolfgang Denk:
Dear Nobuhiro,
while tracking down a memory corruption bug in other code, I ran over
these lines in drivers/net/sh_eth.c :
...
194 /*
195 * Allocate rx descriptors. They must be aligned to size of struct
196 * tx_desc_s.
197 */
198 port_info->tx_desc_alloc =
199 memalign(sizeof(struct tx_desc_s), alloc_desc_size);
...
246 /*
247 * Allocate rx descriptors. They must be aligned to size of struct
248 * rx_desc_s.
249 */
250 port_info->rx_desc_alloc =
251 memalign(sizeof(struct rx_desc_s), alloc_desc_size);
There is some padding done (in drivers/net/sh_eth.h) to the stucts
tx_desc_s and rx_desc_s, but it appears onecritical fact is nowhere
checked:
Quoting from "common/dlmalloc.c":
2784 memalign algorithm:
2785
2786 memalign requests more than enough space from malloc, finds a spot
2787 within that chunk that meets the alignment request, and then
2788 possibly frees the leading and trailing space.
2789
2790 The alignment argument must be a power of two. This property is not
2791 checked by memalign, so misuse may result in random runtime errors.
^
I. e. it is _mandatory_ that the first argument to memalign() must be
a power of two. The current code does not guarantee this, and the
comments in the code (drivers/net/sh_eth.h) do not hint on this
restriction either:
...
51 /* The size of the tx descriptor is determined by how much padding is used.
524, 20, or 52 bytes of padding can be used */
I recommend to make this restriction more visible in the code and in
the comment, and/or even add a compile time test to guarantee this
requirement is met.
Maybe you try the following patch on your hardware:
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index b5bb051..cb2a5d8 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -2797,6 +2797,15 @@ Void_t* rEALLOc(oldmem, bytes) Void_t* oldmem; size_t
bytes;
*/
+/*
+ * from:
+ *
http://www.exploringbinary.com/ten-ways-to-check-if-an-integer-is-a-power-of-two-in-c/
+ * "10. Complement and Compare"
+ */
+static int isPowerOfTwo(size_t x)
+{
+ return ((x != 0) && ((x & (~x + 1)) == x));
+}
#if __STD_C
Void_t* mEMALIGn(size_t alignment, size_t bytes)
@@ -2824,6 +2833,12 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment;
size_t bytes;
if (alignment < MINSIZE) alignment = MINSIZE;
+ /* check if alignment is a power of 2 */
+ if (isPowerOfTwo(alignment) == 0) {
+printf("%s: %d is not power of 2!\n", __func__, alignment);
+return NULL;
+ }
+
/* Call malloc with worst case padding to hit alignment. */
nb = request2size(bytes);
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] ARMv7: PSCI: add PSCI v1.0 support
Hi all,
Purpose of my previous reply was to explain that other platform's psci
codes are touched several times in my patches, but they are not
changed much at last, while that reply was identified by patch work as
a patch too, reviews please ignore it:
https://patchwork.ozlabs.org/patch/607904/
On Fri, Apr 8, 2016 at 3:57 PM, hb zhang wrote:
> This patch set touches other psci drivers, such as
>
> arch/arm/cpu/armv7/mx7/psci.S | 7 +-
> arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 8 +-
> arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 8 +-
> arch/arm/mach-tegra/psci.S | 7 +-
>
> But the changes are quite slightly, take the psci_sun7i.S for example,
> changes after all patches are like this:
>
> diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> index e15d587..b0601a7 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> @@ -119,14 +119,12 @@ out: mcr p15, 0, r7, c1, c1, 0
>
> @ r1 = target CPU
> @ r2 = target PC
> + @ r3 = target Conetxt ID
> .globl psci_cpu_on
> psci_cpu_on:
> push{lr}
>
> - mov r0, r1
> - bl psci_get_cpu_stack_top @ get stack top of target CPU
> - str r2, [r0]@ store target PC at stack top
> - dsb
> + bl psci_cpu_on_common
>
> movwr0, #(SUN7I_CPUCFG_BASE & 0x)
> movtr0, #(SUN7I_CPUCFG_BASE >> 16)
> @@ -179,7 +177,7 @@ psci_cpu_on:
> orr r6, r6, r4
> str r6, [r0, #0x1e4]
>
> - mov r0, #ARM_PSCI_RET_SUCCESS @ Return PSCI_RET_SUCCESS
> + mov r0, #PSCI_RET_SUCCESS @ Return PSCI_RET_SUCCESS
> pop {pc}
>
>
>
> On Fri, Apr 8, 2016 at 2:23 PM, wrote:
>> From: Hongbo Zhang
>>
>> This patch set contains two parts:
>> ARMv7 PSCI common framework: fix some issues and add v1.0 support
>> NXP (was Freescale) LS102XA: codes enhancement and add v1.0 implementation
>>
>> Changes since v1:
>> - re-organize psci_cpu_on_common, this code should be called by each
>> platform's
>> psci_cpu_on, should not be a function calling each psci_cpu_on, all related
>> functions are updated due to this change
>> - update some registers usage, e.g. if r10 is used without push/pop, u-boot
>> cannot launch rt-kernel
>> - update some comments to be clearer, re-organize all patches for easier
>> review
>> - add patch to check already_on or on_pending for LS102XA
>>
>>
>> Hongbo Zhang:
>> Wang Dongsheng:
>> ARMv7: PSCI: update function psci_get_cpu_stack_top
>> ARMv7: PSCI: update the place of saving target PC
>> ARMv7: PSCI: add codes to save context ID for CPU_ON
>> ARMv7: PSCI: factor out reusable psci_cpu_on_common
>> ARMv7: PSCI: add PSCI v1.0 functions skeleton
>> ARMv7: PSCI: ls102xa: check target CPU ID before further operations
>> ARMv7: PSCI: ls102xa: check ALREADY_ON or ON_PENDING for CPU_ON
>> ARMv7: PSCI: ls102xa: add more PSCI v1.0 functions implemention
>> ARMv7: PSCI: ls102xa: move secure text section into OCRAM
>> ARM: PSCI: change PSCI function IDs base and offsets
>> ARM: PSCI: change PSCI related macros definition style
>>
>> arch/arm/cpu/armv7/ls102xa/psci.S | 177
>> +++--
>> arch/arm/cpu/armv7/mx7/psci.S | 7 +-
>> arch/arm/cpu/armv7/nonsec_virt.S | 7 ++
>> arch/arm/cpu/armv7/psci.S | 113 +++---
>> arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 8 +-
>> arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 8 +-
>> arch/arm/cpu/armv7/virt-dt.c | 54 ++---
>> arch/arm/include/asm/arch-ls102xa/config.h | 3 +-
>> arch/arm/include/asm/psci.h| 62 +++---
>> arch/arm/mach-tegra/psci.S | 7 +-
>> board/freescale/ls1021aqds/Makefile| 1 +
>> board/freescale/ls1021aqds/psci.S | 36 ++
>> board/freescale/ls1021atwr/Makefile| 1 +
>> board/freescale/ls1021atwr/psci.S | 28 +
>> include/configs/ls1021aqds.h | 3 +
>> include/configs/ls1021atwr.h | 3 +
>> 16 files changed, 449 insertions(+), 69 deletions(-)
>> create mode 100644 board/freescale/ls1021aqds/psci.S
>> create mode 100644 board/freescale/ls1021atwr/psci.S
>>
>> --
>> 2.1.4
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] ARMv7: PSCI: add PSCI v1.0 support
This patch set touches other psci drivers, such as
arch/arm/cpu/armv7/mx7/psci.S | 7 +-
arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 8 +-
arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 8 +-
arch/arm/mach-tegra/psci.S | 7 +-
But the changes are quite slightly, take the psci_sun7i.S for example,
changes after all patches are like this:
diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
index e15d587..b0601a7 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
@@ -119,14 +119,12 @@ out: mcr p15, 0, r7, c1, c1, 0
@ r1 = target CPU
@ r2 = target PC
+ @ r3 = target Conetxt ID
.globl psci_cpu_on
psci_cpu_on:
push{lr}
- mov r0, r1
- bl psci_get_cpu_stack_top @ get stack top of target CPU
- str r2, [r0]@ store target PC at stack top
- dsb
+ bl psci_cpu_on_common
movwr0, #(SUN7I_CPUCFG_BASE & 0x)
movtr0, #(SUN7I_CPUCFG_BASE >> 16)
@@ -179,7 +177,7 @@ psci_cpu_on:
orr r6, r6, r4
str r6, [r0, #0x1e4]
- mov r0, #ARM_PSCI_RET_SUCCESS @ Return PSCI_RET_SUCCESS
+ mov r0, #PSCI_RET_SUCCESS @ Return PSCI_RET_SUCCESS
pop {pc}
On Fri, Apr 8, 2016 at 2:23 PM, wrote:
> From: Hongbo Zhang
>
> This patch set contains two parts:
> ARMv7 PSCI common framework: fix some issues and add v1.0 support
> NXP (was Freescale) LS102XA: codes enhancement and add v1.0 implementation
>
> Changes since v1:
> - re-organize psci_cpu_on_common, this code should be called by each
> platform's
> psci_cpu_on, should not be a function calling each psci_cpu_on, all related
> functions are updated due to this change
> - update some registers usage, e.g. if r10 is used without push/pop, u-boot
> cannot launch rt-kernel
> - update some comments to be clearer, re-organize all patches for easier
> review
> - add patch to check already_on or on_pending for LS102XA
>
>
> Hongbo Zhang:
> Wang Dongsheng:
> ARMv7: PSCI: update function psci_get_cpu_stack_top
> ARMv7: PSCI: update the place of saving target PC
> ARMv7: PSCI: add codes to save context ID for CPU_ON
> ARMv7: PSCI: factor out reusable psci_cpu_on_common
> ARMv7: PSCI: add PSCI v1.0 functions skeleton
> ARMv7: PSCI: ls102xa: check target CPU ID before further operations
> ARMv7: PSCI: ls102xa: check ALREADY_ON or ON_PENDING for CPU_ON
> ARMv7: PSCI: ls102xa: add more PSCI v1.0 functions implemention
> ARMv7: PSCI: ls102xa: move secure text section into OCRAM
> ARM: PSCI: change PSCI function IDs base and offsets
> ARM: PSCI: change PSCI related macros definition style
>
> arch/arm/cpu/armv7/ls102xa/psci.S | 177
> +++--
> arch/arm/cpu/armv7/mx7/psci.S | 7 +-
> arch/arm/cpu/armv7/nonsec_virt.S | 7 ++
> arch/arm/cpu/armv7/psci.S | 113 +++---
> arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 8 +-
> arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 8 +-
> arch/arm/cpu/armv7/virt-dt.c | 54 ++---
> arch/arm/include/asm/arch-ls102xa/config.h | 3 +-
> arch/arm/include/asm/psci.h| 62 +++---
> arch/arm/mach-tegra/psci.S | 7 +-
> board/freescale/ls1021aqds/Makefile| 1 +
> board/freescale/ls1021aqds/psci.S | 36 ++
> board/freescale/ls1021atwr/Makefile| 1 +
> board/freescale/ls1021atwr/psci.S | 28 +
> include/configs/ls1021aqds.h | 3 +
> include/configs/ls1021atwr.h | 3 +
> 16 files changed, 449 insertions(+), 69 deletions(-)
> create mode 100644 board/freescale/ls1021aqds/psci.S
> create mode 100644 board/freescale/ls1021atwr/psci.S
>
> --
> 2.1.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 11/11] ARMv7: PSCI: ls102xa: move secure text section into OCRAM
From: Hongbo Zhang LS1021 offers two secure OCRAM blocks for trustzone. This patch moves all the secure text sections into the OCRAM. Signed-off-by: Wang Dongsheng Signed-off-by: Hongbo Zhang --- arch/arm/include/asm/arch-ls102xa/config.h | 2 +- include/configs/ls1021atwr.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index 955a074..0266352 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -10,7 +10,7 @@ #define CONFIG_SYS_CACHELINE_SIZE 64 #define OCRAM_BASE_ADDR0x1000 -#define OCRAM_SIZE 0x0002 +#define OCRAM_SIZE 0x0001 #define OCRAM_BASE_S_ADDR 0x1001 #define OCRAM_S_SIZE 0x0001 diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index f7e1457..54d4439 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -12,6 +12,8 @@ #define CONFIG_ARMV7_PSCI #define CONFIG_ARMV7_PSCI_1_0 +#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR + #define CONFIG_SYS_FSL_CLK #define CONFIG_DISPLAY_CPUINFO -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
