March 2015 - U-Boot

[U-Boot] davinci: LCDK board
by Peter Howard 12 Mar '15

12 Mar '15

I have a build of u-boot for the TI LCDK (the successor to the Hawkboard). It is based on: * The LCDK code TI supplied against 2012.04.01 * The now-departed Hawkboard build in mainline prior to 2015.04 * The current da850evm build. It is built against the generic board framework. It works well enough for me the way I want to use it (conversion post-build with a TI utility for flashing into NAND), but I haven't tried any of the other options yet (e.g. booting off SD). I'd like to get it into mainline; my question is what is the best way from where I am? Just post the patch as it is to the list? Find someone else to play with off list (any volunteers?). Go through more of the target options first? Thanks, -- Peter Howard <pjh(a)northern-ridge.com.au>

1 0

Re: [U-Boot] Regression in bootcmd handling in v2015.04-rc3?
by Stephen Warren 11 Mar '15

11 Mar '15

On 03/11/2015 03:21 PM, Karsten Merker wrote: > On Wed, Mar 11, 2015 at 02:31:07PM -0600, Stephen Warren wrote: > >> For manual booting, I would expect to always run the device-specific >> command (e.g. bootcmd_usb0 or bootcmd_mmc1) rather than the >> device-type-specific command (e.g. usb_boot, mmc_boot). >> >> I'm not sure how the type-generic commands ever worked without >> variables such as ${devnum} set, since they all pass ${devnum} to a >> variety of commands in addition to the new "part list". Perhaps >> those commands default to devnum==0 if the parameter is missing, and >> you never wanted to boot e.g. from mmc 1 instead of mmc 0? > > Yes, indeed - my boards only have a single instance of all devices. > > I have just tried to "single-step" through the bootcmd framework > in u-boot 2014.10 (which is what Debian 8 will release with and > where "run usb_boot" works). All commands used there work when > ${devnum} is empty and then default to 0, while the later-added > "part list" fails without an explictly set ${devnum}. > > As a result I will need to update the Debian installation > documentation. As I would like to do it right this time ;-), I > just would like to get the confirmation that the device-specific > commands, such as "run bootcmd_usb0", are an "official" interface > that is going to stay in future u-boot versions, or - if they are > not - get the information what is the offical method for booting > from a specific device at the prompt. We don't actually have an official specification of that at present. doc/README.distro should probably cover this but doesn't. Suffice to say, I use those macros all the time, and I intended them to be used this way when I wrote the boot scripts. So, if I notice a change that stops them from working without extremely good reason, I'll complain.

1 0

Re: [U-Boot] Regression in bootcmd handling in v2015.04-rc3? (was: [ANN] U-Boot v2015.04-rc3 released)
by Tom Rini 11 Mar '15

11 Mar '15

On Wed, Mar 11, 2015 at 09:20:46PM +0100, Karsten Merker wrote: > On Wed, Mar 04, 2015 at 08:53:37PM +0100, Karsten Merker wrote: > > On Tue, Mar 03, 2015 at 06:31:37PM -0500, Tom Rini wrote: > > > > > I've pushed v2015.04-rc3 out to the repository and tarballs should exist > > > soon. > > [...] > > > As always, if anything is broken please speak up. > > > > Hello, > > > > I have tested v2015.04-rc3 and have stumbled over a problem with the > > distro_bootcmd framework when trying to boot from a specific device > > at the u-boot command prompt by using "run <device>_boot". > > Autobooting without user interruption of the boot process works fine: > > > > U-Boot SPL 2015.04-rc3 (Mar 04 2015 - 19:43:43) > > DRAM: 1024 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 > > > > > > U-Boot 2015.04-rc3 (Mar 04 2015 - 19:43:43) Allwinner Technology > > > > CPU: Allwinner A20 (SUN7I) > > I2C: ready > > DRAM: 1 GiB > > MMC: SUNXI SD/MMC: 0 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > Err: serial > > SCSI: SUNXI SCSI INIT > > SATA link 0 timeout. > > AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode > > flags: ncq stag pm led clo only pmp pio slum part ccc apst > > Net: dwmac.1c50000 > > starting USB... > > USB0: USB EHCI 1.00 > > scanning bus 0 for devices... 2 USB Device(s) found > > USB1: USB EHCI 1.00 > > scanning bus 1 for devices... 1 USB Device(s) found > > scanning usb for storage devices... 1 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > switch to partitions #0, OK > > mmc0 is current device > > scanning bus for devices... > > Found 0 device(s). > > > > SCSI device 0: > > Device 0: not available > > > > USB device 0: > > Device 0: Vendor: Intenso Rev: Prod: Rainbow > > Type: Removable Hard Disk > > Capacity: 7620.0 MB = 7.4 GB (15605760 x 512) > > ... is now current device > > Scanning usb 0:1... > > Found U-Boot script /boot.scr > > reading /boot.scr > > 1263 bytes read in 22 ms (55.7 KiB/s) > > ## Executing script at 43100000 > > [...] > > > > Interrupting the boot sequence and then manually executing e.g. "run > > usb_boot" results in a "** Bad device specification usb devplist **" > > error message: > > > > sunxi# run usb_boot > > > > USB device 0: Vendor: Intenso Rev: Prod: Rainbow > > Type: Removable Hard Disk > > Capacity: 7620.0 MB = 7.4 GB (15605760 x 512) > > ** Bad device specification usb devplist ** > > sunxi# > > > > The reason for this is that in this constellation ${devnum} is > > undefined, which leads to a failure of the "part list ${devtype} > > ${devnum} devplist" command in ${scan_dev_for_boot_part}. Older > > versions of u-boot did not use the part list command, so this problem > > did not occur there. Using "run bootcmd_usb0" instead of "run > > usb_boot" works, but my understanding (which may of course be wrong) > > was that the user is expected to use "run <device>_boot" for booting > > from a specific device at the u-boot command prompt, and that has > > worked without problems in previous u-boot versions. > > Hello, > > as my original email appears to have fallen through the cracks, > I'd like to ask again whether using "run <device>_boot" is > "officially" expected to work or not. If it is not, what is the > officially supported way for a user to boot from a certain device > at the u-boot prompt? Should people use "setenv boot_targets > foo; run bootcmd" instead? Can you git bisect down to the problem commit and then we can poke the authors and other folks with a strong opinion on the distro bootcmd bits? Thanks again! -- Tom

1 0

Re: [U-Boot] Regression in bootcmd handling in v2015.04-rc3?
by Stephen Warren 11 Mar '15

11 Mar '15

On 03/11/2015 02:20 PM, Karsten Merker wrote: > On Wed, Mar 04, 2015 at 08:53:37PM +0100, Karsten Merker wrote: >> On Tue, Mar 03, 2015 at 06:31:37PM -0500, Tom Rini wrote: >> >>> I've pushed v2015.04-rc3 out to the repository and tarballs should exist >>> soon. >> [...] >>> As always, if anything is broken please speak up. >> >> Hello, >> >> I have tested v2015.04-rc3 and have stumbled over a problem with the >> distro_bootcmd framework when trying to boot from a specific device >> at the u-boot command prompt by using "run <device>_boot". >> Autobooting without user interruption of the boot process works fine: ... >> Interrupting the boot sequence and then manually executing e.g. "run >> usb_boot" results in a "** Bad device specification usb devplist **" >> error message: >> >> sunxi# run usb_boot >> >> USB device 0: Vendor: Intenso Rev: Prod: Rainbow >> Type: Removable Hard Disk >> Capacity: 7620.0 MB = 7.4 GB (15605760 x 512) >> ** Bad device specification usb devplist ** >> sunxi# >> >> The reason for this is that in this constellation ${devnum} is >> undefined, which leads to a failure of the "part list ${devtype} >> ${devnum} devplist" command in ${scan_dev_for_boot_part}. Older >> versions of u-boot did not use the part list command, so this problem >> did not occur there. Using "run bootcmd_usb0" instead of "run >> usb_boot" works, but my understanding (which may of course be wrong) >> was that the user is expected to use "run <device>_boot" for booting >> from a specific device at the u-boot command prompt, and that has >> worked without problems in previous u-boot versions. > > Hello, > > as my original email appears to have fallen through the cracks, > I'd like to ask again whether using "run <device>_boot" is > "officially" expected to work or not. If it is not, what is the > officially supported way for a user to boot from a certain device > at the u-boot prompt? Should people use "setenv boot_targets > foo; run bootcmd" instead? Sorry, I didn't see the original email. For manual booting, I would expect to always run the device-specific command (e.g. bootcmd_usb0 or bootcmd_mmc1) rather than the device-type-specific command (e.g. usb_boot, mmc_boot). I'm not sure how the type-generic commands ever worked without variables such as ${devnum} set, since they all pass ${devnum} to a variety of commands in addition to the new "part list". Perhaps those commands default to devnum==0 if the parameter is missing, and you never wanted to boot e.g. from mmc 1 instead of mmc 0?

1 0

[U-Boot] [PATCH RESEND] tegra: Remove tegra_spl_gpio_direction_output declaration from header file
by Axel Lin 11 Mar '15

11 Mar '15

This function is deleted by commit 2fccd2d96bad "tegra: Convert tegra GPIO driver to use driver model". Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- I forgot adding Tom Warren in CC in my previous mail. So here is a resend. arch/arm/include/asm/arch-tegra/gpio.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/arch/arm/include/asm/arch-tegra/gpio.h b/arch/arm/include/asm/arch-tegra/gpio.h index 7334e0c..daf5698 100644 --- a/arch/arm/include/asm/arch-tegra/gpio.h +++ b/arch/arm/include/asm/arch-tegra/gpio.h @@ -28,15 +28,6 @@ struct tegra_gpio_config { }; /** - * tegra_spl_gpio_direction_output() - set the output value of a GPIO - * - * This function is only used from SPL on seaboard, which needs to enable a - * GPIO to get the UART running. It could be done in U-Boot rather than SPL, - * but for now, this gets it working - */ -int tegra_spl_gpio_direction_output(int gpio, int value); - -/** * Configure a list of GPIOs * * @param config List of GPIO configurations -- 1.9.1

2 1

Re: [U-Boot] Please pull u-boot-tegra.git/master
by Tom Warren 11 Mar '15

11 Mar '15

Albert – are you getting these emails? I know they’re bouncing from the list (need to find a mailer that doesn’t use MIME64), but I haven’t heard back from you for the last 2 PRs. Should I send these to Tom Rini instead? Please let me know. Tom From: Tom Warren [mailto:tomcwarren3959@gmail.com] Sent: Thursday, March 05, 2015 4:27 PM To: Albert ARIBAUD Cc: u-boot(a)lists.denx.de; Marcel Ziswiler; Stephen Warren; Tom Warren Subject: Please pull u-boot-tegra.git/master Albert, Please pull u-boot-tegra.git/master into ARM master. ./MAKEALL -s tegra is clean. Stephen confirmed that Jetson-TK1 looks OK. NOTE: This PR includes some of Stephen's patches from a previous PR that never went in AFAICT (Sent Feb 3rd). I'm sending this from my Gmail account since my work Outlook always bounces from the list due to base64 MIME errors. The following changes since commit 02251eefc95c477f4ff6aa7568dfd4be7c69c31f: ARM: HYP/non-sec: relocation before enable secondary cores (2015-03-01 16:33:21 +0100) are available in the git repository at: git://git.denx.de/u-boot-tegra.git<http://git.denx.de/u-boot-tegra.git> master for you to fetch changes up to d5338c693e6a35a7108c184839d688a7377d117c: apalis/colibri_t30: add misc cmds increase buf sizes and max args (2015-03-04 10:09:02 -0700) ---------------------------------------------------------------- Marcel Ziswiler (4): dm: tegra: dts: add aliases for spi on apalis_t30 apalis/colibri_t30: fix MMC/SD card detect GPIOs apalis_t30: enable gigabit ethernet via pcie apalis/colibri_t30: add misc cmds increase buf sizes and max args Stephen Warren (16): common: board: support systems with where RAM ends beyond 4GB ARM: tegra: fix variable naming in query_sdram_size() ARM: tegra: support large RAM sizes ARM: tegra: move common config defines centrally ARM: tegra: support running in non-secure mode ARM: tegra: add function to clear pinmux CLAMPING bit ARM: tegra: import latest Jetson TK1 pinmux ARM: tegra: pinmux: add note re: drive group field defines ARM: tegra: pinmux: simplify some defines ARM: tegra: pinmux: handle feature removal on newer SoCs ARM: tegra: pinmux: move some type definitions ARM: tegra: pinmux: partially handle varying register layouts ARM: tegra: pinmux: support hsm/schmitt on pins ARM: tegra: pinmux: account for different drivegroup base registers ARM: tegra: pinmux: support Tegra210's e_io_hv pin option ARM: tegra: pinmux: add Tegra210 support README | 7 + arch/arm/cpu/tegra210-common/pinmux.c | 195 ++++++++++ arch/arm/dts/tegra30-apalis.dts | 13 +- arch/arm/dts/tegra30-colibri.dts | 4 +- arch/arm/include/asm/arch-tegra/ap.h | 4 + arch/arm/include/asm/arch-tegra/pinmux.h | 110 ++++-- arch/arm/include/asm/arch-tegra114/pinmux.h | 14 +- arch/arm/include/asm/arch-tegra124/pinmux.h | 14 +- arch/arm/include/asm/arch-tegra20/pinmux.h | 1 + arch/arm/include/asm/arch-tegra210/pinmux.h | 416 +++++++++++++++++++++ arch/arm/include/asm/arch-tegra30/pinmux.h | 11 +- arch/arm/mach-tegra/board.c | 56 ++- arch/arm/mach-tegra/clock.c | 6 +- arch/arm/mach-tegra/pinmux-common.c | 223 +++++++++-- board/nvidia/common/board.c | 9 + board/nvidia/jetson-tk1/jetson-tk1.c | 2 +- board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 303 +++++++-------- common/board_f.c | 12 + include/configs/apalis_t30.h | 31 +- include/configs/beaver.h | 2 - include/configs/cardhu.h | 2 - include/configs/colibri_t20_iris.h | 2 - include/configs/colibri_t30.h | 26 +- include/configs/dalmore.h | 2 - include/configs/harmony.h | 3 - include/configs/jetson-tk1.h | 2 - include/configs/medcom-wide.h | 3 - include/configs/nyan-big.h | 2 - include/configs/paz00.h | 3 - include/configs/plutux.h | 3 - include/configs/seaboard.h | 3 - include/configs/tec-ng.h | 2 - include/configs/tec.h | 3 - include/configs/tegra-common.h | 2 + include/configs/trimslice.h | 2 - include/configs/venice2.h | 2 - include/configs/ventana.h | 3 - include/configs/whistler.h | 2 - 38 files changed, 1197 insertions(+), 303 deletions(-) create mode 100644 arch/arm/cpu/tegra210-common/pinmux.c create mode 100644 arch/arm/include/asm/arch-tegra210/pinmux.h ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

3 4

[U-Boot] [U-Boot PATCH 0/3] Add support for pcf8575
by Vignesh R 11 Mar '15

11 Mar '15

Hi, This adds driver for pcf8575 in uboot. The driver supports basic read and write operations on pcf gpio pins. The first patch adds the driver, second patch and third patch switches cpsw to use slave0 on DRA72 EVM. Tested pcf driver on DRA72 EVM by probing pcf lines and cpsw by runnning tftp. Vignesh R (3): gpio: pcf8575: Add pcf8575 driver to control gpio lines ARM: dra7xx_evm: Enable pcf driver ARM: DRA7-EVM: switch cpsw to use slave0 board/ti/dra7xx/evm.c | 13 ++- drivers/gpio/Makefile | 1 + drivers/gpio/pcf8575.c | 248 +++++++++++++++++++++++++++++++++++++++++++ include/configs/dra7xx_evm.h | 4 + include/pcf8575.h | 25 +++++ 5 files changed, 289 insertions(+), 2 deletions(-) create mode 100644 drivers/gpio/pcf8575.c create mode 100644 include/pcf8575.h -- 1.9.1

2 8

[U-Boot] [PATCH] arm: armada-xp: Fix SPL for AXP by using save_boot_params_ret
by Stefan Roese 11 Mar '15

11 Mar '15

Patch e11c6c27 (arm: Allow lr to be saved by board code) introduced a different method to return from save_boot_params(). The SPL support for AXP has been pulled and changing to this new method is now required for SPL to work correctly. Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Simon Glass <sjg(a)chromium.org> Cc: Luka Perkov <luka.perkov(a)sartura.hr> --- arch/arm/cpu/armv7/armada-xp/lowlevel_spl.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/armada-xp/lowlevel_spl.S b/arch/arm/cpu/armv7/armada-xp/lowlevel_spl.S index 1febd7b..6c5e544 100644 --- a/arch/arm/cpu/armv7/armada-xp/lowlevel_spl.S +++ b/arch/arm/cpu/armv7/armada-xp/lowlevel_spl.S @@ -7,7 +7,7 @@ #include <linux/linkage.h> ENTRY(save_boot_params) - bx lr + b save_boot_params_ret ENDPROC(save_boot_params) /* -- 2.3.2

2 1

Re: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue
by prabhakar＠freescale.com 11 Mar '15

11 Mar '15

Resending because some issue in my mail-box. Regards, Prabhakar -----Original Message----- From: Kushwaha Prabhakar-B32579 Sent: Wednesday, March 11, 2015 10:01 AM To: 'Zhao Qiang'; u-boot(a)lists.denx.de; Sun York-R58495 Subject: RE: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue Hi Zhao, Can you please rephrase the subject. No need to mention T2080QDS twice in the subject > -----Original Message----- > From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Zhao > Qiang > Sent: Tuesday, March 10, 2015 2:55 PM > To: u-boot(a)lists.denx.de; Sun York-R58495 > Cc: Zhao Qiang-B45475 > Subject: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS > for down-training issue > > T2080QDS PEX1/Slot#1 will down-train from x4 to x2, with SRDS_PRTCL_S1 > = > 0x66 and SRDS_PRTCL_S2 = 0x15. > Soft reset PCIe can fix this issue, this is a workaround. > Can you please rephrase the description. is this issue only occur with mentioned protocol or other SerDes protocol has not been tested? > Signed-off-by: Zhao Qiang <B45475(a)freescale.com> > --- > drivers/pci/fsl_pci_init.c | 17 +++++++++++++++++ > include/configs/T208xQDS.h > | 1 + > 2 files changed, 18 insertions(+) > > diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c > index 231b075..327fa7d 100644 > --- a/drivers/pci/fsl_pci_init.c > +++ b/drivers/pci/fsl_pci_init.c > @@ -481,6 +481,23 @@ void fsl_pci_init(struct pci_controller *hose, > struct fsl_pci_info *pci_info) #endif > } > > +#ifdef CONFIG_FSL_PCIE_T2080QDS_RESET > + int i; > + /* assert PCIe reset */ > + setbits_be32(&pci->pdb_stat, 0x08000000); > + (void) in_be32(&pci->pdb_stat); > + udelay(1000); > + /* clear PCIe reset */ > + clrbits_be32(&pci->pdb_stat, 0x08000000); > + asm("sync;isync"); > + for (i = 0; i < 100 && ltssm < PCI_LTSSM_L0; i++) { > + pci_hose_read_config_word(hose, dev, PCI_LTSSM, > + &ltssm); > + udelay(1000); > + } > + > +#endif > + > #ifdef CONFIG_SYS_P4080_ERRATUM_PCIE_A003 > if (enabled == 0) { > serdes_corenet_t *srds_regs = (void > *)CONFIG_SYS_FSL_CORENET_SERDES_ADDR; > diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h > index > 395472b..851b4f9 100644 > --- a/include/configs/T208xQDS.h > +++ b/include/configs/T208xQDS.h > @@ -558,6 +558,7 @@ unsigned long get_board_ddr_clk(void); > #define CONFIG_PCIE2 /* PCIE controler 2 */ > #define CONFIG_PCIE3 /* PCIE controler 3 */ > #define CONFIG_PCIE4 /* PCIE controler 4 */ > +#define CONFIG_FSL_PCIE_T2080QDS_RESET As your patch is reseting PCIe independent of SerDes Protocols What about defining CONFIG_FSL_PCIE_RESET Regards, Prabhakar

1 0

[U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue
by Zhao Qiang 11 Mar '15

11 Mar '15

T2080QDS PEX1/Slot#1 will down-train from x4 to x2, with SRDS_PRTCL_S1 = 0x66 and SRDS_PRTCL_S2 = 0x15. Soft reset PCIe can fix this issue, this is a workaround. Signed-off-by: Zhao Qiang <B45475(a)freescale.com> --- drivers/pci/fsl_pci_init.c | 17 +++++++++++++++++ include/configs/T208xQDS.h | 1 + 2 files changed, 18 insertions(+) diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c index 231b075..327fa7d 100644 --- a/drivers/pci/fsl_pci_init.c +++ b/drivers/pci/fsl_pci_init.c @@ -481,6 +481,23 @@ void fsl_pci_init(struct pci_controller *hose, struct fsl_pci_info *pci_info) #endif } +#ifdef CONFIG_FSL_PCIE_T2080QDS_RESET + int i; + /* assert PCIe reset */ + setbits_be32(&pci->pdb_stat, 0x08000000); + (void) in_be32(&pci->pdb_stat); + udelay(1000); + /* clear PCIe reset */ + clrbits_be32(&pci->pdb_stat, 0x08000000); + asm("sync;isync"); + for (i = 0; i < 100 && ltssm < PCI_LTSSM_L0; i++) { + pci_hose_read_config_word(hose, dev, PCI_LTSSM, + &ltssm); + udelay(1000); + } + +#endif + #ifdef CONFIG_SYS_P4080_ERRATUM_PCIE_A003 if (enabled == 0) { serdes_corenet_t *srds_regs = (void *)CONFIG_SYS_FSL_CORENET_SERDES_ADDR; diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h index 395472b..851b4f9 100644 --- a/include/configs/T208xQDS.h +++ b/include/configs/T208xQDS.h @@ -558,6 +558,7 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_PCIE2 /* PCIE controler 2 */ #define CONFIG_PCIE3 /* PCIE controler 3 */ #define CONFIG_PCIE4 /* PCIE controler 4 */ +#define CONFIG_FSL_PCIE_T2080QDS_RESET #define CONFIG_FSL_PCI_INIT /* Use common FSL init code */ #define CONFIG_SYS_PCI_64BIT /* enable 64-bit PCI resources */ /* controller 1, direct to uli, tgtid 3, Base address 20000 */ -- 2.1.0.27.g96db324

2 2