[U-Boot] tftp using ENC424J600
Can u-boot currently do tftp using a Microchip ENC424J600? This is an ethernet over SPI module. Thanks for any information. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] kconfig: introduce kconfig for UBI
move the UBI config options into Kconfig.
Signed-off-by: Heiko Schocher
---
Tested with tbot:
http://lists.denx.de/pipermail/u-boot/2016-June/258119.html
result:
Boards : 1196
compile err : 36
not checked : 0
U-Boot good : 1157 bad 3
SPL good: 427 bad 0
('compile err :', [...]
('bad :', ['sandbox', 'sandbox_noblk', 'sandbox_spl'])
I have 36 boards, which do not compile, at least with my
toolchains used, see:
https://github.com/hsdenx/tbot/blob/master/config/tbot_uboot_kconfig_check.cfg#L68
but none of them had UBI support, so this should be OK.
One change which should be discussed in microblaze-generic:
(I preceded the patchsnipset with a 'D' so I hope it does
not confuse patchwork)
Ddiff --git a/include/configs/microblaze-generic.h
b/include/configs/microblaze-generic.h
Dindex e5bf700..d8e65f8 100644
D--- a/include/configs/microblaze-generic.h
D+++ b/include/configs/microblaze-generic.h
D@@ -177,7 +177,6 @@
D
D #if defined(FLASH)
D # define CONFIG_CMD_JFFS2
D-# define CONFIG_CMD_UBI
D # undef CONFIG_CMD_UBIFS
D
D # if !defined(RAMENV)
D@@ -192,7 +191,6 @@
D # endif
D #else
D # undef CONFIG_CMD_JFFS2
D-# undef CONFIG_CMD_UBI
D # undef CONFIG_CMD_UBIFS
D #endif
D #endif
D@@ -202,7 +200,6 @@
D #endif
D
D #if defined(CONFIG_CMD_UBIFS)
D-# define CONFIG_CMD_UBI
D # define CONFIG_LZO
D #endif
Hmm... how to handle such a move?
Just ignore it, as my test does not detect different
binaries?
cmd/Kconfig | 12 +++
configs/PLU405_defconfig| 1 +
configs/VCMA9_defconfig | 1 +
configs/a3m071_defconfig| 1 +
configs/a4m2k_defconfig | 1 +
configs/am335x_baltos_defconfig | 1 +
configs/am3517_evm_defconfig| 1 +
configs/apf27_defconfig | 1 +
configs/apx4devkit_defconfig| 1 +
configs/aristainetos2_defconfig | 3 +
configs/aristainetos2b_defconfig| 3 +
configs/aristainetos_defconfig | 3 +
configs/at91sam9x5ek_dataflash_defconfig| 1 +
configs/at91sam9x5ek_mmc_defconfig | 1 +
configs/at91sam9x5ek_nandflash_defconfig| 1 +
configs/at91sam9x5ek_spiflash_defconfig | 1 +
configs/colibri_imx7_defconfig | 2 +
configs/colibri_t20_defconfig | 2 +
configs/colibri_vf_defconfig| 2 +
configs/dns325_defconfig| 1 +
configs/dockstar_defconfig | 1 +
configs/draco_defconfig | 3 +
configs/ds414_defconfig | 1 +
configs/ea20_defconfig | 1 +
configs/eco5pk_defconfig| 1 +
configs/etamin_defconfig| 3 +
configs/ethernut5_defconfig | 1 +
configs/goflexhome_defconfig| 1 +
configs/guruplug_defconfig | 1 +
configs/gwventana_defconfig | 1 +
configs/ib62x0_defconfig| 1 +
configs/iconnect_defconfig | 1 +
configs/ids8313_defconfig | 1 +
configs/igep0020_defconfig | 1 +
configs/igep0030_defconfig | 1 +
configs/igep0030_nand_defconfig | 1 +
configs/igep0032_defconfig | 1 +
configs/ipam390_defconfig | 1 +
configs/k2e_evm_defconfig | 1 +
configs/k2g_evm_defconfig | 1 +
configs/k2hk_evm_defconfig | 1 +
configs/k2l_evm_defconfig | 1 +
configs/km_kirkwood_128m16_defconfig| 1 +
configs/km_kirkwood_defconfig | 1 +
configs/km_kirkwood_pci_defconfig | 1 +
configs/kmcoge4_defconfig | 1 +
configs/kmcoge5ne_defconfig | 1 +
configs/kmcoge5un_defconfig | 1 +
configs/kmeter1_defconfig | 1 +
configs/kmlion1_defconfig | 1 +
configs/kmnusa_defconfig| 1 +
configs/kmopti2_defconfig | 1 +
configs/kmsugp1_defconfig | 1 +
configs/kmsupx5_defconfig | 1 +
configs/kmsuv31_defconfig | 1 +
configs/kmtegr1_defconfig | 1 +
configs/kmtepr2_defconfig | 1 +
configs/kmvect1_defconfig | 1 +
configs/m28evk_defconfig| 1 +
configs/m53evk_defconfig| 1 +
configs/mcx_defconfig | 1 +
configs/mgcoge3ne_defconfig | 1 +
configs/mgcoge3un_defconfig | 1 +
configs/mgcoge_defconfig
Re: [U-Boot] [PATCH 1/5] power: regulator: Add ctrl_reg and volt_reg fields for pmic
Hi Marczak,
On Wednesday 14 September 2016 01:33 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/14/2016 06:28 AM, Keerthy wrote:
The ctrl reg contains bit fields to enable and disable regulators,
and volt_reg has the bit fields to configure the voltage values.
The registers are frequently accessed hence make them part
of dm_regulator_uclass_platdata structure.
Signed-off-by: Keerthy
---
include/power/regulator.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 9bcd728..57b14a3 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -171,6 +171,8 @@ struct dm_regulator_uclass_platdata {
bool boot_on;
const char *name;
int flags;
+u8 ctrl_reg;
+u8 volt_reg;
};
/* Regulator device operations */
This structure above is used for some common "high-level" data, which
can be used by regulator uclass driver.
Even if most of PMICs has some ctrl/volt/etc regs, the regulator uclass
driver doesn't know, how to use it, so from this point of view it is
useless.
But, you can keep device/driver data in a proper fields. Please look at
those files:
drivers/power/regulator/fixed.c:119
drivers/power/regulator/pfuze100.c:567
To store some device internal data, you can use:
.platdata_auto_alloc_size -> with access by dev_get_platdata()
.priv_auto_alloc_size -> with access by dev_get_priv()
Thanks for a quick review. I did look at some of those options before
introducing volt and ctrl here.
Many PMICs will have ctrl/volt registers we might end up having lot of
private strutures with the same ctrl/volt fields. I agree uclass driver
will not know how to use it.
If i have to draw parallels from the kernel world regulator_desc is a
common structure which hosts vsel_reg/enable_reg fields.
Isn't it better to have a common structure instead of having a some
platform specific structure that might have the same fields?
Let me know your thoughts on this.
Best regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] test: add NFS download test
Add a NFS download test, based on TFTP test.
Tested on i.MX6 SabreLite board.
Signed-off-by: Guillaume GARDET
Cc: Tom Rini
Cc: Joe Hershberger
Cc: Stephen Warren
Cc: Simon Glass
---
test/py/tests/test_net.py | 49 +++
1 file changed, 49 insertions(+)
diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index 4ab58b4..0884051 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -47,6 +47,15 @@ env__net_tftp_readable_file = {
"size": 5058624,
"crc32": "c2244b26",
}
+
+# Details regarding a file that may be read from a NFS server. This variable
+# may be omitted or set to None if NFS testing is not possible or desired.
+env__net_nfs_readable_file = {
+"fn": "ubtest-readable.bin",
+"addr": 0x1000,
+"size": 5058624,
+"crc32": "c2244b26",
+}
"""
net_set_up = False
@@ -157,3 +166,43 @@ def test_net_tftpboot(u_boot_console):
output = u_boot_console.run_command('crc32 %x $filesize' % addr)
assert expected_crc in output
+
+@pytest.mark.buildconfigspec('cmd_nfs')
+def test_net_nfs(u_boot_console):
+"""Test the nfs command.
+
+A file is downloaded from the NFS server, its size and optionally its
+CRC32 are validated.
+
+The details of the file to download are provided by the boardenv_* file;
+see the comment at the beginning of this file.
+"""
+
+if not net_set_up:
+pytest.skip('Network not initialized')
+
+f = u_boot_console.config.env.get('env__net_nfs_readable_file', None)
+if not f:
+pytest.skip('No NFS readable file to read')
+
+addr = f.get('addr', None)
+if not addr:
+addr = u_boot_utils.find_ram_base(u_boot_console)
+
+fn = f['fn']
+output = u_boot_console.run_command('nfs %x %s' % (addr, fn))
+expected_text = 'Bytes transferred = '
+sz = f.get('size', None)
+if sz:
+expected_text += '%d' % sz
+assert expected_text in output
+
+expected_crc = f.get('crc32', None)
+if not expected_crc:
+return
+
+if u_boot_console.config.buildconfig.get('config_cmd_crc32', 'n') != 'y':
+return
+
+output = u_boot_console.run_command('crc32 %x $filesize' % addr)
+assert expected_crc in output
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] recommended place to add some custom settings to u-boot environment?
on my target board, there is some non-linux environment info in "var=val" form that i want to drag into the current environment whenever u-boot starts up. my plan is just to import that content into a (new) hash table, then tweak it a bit before further adding it to "env_htab". the logistics seem pretty straightforward, i'm just curious as to where the *right*(?) place is to do this. currently, we're not taking advantage of CONFIG_MISC_INIT_R, so it seems that would be a reasonable place to do that, in the board source file. does that make sense? at that point, all of the normal environment will have been initialized, and i'll have access to "env_htab". thoughts? is there a better place to "adjust" the u-boot environment once u-boot has done its normal work? thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
Dear Robert, In message you wrote: > > on my target board, there is some non-linux environment info in > "var=val" form that i want to drag into the current environment > whenever u-boot starts up. my plan is just to import that content into > a (new) hash table, then tweak it a bit before further adding it to > "env_htab". the logistics seem pretty straightforward, i'm just > curious as to where the *right*(?) place is to do this. Sounds complicated... > does that make sense? at that point, all of the normal environment > will have been initialized, and i'll have access to "env_htab". > thoughts? is there a better place to "adjust" the u-boot environment > once u-boot has done its normal work? thanks. Why not simply putting this as text (or wrapped with an uImage header) into some storage (or even a file) and then use "env import" to load it? 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 Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > on my target board, there is some non-linux environment info in > > "var=val" form that i want to drag into the current environment > > whenever u-boot starts up. my plan is just to import that content > > into a (new) hash table, then tweak it a bit before further adding > > it to "env_htab". the logistics seem pretty straightforward, i'm > > just curious as to where the *right*(?) place is to do this. > > Sounds complicated... > > > does that make sense? at that point, all of the normal > > environment will have been initialized, and i'll have access to > > "env_htab". thoughts? is there a better place to "adjust" the > > u-boot environment once u-boot has done its normal work? thanks. > > Why not simply putting this as text (or wrapped with an uImage > header) into some storage (or even a file) and then use "env import" > to load it? the problem is that that additional "environment" info is on the target board because of a legacy non-linux OS -- it's at a well-known address in flash, and we have no freedom to change it, we can only read it, make some adjustments, then incorporate it into the current environment. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system initialization
Hi Prabhakar, > -Original Message- > From: Prabhakar Kushwaha > Sent: 2016年9月14日 16:18 > To: Z.Q. Hou ; u-boot@lists.denx.de; > albert.u.b...@aribaud.net; york sun ; Mingkai Hu > ; Calvin Johnson > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system > initialization > > > > -Original Message- > > From: Z.Q. Hou > > Sent: Wednesday, September 14, 2016 8:16 AM > > To: Prabhakar Kushwaha ; u- > > b...@lists.denx.de; albert.u.b...@aribaud.net; york sun > > ; Vincent Hu ; Calvin Johnson > > > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system > > initialization > > > > Hi Prabhakar, > > > > Thanks for your feedback! > > > > > -Original Message- > > > From: Prabhakar Kushwaha > > > Sent: 2016年9月13日 18:04 > > > To: Z.Q. Hou ; u-boot@lists.denx.de; > > > albert.u.b...@aribaud.net; york sun ; Vincent Hu > > > ; Calvin Johnson > > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock > > > system initialization > > > > > > > > > > -Original Message- > > > > From: Z.Q. Hou > > > > Sent: Tuesday, September 13, 2016 2:39 PM > > > > To: Prabhakar Kushwaha ; u- > > > > b...@lists.denx.de; albert.u.b...@aribaud.net; york sun > > > > ; Vincent Hu ; Calvin > > > > Johnson > > > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock > > > > system initialization > > > > > > > > Hi Prabhakar, > > > > > > > > Thanks for your feedback. > > > > > > > > > -Original Message- > > > > > From: Prabhakar Kushwaha > > > > > Sent: 2016年9月13日 15:22 > > > > > To: Z.Q. Hou ; u-boot@lists.denx.de; > > > > > albert.u.b...@aribaud.net; york sun ; Vincent > > > > > Hu ; Calvin Johnson > > > > > Cc: Z.Q. Hou > > > > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock > > > > > system initialization > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Zhiqiang Hou [mailto:zhiqiang@nxp.com] > > > > > > Sent: Monday, September 12, 2016 9:39 AM > > > > > > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; york sun > > > > > > ; Vincent Hu ; Prabhakar > > > > > > Kushwaha ; Calvin Johnson > > > > > > > > > > > > Cc: Z.Q. Hou > > > > > > Subject: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock > > > > > > system initialization > > > > > > > > > > > > From: Hou Zhiqiang > > > > > > > > > > > > This patch map the sys_info->freq_systembus to Platform PLL, > > > > > > and implement the IPs' clock function individually. > > > > > > > > > > > > Signed-off-by: Hou Zhiqiang > > > > > > --- > > > > > > .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 26 > > > > > > +-- > > > > > > --- > > > > > > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 1 + > > > > > > include/configs/ls2080a_common.h | 2 +- > > > > > > 3 files changed, 22 insertions(+), 7 deletions(-) > > > > > > > > > > > > diff --git > > > > > > a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > > index a9b12a4..daad80a 100644 > > > > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > > @@ -88,11 +88,10 @@ void get_sys_info(struct sys_info > > > > > > *sys_info) #endif #endif > > > > > > > > > > > > + /* The freq_systembus is used to record frequency of > > > > > > +platform PLL */ > > > > > > sys_info->freq_systembus *= (gur_in32(&gur->rcwsr[0]) >> > > > > > > FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_SHIFT) & > > > > > > FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_MASK; > > > > > > - /* Platform clock is half of platform PLL */ > > > > > > - sys_info->freq_systembus /= 2; > > > > > > > > > > This is required only for ls2080A and ls2088A otherwise u-boot > > > > > will be printing dicken speed in boot log. > > > > > > > > Why it is required by ls2080A and ls2088A? and I don't know what's > > > > 'dicken speed'? > > > > > > > > > > Clock generated by SYSCLK * RCW[SYS_PLL_RAT] == dicken speed for > > > LS2080 and LS2088A. > > > Platform clock or CCB = dicken speed/2 > > > > Why it is required by ls2080A and ls2088A but without #ifdef > LS2080||LS2088? > > Is there any document upon the concept 'dicken speed'? As you said the > > dicken speed == platform PLL frequency on LS2080A and LS2088A, what > > about other SoCs? > > if the platform clock == dicken speed/2 on all Layerscape chassis2 and 3? > > > > Platform clock == dicken speed/2. It is only for LS2080A and LS2088A. > For ls1088a and other SoCs platform clock = SYSCLK * RCW[SYS_PLL_RAT] > Refer to LS1012A RM revC, the ls1012a platform clock = SYSCLK * RCW[SYS_PLL_RAT] / 2. For this patch, what do you think about matching sys_info->freq_systembus with platform PLL frequency? Do you have any suggestion on either the platform PLL or platform clock should be printed as bus clock in u-boot? > > > > > > > > > > > > > > sys_info->freq_
Re: [U-Boot] [bug report] sunxi: booting from eMMC
Hi, On 13-09-16 13:50, Maxime Ripard wrote: Hi, On Mon, Sep 12, 2016 at 04:47:49PM +0200, Hans de Goede wrote: On 12-09-16 15:56, Maxime Ripard wrote: Hi, On Mon, Sep 12, 2016 at 01:53:24PM +0200, Ciprian Manea wrote: I'm using a SinA33 dev board (Allwinner a33 SoC) and at the moment I'm trying to boot from the eMMC. But it fails in the following way: *Got the following error at boot time:* *U-Boot SPL 2016.09-rc2-00125-g6e8b42f (Sep 08 2016 - 11:00:46) DRAM: 1024 MiB Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###* So I've been on the same issue for the last couple of days. Since that board is already supported, adding support for the eMMC basically came down to that patch on top of 2016.09-rc2. http://code.bulix.org/kcgxri-106037?raw (Quite hackish, the 8-Bits part being a separate issue that would need to be addressed somehow). However, it doesn't work, neither when flashing u-boot on the eMMC itself (where there's a timeout error in the SPL) nor when trying to access the eMMC from a U-Boot loaded from the (external) SD. In the latter case, even mmc dev 1 fails silently. I traced that down to the mmc_switch here: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530 Which fails with ETIMEDOUT, and more specifically, it's the call to mmc_rint_wait here http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sunxi_mmc.c#l383 that times out. Increasing the timeout value (to 1) doesn't really change anything. I guess this is also the reason why we had a timeout error in the SPL. This eMMC works fine in Linux, with the same muxing (and I guess the earlier commands wouldn't be successful if the muxing or power was not set up appropriately). So I'm kind of running out of ideas on what could be the root cause of this. Hans, any ideas? Maybe the emmc needs external pull-ups ? I don't remember if u-boot always enables those or not ... So I pushed this a bit more, and it seems like commenting the call to mmc_change_freq makes everything just work. Reading the JEDEC spec, it looks like when you switch to high speed, you also need to change the controller clock rate, that u-boot doesn't seem to do at the moment, which obviously will fail, since the controller will be stuck at the former rate, while the eMMC would be switched. If I comment mmc_change_freq, everything works. Hmm, I'm pretty sure the u-boot sunxi mmc code does properly change the clock, see mmc_set_mod_clk() in drivers/mmc/sunxi_mmc.c This will switch to the right PLL, etc. So there likely is something else going on making things not work at higher speeds. Maybe we need a higher driver strenghts at the mmc io pins, or maybe we've a completely unrelated issue ? I'm pretty sure that the eMMC's on A20 devices work fine in 50MHZ (SDR) mode. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v6 5/9] armv8: fsl-layerscape: spl: remove BSS clearing and board_init_r
Hi York, I'm still using an older version of toolchain(4.9-2014.07). But I just tried to use the gcc-linaro-4.9-2016.02. It couldn't boot up even without my patchset(hang in SPL). Regards, Qianyu From: york sun Sent: Wednesday, September 14, 2016 4:45:37 AM To: Q.Y. Gong; u-boot@lists.denx.de Cc: Prabhakar Kushwaha; Vincent Hu; S.H. Xie; Z.Q. Hou; Wenbin Song; Shengzhou Liu Subject: Re: [Patch v6 5/9] armv8: fsl-layerscape: spl: remove BSS clearing and board_init_r On 09/08/2016 11:12 PM, Q.Y. Gong wrote: > > I can boot it up with this patch set on star server: LS2085ARDB-1. > I also tested the single patch and no issue. > > This is my U-Boot command: > =>tftp 8200 b52263/ls2080ardb/u-boot-with-spl.bin;nand erase 8 > 18;nand write 8200 8 12;qixis_reset nand > It looks like I have a bad combination of toolchain and code. First I have to revert commit "ARM: Rework and correct barrier definitions", then I can make it boot with older toolchains Linaro GCC 4.9-2015.03, and Linaro GCC 4.9-2014.09 But I cannot use a newer toolchain with the same code, for example gcc-linaro-4.9-2016.02, gcc-linaro-5.3-2016.02. What's your toolchain version? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rtl8169: fix cache misalignment message on transmit.
2016-09-14 3:29 GMT+02:00 : > The call to flush cache on the transmit buffer was misplaced (for very > short packets) and asked to flush less than a cacheline. > > Move the flush cache call to after a short packet has been padded > to minimum length (so the padding is flushed too), and round the size > up to a cacheline. > > Signed-off-by: Peter Chubb > Acked-by: Joe Hershberger > --- > drivers/net/rtl8169.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Tested-by Nicolas Chauvet This fix the following message on trimslice with 2016.09: --- BOOTP broadcast 1 CACHE: Misaligned operation at range [3ffba600, 3ffba756] --- Thx -- - Nicolas (kwizart) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] eb_cpu5282.c board returns failure(?) from misc_init_r()
i was just perusing the underlying code for invoking initcalls
(mostly because i forgot to return the correct value, and bricked my
target board), and i see this in lib/initcall.c:
ret = (*init_fnc_ptr)();
if (ret) {
printf("initcall sequence %p failed at call %p (err=%d)\n",
init_sequence,
(char *)*init_fnc_ptr - reloc_ofs, ret);
return -1;
}
so, perfectly reasonably, if an initcall returns a non-zero value,
that's failure, which is why misc_init_r() should, as long as
everything succeeds, return zero, correct?
but there's this in board/BuS/eb_cpu5282/eb_cpu5282.c:
int misc_init_r(void)
{
#ifdef CONFIG_HW_WATCHDOG
hw_watchdog_init();
#endif
return 1;
}
i haven't dug into this any further to see if that's a special case,
but isn't that going to return failure every time it's invoked?
it may be that that board doesn't define the watchdog or the use of
misc_init_r(), but that just seems ... wrong? thoughts?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Xilinx changes
Hi Tom, here are patches I have collected for improving Xilinx support. I have also patches regarding moving IDENT_STRING to Kconfig but they need to be rework because simple adding it to Kconfig won't work. All boards need to be converted in this patch. Also I have pending patches around moving ceva driver to DM which need to be reviewed by Simon. Thanks, Michal The following changes since commit 8cbb389bb3da80cbf8911f8386cbff92c6a78afe: Prepare v2016.09 (2016-09-12 10:05:51 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master for you to fetch changes up to 463265791c51dbdf16c0be763ff5bcd148964837: ARM64: zynqmp: Enable CONFIG_AHCI via Kconfig (2016-09-14 13:11:04 +0200) Michal Simek (12): ARM64: zynqmp: Wire up both USBs available on ZynqMP ARM64: zynqmp: Force certain bootmode for SPL ARM64: zynqmp: Fix usb_gadget_handle_interrupt routine spi: zynq: Use variable to remove u32 to u64 conversions ARM64: zynqmp: Move BSS location to the beginning of ram ARM64: zynqmp: Add USB boot mode ARM: Add new BOOT_DEVICE_DFU boot mode ARM64: zynqmp: Add support for DFU from SPL ARM64: zynqmp: Add support for USB ulpi phy reset via mode pins ARM64: zynqmp: Fix USB ulpi phy sequence ARM64: zynqmp: Add support for chip ID detection ARM64: zynqmp: Enable CONFIG_AHCI via Kconfig Siva Durga Prasad Paladugu (1): fpga: xilinx: zynqmp: Add PL bitstream download support for ZynqMP arch/arm/cpu/armv8/zynqmp/Kconfig | 48 + arch/arm/cpu/armv8/zynqmp/spl.c | 30 + arch/arm/include/asm/arch-zynqmp/hardware.h | 14 +- arch/arm/include/asm/spl.h | 1 + board/xilinx/zynqmp/zynqmp.c| 128 --- configs/xilinx_zynqmp_ep_defconfig | 1 + configs/xilinx_zynqmp_zcu102_defconfig | 1 + configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 + drivers/fpga/Makefile | 1 + drivers/fpga/xilinx.c | 6 + drivers/fpga/zynqmppl.c | 238 + drivers/spi/zynq_spi.c | 7 +++-- include/configs/xilinx_zynqmp.h | 43 - include/configs/xilinx_zynqmp_ep.h | 1 - include/xilinx.h| 2 ++ include/zynqmppl.h | 24 + 16 files changed, 532 insertions(+), 14 deletions(-) create mode 100644 drivers/fpga/zynqmppl.c create mode 100644 include/zynqmppl.h -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc 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 1/5] power: regulator: Add ctrl_reg and volt_reg fields for pmic
Hello Keerthy,
On 09/14/2016 06:28 AM, Keerthy wrote:
The ctrl reg contains bit fields to enable and disable regulators,
and volt_reg has the bit fields to configure the voltage values.
The registers are frequently accessed hence make them part
of dm_regulator_uclass_platdata structure.
Signed-off-by: Keerthy
---
include/power/regulator.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 9bcd728..57b14a3 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -171,6 +171,8 @@ struct dm_regulator_uclass_platdata {
bool boot_on;
const char *name;
int flags;
+ u8 ctrl_reg;
+ u8 volt_reg;
};
/* Regulator device operations */
This structure above is used for some common "high-level" data, which
can be used by regulator uclass driver.
Even if most of PMICs has some ctrl/volt/etc regs, the regulator uclass
driver doesn't know, how to use it, so from this point of view it is
useless.
But, you can keep device/driver data in a proper fields. Please look at
those files:
drivers/power/regulator/fixed.c:119
drivers/power/regulator/pfuze100.c:567
To store some device internal data, you can use:
.platdata_auto_alloc_size -> with access by dev_get_platdata()
.priv_auto_alloc_size -> with access by dev_get_priv()
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] really weird return codes in mcf5373l.c, misc_init_r()
ok, now i'm just being entertained by the truly strange code i'm
running across. here's a snippet from board/astro/mcf5373l/mcf5373l.c;
what strikes you as odd about it?
int misc_init_r(void)
{
int retval = 0;
puts("Configure Xilinx FPGA...");
retval = astro5373l_xilinx_load();
if (!retval) {
puts("failed!\n");
return retval;
}
puts("done\n");
puts("Configure Altera FPGA...");
retval = astro5373l_altera_load();
if (!retval) {
puts("failed!\n");
return retval;
}
puts("done\n");
return retval;
}
yes, if astro5373l_xilinx_load() returns zero, then "!retval" is true,
at which point that call will have failed, and this routine will
return ... zero. same with the code below that. so under what
circumstances can that routine return zero? oh ... it can't:
/* Initialize the fpga. Return 1 on success, 0 on failure. */
int astro5373l_xilinx_load(void)
{
int i;
fpga_init();
for (i = 0; i < CONFIG_FPGA_COUNT; i++) {
/*
* I did not yet manage to get relocation work properly,
* so set stuff here instead of static initialisation:
*/
xilinx_fns.pre = xilinx_pre_config_fn;
xilinx_fns.pgm = xilinx_pgm_config_fn;
xilinx_fns.clk = xilinx_clk_config_fn;
xilinx_fns.init = xilinx_init_config_fn;
xilinx_fns.done = xilinx_done_config_fn;
xilinx_fns.wr = xilinx_wr_config_fn;
xilinx_fns.bwr = xilinx_fastwr_config_fn;
xilinx_fpga[i].iface_fns = (void *)&xilinx_fns;
fpga_add(fpga_xilinx, &xilinx_fpga[i]);
}
return 1;
i've seen other strange examples like this.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Fix crash on 32-bit systems
Hi Alex. On Wed 14 Sep 08:34:47 2016, Alexander Graf wrote: [...] > Very nice catch! Thanks! [...] > Can you please double-check that this is the only place the type > mismatch happened? So I skimmed through the boot and run-time service API implementations and couldn't spot another instance of a mismatch. Ideally it would be neat to have an automated way to check for these things - maybe Coccinelle or something. > For this change however, the fix is already correct: > > Reviewed-by: Alexander Graf Thanks, Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system initialization
Hi Prabhakar,
Thanks for your feedback!
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: 2016年9月13日 18:04
> To: Z.Q. Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; york sun ; Vincent Hu
> ; Calvin Johnson
> Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system
> initialization
>
>
> > -Original Message-
> > From: Z.Q. Hou
> > Sent: Tuesday, September 13, 2016 2:39 PM
> > To: Prabhakar Kushwaha ; u-
> > b...@lists.denx.de; albert.u.b...@aribaud.net; york sun
> > ; Vincent Hu ; Calvin Johnson
> >
> > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system
> > initialization
> >
> > Hi Prabhakar,
> >
> > Thanks for your feedback.
> >
> > > -Original Message-
> > > From: Prabhakar Kushwaha
> > > Sent: 2016年9月13日 15:22
> > > To: Z.Q. Hou ; u-boot@lists.denx.de;
> > > albert.u.b...@aribaud.net; york sun ; Vincent Hu
> > > ; Calvin Johnson
> > > Cc: Z.Q. Hou
> > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock
> > > system initialization
> > >
> > >
> > > > -Original Message-
> > > > From: Zhiqiang Hou [mailto:zhiqiang@nxp.com]
> > > > Sent: Monday, September 12, 2016 9:39 AM
> > > > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; york sun
> > > > ; Vincent Hu ; Prabhakar
> > > > Kushwaha ; Calvin Johnson
> > > >
> > > > Cc: Z.Q. Hou
> > > > Subject: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system
> > > > initialization
> > > >
> > > > From: Hou Zhiqiang
> > > >
> > > > This patch map the sys_info->freq_systembus to Platform PLL, and
> > > > implement the IPs' clock function individually.
> > > >
> > > > Signed-off-by: Hou Zhiqiang
> > > > ---
> > > > .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 26
> > > > +--
> > > > ---
> > > > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 1 +
> > > > include/configs/ls2080a_common.h | 2 +-
> > > > 3 files changed, 22 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
> > > > index a9b12a4..daad80a 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
> > > > @@ -88,11 +88,10 @@ void get_sys_info(struct sys_info *sys_info)
> > > > #endif #endif
> > > >
> > > > + /* The freq_systembus is used to record frequency of platform
> > > > +PLL */
> > > > sys_info->freq_systembus *= (gur_in32(&gur->rcwsr[0]) >>
> > > > FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_SHIFT) &
> > > > FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_MASK;
> > > > - /* Platform clock is half of platform PLL */
> > > > - sys_info->freq_systembus /= 2;
> > >
> > > This is required only for ls2080A and ls2088A otherwise u-boot will
> > > be printing dicken speed in boot log.
> >
> > Why it is required by ls2080A and ls2088A? and I don't know what's
> > 'dicken speed'?
> >
>
> Clock generated by SYSCLK * RCW[SYS_PLL_RAT] == dicken speed for LS2080
> and LS2088A.
> Platform clock or CCB = dicken speed/2
Why it is required by ls2080A and ls2088A but without #ifdef LS2080||LS2088?
Is there any document upon the concept 'dicken speed'? As you said the dicken
speed == platform PLL frequency on LS2080A and LS2088A, what about other SoCs?
if the platform clock == dicken speed/2 on all Layerscape chassis2 and 3?
>
> > >
> > > > sys_info->freq_ddrbus *= (gur_in32(&gur->rcwsr[0]) >>
> > > > FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_SHIFT) &
> > > > FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK;
> > > > @@ -132,7 +131,7 @@ void get_sys_info(struct sys_info *sys_info)
> > > > ccr = ifc_in32(&ifc_regs.gregs->ifc_ccr);
> > > > ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT)
> +
> > > > 1;
> > > >
> > > > - sys_info->freq_localbus = sys_info->freq_systembus / ccr;
> > > > + sys_info->freq_localbus = sys_info->freq_systembus / 2 / ccr;
> > > > #endif
> > > > }
> > > >
> > > > @@ -159,7 +158,7 @@ int get_clocks(void)
> > > >
> > > > /
> > > > * get_bus_freq
> > > > - * return system bus freq in Hz
> > > > + * return platform PLL freq in Hz
> > > > */
> > > > ulong get_bus_freq(ulong dummy)
> > > > {
> > > > @@ -190,13 +189,28 @@ ulong get_ddr_freq(ulong ctrl_num)
> > > > return gd->mem_clk;
> > > > }
> > > >
> > > > +int get_i2c_freq(ulong dummy)
> > > > +{
> > > > + return get_bus_freq(0) / 4;
> > > > +}
> > > > +
> > > > +int get_dspi_freq(ulong dummy)
> > > > +{
> > > > + return get_bus_freq(0) / 4;
> > > > +}
> > > > +
> > > > +int get_serial_clock(void)
> > > > +{
> > > > + return get_bus_freq(0) / 4;
> > > > +}
> > > > +
> > >
> > > get_bus_freq(0) / 4 --> May not be true for LS1088A. So A
Re: [U-Boot] [RFC] board/liteboard: Add support for liteSOM and liteBoard
On 13.09.2016 20:23, Fabio Estevam wrote:
Hi Marcin,
On Wed, Aug 31, 2016 at 7:54 AM, Marcin Niestroj
wrote:
liteSOM is a System On Module (http://grinn-global.com/litesom/). It
can't exists on its own, but will be used as part of other boards.
Hardware specification:
* NXP i.MX6UL processor
* 256M or 512M DDR3 memory
* optional eMMC (uSDHC2)
liteBoard is a development board which uses liteSOM as its base.
Hardware specification:
* liteSOM (i.MX6UL, DRAM, eMMC)
* Ethernet PHY (id 0)
* USB host (usb_otg1)
* MicroSD slot (uSDHC1)
The main question is: how should liteSOM sources be integrated? I didn't
find similar modules, which are part of different boards in u-boot
tree. For now, I've put source into arch/arm/mach-litesom, but I guess
it is not the best place for them.
What about placing it inside board/grinn/ ?
Putting them in board/grinn/ was my first idea (adding them to
board/litesom/). Unfortunately there is no easy way to build those
sources there.
Board sources are built depending on vendor and board name. As litesom
will never be a board name, these sources won't compile.
Additionally there is a possibility to add "common" directory inside
vendor directory (so there would be something like
board/grinn/common/litesom/). This will work for all grinn boards. But
the idea is
that some other vendor can make a board that will use litesom. And in
that case sources from board/grinn/ directory won't compile.
So my idea was to treat SOM go rather like SOC which is in arch/, than
BOARD.
+ .p0_mpdgctrl0 = 0x41490145,
+ .p0_mprddlctl = 0x40404546,
+ .p0_mpwrdlctl = 0x4040524D,
+};
+
+struct mx6_ddr_sysinfo ddr_sysinfo = {
+ .dsize = 0,
+ .cs_density = 20,
+ .ncs = 1,
+ .cs1_mirror = 0,
+ .rtt_wr = 2,
+ .rtt_nom = 1, /* RTT_Nom = RZQ/2 */
+ .walat = 1, /* Write additional latency */
+ .ralat = 5, /* Read additional latency */
+ .mif3_mode = 3, /* Command prediction working mode */
+ .bi_on = 1, /* Bank interleaving enabled */
+ .sde_to_rst = 0x10, /* 14 cycles, 200us (JEDEC default) */
+ .rst_to_cke = 0x23, /* 33 cycles, 500us (JEDEC default) */
+ .ddr_type = DDR_TYPE_DDR3,
Please rebase against U-Boot 2016.09. There are new fields now: refsel and refr.
Thanks for noticing.
--
Marcin Niestroj
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
Dear Robert, In message you wrote: > > > Why not simply putting this as text (or wrapped with an uImage > > header) into some storage (or even a file) and then use "env import" > > to load it? > > the problem is that that additional "environment" info is on the > target board because of a legacy non-linux OS -- it's at a well-known > address in flash, and we have no freedom to change it, we can only > read it, make some adjustments, then incorporate it into the current > environment. Which format is used? Can it not be made to work with "env import" using this well-known address? I mean, if it's plain text, it should just work. If it's some other, more exotic format, you could probably implement a custom import format? 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 When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute -- and it's lon- ger than any hour. That's relativity. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > > Why not simply putting this as text (or wrapped with an uImage > > > header) into some storage (or even a file) and then use "env import" > > > to load it? > > > > the problem is that that additional "environment" info is on the > > target board because of a legacy non-linux OS -- it's at a > > well-known address in flash, and we have no freedom to change it, > > we can only read it, make some adjustments, then incorporate it > > into the current environment. > > Which format is used? Can it not be made to work with "env import" > using this well-known address? I mean, if it's plain text, it > should just work. If it's some other, more exotic format, you could > probably implement a custom import format? it needs to be done programatically, and i *believe* himport_r() can handle it, as the string is space-separated and null-terminated, so i'm about to test that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] does it make sense to define misc_init_r() not conditional on CONFIG_MISC_INIT_R?
another oddity i noted in my travels ... in common/board_r.c, this:
#ifdef CONFIG_MISC_INIT_R
misc_init_r,/* miscellaneous platform-dependent init */
#endif
suggests that any *definition* of a board's misc_init_r() routine
should be similarly conditional, but there are well over a hundred
counter-examples like, say, this from km83xx.c:
int misc_init_r(void)
{
ivm_read_eeprom(ivm_content, CONFIG_SYS_IVM_EEPROM_MAX_LEN);
return 0;
}
doesn't hurt, of course ... binary just ends up containing a
superfluous misc_init_r() routine that's never called. i suspect
there's a lot of that with other routines as well.
or is there something else going on here more subtle that i don't
understand?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Enhance fs tests
Hi Stefan, On 13 September 2016 at 17:01, Stefan Brüns wrote: > The first 3 patches do some cleanups for the current test, especially TC11 > had some issues (strange match for expected output, use of unitialized > variable). > > The last two patches add test cases for handling ".". Ext4 used to crash, > as a match on the first entry of a directory block was not handled > correctly. I think we should move these to pytest before enhancing them. > > v2: > Updated: > test/fs: Restructure file path specification to allow some flexibility > * avoid creation of paths with double slashes > test/fs: Check writes using "." (same dir) relative path > * fix issues copied from TC11 > * delete written file in cleanup > Added: > test/fs: remove use of undefined WRITE_FILE variable > test/fs: strip noise from filesystem code prior to checking results > > Stefan Brüns (5): > test/fs: Restructure file path specification to allow some flexibility > test/fs: remove use of undefined WRITE_FILE variable > test/fs: strip noise from filesystem code prior to checking results > test/fs: Check ext4 behaviour if dirent is first entry in directory > block > test/fs: Check writes using "." (same dir) relative path > > test/fs/fs-test.sh | 131 > +++-- > 1 file changed, 78 insertions(+), 53 deletions(-) > > -- > 2.10.0 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
Dear Robert, In message you wrote: > > it needs to be done programatically, and i *believe* himport_r() can > handle it, as the string is space-separated and null-terminated, so > i'm about to test that. It will not realy work. "space-separated" is not good enough as a space character is a legal part of the value of an environment variable. You would need to tweak the import code. 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 Status quo. Latin for "the mess we're in." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > it needs to be done programatically, and i *believe* himport_r() can > > handle it, as the string is space-separated and null-terminated, so > > i'm about to test that. > > It will not realy work. "space-separated" is not good enough as a > space character is a legal part of the value of an environment > variable. You would need to tweak the import code. but himport_r() explicitly takes a separator character, and i can guarantee the strings being "imported" have no embedded space characters in their values. so as long as that's the case, shouldn't himport_r() properly handle that given a separator of space? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Enhance fs tests
On Wed, Sep 14, 2016 at 07:32:47AM -0600, Simon Glass wrote: > Hi Stefan, > > On 13 September 2016 at 17:01, Stefan Brüns > wrote: > > The first 3 patches do some cleanups for the current test, especially TC11 > > had some issues (strange match for expected output, use of unitialized > > variable). > > > > The last two patches add test cases for handling ".". Ext4 used to crash, > > as a match on the first entry of a directory block was not handled > > correctly. > > I think we should move these to pytest before enhancing them. For the moment, I disagree. We have fs issues, and we're fixing fs issues and getting tests while we're doing that is important. It would be good, and would make my (and everyone else that has one too) setup easier if these were migrated but I don't want to blocks more tests on having them be made into different but equivalent tests first. -- 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] [ANN] U-Boot v2016.09 is released
On Tue, Sep 13, 2016 at 07:49:55AM +0200, Heiko Schocher wrote: > Hello Tom, > > Am 12.09.2016 um 18:21 schrieb Tom Rini: > >Hey all, > > > >I've released v2016.09 and it's now live on git and FTP and ACD (along > >with PGP sig file). > > > >To repeat some of the highlights from the rc releases: > >- More DM work (MMC, of-platdata for size constrained instances, etc) > >- Lots and lots of architecture / SoC / Platform updates: x86, rockchip, > > sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier > >- mkimage cleanups > >- More test.py updates, vboot now a testcase > >- Secure boot work on both ARM and PowerPC. > >- PSCI updates > >- MAKEALL is gone, buildman is for use by all > >- We now have xtensa support > >- DT overlays > >- More Kconfig migration > >- Some NFS fixes > > > >Note that in some cases you may see a message like: > >CACHE: Misaligned operation at range [,] > >and there's good and bad news here. What had been a debug print (and so > >off basically) is now a regular message. So there's no new problems, > >just problems that are now visible and we're working on fixing. Some of > >these were solved during the cycle but some of them still need some more > >discussion or just a decision being made (so, that's on me). > > I had posted 2 fixes for at91 based boards: > > [U-Boot] net, macb: fix misaligned cache operation warning > http://patchwork.ozlabs.org/patch/663488/ > [U-Boot] net, cmd: fix misaligned cache operation warning > http://patchwork.ozlabs.org/patch/663489/ > > Is there any issue with them? I think I was waiting for Andreas and Joe to ack and pick them up. > >Another thing I'd like to call out, and ask for a little help with too > >is automated testing. The framework in test/py/test.py can be used on > >real hardware and Stephen Warren has been doing a good job having things > >run on Tegra boards. You can see his scripts here[1]. I've setup > >locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm > >looking at adding more still, so long as I can update U-Boot in a way > >that does not involve the console. You can see my scripts here[2] and > >I'm cleaning things up and pushing them back up to Stephen. But there's > >always more to do and test. Is anyone else out there running this on > >real hardware, or would like to set this up? Has anyone out there > >gotten this hooked up with qemu? > > Did you tried tbot[1]? With it you can checkout, apply patches (directly from > your patchwork ToDo list if you want), compile, install for example U-Boot > and run tbot testcases on the hardware you have ... > > I integrated test/py into tbot and use it for testing some boards > (powerpc mpc52xx, imx6, at91, am335x based boards), for example > current mainline on the at91 based board corvus here: > > [2] http://xeidos.ddns.net/tests/test_db_auslesen.php#86 > http://xeidos.ddns.net/tbot/id_86/test-log.html I keep meaning to try tbot more but I haven't had a "slow" point where I can go and rearrange my workflow (I've done a lot with Jenkins over the years and I still have a plugin that people use out there, so it was a quick thing for me to fire up an instance and a few jobs). [snip] > So "my dream" is, that everybody who have a board and want to support > automated U-Boot testing on it, he can setup a so called virtual lab, > and give us ssh access for testing, and we setup such a testserver. > As an example how this could look like, I did for my use such a setup > on a raspberry pi [3] running buildbot and tbot. I use buildbot only > for the webinterface and starting tbot. This is something I very strongly agree with. I really really want it to be easy and documented and understandable how to use our tests on real boards at least manually. Labs of boards testing master (or polling my WIP branches or some to be made up branch or whatever) would be awesome, but equally so if people can post a patch to $whatever and can say they ran test.py and saw no regressions. -- 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/12] ARM: uniphier: UniPhier SoC updates for v2016.11-rc1
2016-09-14 1:05 GMT+09:00 Masahiro Yamada : > I want to get this series in during this merge window. > > - DM migration > * remove legacy xHCI driver > * convert MMC driver to CONFIG_BLOCK > - Pinctrl driver improvements > * New pin-group > * Macro cleanup > - Misc fixes, cleanups > * Fix DRAM size of LD21 SoC > * Consolidate board init functions > > > > Masahiro Yamada (12): > ARM: uniphier: sort select:s alphabetically > usb: uniphier: remove UniPhier xHCI driver and select DM_USB > ARM: uniphier: delete unnecessary xHCI pin-mux settings > ARM: uniphier: enable Generic EHCI driver for Pro4 SoC > mmc: uniphier-sd: migrate to CONFIG_BLK > pinctrl: uniphier: add System Bus pin-mux settings > pinctrl: uniphier: move register base macros from header to .c file > ARM: uniphier: remove IECTRL setup code of LD4 SoC > ARM: uniphier: use checkboard() instead of misc_init_f() > ARM: uniphier: merge board init functions into board_init() > ARM: uniphier: fix DRAM size of LD21 SoC package > ARM: uniphier: introduce flags to adjust DRAM timing for LD20/LD21 Series, applied to u-boot-uniphier. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request: u-boot-uniphier/master
Hi Tom,
Here is the fist pull request from me
for the v2016.11 development cycle.
The following UniPhier updates are included:
- DM migration
* remove legacy xHCI driver
* convert MMC driver to CONFIG_BLOCK
- Pinctrl driver improvements
* New pin-group
* Macro cleanup
- Misc fixes, cleanups
* Fix DRAM size of LD21 SoC
* Consolidate board init functions
Please pull!
The following changes since commit 8cbb389bb3da80cbf8911f8386cbff92c6a78afe:
Prepare v2016.09 (2016-09-12 10:05:51 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-uniphier.git master
for you to fetch changes up to c55b84c37654e4bf6118d7e37893fdc55f0565e3:
ARM: uniphier: introduce flags to adjust DRAM timing for LD20/LD21
(2016-09-14 22:54:20 +0900)
Masahiro Yamada (12):
ARM: uniphier: sort select:s alphabetically
usb: uniphier: remove UniPhier xHCI driver and select DM_USB
ARM: uniphier: delete unnecessary xHCI pin-mux settings
ARM: uniphier: enable Generic EHCI driver for Pro4 SoC
mmc: uniphier-sd: migrate to CONFIG_BLK
pinctrl: uniphier: add System Bus pin-mux settings
pinctrl: uniphier: move register base macros from header to .c file
ARM: uniphier: remove IECTRL setup code of LD4 SoC
ARM: uniphier: use checkboard() instead of misc_init_f()
ARM: uniphier: merge board init functions into board_init()
ARM: uniphier: fix DRAM size of LD21 SoC package
ARM: uniphier: introduce flags to adjust DRAM timing for LD20/LD21
arch/arm/Kconfig | 16 ++--
arch/arm/mach-uniphier/Makefile| 5 +-
arch/arm/mach-uniphier/board_common.c | 20 -
arch/arm/mach-uniphier/board_early_init_r.c| 15
.../{board_early_init_f.c => board_init.c} | 16 +++-
arch/arm/mach-uniphier/boards.c| 29 +++-
arch/arm/mach-uniphier/init.h | 12 ++-
arch/arm/mach-uniphier/micro-support-card.c| 2 +-
arch/arm/mach-uniphier/micro-support-card.h| 16 ++--
arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c | 12 ---
arch/arm/mach-uniphier/pinctrl/pinctrl-ld4.c | 6 --
arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c | 11 ---
arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c | 7 --
arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c | 7 --
arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c | 11 ---
arch/arm/mach-uniphier/print_misc_info.c | 12 ---
configs/uniphier_ld4_sld8_defconfig| 1 -
configs/uniphier_pro4_defconfig| 2 +
configs/uniphier_sld3_defconfig| 1 -
drivers/mmc/Kconfig| 1 +
drivers/mmc/uniphier-sd.c | 50 ++---
drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 4 +
drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 9 +++
drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 9 +++
drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c| 18 +
drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c | 21 ++
drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c | 30
drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c | 30
drivers/pinctrl/uniphier/pinctrl-uniphier-pxs2.c | 9 +++
drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c | 21 ++
drivers/pinctrl/uniphier/pinctrl-uniphier.h| 4 -
drivers/usb/host/Kconfig | 7 --
drivers/usb/host/Makefile | 1 -
drivers/usb/host/xhci-uniphier.c | 85 --
include/configs/uniphier.h | 3 -
include/fdtdec.h | 1 -
lib/fdtdec.c | 1 -
37 files changed, 244 insertions(+), 261 deletions(-)
delete mode 100644 arch/arm/mach-uniphier/board_common.c
delete mode 100644 arch/arm/mach-uniphier/board_early_init_r.c
rename arch/arm/mach-uniphier/{board_early_init_f.c => board_init.c} (88%)
delete mode 100644 arch/arm/mach-uniphier/print_misc_info.c
delete mode 100644 drivers/usb/host/xhci-uniphier.c
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Enhance fs tests
Hi Tom, On 14 September 2016 at 07:38, Tom Rini wrote: > On Wed, Sep 14, 2016 at 07:32:47AM -0600, Simon Glass wrote: >> Hi Stefan, >> >> On 13 September 2016 at 17:01, Stefan Brüns >> wrote: >> > The first 3 patches do some cleanups for the current test, especially TC11 >> > had some issues (strange match for expected output, use of unitialized >> > variable). >> > >> > The last two patches add test cases for handling ".". Ext4 used to crash, >> > as a match on the first entry of a directory block was not handled >> > correctly. >> >> I think we should move these to pytest before enhancing them. > > For the moment, I disagree. We have fs issues, and we're fixing fs > issues and getting tests while we're doing that is important. It would > be good, and would make my (and everyone else that has one too) setup > easier if these were migrated but I don't want to blocks more tests on > having them be made into different but equivalent tests first. Fair enough, I've seen the issues and these are not large additions. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
Dear Robert, In message you wrote: > > > It will not realy work. "space-separated" is not good enough as a > > space character is a legal part of the value of an environment > > variable. You would need to tweak the import code. > > but himport_r() explicitly takes a separator character, and i can > guarantee the strings being "imported" have no embedded space > characters in their values. so as long as that's the case, shouldn't > himport_r() properly handle that given a separator of space? Well, yes, but it sounds a bit fragile to me. Experience tells me that very soon someone _will_ use a space in a variable. 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 The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane. - Nikola Tesla ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND
Hi Let me firstly explain my need. We use U-boot as a primary bootloader, with a bootcmd which loads and executes a script on one external device (SD ou USB). This script will continue the boot process (launch a kernel for example). The corresponding bootcmd defined in CONFIG_BOOTCOMMAND does this load/execute operation. Of course, the user will be able to modify the content of the script, to fit with their needs. But on our side, provider of this primary bootloader, we want to be sure that the environment of this u-boot won't be changed by the user, so that we want to disable all access to "saveenv" command. That's why we configure: #undef CONFIG_CMD_SAVEENV With this modifications, saveenv command is not available in the u-boot commands, that's nice. But bootcmd is empty. It's like there was an interaction between both settings, maybe the saveenv primitive is necessary one time to construct the environment content. How could we do to have a well-constructed and not updatable env content? Thanls in advance for your answers Best Regards Nicolas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system initialization
> -Original Message- > From: Z.Q. Hou > Sent: Wednesday, September 14, 2016 8:16 AM > To: Prabhakar Kushwaha ; u- > b...@lists.denx.de; albert.u.b...@aribaud.net; york sun ; > Vincent Hu ; Calvin Johnson > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system > initialization > > Hi Prabhakar, > > Thanks for your feedback! > > > -Original Message- > > From: Prabhakar Kushwaha > > Sent: 2016年9月13日 18:04 > > To: Z.Q. Hou ; u-boot@lists.denx.de; > > albert.u.b...@aribaud.net; york sun ; Vincent Hu > > ; Calvin Johnson > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system > > initialization > > > > > > > -Original Message- > > > From: Z.Q. Hou > > > Sent: Tuesday, September 13, 2016 2:39 PM > > > To: Prabhakar Kushwaha ; u- > > > b...@lists.denx.de; albert.u.b...@aribaud.net; york sun > > > ; Vincent Hu ; Calvin Johnson > > > > > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system > > > initialization > > > > > > Hi Prabhakar, > > > > > > Thanks for your feedback. > > > > > > > -Original Message- > > > > From: Prabhakar Kushwaha > > > > Sent: 2016年9月13日 15:22 > > > > To: Z.Q. Hou ; u-boot@lists.denx.de; > > > > albert.u.b...@aribaud.net; york sun ; Vincent Hu > > > > ; Calvin Johnson > > > > Cc: Z.Q. Hou > > > > Subject: RE: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock > > > > system initialization > > > > > > > > > > > > > -Original Message- > > > > > From: Zhiqiang Hou [mailto:zhiqiang@nxp.com] > > > > > Sent: Monday, September 12, 2016 9:39 AM > > > > > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; york sun > > > > > ; Vincent Hu ; Prabhakar > > > > > Kushwaha ; Calvin Johnson > > > > > > > > > > Cc: Z.Q. Hou > > > > > Subject: [PATCH 2/2] armv8/fsl-lsch3: consolidate the clock system > > > > > initialization > > > > > > > > > > From: Hou Zhiqiang > > > > > > > > > > This patch map the sys_info->freq_systembus to Platform PLL, and > > > > > implement the IPs' clock function individually. > > > > > > > > > > Signed-off-by: Hou Zhiqiang > > > > > --- > > > > > .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 26 > > > > > +-- > > > > > --- > > > > > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 1 + > > > > > include/configs/ls2080a_common.h | 2 +- > > > > > 3 files changed, 22 insertions(+), 7 deletions(-) > > > > > > > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > index a9b12a4..daad80a 100644 > > > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c > > > > > @@ -88,11 +88,10 @@ void get_sys_info(struct sys_info *sys_info) > > > > > #endif #endif > > > > > > > > > > + /* The freq_systembus is used to record frequency of platform > > > > > +PLL */ > > > > > sys_info->freq_systembus *= (gur_in32(&gur->rcwsr[0]) >> > > > > > FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_SHIFT) & > > > > > FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_MASK; > > > > > - /* Platform clock is half of platform PLL */ > > > > > - sys_info->freq_systembus /= 2; > > > > > > > > This is required only for ls2080A and ls2088A otherwise u-boot will > > > > be printing dicken speed in boot log. > > > > > > Why it is required by ls2080A and ls2088A? and I don't know what's > > > 'dicken speed'? > > > > > > > Clock generated by SYSCLK * RCW[SYS_PLL_RAT] == dicken speed for LS2080 > > and LS2088A. > > Platform clock or CCB = dicken speed/2 > > Why it is required by ls2080A and ls2088A but without #ifdef LS2080||LS2088? > Is there any document upon the concept 'dicken speed'? As you said the dicken > speed == platform PLL frequency on LS2080A and LS2088A, what about other > SoCs? > if the platform clock == dicken speed/2 on all Layerscape chassis2 and 3? > Platform clock == dicken speed/2. It is only for LS2080A and LS2088A. For ls1088a and other SoCs platform clock = SYSCLK * RCW[SYS_PLL_RAT] > > > > > > > > > > > sys_info->freq_ddrbus *= (gur_in32(&gur->rcwsr[0]) >> > > > > > FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_SHIFT) & > > > > > FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK; > > > > > @@ -132,7 +131,7 @@ void get_sys_info(struct sys_info *sys_info) > > > > > ccr = ifc_in32(&ifc_regs.gregs->ifc_ccr); > > > > > ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) > > + > > > > > 1; > > > > > > > > > > - sys_info->freq_localbus = sys_info->freq_systembus / ccr; > > > > > + sys_info->freq_localbus = sys_info->freq_systembus / 2 / ccr; > > > > > #endif > > > > > } > > > > > > > > > > @@ -159,7 +158,7 @@ int get_clocks(void) > > > > > > > > > > / > > > > > * get_bus_freq > > > > > - * return system bus freq in Hz > > > > > + * return platform P
Re: [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND
Dear Nicolas, In message you wrote: > > Of course, the user will be able to modify the content of the script, to > fit with their needs. But on our side, provider of this primary bootloader, > we want to be sure that the environment of this u-boot won't be changed by > the user, so that we want to disable all access to "saveenv" command. Would that really be enough? Please keep in mind that "env save" (or "saveenv") is only responsible for storing the current environment into persistant storage. It does not modify the environment at all. To modify the environment, you can use quite a number of commands, including "env set", "env import" etc. You would have to disable all of these to prevent modifications of the environment settings - and probably cripple U-Boot to a level where it becomes unusable. > That's why we configure: #undef CONFIG_CMD_SAVEENV > > With this modifications, saveenv command is not available in the u-boot > commands, that's nice. But bootcmd is empty. It's like there was an > interaction between both settings, maybe the saveenv primitive is necessary > one time to construct the environment content. This would be a bug. Whcih exact version of U-Boot are you talking about? 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 "There are three principal ways to lose money: wine, women, and en- gineers. While the first two are more pleasant, the third is by far the more certain." -- Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you wrote: > > > > > It will not realy work. "space-separated" is not good enough as a > > > space character is a legal part of the value of an environment > > > variable. You would need to tweak the import code. > > > > but himport_r() explicitly takes a separator character, and i can > > guarantee the strings being "imported" have no embedded space > > characters in their values. so as long as that's the case, shouldn't > > himport_r() properly handle that given a separator of space? > > Well, yes, but it sounds a bit fragile to me. Experience tells me > that very soon someone _will_ use a space in a variable. in this case, no ... it's legacy info that will never, ever change at this point. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/5] tegra: usb gadget: fix ci udc operation if not hostpc capable
On Mon, 2016-09-12 at 12:13 -0600, Stephen Warren wrote: > On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: > > > > The Tegra 2 aka T20 is not host PC capable. Therefore move the > > define > > CONFIG_CI_UDC_HAS_HOSTPC from the generic tegra-common-usb-gadget.h > > header file into resp. SoC type specific ones. > This is OK, but ... > > > > > diff --git a/include/configs/tegra-common-usb-gadget.h > > b/include/configs/tegra-common-usb-gadget.h > > > > #ifndef CONFIG_SPL_BUILD > > /* USB gadget mode support*/ > > -#define CONFIG_CI_UDC_HAS_HOSTPC > ... it seems a bit simpler to just wrap that in #ifndef > CONFIG_TEGRA20. > > That would avoid having to duplicate the define in all tegra*- > common.h > forever. Still, it's not a huge deal. Agreed, I will change this in a v2. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] spi: pl022_spi: Add support for ARM PL022 spi controller
Ciao Michael,
On 09/08/2016 04:21 PM, Michael Brandl wrote:
Dear U-Boot (SPI) Developers,
this patch seems to be my only chance to get spi working without/before Linux.
I wrote and used this code for u-boot for a asic
specified by one of our customers. The patch was generic
enough to be pushed in u-boot, but I didn't have
much time to test it on a different, more generic
platform. So the maintainer decided to drop it...
Would be nice if you could work on it and resurrect it...
:)
Let me know if you have progressed on this or abandoned it.
I'm a student from Augsburg (Germany) experimenting with the Hikey Board from
96boards.
The hi6220 processor from HiSilicon isn't fully documented, there is just one
document called Function Description:
http://mirror.lemaker.org/Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf
Yes, I'm currently using HiKey platform for doing my day by day
job here in office. Nevertheless, I don't think I have enough
time to take a look into testing this commit.
U-Boot already supports the Hikey Board to be loaded from ARM Trusted Firmware
(ATF) but only UART and SDMMC is supported by now.
I cloned the u-boot-spi.git and tried to integrate this patch but I'm not
experienced enough to adjust the specific config for the Hikey Board.
Maybe I can try to recover the work that was done to integrate
this commit into the customer platform I was talking about.
I'll take a look into it right now...
Taking a look at armv7 devices with spi support I started like this:
+++ b/arch/arm/include/asm/arch-hi6220/hi6220.h
+/*Hi6220V100_Multi-Mode_Application_Processor_Function_Description on p.5-45*/
+#define HI6220_SPI_BASE0xF7106000
+++ b/include/configs/hikey.h
+/* Synchronous Serial Port PL022 for SPI */
+#define CONFIG_PL022_SPI
+++ b/board/hisilicon/hikey/hikey.c
int board_init(void)
{
+#ifdef CONFIG_PL022_SPI
+ hikey_spi0_hw_init();
+#endif
return 0;
}
+static void hikey_spi0_hw_init(void)
+{
+ hi6220_pinmux_config(PERIPH_ID_SPI0)
+// at91_set_pio_output(AT91_PIO_PORTC, 3, 1); /* SPI0_CS0 */
+ gpio_request(0, "PWR_HOLD_GPIO0_0");
+ gpio_direction_output(0, 1);
+
+ /* Enable clock */
+// at91_periph_clk_enable(ATMEL_ID_SPI0);
+/* from Kernel { HI6220_SPI_CLK, "spi_clk", "clk_150m",
CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x230, 9, 0, }, */
+ hi6220_clk_enable(PERI_CLK0_SPI0, &peri_sc->clk3_en);
+
+}
+#endif /* CONFIG_PL022_SPI */
+
+++ b/arch/arm/cpu/armv8/hisilicon/pinmux.c
+static void hi6220_spi_config(int peripheral)
+{
+ switch (peripheral) {
+ case PERIPH_ID_SPI0:
+// at91_set_a_periph(AT91_PIO_PORTC, 0, 0);/* SPI0_MISO */
+// at91_set_a_periph(AT91_PIO_PORTC, 1, 0);/* SPI0_MOSI */
+// at91_set_a_periph(AT91_PIO_PORTC, 2, 0);/* SPI0_SPCK */
+ break;
+
+ case PERIPH_ID_SPI1:
+ break;
+
+ default:
+ debug("%s: invalid peripheral %d", __func__, peripheral);
+ return;
+ }
+}
Maybe you can help me to get spi working on Hikey. My overall aim is to port
the pl022 driver then to ARM TF ... maybe also that could be interessing for
you.
With kind Regards,
Michael Brandl
Rgds,
Armando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 5/5] colibri_t20: enable dfu also for nand
On Mon, 2016-09-12 at 12:24 -0600, Stephen Warren wrote: > On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: > > > > Enable USB gadget DFU functionality for NAND as well. > > > > diff --git a/include/configs/colibri_t20.h > > b/include/configs/colibri_t20.h > > > > +/* USB DFU */ > > +#define CONFIG_DFU_NAND > Oh, I see this file already includes tegra-common-usb-gadget.h, so > USB > device-mode is already enabled for this board. Does that make sense > given that it doesn't actually work? Well, it's not like it hurts anything else really isn't it? My hopes were that somebody may actually help me looking into it which this would ease. However I understand that you NVIDIA people long since stopped even having any of them older Tegra 2 and 3 hardware any longer. At least Harmony and Ventana currently looks rather broken in many aspects which I left for another days exercise. > > +#define DFU_ALT_NAND_INFO "u-boot part 0,1;ubi part 0,4" > > + > > #define BOARD_EXTRA_ENV_SETTINGS \ > > + "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \ > I would defer this to the user, since people may choose different > flash > layouts. Given the DFU NAND syntax being rather delicate at least Google returning rather some wrong stuff with respect to now starting with zero or one I thought that would at least make it clear. It's not that a user could not overwrite it any time if he wishes to do so isn't it? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [arm] Where to put files for armv8 ThunderX
On Mon, Jun 20, 2016 at 3:15 PM, Aaron Williams wrote: > I have just been handed the task of cleaning up our U-Boot port to our > ThunderX armv8 chip and am wondering where I should put the files specific > to our chip. > > The people who previously worked on the chip created a subdirectory under > u-boot and have things scattered about. > > Should I create a subdirectory under arch/arm/cpu/armv8 like > arch/arm/cpu/armv8/mach-thunderx or should I create a mach-thunderx > directory directly under the cpu directory? > > I'm assuming include files should go under > arch/arm/include/asm/arch-thunderx. > > I very much want to get this stuff pushed upstream so I don't run into the > situation we've been stuck with our Octeon MIPS processors. My biggest > problem is that a lot of code doesn't work. > > I'm still trying to get up to speed with the armv8 U-Boot. > > -Aaron Aaron, I came across this post while searching for Octeon support. Are you still working on this project? Are you also working on pushing up support for the Octeon TX? I have been pointed to a github repo for u-boot-81xx for support of the Octeon TX 80xx/81xx and am trying to determine what the state/timeline is for Octeon TX support in mainline u-boot. Unfortunately the git tree is not a fork/clone of mainline u-boot and instead is just a full directory push without history (why would someone even do that?) so it makes it difficult to see the extent of the patches. Regards, Tim Tim Harvey - Principal Software Engineer Gateworks Corporation - http://www.gateworks.com/ 3026 S. Higuera St. San Luis Obispo CA 93401 805-781-2000 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND
Would that really be enough? Please keep in mind that "env save" (or "saveenv") is only responsible for storing the current environment into persistant storage. It does not modify the environment at all. To modify the environment, you can use quite a number of commands, including "env set", "env import" etc. You would have to disable all of these to prevent modifications of the environment settings - and probably cripple U-Boot to a level where it becomes unusable. >> Our objective is just to avoid the user to modify the content in the persistent storage. Indeed, we have to retrieve the original content at each reboot. If the user makes something wrong in its current environment, this is its responsability, but after the reset, we have to gat back the original content we stored once for all. In that case, saveenv would maybe be enough, don't you think? Which exact version of U-Boot are you talking about? >> a quite old one, v2015.01 :-( And we do not plan to upgrade this "primary bootloader" u-boot. Regards, Nicolas 2016-09-14 17:00 GMT+02:00 Wolfgang Denk : > Dear Nicolas, > > In message ddgl2b+gnb+...@mail.gmail.com> you wrote: > > > > Of course, the user will be able to modify the content of the script, to > > fit with their needs. But on our side, provider of this primary > bootloader, > > we want to be sure that the environment of this u-boot won't be changed > by > > the user, so that we want to disable all access to "saveenv" command. > > Would that really be enough? Please keep in mind that "env save" (or > "saveenv") is only responsible for storing the current environment > into persistant storage. It does not modify the environment at all. > To modify the environment, you can use quite a number of commands, > including "env set", "env import" etc. You would have to disable all > of these to prevent modifications of the environment settings - and > probably cripple U-Boot to a level where it becomes unusable. > > > That's why we configure: #undef CONFIG_CMD_SAVEENV > > > > With this modifications, saveenv command is not available in the u-boot > > commands, that's nice. But bootcmd is empty. It's like there was an > > interaction between both settings, maybe the saveenv primitive is > necessary > > one time to construct the environment content. > > This would be a bug. Whcih exact version of U-Boot are you talking > about? > > 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 > "There are three principal ways to lose money: wine, women, and en- > gineers. While the first two are more pleasant, the third is by far > the more certain." -- Baron Rothschild, ca. 1800 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/5] colibri_t20: fix display configuration
On 09/14/2016 09:20 AM, Marcel Ziswiler wrote: On Mon, 2016-09-12 at 12:18 -0600, Stephen Warren wrote: On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: Without this patch the following error will be shown: stdio_add_devices: Video device failed (ret=-22) As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: tegra: Move to using simple-panel and pwm-backlight) states the Colibri T20 needs updating too which this patch finally attempts doing. Please note that the current U-Boot implementation requires a dummy GPIO e.g. for a fixed backlight regulator to be explicitly defined in order to work unlike in the Linux kernel where this is taken care of automatically. + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "Dummy"; + /* Dummy N/C */ + gpio = <&gpio TEGRA_GPIO(V, 7) GPIO_ACTIVE_HIGH>; >> This is wrong. If that GPIO isn't actually part of the backlight, the DT should not say that it is. The gpio property is optional according to the DT binding documentation, so this shouldn't be needed. Well, I guess then it's lying. Does "it" mean the binding? Please note that the binding defines how the DT should be structured and how code interpreting the DT should operate. The binding isn't derived from the code, but rather the code is derived from the binding. > If I leave it away I get the following: stdio_add_devices: Video device failed (ret=-38) And it won't quite work. That sounds like a bug in the U-Boot regulator driver. I believe you should fix that, rather than working around the bug in DT. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 5/5] colibri_t20: enable dfu also for nand
On 09/14/2016 09:41 AM, Marcel Ziswiler wrote: On Mon, 2016-09-12 at 12:24 -0600, Stephen Warren wrote: On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: Enable USB gadget DFU functionality for NAND as well. diff --git a/include/configs/colibri_t20.h b/include/configs/colibri_t20.h +/* USB DFU */ +#define CONFIG_DFU_NAND Oh, I see this file already includes tegra-common-usb-gadget.h, so USB device-mode is already enabled for this board. Does that make sense given that it doesn't actually work? Well, it's not like it hurts anything else really isn't it? Having the feature enabled implies that it works in my opinion. If it doesn't, I think this will only confuse users. My hopes were that somebody may actually help me looking into it which this would ease. However I understand that you NVIDIA people long since stopped even having any of them older Tegra 2 and 3 hardware any longer. At least Harmony and Ventana currently looks rather broken in many aspects which I left for another days exercise. If someone wants to fix USB device mode on Tegra20, I don't imagine it would be hard for them to enable it while working on it. What's broken on Harmony and Ventana? They both worked when I tested all Tegra boards within the last few months. We have a Tegra30 board (but admittedly not Tegra20 board) in our automated upstream U-Boot test farm (running test/py). +#define DFU_ALT_NAND_INFO "u-boot part 0,1;ubi part 0,4" + #define BOARD_EXTRA_ENV_SETTINGS \ + "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \ I would defer this to the user, since people may choose different flash layouts. Given the DFU NAND syntax being rather delicate at least Google returning rather some wrong stuff with respect to now starting with zero or one I thought that would at least make it clear. It's not that a user could not overwrite it any time if he wishes to do so isn't it? Certainly a user could over-write it. However, I'm not convinced it's a good idea to provide an arbitrary default value that may or may not be remotely relevant to the user's actual configuration. Again, this may lead users down the wrong path of wondering why they can't get this default configuration to work, rather than researching what the correct configuration is. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] test: add NFS download test
On 09/14/2016 02:29 AM, Guillaume GARDET wrote: Add a NFS download test, based on TFTP test. Tested on i.MX6 SabreLite board. Signed-off-by: Guillaume GARDET Cc: Tom Rini Nit: There shouldn't be a blank line between your s-o-b and any other tags. Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] spi: pl022_spi: Add support for ARM PL022 spi controller
On Thu, Sep 8, 2016 at 7:51 PM, Michael Brandl wrote: > Dear U-Boot (SPI) Developers, > > this patch seems to be my only chance to get spi working without/before > Linux. > > I'm a student from Augsburg (Germany) experimenting with the Hikey Board > from 96boards. > The hi6220 processor from HiSilicon isn't fully documented, there is just > one document called Function Description: > http://mirror.lemaker.org/Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf > > U-Boot already supports the Hikey Board to be loaded from ARM Trusted > Firmware (ATF) but only UART and SDMMC is supported by now. > I cloned the u-boot-spi.git and tried to integrate this patch but I'm not > experienced enough to adjust the specific config for the Hikey Board. Please try to use u-boot.git and send the patch format. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND
Dear Nicolas, In message you wrote: > > > Would that really be enough? Please keep in mind that "env save" (or > > "saveenv") is only responsible for storing the current environment > > into persistant storage. It does not modify the environment at all. > > To modify the environment, you can use quite a number of commands, > > including "env set", "env import" etc. You would have to disable all > > of these to prevent modifications of the environment settings - and > > probably cripple U-Boot to a level where it becomes unusable. > > >> Our objective is just to avoid the user to modify the content in the > persistent storage. Indeed, we have to retrieve the original content at > each reboot. > If the user makes something wrong in its current environment, this is its > responsability, but after the reset, we have to gat back the original > content we stored once for all. In that case, saveenv would maybe be > enough, don't you think? It should work as you expect. But since you ask what I _think_ ... :-) As a developer I really hate systems that attempt to lock me down into such a crippled environment. I still love and cherish the old quote: "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn You plan to implement a policy that restricts the freedom of the user for a questionable (to me - I don't know your requirements) advantage. Would it not be possible to implement a more open design, where the user can actually save his changes to the persistent environment (so someone who knows what he is doing can use the full power of the software), and instead provide a way to perform a factory reset (using "env default -f" or similar) to your original settings? That would feel much more U-Boot-like to me :-) > > Which exact version of U-Boot are you talking about? > >> a quite old one, v2015.01 :-( And we do not plan to upgrade this > "primary bootloader" u-boot. Hm... this should still not show such behaviour. Check your board config file thoroughly, especially your environment settings. Check that environment definitions are explicitly terminated by NUL characters, and that all string quotes pair. If you have any #ifdef magic there, check that, too. 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 All I ask is a chance to prove that money can't make me happy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Detect and reject new ad-hoc CONFIG options
On Tue, Sep 13, 2016 at 12:38:45PM -0600, Simon Glass wrote: > Hi Tom, > > On 13 September 2016 at 07:49, Tom Rini wrote: > > On Tue, Sep 13, 2016 at 07:35:42AM -0600, Simon Glass wrote: > >> Hi Tom, > >> > >> On 13 September 2016 at 07:16, Tom Rini wrote: > >> > On Mon, Sep 12, 2016 at 11:20:00PM -0600, Simon Glass wrote: > >> > > >> >> Despite the availability of Kconfig, the number of ad-hoc CONFIG > >> >> options in > >> >> U-Boot is still at over 8000. > >> >> > >> >> In February 2015 (commit 741e58e0) there were around 8387 ad-hoc > >> >> CONFIGs. > >> >> As of this patch there are about 8336, only a little fewer. > >> >> > >> >> One problem is that new ones are still being added, admittedly at a > >> >> slower > >> >> rate. This series adds a Makefile check to detect that and produce a > >> >> build > >> >> error. This provides immediate feedback that new CONFIG options should > >> >> go in > >> >> Kconfig. > >> >> > >> >> Changes in v2: > >> >> - Rebase to mainline > >> >> - Fix scripts so that there are no errors > >> >> - Add the 'build-whitelist.sh' script to the tree > >> >> > >> >> Simon Glass (2): > >> >> Kconfig: Add a whitelist of ad-hoc CONFIG options > >> >> Makefile: Give a build error if ad-hoc CONFIG options are added > >> > > >> > OK, this is still a little fragile. When I do: > >> > ./tools/buildman/buildman -b master --force-build --step 0 \ > >> > -SCdvel > >> > 'avr32|nds32|bfin|m68k|microblaze|or32|sh4|sparc|mips|mips64|xtensa' > >> > > >> > vs kconfig-working2 I'm seeing a bunch of failures: > >> > +(M5475GFE) make[1]: *** [no_new_adhoc_configs_check] Error 1 > >> > +(M5475GFE) make: *** [sub-make] Error 2 > >> > >> Yes it looks like I was testing it incorrectly, relying on running on > >> from the SPL series. One problem is that it misses configs with lower > >> case which are defined in Kconfig and then used. I've updated > >> u-boot-dm/kconfig-working2 to deal with that. > >> > >> I'll take another look at this and have an update out today. But we > >> can decouple this from the painful SPL series if you like, since in > >> principle we can run the generation script to create the first of the > >> two patches. > > > > Yes, we can de-couple this. However, you might want to take a look at > > say xtensa as in my check with before/after kconfig-working2 there's a > > tiny size difference and I don't see that normally for a Kconfig > > migration. I'm doing my arm/powerpc build now to see if there's a > > similar set of size changes there and will then start poking at map > > files. > > Here's a full list of config changes for the SPL series as far as I can tell: > > $ buildman -b kc4-conf -fC --step 0 -DI -s > boards.cfg is up to date. Nothing to do. > Summary of 2 commits for 1196 boards (32 threads, 1 job per thread) > 01: buildman > openrisc: + openrisc-generic > sparc: + grsim grsim_leon2 gr_cpci_ax2000 gr_xc3s_1500 gr_ep2s60 > blackfin: + bf609-ezkit > 46: Convert CONFIG_SPL_YMODEM_SUPPORT to Kconfig > arm: >+ u-boot.cfg: CONFIG_ENV_ADDR=(CONFIG_SYS_FLASH_BASE + > CONFIG_SYS_MONITOR_LEN) CONFIG_ENV_IS_IN_FLASH=1 > CONFIG_ENV_SECT_SIZE=0x0001 CONFIG_NAND=1 CONFIG_SPL_ENV_SUPPORT=1 > CONFIG_SPL_NET_SUPPORT=1 CONFIG_SPL_NET_VCI_STRING="" CONFIG_STV0991=1 > CONFIG_SYS_MONITOR_LEN=0x0004 CONFIG_USBTTY=1 >- u-boot.cfg: CONFIG_DW_UDC=1 CONFIG_ENV_IS_IN_NAND=1 > CONFIG_ENV_OFFSET=0x6 CONFIG_ENV_RANGE=0x1 > CONFIG_SPEAR_USBTTY=1 CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL" > CONFIG_USBD_HS=1 CONFIG_USBD_MANUFACTURER="ST Microelectronics" > CONFIG_USBD_PRODUCT_NAME="SPEAr SoC" CONFIG_USB_DEVICE=1 > CONFIG_USB_TTY=1 CONFIG_nand=1 CONFIG_spear300=1 CONFIG_spear310=1 > CONFIG_spear320=1 CONFIG_spear600=1 CONFIG_stv0991=1 CONFIG_usbtty=1 >+ u-boot-spl.cfg: CONFIG_SPL_MMC_SUPPORT=1 > CONFIG_SPL_NAND_SUPPORT=1 CONFIG_SPL_YMODEM_SUPPORT=1 >- u-boot-spl.cfg: CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL" >+ all: CONFIG_ENV_ADDR=(CONFIG_SYS_FLASH_BASE + > CONFIG_SYS_MONITOR_LEN) CONFIG_ENV_IS_IN_FLASH=1 > CONFIG_ENV_SECT_SIZE=0x0001 CONFIG_NAND=1 CONFIG_SPL_ENV_SUPPORT=1 > CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1 > CONFIG_SPL_NET_SUPPORT=1 CONFIG_SPL_NET_VCI_STRING="" > CONFIG_SPL_YMODEM_SUPPORT=1 CONFIG_STV0991=1 > CONFIG_SYS_MONITOR_LEN=0x0004 CONFIG_USBTTY=1 >- all: CONFIG_DW_UDC=1 CONFIG_ENV_IS_IN_NAND=1 > CONFIG_ENV_OFFSET=0x6 CONFIG_ENV_RANGE=0x1 > CONFIG_SPEAR_USBTTY=1 CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL" > CONFIG_USBD_HS=1 CONFIG_USBD_MANUFACTURER="ST Microelectronics" > CONFIG_USBD_PRODUCT_NAME="SPEAr SoC" CONFIG_USB_DEVICE=1 > CONFIG_USB_TTY=1 CONFIG_nand=1 CONFIG_spear300=1 CONFIG_spear310=1 > CONFIG_spear320=1 CONFIG_spear600=1 CONFIG_stv0991=1 CONFIG_usbtty=1 > spear320_usbtty spear320_usbtty_pnor : >+ u-boot.cfg: CONFIG_USBTTY=1 >- u-boot.cfg: CONFIG_DW_UDC=1 CONFIG_SPEAR_USBTTY=1 > CONFIG_USBD_HS=1 CONFIG_USBD_MANUFACTURER="ST Microelectronics" > CONFIG_USBD_PR
Re: [U-Boot] [PATCH v3 0/2] Detect and reject new ad-hoc CONFIG options
On Tue, Sep 13, 2016 at 09:46:18PM -0600, Simon Glass wrote: > Hi Tom, > > On 13 September 2016 at 21:44, Simon Glass wrote: > > Despite the availability of Kconfig, the number of ad-hoc CONFIG options in > > U-Boot is still at over 8000. > > > > In February 2015 (commit 741e58e0) there were around 8387 ad-hoc CONFIGs. > > As of this patch there are about 8336, only a little fewer. > > > > One problem is that new ones are still being added, admittedly at a slower > > rate. This series adds a Makefile check to detect that and produce a build > > error. This provides immediate feedback that new CONFIG options should go in > > Kconfig. > > > > Changes in v3: > > - Update the whitelist with mainline > > - Fix the match partern to exclude .py files, not anything containing "py" > > - Handle Kconfig files with extensions (e.g. Kconfig.64) > > - Handle CONFIG_SYS_EXTRA_OPTIONS containing lower case > > - Include lower-case letters in the CONFIG match string > > - Write error output to stderr so that buildman shows it > > - Handle Kconfig files with extensions (e.g. Kconfig.64) > > - Handle extra whitespace after 'config' / 'menuconfig' > > > > Changes in v2: > > - Rebase to mainline > > - Fix scripts so that there are no errors > > - Add the 'build-whitelist.sh' script to the tree > > > > Simon Glass (2): > > Kconfig: Add a whitelist of ad-hoc CONFIG options > > Makefile: Give a build error if ad-hoc CONFIG options are added > > > > Makefile | 10 +- > > scripts/build-whitelist.sh | 51 + > > scripts/check-config.sh | 55 + > > scripts/config_whitelist.txt | 8420 > > ++ > > 4 files changed, 8535 insertions(+), 1 deletion(-) > > create mode 100755 scripts/build-whitelist.sh > > create mode 100755 scripts/check-config.sh > > create mode 100644 scripts/config_whitelist.txt > > > > -- > > 2.8.0.rc3.226.g39d4020 > > > > I build-tested this on top of the SPL series (see u-boot-dm/kconfig-working2): > > buildman -b kc4 -fC --step 0 -s > boards.cfg is up to date. Nothing to do. > Summary of 2 commits for 1196 boards (32 threads, 1 job per thread) > 01: buildman > blackfin: + cm-bf527 bf609-ezkit bf537-stamp > sparc: + grsim grsim_leon2 gr_cpci_ax2000 gr_xc3s_1500 gr_ep2s60 > nios2: + 10m50 3c120 > microblaze: + microblaze-generic > openrisc: + openrisc-generic > 48: Makefile: Give a build error if ad-hoc CONFIG options are added > (kc4=74f3ab: -- asc asc2 asc3 b/ sandbox/ test/) u> > > There were a number of tweaked needed to get the config checker to > build all boards without error. My previous tested omitted the -C > flag, meaning that it did not reconfigure all of the boards, so > missing loads of problems. Great, 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 v6 5/9] armv8: fsl-layerscape: spl: remove BSS clearing and board_init_r
Qianyu, On 09/14/2016 12:32 AM, Q.Y. Gong wrote: > > Hi York, > > > I'm still using an older version of toolchain(4.9-2014.07). > > > But I just tried to use the gcc-linaro-4.9-2016.02. > > It couldn't boot up even without my patchset(hang in SPL). I think you may just reproduced the issue I have seen. Try to revert a78cd8613204188991c192b8dae2de0aae3b1722, ARM: Rework and correct barrier definitions. See discussion http://lists.denx.de/pipermail/u-boot/2016-September/265593.html. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] doc: typo fix addess -> address
Signed-off-by: Jelle van der Waa --- doc/mkimage.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/mkimage.1 b/doc/mkimage.1 index ffa7d60..e883f07 100644 --- a/doc/mkimage.1 +++ b/doc/mkimage.1 @@ -70,7 +70,7 @@ Set compression type. Pass \-h as the compression to see the list of supported compression type. .TP -.BI "\-a [" "load addess" "]" +.BI "\-a [" "load address" "]" Set load address with a hex number. .TP -- 2.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/5] various fixes mainly for colibri_t20
On Mon, 2016-09-12 at 12:13 -0600, Stephen Warren wrote: > On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: > > > > This series addresses various issues as seen on Colibri T20. Please > > note that for successful Ethernet operation not only on Colibri T20 > > but also on Colibri T30 the following patch will still need > > applying > > as well: > > > > [PATCH] net: asix: Fix ASIX 88772B with driver model > > > > https://www.mail-archive.com/u-boot@lists.denx.de/msg221455.html > > > > Please further note that USB gadget operation on T20 currently > > still > > gives me headaches and despite me comparing the U-Boot sources with > > the Linux driver and trying varous things I am still getting the > > following upon connecting a T20 target device to a host machine: > > > > [70291.779549] usb 2-3.4.2.7: new high-speed USB device number 29 > > using > > xhci_hcd > > [70291.779677] usb 2-3.4.2.7: Device not responding to setup > > address. > > [70291.980783] usb 2-3.4.2.7: Device not responding to setup > > address. > > [70292.181466] usb 2-3.4.2.7: device not accepting address 29, > > error > > -71 > > [70292.181507] usb 2-3.4.2-port7: unable to enumerate USB device > > > > Any feedback or suggestions are much appreciated. > I'm not convinced it's a good idea to enable the feature until it's > reasonably robust? Well, as mentioned before it's not like it hurts anything else really isn't it? My hopes were that somebody may actually help me looking into it which this would ease. I'm not that much familiar with the nitty-gritty details of low-level USB driver interworking plus am currently missing any tool like a USB analyser or the like to help me understand what may be going wrong. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] colibri_t30: fix usb ethernet functionality
On Sat, 2016-09-10 at 18:51 +0200, Marek Vasut wrote:
> On 09/10/2016 04:20 AM, Marcel Ziswiler wrote:
> >
> > Since commit aa7a648747d8c704a9a81c9e493d386930724e9d
> > ("net: Stop including NFS overhead in defragment max") the
> > following
> > has been reproducibly observed while trying to transfer data over
> > TFTP:
> >
> > Load address: 0x80408000
> > Loading: EHCI timed out on TD - token=0x8008d80
> > T EHCI timed out on TD - token=0x88008d80
> > Rx: failed to receive: -5
> >
> > This patch fixes this by upping our maximal de-fragmentation aka IP
> > packet size again.
> >
> > Signed-off-by: Marcel Ziswiler
> >
> > ---
> >
> > include/configs/colibri_t30.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/configs/colibri_t30.h
> > b/include/configs/colibri_t30.h
> > index fbb235d..3431cde 100644
> > --- a/include/configs/colibri_t30.h
> > +++ b/include/configs/colibri_t30.h
> > @@ -48,6 +48,7 @@
> >
> > /* General networking support */
> > #define CONFIG_IP_DEFRAG
> > +#define CONFIG_NET_MAXDEFRAG (16384 + 4096 + 24)
> > #define CONFIG_TFTP_BLOCKSIZE 16384
> > #define CONFIG_TFTP_TSIZE
> >
> >
> Applied, thanks . If you need to rectify this further based on Joe's
> feedback, please do, but I want this fixed before the release.
Unfortunately the release already happened. Nevertheless I will send an
updated version 2 ASAP which fixes all of our boards currently
exhibiting this issue the way Joe suggested.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2016.09 is released
Hi Tom, Am 12.09.2016 um 18:21 schrieb Tom Rini: > > Another thing I'd like to call out, and ask for a little help with too > is automated testing. The framework in test/py/test.py can be used on > real hardware and Stephen Warren has been doing a good job having things > run on Tegra boards. You can see his scripts here[1]. I've setup > locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm > looking at adding more still, so long as I can update U-Boot in a way > that does not involve the console. You can see my scripts here[2] and > I'm cleaning things up and pushing them back up to Stephen. But there's > always more to do and test. Is anyone else out there running this on > real hardware, or would like to set this up? Has anyone out there > gotten this hooked up with qemu? > I have scripts for running tests on MIPS Malta in Qemu [1]. Currently the only non-working tests are test_sleep and test_net_tftpboot on Malta 64Bit. I think it's possible to create a generic ConsoleQemu class but I hadn't time yet to try this. [1] https://github.com/danielschwierzeck/u-boot-test-hooks -- - Daniel signature.asc 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] colibri_t30: fix usb ethernet functionality
On 09/14/2016 04:36 PM, Marcel Ziswiler wrote:
> On Sat, 2016-09-10 at 18:51 +0200, Marek Vasut wrote:
>> On 09/10/2016 04:20 AM, Marcel Ziswiler wrote:
>>>
>>> Since commit aa7a648747d8c704a9a81c9e493d386930724e9d
>>> ("net: Stop including NFS overhead in defragment max") the
>>> following
>>> has been reproducibly observed while trying to transfer data over
>>> TFTP:
>>>
>>> Load address: 0x80408000
>>> Loading: EHCI timed out on TD - token=0x8008d80
>>> T EHCI timed out on TD - token=0x88008d80
>>> Rx: failed to receive: -5
>>>
>>> This patch fixes this by upping our maximal de-fragmentation aka IP
>>> packet size again.
>>>
>>> Signed-off-by: Marcel Ziswiler
>>>
>>> ---
>>>
>>> include/configs/colibri_t30.h | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/include/configs/colibri_t30.h
>>> b/include/configs/colibri_t30.h
>>> index fbb235d..3431cde 100644
>>> --- a/include/configs/colibri_t30.h
>>> +++ b/include/configs/colibri_t30.h
>>> @@ -48,6 +48,7 @@
>>>
>>> /* General networking support */
>>> #define CONFIG_IP_DEFRAG
>>> +#define CONFIG_NET_MAXDEFRAG (16384 + 4096 + 24)
>>> #define CONFIG_TFTP_BLOCKSIZE 16384
>>> #define CONFIG_TFTP_TSIZE
>>>
>>>
>> Applied, thanks . If you need to rectify this further based on Joe's
>> feedback, please do, but I want this fixed before the release.
>
> Unfortunately the release already happened. Nevertheless I will send an
> updated version 2 ASAP which fixes all of our boards currently
> exhibiting this issue the way Joe suggested.
>
Please base that on top of u-boot-usb/master , I already applied V1 .
Me and Tom agreed this is not critical enough to wrap it into release.
--
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 v3] drivers: usb: xhci-fsl: Implement Erratum A-010151 for FSL USB3 controller
On 09/14/2016 07:15 AM, Sriram Dash wrote:
> Currently the controller by default enables the Receive Detect feature in P3
> mode in USB 3.0 PHY. However, USB 3.0 PHY does not reliably support receive
> detection in P3 mode.
> Enabling the USB3 controller to configure USB in P2 mode whenever the Receive
> Detect feature is required.
>
> Signed-off-by: Sriram Dash
> Signed-off-by: Rajesh Bhagat
> ---
> Changes in v3:
> - Fixing conflicts and repost
Changelog of this verbosity is completely useless.
> Changes in v2:
> - Do Soc ver checking for applying erratum
>
> drivers/usb/common/fsl-errata.c | 26 ++
> drivers/usb/host/xhci-dwc3.c| 5 +
> drivers/usb/host/xhci-fsl.c | 8
> include/fsl_usb.h | 1 +
> include/linux/usb/dwc3.h| 2 ++
> 5 files changed, 42 insertions(+)
>
> diff --git a/drivers/usb/common/fsl-errata.c b/drivers/usb/common/fsl-errata.c
> index 183bf2b..f2bffba 100644
> --- a/drivers/usb/common/fsl-errata.c
> +++ b/drivers/usb/common/fsl-errata.c
> @@ -190,4 +190,30 @@ bool has_erratum_a008751(void)
> return false;
> }
>
> +bool has_erratum_a010151(void)
> +{
> + u32 svr = get_svr();
> + u32 soc = SVR_SOC_VER(svr);
> +
> + switch (soc) {
> +#ifdef CONFIG_ARM64
> + case SVR_LS2080A:
> + case SVR_LS2085A:
> + case SVR_LS1046A:
> + case SVR_LS1012A:
> + return IS_SVR_REV(svr, 1, 0);
> + case SVR_LS1043A:
> + return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 1, 1);
> +#endif
> +#ifdef CONFIG_LS102XA
> + case SOC_VER_LS1020:
> + case SOC_VER_LS1021:
> + case SOC_VER_LS1022:
> + case SOC_VER_SLS1020:
> + return IS_SVR_REV(svr, 2, 0);
> +#endif
> + }
> + return false;
> +}
> +
> #endif
> diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
> index 33961cd..adbd9b5 100644
> --- a/drivers/usb/host/xhci-dwc3.c
> +++ b/drivers/usb/host/xhci-dwc3.c
> @@ -97,3 +97,8 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
> setbits_le32(&dwc3_reg->g_fladj, GFLADJ_30MHZ_REG_SEL |
> GFLADJ_30MHZ(val));
> }
> +
> +void dwc3_set_rxdetect_power_mode(struct dwc3 *dwc3_reg, u32 val)
> +{
> + setbits_le32(&dwc3_reg->g_usb3pipectl[0], val);
So what would happen if I wanted to clean some bits instead ?
Why do you even need a dedicated function to write a single register?
> +}
> diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
> index 0e3e056..9297ced 100644
> --- a/drivers/usb/host/xhci-fsl.c
> +++ b/drivers/usb/host/xhci-fsl.c
> @@ -84,6 +84,14 @@ static int fsl_xhci_core_init(struct fsl_xhci *fsl_xhci)
> /* Change beat burst and outstanding pipelined transfers requests */
> fsl_xhci_set_beat_burst_length(fsl_xhci->dwc3_reg);
>
> + /*
> + * A-010151: USB controller to configure USB in P2 mode
> + * whenever the Receive Detect feature is required
> + */
> + if (has_erratum_a010151())
> + dwc3_set_rxdetect_power_mode(fsl_xhci->dwc3_reg,
> + DWC3_GUSB3PIPECTL_DISRXDETP3);
Can't you parse these errata infos from device tree ?
> return ret;
> }
>
> diff --git a/include/fsl_usb.h b/include/fsl_usb.h
> index fc72fb9..73235b8 100644
> --- a/include/fsl_usb.h
> +++ b/include/fsl_usb.h
> @@ -95,5 +95,6 @@ bool has_erratum_a007792(void);
> bool has_erratum_a005697(void);
> bool has_erratum_a004477(void);
> bool has_erratum_a008751(void);
> +bool has_erratum_a010151(void);
> #endif
> #endif /*_ASM_FSL_USB_H_ */
> diff --git a/include/linux/usb/dwc3.h b/include/linux/usb/dwc3.h
> index 6d1e365..f68cdd2 100644
> --- a/include/linux/usb/dwc3.h
> +++ b/include/linux/usb/dwc3.h
> @@ -184,6 +184,7 @@ struct dwc3 { /*
> offset: 0xC100 */
>
> /* Global USB3 PIPE Control Register */
> #define DWC3_GUSB3PIPECTL_PHYSOFTRST (1 << 31)
> +#define DWC3_GUSB3PIPECTL_DISRXDETP3 (1 << 28)
> #define DWC3_GUSB3PIPECTL_SUSPHY (1 << 17)
>
> /* Global TX Fifo Size Register */
> @@ -205,5 +206,6 @@ void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode);
> void dwc3_core_soft_reset(struct dwc3 *dwc3_reg);
> int dwc3_core_init(struct dwc3 *dwc3_reg);
> void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val);
> +void dwc3_set_rxdetect_power_mode(struct dwc3 *dwc3_reg, u32 val);
> #endif
> #endif /* __DWC3_H_ */
>
--
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 v2] drivers: usb: fsl-dt-fixup: Fix the dt for multiple USB nodes in single traversal of device tree
On 09/14/2016 07:22 AM, Sriram Dash wrote:
>> From: Sriram Dash [mailto:sriram.d...@nxp.com]
>>
>
> Hello Marek,
>
> Any comments?
Waiting for York to review this.
It's a bulky patch V2 without changelog, shall I review the whole thing
again ?
>> For FSL USB node fixup, the dt is walked multiple times for fixing erratum
>> and phy
>> type. This patch walks the tree and fixes the node till no more USB nodes
>> are left.
>>
>> Signed-off-by: Sriram Dash
>> Signed-off-by: Rajesh Bhagat
>> ---
>> drivers/usb/common/fsl-dt-fixup.c | 108
>> +-
>> 1 file changed, 47 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/usb/common/fsl-dt-fixup.c
>> b/drivers/usb/common/fsl-dt-fixup.c
>> index 9c48852..df785a6 100644
>> --- a/drivers/usb/common/fsl-dt-fixup.c
>> +++ b/drivers/usb/common/fsl-dt-fixup.c
>> @@ -54,25 +54,19 @@ static int fdt_usb_get_node_type(void *blob, int
>> start_offset, }
>>
>> static int fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
>> - const char *phy_type, int start_offset)
>> + const char *phy_type, int node_offset,
>> + const char **node_type)
>> {
>> const char *prop_mode = "dr_mode";
>> const char *prop_type = "phy_type";
>> -const char *node_type = NULL;
>> -int node_offset;
>> -int err;
>> -
>> -err = fdt_usb_get_node_type(blob, start_offset,
>> -&node_offset, &node_type);
>> -if (err < 0)
>> -return err;
>> +int err = 0;
>>
>> if (mode) {
>> err = fdt_setprop(blob, node_offset, prop_mode, mode,
>>strlen(mode) + 1);
>> if (err < 0)
>> printf("WARNING: could not set %s for %s: %s.\n",
>> - prop_mode, node_type, fdt_strerror(err));
>> + prop_mode, *node_type, fdt_strerror(err));
>> }
>>
>> if (phy_type) {
>> @@ -80,52 +74,48 @@ static int fdt_fixup_usb_mode_phy_type(void *blob, const
>> char *mode,
>>strlen(phy_type) + 1);
>> if (err < 0)
>> printf("WARNING: could not set %s for %s: %s.\n",
>> - prop_type, node_type, fdt_strerror(err));
>> + prop_type, *node_type, fdt_strerror(err));
>> }
>>
>> -return node_offset;
>> +return err;
>> }
>>
>> static int fdt_fixup_usb_erratum(void *blob, const char *prop_erratum,
>> - const char *controller_type, int start_offset)
>> + const char *controller_type, int node_offset,
>> + const char **node_type)
>> {
>> -int node_offset, err;
>> -const char *node_type = NULL;
>> +int err = -1;
>> const char *node_name = NULL;
>>
>> -err = fdt_usb_get_node_type(blob, start_offset,
>> -&node_offset, &node_type);
>> -if (err < 0)
>> -return err;
>> -
>> -if (!strcmp(node_type, FSL_USB2_MPH) || !strcmp(node_type,
>> FSL_USB2_DR))
>> +if (!strcmp(*node_type, FSL_USB2_MPH) ||
>> +!strcmp(*node_type, FSL_USB2_DR))
>> node_name = CHIPIDEA_USB2;
>> else
>> -node_name = node_type;
>> +node_name = *node_type;
>> if (strcmp(node_name, controller_type))
>> return err;
>>
>> err = fdt_setprop(blob, node_offset, prop_erratum, NULL, 0);
>> if (err < 0) {
>> printf("ERROR: could not set %s for %s: %s.\n",
>> - prop_erratum, node_type, fdt_strerror(err));
>> + prop_erratum, *node_type, fdt_strerror(err));
>> }
>>
>> -return node_offset;
>> +return err;
>> }
>>
>> -static int fdt_fixup_erratum(int *usb_erratum_off, void *blob,
>> +static int fdt_fixup_erratum(int node_offset, void *blob,
>> const char *controller_type, char *str,
>> - bool (*has_erratum)(void))
>> + bool (*has_erratum)(void), const char **node_type)
>> {
>> char buf[32] = {0};
>>
>> snprintf(buf, sizeof(buf), "fsl,usb-erratum-%s", str);
>> if (!has_erratum())
>> return -EINVAL;
>> -*usb_erratum_off = fdt_fixup_usb_erratum(blob, buf, controller_type,
>> - *usb_erratum_off);
>> -if (*usb_erratum_off < 0)
>> +node_offset = fdt_fixup_usb_erratum(blob, buf, controller_type,
>> +node_offset, node_type);
>> +if (node_offset < 0)
>> return -ENOSPC;
>> debug("Adding USB erratum %s\n", str);
>> return 0;
>> @@ -135,23 +125,23 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd) {
>> static const char * const modes[] = { "host", "peripheral", "otg" };
>> static const char * const phys[] = {
Re: [U-Boot] [PATCH v1 3/5] colibri_t20: fix display configuration
On Wed, 2016-09-14 at 17:19 +, Stephen Warren wrote: > On 09/14/2016 09:20 AM, Marcel Ziswiler wrote: > > > > On Mon, 2016-09-12 at 12:18 -0600, Stephen Warren wrote: > > > > > > On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: > > > > > > > > > > > > Without this patch the following error will be shown: > > > > > > > > stdio_add_devices: Video device failed (ret=-22) > > > > > > > > As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: > > > > tegra: Move > > > > to using simple-panel and pwm-backlight) states the Colibri T20 > > > > needs > > > > updating too which this patch finally attempts doing. > > > > > > > > Please note that the current U-Boot implementation requires a > > > > dummy > > > > GPIO e.g. for a fixed backlight regulator to be explicitly > > > > defined in > > > > order to work unlike in the Linux kernel where this is taken > > > > care of > > > > automatically. > > > > > > > > > > > > > + compatible = "regulator-fixed"; > > > > + reg = <0>; > > > > + regulator-name = "Dummy"; > > > > + /* Dummy N/C */ > > > > + gpio = <&gpio TEGRA_GPIO(V, 7) > > > > GPIO_ACTIVE_HIGH>; > >> > > > > > > > > This is wrong. If that GPIO isn't actually part of the backlight, > > > the DT > > > should not say that it is. The gpio property is optional > > > according to > > > the DT binding documentation, so this shouldn't be needed. > > Well, I guess then it's lying. > Does "it" mean the binding? Please note that the binding defines how > the > DT should be structured and how code interpreting the DT should > operate. > The binding isn't derived from the code, but rather the code is > derived > from the binding. In theory I agree but in practical speak this is wishful thinking as we just first handedly saw now. > > If I leave it away I get the following: > > > > > > stdio_add_devices: Video device failed (ret=-38) > > > > And it won't quite work. > That sounds like a bug in the U-Boot regulator driver. I believe you > should fix that, rather than working around the bug in DT. Yes, I am pretty sure it won't be the last bug I uncover. Unfortunately right now I do not feel like fixing all of U-Boot. This series just tries to fix a very few select things (e.g. display and USB) which used to work just fine before some bigger agendas came along and broke them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/5] colibri_t20: fix usb operation and controller order
On Mon, 2016-09-12 at 12:20 -0600, Stephen Warren wrote: > On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: > > > > Without this patch the following error will be shown: > > > > Colibri T20 # usb start > > starting USB... > > No controllers found > This change seems fine, but I'm concerned that the alias order > causes > failures; arbitrary orders should be allowed. Have you determined > what > the problem is? Not really, no. Unfortunately with U-Boot there is so much broken- resp. strangeness everywhere if I would start looking into every detail I would never get any real work done. As for this particular case I guess we are now just doing what all other Tegra boards do really. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] simple panel: fix spelling of debug message
Fix spelling of debug message from cnnot to cannot.
Signed-off-by: Marcel Ziswiler
Acked-by: Anatolij Gustschin
---
Changes in v2:
- Add Anatolij's ack.
drivers/video/simple_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c
index b2fe345..baa95f6 100644
--- a/drivers/video/simple_panel.c
+++ b/drivers/video/simple_panel.c
@@ -42,7 +42,7 @@ static int simple_panel_ofdata_to_platdata(struct udevice
*dev)
ret = uclass_get_device_by_phandle(UCLASS_REGULATOR, dev,
"power-supply", &priv->reg);
if (ret) {
- debug("%s: Warning: cnnot get power supply: ret=%d\n",
+ debug("%s: Warning: cannot get power supply: ret=%d\n",
__func__, ret);
if (ret != -ENOENT)
return ret;
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] various fixes mainly for colibri_t20
This series addresses various issues as seen on Colibri T20. Please note that for successful Ethernet operation not only on Colibri T20 but also on Colibri T30 the following patch will still be required already waiting in Marek's usb tree: [PATCH v2] net: asix: Fix ASIX 88772B with driver model https://www.mail-archive.com/u-boot@lists.denx.de/msg224349.html Changes in v2: - As suggested by Stephen gating the CONFIG_CI_UDC_HAS_HOSTPC define with CONFIG_TEGRA20 rather than duplicating the same into all other SoC type specific header files. - Add Anatolij's ack. - Rename dummy regulator to reg_3v3 as suggested by Stephen. - Keep dummy N/C GPIO to work around bug in U-Boot regulator driver requiring such node despite its binding claiming it being optional. - No change. - As suggested by Stephen remove last patch 5/5 colibri_t20: enable dfu also for nand. Marcel Ziswiler (4): tegra: usb gadget: fix ci udc operation if not hostpc capable simple panel: fix spelling of debug message colibri_t20: fix display configuration colibri_t20: fix usb operation and controller order arch/arm/dts/tegra20-colibri.dts | 118 +++--- drivers/video/simple_panel.c | 2 +- include/configs/tegra-common-usb-gadget.h | 2 + 3 files changed, 80 insertions(+), 42 deletions(-) -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] colibri_t20: fix usb operation and controller order
Without this patch the following error will be shown:
Colibri T20 # usb start
starting USB...
No controllers found
This patch fixes USB operation and also the controller order as the
CI UDC driver may only be instantiated on the first aka OTG port.
Signed-off-by: Marcel Ziswiler
---
Changes in v2:
- No change.
- As suggested by Stephen remove last patch 5/5 colibri_t20: enable dfu
also for nand.
arch/arm/dts/tegra20-colibri.dts | 45 +---
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts
index 616c329..8195e5d 100644
--- a/arch/arm/dts/tegra20-colibri.dts
+++ b/arch/arm/dts/tegra20-colibri.dts
@@ -14,10 +14,10 @@
i2c0 = "/i2c@7000d000";
i2c1 = "/i2c@7000c000";
i2c2 = "/i2c@7000c400";
- usb0 = "/usb@c5008000";
- usb1 = "/usb@c500";
- usb2 = "/usb@c5004000";
sdhci0 = "/sdhci@c8000600";
+ usb0 = "/usb@c500";
+ usb1 = "/usb@c5004000"; /* on-module only, for ASIX */
+ usb2 = "/usb@c5008000";
};
host1x@5000 {
@@ -43,24 +43,6 @@
};
};
- usb@c500 {
- statuc = "okay";
- dr_mode = "otg";
- };
-
- usb@c5004000 {
- statuc = "okay";
- /* VBUS_LAN */
- nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
GPIO_ACTIVE_HIGH>;
- nvidia,vbus-gpio = <&gpio TEGRA_GPIO(BB, 1) GPIO_ACTIVE_HIGH>;
- };
-
- usb@c5008000 {
- statuc = "okay";
- /* USBH_PEN */
- nvidia,vbus-gpio = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
- };
-
nand-controller@70008000 {
nvidia,wp-gpios = <&gpio TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
nvidia,width = <8>;
@@ -101,6 +83,27 @@
clock-frequency = <10>;
};
+ /* EHCI instance 0: USB1_DP/N -> USBC_P/N */
+ usb@c500 {
+ status = "okay";
+ dr_mode = "otg";
+ };
+
+ /* EHCI instance 1: ULPI -> USB3340 -> AX88772B */
+ usb@c5004000 {
+ status = "okay";
+ /* VBUS_LAN */
+ nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
GPIO_ACTIVE_HIGH>;
+ nvidia,vbus-gpio = <&gpio TEGRA_GPIO(BB, 1) GPIO_ACTIVE_HIGH>;
+ };
+
+ /* EHCI instance 2: USB3_DP/N -> USBH_P/N */
+ usb@c5008000 {
+ status = "okay";
+ /* USBH_PEN */
+ nvidia,vbus-gpio = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
+ };
+
sdhci@c8000600 {
status = "okay";
bus-width = <4>;
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] tegra: usb gadget: fix ci udc operation if not hostpc capable
The Tegra 2 aka T20 is not host PC capable. Therefore gate the define CONFIG_CI_UDC_HAS_HOSTPC in tegra-common-usb-gadget.h in case of CONFIG_TEGRA20. Signed-off-by: Marcel Ziswiler --- Changes in v2: - As suggested by Stephen gating the CONFIG_CI_UDC_HAS_HOSTPC define with CONFIG_TEGRA20 rather than duplicating the same into all other SoC type specific header files. include/configs/tegra-common-usb-gadget.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/tegra-common-usb-gadget.h b/include/configs/tegra-common-usb-gadget.h index 3e3eeea..2e492c1 100644 --- a/include/configs/tegra-common-usb-gadget.h +++ b/include/configs/tegra-common-usb-gadget.h @@ -10,7 +10,9 @@ #ifndef CONFIG_SPL_BUILD /* USB gadget mode support*/ +#ifndef CONFIG_TEGRA20 #define CONFIG_CI_UDC_HAS_HOSTPC +#endif /* USB mass storage protocol */ #define CONFIG_USB_FUNCTION_MASS_STORAGE /* DFU protocol */ -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] colibri_t20: fix display configuration
Without this patch the following error will be shown:
stdio_add_devices: Video device failed (ret=-22)
As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: tegra: Move
to using simple-panel and pwm-backlight) states the Colibri T20 needs
updating too which this patch finally attempts doing.
Please note that the current U-Boot implementation requires a dummy
GPIO e.g. for a fixed backlight regulator to be explicitly defined in
order to work unlike in the Linux kernel where this is taken care of
automatically.
Signed-off-by: Marcel Ziswiler
---
Changes in v2:
- Rename dummy regulator to reg_3v3 as suggested by Stephen.
- Keep dummy N/C GPIO to work around bug in U-Boot regulator driver
requiring such node despite its binding claiming it being optional.
arch/arm/dts/tegra20-colibri.dts | 73 +---
1 file changed, 53 insertions(+), 20 deletions(-)
diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts
index 2cf24d3..616c329 100644
--- a/arch/arm/dts/tegra20-colibri.dts
+++ b/arch/arm/dts/tegra20-colibri.dts
@@ -21,12 +21,24 @@
};
host1x@5000 {
- status = "okay";
dc@5420 {
- status = "okay";
rgb {
status = "okay";
nvidia,panel = <&lcd_panel>;
+ display-timings {
+ timing@0 {
+ /* VESA VGA */
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vback-porch = <31>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
};
@@ -60,6 +72,10 @@
};
};
+ pwm@7000a000 {
+ status = "okay";
+ };
+
/*
* GEN1_I2C: I2C_SDA/SCL on SODIMM pin 194/196 (e.g. RTC on carrier
* board)
@@ -91,6 +107,18 @@
cd-gpios = <&gpio TEGRA_GPIO(C, 7) GPIO_ACTIVE_LOW>;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+
+ brightness-levels = <255 128 64 32 16 8 4 0>;
+ default-brightness-level = <6>;
+ /* BL_ON */
+ enable-gpios = <&gpio TEGRA_GPIO(T, 4) GPIO_ACTIVE_HIGH>;
+ power-supply = <®_3v3>;
+ /* PWM */
+ pwms = <&pwm 0 500>;
+ };
+
clocks {
compatible = "simple-bus";
#address-cells = <1>;
@@ -104,25 +132,30 @@
};
};
- pwm: pwm@7000a000 {
- status = "okay";
+ lcd_panel: panel {
+ /*
+* edt,et057090dhu: EDT 5.7" LCD TFT
+* edt,et070080dh6: EDT 7.0" LCD TFT
+*/
+ compatible = "edt,et057090dhu", "simple-panel";
+
+ backlight = <&backlight>;
};
- lcd_panel: panel {
- clock = <25175000>;
- xres = <640>;
- yres = <480>;
- left-margin = <48>; /* horizontal back porch */
- right-margin = <16>;/* horizontal front porch */
- hsync-len = <96>;
- lower-margin = <11>;/* vertical front porch */
- upper-margin = <31>;/* vertical back porch */
- vsync-len = <2>;
- hsync-active-high;
- vsync-active-high;
- nvidia,bits-per-pixel = <16>;
- nvidia,pwm = <&pwm 0 0>;
- nvidia,backlight-enable-gpios = <&gpio TEGRA_GPIO(T, 4)
GPIO_ACTIVE_HIGH>;
- nvidia,panel-timings = <0 0 0 0>;
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_3v3: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "+V3.3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ /* Dummy N/C */
+ gpio = <&gpio TEGRA_GPIO(V, 7) GPIO_ACTIVE_HIGH>;
+ };
};
};
--
2.5.5
__
[U-Boot] [PATCH] ARM: vf610: use strcpy for soc environment variable
From: Stefan Agner
To create the soc environment variable we concatenate two strings
on the stack. So far, strcat has been used for the first string as
well as for the second string. Since the variable on the stack is
not initialized, the first strcat may not start using the first
entry in the character array. This then could lead to an buffer
overflow on the stack.
Signed-off-by: Stefan Agner
Acked-by: Marcel Ziswiler
Signed-off-by: Marcel Ziswiler
---
arch/arm/cpu/armv7/vf610/generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/vf610/generic.c
b/arch/arm/cpu/armv7/vf610/generic.c
index 08b9ef4..50eb0c6 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -322,7 +322,7 @@ int arch_misc_init(void)
{
char soc[6];
- strcat(soc, "vf");
+ strcpy(soc, "vf");
strcat(soc, soc_type);
setenv("soc", soc);
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] drivers: usb: fsl-dt-fixup: Fix the dt for multiple USB nodes in single traversal of device tree
On 09/14/2016 02:35 PM, Marek Vasut wrote:
> On 09/14/2016 07:22 AM, Sriram Dash wrote:
>>> From: Sriram Dash [mailto:sriram.d...@nxp.com]
>>>
>>
>> Hello Marek,
>>
>> Any comments?
>
> Waiting for York to review this.
>
> It's a bulky patch V2 without changelog, shall I review the whole thing
> again ?
>
>>> For FSL USB node fixup, the dt is walked multiple times for fixing erratum
>>> and phy
>>> type. This patch walks the tree and fixes the node till no more USB nodes
>>> are left.
>>>
>>> Signed-off-by: Sriram Dash
>>> Signed-off-by: Rajesh Bhagat
>>> ---
>>> drivers/usb/common/fsl-dt-fixup.c | 108
>>> +-
>>> 1 file changed, 47 insertions(+), 61 deletions(-)
>>>
>>> diff --git a/drivers/usb/common/fsl-dt-fixup.c
>>> b/drivers/usb/common/fsl-dt-fixup.c
>>> index 9c48852..df785a6 100644
>>> --- a/drivers/usb/common/fsl-dt-fixup.c
>>> +++ b/drivers/usb/common/fsl-dt-fixup.c
>>> @@ -54,25 +54,19 @@ static int fdt_usb_get_node_type(void *blob, int
>>> start_offset, }
>>>
>>> static int fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
>>> - const char *phy_type, int start_offset)
>>> + const char *phy_type, int node_offset,
>>> + const char **node_type)
>>> {
>>> const char *prop_mode = "dr_mode";
>>> const char *prop_type = "phy_type";
>>> - const char *node_type = NULL;
>>> - int node_offset;
>>> - int err;
>>> -
>>> - err = fdt_usb_get_node_type(blob, start_offset,
>>> - &node_offset, &node_type);
>>> - if (err < 0)
>>> - return err;
>>> + int err = 0;
>>>
>>> if (mode) {
>>> err = fdt_setprop(blob, node_offset, prop_mode, mode,
>>> strlen(mode) + 1);
>>> if (err < 0)
>>> printf("WARNING: could not set %s for %s: %s.\n",
>>> - prop_mode, node_type, fdt_strerror(err));
>>> + prop_mode, *node_type, fdt_strerror(err));
>>> }
>>>
>>> if (phy_type) {
>>> @@ -80,52 +74,48 @@ static int fdt_fixup_usb_mode_phy_type(void *blob, const
>>> char *mode,
>>> strlen(phy_type) + 1);
>>> if (err < 0)
>>> printf("WARNING: could not set %s for %s: %s.\n",
>>> - prop_type, node_type, fdt_strerror(err));
>>> + prop_type, *node_type, fdt_strerror(err));
>>> }
>>>
>>> - return node_offset;
>>> + return err;
>>> }
>>>
>>> static int fdt_fixup_usb_erratum(void *blob, const char *prop_erratum,
>>> -const char *controller_type, int start_offset)
>>> +const char *controller_type, int node_offset,
>>> +const char **node_type)
>>> {
>>> - int node_offset, err;
>>> - const char *node_type = NULL;
>>> + int err = -1;
>>> const char *node_name = NULL;
>>>
>>> - err = fdt_usb_get_node_type(blob, start_offset,
>>> - &node_offset, &node_type);
>>> - if (err < 0)
>>> - return err;
>>> -
>>> - if (!strcmp(node_type, FSL_USB2_MPH) || !strcmp(node_type,
>>> FSL_USB2_DR))
>>> + if (!strcmp(*node_type, FSL_USB2_MPH) ||
>>> + !strcmp(*node_type, FSL_USB2_DR))
>>> node_name = CHIPIDEA_USB2;
>>> else
>>> - node_name = node_type;
>>> + node_name = *node_type;
>>> if (strcmp(node_name, controller_type))
>>> return err;
>>>
>>> err = fdt_setprop(blob, node_offset, prop_erratum, NULL, 0);
>>> if (err < 0) {
>>> printf("ERROR: could not set %s for %s: %s.\n",
>>> - prop_erratum, node_type, fdt_strerror(err));
>>> + prop_erratum, *node_type, fdt_strerror(err));
>>> }
>>>
>>> - return node_offset;
>>> + return err;
>>> }
>>>
>>> -static int fdt_fixup_erratum(int *usb_erratum_off, void *blob,
>>> +static int fdt_fixup_erratum(int node_offset, void *blob,
>>> const char *controller_type, char *str,
>>> -bool (*has_erratum)(void))
>>> +bool (*has_erratum)(void), const char **node_type)
>>> {
>>> char buf[32] = {0};
>>>
>>> snprintf(buf, sizeof(buf), "fsl,usb-erratum-%s", str);
>>> if (!has_erratum())
>>> return -EINVAL;
>>> - *usb_erratum_off = fdt_fixup_usb_erratum(blob, buf, controller_type,
>>> -*usb_erratum_off);
>>> - if (*usb_erratum_off < 0)
>>> + node_offset = fdt_fixup_usb_erratum(blob, buf, controller_type,
>>> + node_offset, node_type);
>>> + if (node_offset < 0)
>>> return -ENOSPC;
>>> debug("Adding USB erratum %s\n", str);
>>> return 0;
>>> @@ -135,23 +125,23 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd) {
>>> static const
[U-Boot] [PATCH v2] apalis_t30: colibri_imx7: colibri_t30: fix ethernet functionality
Since commit aa7a648747d8c704a9a81c9e493d386930724e9d
("net: Stop including NFS overhead in defragment max") the following
has been reproducibly observed while trying to transfer data over TFTP:
Load address: 0x80408000
Loading: EHCI timed out on TD - token=0x8008d80
T EHCI timed out on TD - token=0x88008d80
Rx: failed to receive: -5
This patch fixes this by lowering our TFTP block size to be within the
standard maximal de-fragmentation aka IP packet size again.
Signed-off-by: Marcel Ziswiler
---
Changes in v2:
- lowering our TFTP block size rather than increasing the maximal
de-fragmentation aka IP packet size as suggested by Joe
- add Apalis T30 and Colibri iMX7 as well as suggested by Joe
- base on top of u-boot-usb/master as suggested by Marek
include/configs/apalis_t30.h | 2 +-
include/configs/colibri_imx7.h | 4 ++--
include/configs/colibri_t30.h | 3 +--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/configs/apalis_t30.h b/include/configs/apalis_t30.h
index 8c76605..3fc1779 100644
--- a/include/configs/apalis_t30.h
+++ b/include/configs/apalis_t30.h
@@ -52,7 +52,7 @@
/* General networking support */
#define CONFIG_IP_DEFRAG
-#define CONFIG_TFTP_BLOCKSIZE 16384
+#define CONFIG_TFTP_BLOCKSIZE 16352
#define CONFIG_TFTP_TSIZE
/* Miscellaneous commands */
diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index 2ec392e..63f 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -44,9 +44,9 @@
#define CONFIG_PHYLIB
#define CONFIG_PHY_MICREL
-#define CONFIG_TFTP_TSIZE
#define CONFIG_IP_DEFRAG
-#define CONFIG_TFTP_BLOCKSIZE 16384
+#define CONFIG_TFTP_BLOCKSIZE 16352
+#define CONFIG_TFTP_TSIZE
/* ENET1 */
#define IMX_FEC_BASE ENET_IPS_BASE_ADDR
diff --git a/include/configs/colibri_t30.h b/include/configs/colibri_t30.h
index 3431cde..e2a2549 100644
--- a/include/configs/colibri_t30.h
+++ b/include/configs/colibri_t30.h
@@ -48,8 +48,7 @@
/* General networking support */
#define CONFIG_IP_DEFRAG
-#define CONFIG_NET_MAXDEFRAG (16384 + 4096 + 24)
-#define CONFIG_TFTP_BLOCKSIZE 16384
+#define CONFIG_TFTP_BLOCKSIZE 16352
#define CONFIG_TFTP_TSIZE
/* Miscellaneous commands */
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/5] colibri_t20: fix display configuration
On Mon, 2016-09-12 at 12:18 -0600, Stephen Warren wrote:
> On 09/09/2016 10:10 AM, Marcel Ziswiler wrote:
> >
> > Without this patch the following error will be shown:
> >
> > stdio_add_devices: Video device failed (ret=-22)
> >
> > As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: tegra:
> > Move
> > to using simple-panel and pwm-backlight) states the Colibri T20
> > needs
> > updating too which this patch finally attempts doing.
> >
> > Please note that the current U-Boot implementation requires a dummy
> > GPIO e.g. for a fixed backlight regulator to be explicitly defined
> > in
> > order to work unlike in the Linux kernel where this is taken care
> > of
> > automatically.
> The binding documentation does state that the power supply is
> mandatory.
Yes, of course.
> > diff --git a/arch/arm/dts/tegra20-colibri.dts
> > b/arch/arm/dts/tegra20-colibri.dts
> >
> > + regulators {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reg_dummy: regulator@0 {
> Why call this a dummy? This is a real regulator that describes the
> power
> supply to the backlight. Even if there's no SW control over the power
> to
> the backlight, there is still a (fixed) power source, and this DT
> node
> represents that power source.
OK.
> > + compatible = "regulator-fixed";
> > + reg = <0>;
> > + regulator-name = "Dummy";
> > + /* Dummy N/C */
> > + gpio = <&gpio TEGRA_GPIO(V, 7)
> > GPIO_ACTIVE_HIGH>;
> This is wrong. If that GPIO isn't actually part of the backlight, the
> DT
> should not say that it is. The gpio property is optional according
> to
> the DT binding documentation, so this shouldn't be needed.
Well, I guess then it's lying. If I leave it away I get the following:
stdio_add_devices: Video device failed (ret=-38)
And it won't quite work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] tegra: usb gadget: fix ci udc operation if not hostpc capable
On 09/14/2016 04:14 PM, Marcel Ziswiler wrote: The Tegra 2 aka T20 is not host PC capable. Therefore gate the define CONFIG_CI_UDC_HAS_HOSTPC in tegra-common-usb-gadget.h in case of CONFIG_TEGRA20. Signed-off-by: Marcel Ziswiler Acked-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] colibri_t20: fix display configuration
On 09/14/2016 04:14 PM, Marcel Ziswiler wrote: Without this patch the following error will be shown: stdio_add_devices: Video device failed (ret=-22) As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: tegra: Move to using simple-panel and pwm-backlight) states the Colibri T20 needs updating too which this patch finally attempts doing. Please note that the current U-Boot implementation requires a dummy GPIO e.g. for a fixed backlight regulator to be explicitly defined in order to work unlike in the Linux kernel where this is taken care of automatically. diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "+V3.3"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + regulator-always-on; + /* Dummy N/C */ + gpio = <&gpio TEGRA_GPIO(V, 7) GPIO_ACTIVE_HIGH>; NAK while this new DT doesn't actually represent the HW. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] colibri_t20: fix usb operation and controller order
On 09/14/2016 04:14 PM, Marcel Ziswiler wrote: Without this patch the following error will be shown: Colibri T20 # usb start starting USB... No controllers found This patch fixes USB operation and also the controller order as the CI UDC driver may only be instantiated on the first aka OTG port. Acked-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 5/5] colibri_t20: enable dfu also for nand
On Wed, 2016-09-14 at 17:23 +, Stephen Warren wrote: > On 09/14/2016 09:41 AM, Marcel Ziswiler wrote: > > > > On Mon, 2016-09-12 at 12:24 -0600, Stephen Warren wrote: > > > > > > On 09/09/2016 10:10 AM, Marcel Ziswiler wrote: > > > > > > > > > > > > Enable USB gadget DFU functionality for NAND as well. > > > > > > > > diff --git a/include/configs/colibri_t20.h > > > > b/include/configs/colibri_t20.h > > > > > > > > +/* USB DFU */ > > > > +#define CONFIG_DFU_NAND > > > Oh, I see this file already includes tegra-common-usb-gadget.h, > > > so > > > USB > > > device-mode is already enabled for this board. Does that make > > > sense > > > given that it doesn't actually work? > > Well, it's not like it hurts anything else really isn't it? > Having the feature enabled implies that it works in my opinion. If > it > doesn't, I think this will only confuse users. Well, as you correctly noticed it is and always was already enabled anyway. > > My hopes were that somebody may actually help me looking into it > > which > > this would ease. However I understand that you NVIDIA people long > > since > > stopped even having any of them older Tegra 2 and 3 hardware any > > longer. At least Harmony and Ventana currently looks rather broken > > in > > many aspects which I left for another days exercise. > If someone wants to fix USB device mode on Tegra20, I don't imagine > it > would be hard for them to enable it while working on it. Sure, as it long since was already enabled. > What's broken on Harmony and Ventana? They both worked when I tested > all > Tegra boards within the last few months. We have a Tegra30 board > (but > admittedly not Tegra20 board) in our automated upstream U-Boot test > farm > (running test/py). Last I checked a few days ago USB failed at least on Ventana. > > > > +#define DFU_ALT_NAND_INFO "u-boot part 0,1;ubi part > > > > 0,4" > > > > + > > > > #define BOARD_EXTRA_ENV_SETTINGS \ > > > > + "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \ > > > I would defer this to the user, since people may choose different > > > flash > > > layouts. > > Given the DFU NAND syntax being rather delicate at least Google > > returning rather some wrong stuff with respect to now starting with > > zero or one I thought that would at least make it clear. It's not > > that > > a user could not overwrite it any time if he wishes to do so isn't > > it? > Certainly a user could over-write it. However, I'm not convinced it's > a > good idea to provide an arbitrary default value that may or may not > be > remotely relevant to the user's actual configuration. Again, this > may > lead users down the wrong path of wondering why they can't get this > default configuration to work, rather than researching what the > correct > configuration is. Sure, I will just drop this patch. Don't worry. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: imx6: configure NoC on i.MX6DQP
The i.MX6DP and i.MX6QP incorporate NoC interconnect logic
which needs to be configured in order to use external DDR memory.
This patch enables the SPL to configure the necessary registers
in accordance with the NXP engineering bulletin EB828.
Signed-off-by: Filip Brozovic
---
arch/arm/cpu/armv7/mx6/ddr.c| 69 +
arch/arm/include/asm/arch-mx6/mx6-ddr.h | 19 +
2 files changed, 88 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 7beb7ea..60bfd08 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -1181,6 +1181,8 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo,
{
volatile struct mmdc_p_regs *mmdc0;
volatile struct mmdc_p_regs *mmdc1;
+ struct src *src_regs = (struct src *)SRC_BASE_ADDR;
+ u8 soc_boot_cfg3 = ((readl(&src_regs->sbmr1) & 0xff) >> 16) & 0xff;
u32 val;
u8 tcke, tcksrx, tcksre, txpdll, taofpd, taonpd, trrd;
u8 todtlon, taxpd, tanpd, tcwl, txp, tfaw, tcl;
@@ -1473,6 +1475,73 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo,
/* Step 12: Configure and activate periodic refresh */
mmdc0->mdref = (sysinfo->refsel << 14) | (sysinfo->refr << 11);
+ /*
+* i.MX6DQP only: If the NoC scheduler is enabled,
+* configure it and disable MMDC arbitration/reordering (see EB828)
+*/
+ if (is_mx6dqp() && ((soc_boot_cfg3 & 0x30) == 0x00 ||
+ (soc_boot_cfg3 & 0x33) == 0x31)) {
+ struct mx6dqp_noc_sched_regs *noc_sched =
+ (struct mx6dqp_noc_sched_regs *)MX6DQP_NOC_SCHED_BASE;
+
+ /* These values are fixed based on integration parameters and
+* should not be modified */
+ noc_sched->rlat = 0x0040;
+ noc_sched->ipu1 = 0x0020;
+ noc_sched->ipu2 = 0x0020;
+
+ noc_sched->activate = (1 << 10) | /* FawBank */
+ (tfaw << 4) |
+ (trrd << 0);
+ noc_sched->ddrtiming = (((sysinfo->dsize == 1) ? 1 : 0) << 31) |
+ ((tcwl + twtr) << 26) |
+ ((tcl - tcwl + 2) << 21) |
+ (4 << 18) | /* Burst Length = 8 */
+ ((tcwl + twr + trp + trcd) << 12) |
+ ((trtp + trp + trcd - 4) << 6) |
+ (trc << 0);
+
+ if (sysinfo->dsize == 2) {
+ if (ddr3_cfg->coladdr == 10) {
+ if (ddr3_cfg->rowaddr == 15 &&
+ sysinfo->ncs == 2)
+ noc_sched->ddrconf = 4;
+ else
+ noc_sched->ddrconf = 0;
+ } else if (ddr3_cfg->coladdr == 11) {
+ noc_sched->ddrconf = 1;
+ }
+ } else {
+ if (ddr3_cfg->coladdr == 9) {
+ if (ddr3_cfg->rowaddr == 13)
+ noc_sched->ddrconf = 2;
+ else if (ddr3_cfg->rowaddr == 14)
+ noc_sched->ddrconf = 15;
+ } else if (ddr3_cfg->coladdr == 10) {
+ if (ddr3_cfg->rowaddr == 14 &&
+ sysinfo->ncs == 2)
+ noc_sched->ddrconf = 14;
+ else if (ddr3_cfg->rowaddr == 15 &&
+sysinfo->ncs == 2)
+ noc_sched->ddrconf = 9;
+ else
+ noc_sched->ddrconf = 3;
+ } else if (ddr3_cfg->coladdr == 11) {
+ if (ddr3_cfg->rowaddr == 15 &&
+ sysinfo->ncs == 2)
+ noc_sched->ddrconf = 4;
+ else
+ noc_sched->ddrconf = 0;
+ } else if (ddr3_cfg->coladdr == 12) {
+ if (ddr3_cfg->rowaddr == 14)
+ noc_sched->ddrconf = 1;
+ }
+ }
+
+ /* Disable MMDC arbitration/reordering */
+ mmdc0->maarcr = 0x1442;
+ }
+
/* Step 13: Deassert config request - init complete */
mmdc0->mdscr = 0x;
diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index 9922409..c881782 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+
[U-Boot] [PATCH] imx: iomux-v3: fix pad setup on i.MX6DQP when CONFIG_MX6QDL is defined
The CPU detection macro is_mx6dq returns 0 on an i.MX6DQP, so we need to check for it explicitly in order to correctly initialize the pads when CONFIG_MX6QDL is defined. Signed-off-by: Filip Brozovic --- arch/arm/imx-common/iomux-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c index 66137d1..2612e09 100644 --- a/arch/arm/imx-common/iomux-v3.c +++ b/arch/arm/imx-common/iomux-v3.c @@ -83,7 +83,7 @@ void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, #if defined(CONFIG_MX6QDL) stride = 2; - if (!is_mx6dq()) + if (!is_mx6dq() && !is_mx6dqp()) p += 1; #else stride = 1; -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] power: regulator: Add ctrl_reg and volt_reg fields for pmic
Hello Keerthy,
On 09/14/2016 10:24 AM, Keerthy wrote:
Hi Marczak,
On Wednesday 14 September 2016 01:33 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/14/2016 06:28 AM, Keerthy wrote:
The ctrl reg contains bit fields to enable and disable regulators,
and volt_reg has the bit fields to configure the voltage values.
The registers are frequently accessed hence make them part
of dm_regulator_uclass_platdata structure.
Signed-off-by: Keerthy
---
include/power/regulator.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 9bcd728..57b14a3 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -171,6 +171,8 @@ struct dm_regulator_uclass_platdata {
bool boot_on;
const char *name;
int flags;
+u8 ctrl_reg;
+u8 volt_reg;
};
/* Regulator device operations */
This structure above is used for some common "high-level" data, which
can be used by regulator uclass driver.
Even if most of PMICs has some ctrl/volt/etc regs, the regulator uclass
driver doesn't know, how to use it, so from this point of view it is
useless.
But, you can keep device/driver data in a proper fields. Please look at
those files:
drivers/power/regulator/fixed.c:119
drivers/power/regulator/pfuze100.c:567
To store some device internal data, you can use:
.platdata_auto_alloc_size -> with access by dev_get_platdata()
.priv_auto_alloc_size -> with access by dev_get_priv()
Thanks for a quick review. I did look at some of those options before
introducing volt and ctrl here.
Many PMICs will have ctrl/volt registers we might end up having lot of
private strutures with the same ctrl/volt fields. I agree uclass
driver will not know how to use it.
If i have to draw parallels from the kernel world regulator_desc is a
common structure which hosts vsel_reg/enable_reg fields.
Isn't it better to have a common structure instead of having a some
platform specific structure that might have the same fields?
Let me know your thoughts on this.
Best regards,
You are right and I agree with you that make things common is a good
approach.
At the begin of introducing this framework, I just wanted to provide a
simple user interface for regulators, so I didn't tried to put all
common things into a single structure, because not always it could be
useful.
The present structure layout seems to be a good representation of
regulator's node in the device-tree.
In the other hand, each driver can provide a static arrays with proper
data like reg/mask/etc,
the driver:
drivers/power/regulator/s5m8767.c- is a good example.
I'm not going to break your solution, but let's wait for Simon's opinion.
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Add TOPIC Miami boards
These patches add support for the Miami range of boards from TOPIC. The boards are based on Xilinx Zynq SoCs, these two patches are for the 7-series, the Ultrascale MPSOC boards are to be added later. Please note that the "ps7_init_gpl" files are largely generated by a tool and as a result of that, contain many style issues. Mike Looijmans (2): Add topic-miami board support Add topic_miamiplus board arch/arm/dts/Makefile |2 + arch/arm/dts/zynq-topic-miami.dts | 98 + arch/arm/dts/zynq-topic-miamiplus.dts | 22 + board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c | 4324 +++ board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h | 118 + .../zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 4425 .../zynq/zynq-topic-miamiplus/ps7_init_gpl.h | 150 + configs/topic_miami_defconfig | 47 + configs/topic_miamiplus_defconfig | 47 + include/configs/topic_miami.h | 147 + include/configs/topic_miamiplus.h |2 + 11 files changed, 9382 insertions(+) create mode 100644 arch/arm/dts/zynq-topic-miami.dts create mode 100644 arch/arm/dts/zynq-topic-miamiplus.dts create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.c create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.h create mode 100644 configs/topic_miami_defconfig create mode 100644 configs/topic_miamiplus_defconfig create mode 100644 include/configs/topic_miami.h create mode 100644 include/configs/topic_miamiplus.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] drivers: usb: fsl-dt-fixup: Fix the dt for multiple USB nodes in single traversal of device tree
>From: york sun
>On 09/14/2016 02:35 PM, Marek Vasut wrote:
>> On 09/14/2016 07:22 AM, Sriram Dash wrote:
From: Sriram Dash [mailto:sriram.d...@nxp.com]
>>>
>>> Hello Marek,
>>>
>>> Any comments?
>>
>> Waiting for York to review this.
>>
>> It's a bulky patch V2 without changelog, shall I review the whole
>> thing again ?
>>
Will take care the next time for changelog. I agree the patch is
completely changed from v1. The major change is that the dt traversal
is reduced.
For FSL USB node fixup, the dt is walked multiple times for fixing
erratum and phy type. This patch walks the tree and fixes the node till no
more
>USB nodes are left.
Signed-off-by: Sriram Dash
Signed-off-by: Rajesh Bhagat
---
drivers/usb/common/fsl-dt-fixup.c | 108
+-
1 file changed, 47 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/common/fsl-dt-fixup.c
b/drivers/usb/common/fsl-dt-fixup.c
index 9c48852..df785a6 100644
--- a/drivers/usb/common/fsl-dt-fixup.c
+++ b/drivers/usb/common/fsl-dt-fixup.c
@@ -54,25 +54,19 @@ static int fdt_usb_get_node_type(void *blob, int
start_offset, }
static int fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
- const char *phy_type, int start_offset)
+ const char *phy_type, int node_offset,
+ const char **node_type)
{
const char *prop_mode = "dr_mode";
const char *prop_type = "phy_type";
- const char *node_type = NULL;
- int node_offset;
- int err;
-
- err = fdt_usb_get_node_type(blob, start_offset,
- &node_offset, &node_type);
- if (err < 0)
- return err;
+ int err = 0;
if (mode) {
err = fdt_setprop(blob, node_offset, prop_mode, mode,
strlen(mode) + 1);
if (err < 0)
printf("WARNING: could not set %s for %s: %s.\n",
- prop_mode, node_type, fdt_strerror(err));
+ prop_mode, *node_type, fdt_strerror(err));
}
if (phy_type) {
@@ -80,52 +74,48 @@ static int fdt_fixup_usb_mode_phy_type(void
*blob, const char *mode,
strlen(phy_type) + 1);
if (err < 0)
printf("WARNING: could not set %s for %s: %s.\n",
- prop_type, node_type, fdt_strerror(err));
+ prop_type, *node_type, fdt_strerror(err));
}
- return node_offset;
+ return err;
}
static int fdt_fixup_usb_erratum(void *blob, const char *prop_erratum,
- const char *controller_type, int start_offset)
+ const char *controller_type, int node_offset,
+ const char **node_type)
{
- int node_offset, err;
- const char *node_type = NULL;
+ int err = -1;
const char *node_name = NULL;
- err = fdt_usb_get_node_type(blob, start_offset,
- &node_offset, &node_type);
- if (err < 0)
- return err;
-
- if (!strcmp(node_type, FSL_USB2_MPH) || !strcmp(node_type,
FSL_USB2_DR))
+ if (!strcmp(*node_type, FSL_USB2_MPH) ||
+ !strcmp(*node_type, FSL_USB2_DR))
node_name = CHIPIDEA_USB2;
else
- node_name = node_type;
+ node_name = *node_type;
if (strcmp(node_name, controller_type))
return err;
err = fdt_setprop(blob, node_offset, prop_erratum, NULL, 0);
if (err < 0) {
printf("ERROR: could not set %s for %s: %s.\n",
- prop_erratum, node_type, fdt_strerror(err));
+ prop_erratum, *node_type, fdt_strerror(err));
}
- return node_offset;
+ return err;
}
-static int fdt_fixup_erratum(int *usb_erratum_off, void *blob,
+static int fdt_fixup_erratum(int node_offset, void *blob,
const char *controller_type, char *str,
- bool (*has_erratum)(void))
+ bool (*has_erratum)(void), const char **node_type)
{
char buf[32] = {0};
snprintf(buf, sizeof(buf), "fsl,usb-erratum-%s", str);
if (!has_erratum())
return -EINVAL;
- *usb_erratum_off = fdt_fixup_usb_erratum(blob, buf, controller_type,
- *usb_erratum_off);
- if (*usb_erratum_off < 0)
+ node_offset = fdt_fixup_usb_erratum(blob, buf, controller_type,
+ node_offset, node_type);
Re: [U-Boot] [PATCH v3] drivers: usb: xhci-fsl: Implement Erratum A-010151 for FSL USB3 controller
>From: Marek Vasut [mailto:ma...@denx.de]
>On 09/14/2016 07:15 AM, Sriram Dash wrote:
>> Currently the controller by default enables the Receive Detect feature
>> in P3 mode in USB 3.0 PHY. However, USB 3.0 PHY does not reliably
>> support receive detection in P3 mode.
>> Enabling the USB3 controller to configure USB in P2 mode whenever the
>> Receive Detect feature is required.
>>
>> Signed-off-by: Sriram Dash
>> Signed-off-by: Rajesh Bhagat
>> ---
>> Changes in v3:
>> - Fixing conflicts and repost
>
>Changelog of this verbosity is completely useless.
>
I will take care the next time.
>> Changes in v2:
>> - Do Soc ver checking for applying erratum
>>
>> drivers/usb/common/fsl-errata.c | 26 ++
>> drivers/usb/host/xhci-dwc3.c| 5 +
>> drivers/usb/host/xhci-fsl.c | 8
>> include/fsl_usb.h | 1 +
>> include/linux/usb/dwc3.h| 2 ++
>> 5 files changed, 42 insertions(+)
>>
>> diff --git a/drivers/usb/common/fsl-errata.c
>> b/drivers/usb/common/fsl-errata.c index 183bf2b..f2bffba 100644
>> --- a/drivers/usb/common/fsl-errata.c
>> +++ b/drivers/usb/common/fsl-errata.c
>> @@ -190,4 +190,30 @@ bool has_erratum_a008751(void)
>> return false;
>> }
>>
>> +bool has_erratum_a010151(void)
>> +{
>> +u32 svr = get_svr();
>> +u32 soc = SVR_SOC_VER(svr);
>> +
>> +switch (soc) {
>> +#ifdef CONFIG_ARM64
>> +case SVR_LS2080A:
>> +case SVR_LS2085A:
>> +case SVR_LS1046A:
>> +case SVR_LS1012A:
>> +return IS_SVR_REV(svr, 1, 0);
>> +case SVR_LS1043A:
>> +return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 1, 1); #endif
>> +#ifdef CONFIG_LS102XA
>> +case SOC_VER_LS1020:
>> +case SOC_VER_LS1021:
>> +case SOC_VER_LS1022:
>> +case SOC_VER_SLS1020:
>> +return IS_SVR_REV(svr, 2, 0);
>> +#endif
>> +}
>> +return false;
>> +}
>> +
>> #endif
>> diff --git a/drivers/usb/host/xhci-dwc3.c
>> b/drivers/usb/host/xhci-dwc3.c index 33961cd..adbd9b5 100644
>> --- a/drivers/usb/host/xhci-dwc3.c
>> +++ b/drivers/usb/host/xhci-dwc3.c
>> @@ -97,3 +97,8 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
>> setbits_le32(&dwc3_reg->g_fladj, GFLADJ_30MHZ_REG_SEL |
>> GFLADJ_30MHZ(val));
>> }
>> +
>> +void dwc3_set_rxdetect_power_mode(struct dwc3 *dwc3_reg, u32 val) {
>> +setbits_le32(&dwc3_reg->g_usb3pipectl[0], val);
>
>So what would happen if I wanted to clean some bits instead ?
Setting the Rx detect in P2 mode is a one time job,
and it does not change. Hence, IMO, the clear bit
functionality is not required.
>Why do you even need a dedicated function to write a single register?
>
The dwc3 phy for the specific controller version does not reliably
support Rx Detect in P3 mode(P3 is the default setting). So, this
setting can be used by any other Soc, apart from freescale. IMO, this
function is required.
>> +}
>> diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
>> index 0e3e056..9297ced 100644
>> --- a/drivers/usb/host/xhci-fsl.c
>> +++ b/drivers/usb/host/xhci-fsl.c
>> @@ -84,6 +84,14 @@ static int fsl_xhci_core_init(struct fsl_xhci *fsl_xhci)
>> /* Change beat burst and outstanding pipelined transfers requests */
>> fsl_xhci_set_beat_burst_length(fsl_xhci->dwc3_reg);
>>
>> +/*
>> + * A-010151: USB controller to configure USB in P2 mode
>> + * whenever the Receive Detect feature is required
>> + */
>> +if (has_erratum_a010151())
>> +dwc3_set_rxdetect_power_mode(fsl_xhci->dwc3_reg,
>> + DWC3_GUSB3PIPECTL_DISRXDETP3);
>
>Can't you parse these errata infos from device tree ?
>
Currently, all the freescale Socs using this controller are not using DM.
Shall we proceed with this solution currently, and then when the DM is
supported by all Socs, modify the implementation according to device tree?
What do you suggest?
>> return ret;
>> }
>>
>> diff --git a/include/fsl_usb.h b/include/fsl_usb.h index
>> fc72fb9..73235b8 100644
>> --- a/include/fsl_usb.h
>> +++ b/include/fsl_usb.h
>> @@ -95,5 +95,6 @@ bool has_erratum_a007792(void); bool
>> has_erratum_a005697(void); bool has_erratum_a004477(void); bool
>> has_erratum_a008751(void);
>> +bool has_erratum_a010151(void);
>> #endif
>> #endif /*_ASM_FSL_USB_H_ */
>> diff --git a/include/linux/usb/dwc3.h b/include/linux/usb/dwc3.h index
>> 6d1e365..f68cdd2 100644
>> --- a/include/linux/usb/dwc3.h
>> +++ b/include/linux/usb/dwc3.h
>> @@ -184,6 +184,7 @@ struct dwc3 {/*
>> offset:
>0xC100 */
>>
>> /* Global USB3 PIPE Control Register */
>> #define DWC3_GUSB3PIPECTL_PHYSOFTRST(1 << 31)
>> +#define DWC3_GUSB3PIPECTL_DISRXDETP3(1 << 28)
>> #define DWC3_GUSB3PIPECTL_SUSPHY(1 << 17)
>>
>> /* Global TX Fifo Size Register */
>> @@ -205,5 +206,6 @@ void dwc3_set_mode(struct dwc3 *dwc3_reg, u32
>> mode); void dwc3_core_soft_
Re: [U-Boot] [PATCH 0/2] Add TOPIC Miami boards
Hi Mike, On 15.9.2016 08:02, Mike Looijmans wrote: > These patches add support for the Miami range of boards from TOPIC. > The boards are based on Xilinx Zynq SoCs, these two patches are for > the 7-series, the Ultrascale MPSOC boards are to be added later. > > Please note that the "ps7_init_gpl" files are largely generated by a > tool and as a result of that, contain many style issues. > > Mike Looijmans (2): > Add topic-miami board support > Add topic_miamiplus board > > arch/arm/dts/Makefile |2 + > arch/arm/dts/zynq-topic-miami.dts | 98 + > arch/arm/dts/zynq-topic-miamiplus.dts | 22 + > board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c | 4324 +++ > board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h | 118 + > .../zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 4425 > > .../zynq/zynq-topic-miamiplus/ps7_init_gpl.h | 150 + > configs/topic_miami_defconfig | 47 + > configs/topic_miamiplus_defconfig | 47 + > include/configs/topic_miami.h | 147 + > include/configs/topic_miamiplus.h |2 + > 11 files changed, 9382 insertions(+) > create mode 100644 arch/arm/dts/zynq-topic-miami.dts > create mode 100644 arch/arm/dts/zynq-topic-miamiplus.dts > create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c > create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h > create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.c > create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.h > create mode 100644 configs/topic_miami_defconfig > create mode 100644 configs/topic_miamiplus_defconfig > create mode 100644 include/configs/topic_miami.h > create mode 100644 include/configs/topic_miamiplus.h > It is a question if this should go to board/xilinx folder. I think you should create own folder just for your company. Probably doesn't make sense to copy all Makefiles and so but I think you can source them from Xilinx folder to be only at one location. The next thing is that there needs to be additional steps to fix ps7_init_gpl.* files to keep checkpatch happy. I have created change request to fix this directly in tools but still none has fixed it and the team which is responsible for it is keep moving to the next release but I can do nothing with it. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
