Re: [U-Boot] Testing u-boot-dm/next
Hi Simon, On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass s...@chromium.org wrote: (Correcting address for Masahiro, sorry) On 8 April 2015 at 21:07, Simon Glass s...@chromium.org wrote: Hi, I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options. If anyone has time and can give it a spin on their board, it would be much appreciated! Regards, Simon I've tested it on CrownBay board and found one issue: During the boot up, or typing 'sf probe' in the U-Boot shell, it reports: Invalid bus 0 (err=-19) I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's
Hello,
On 15-04-09 18:09:46, Marek Vasut wrote:
On Tuesday, April 07, 2015 at 09:03:45 AM, maitysancha...@gmail.com wrote:
Hello,
On 15-04-01 21:15:21, Marek Vasut wrote:
On Wednesday, April 01, 2015 at 11:54:22 AM, Sanchayan Maity wrote:
The commit message is missing, please fix in v2.
Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
[...]
+#define USB_NC_REG_OFFSET 0x0800
+#define USBCx_CTRL_OFFSET 0x
+#define USBCx_PHY_CTRL_OFFSET 0x0018
Please define the register offsets using the regular struct {} method,
see for example struct mxs_usbphy_regs and it's usage in ehci-mxs.c .
I had a query here, just to be sure and avoid rework. The vybrid defines
would be similar to mxs. I assume I can add them to the regs-common.h
file along with a note that the VF610 also has the same _set, _clr,
_tog register? Or perhaps it would be more appropriate to have the file
have generic names which mxs, vf and imx can all leverage? Though for
now this would require reworking all the three drivers.
The USB phy definitions part is ok, as they would go in the arch
specific folder.
If these are really IMX/MXS/VF specific, then the defines should go into
arch/arm/include/asm/imx-common/ . Otherwise, you can make chipidea specific
file in include/usb/ .
Not really much VF specific. I was not sure about using the mxs_ prefix
accessors for VF as well. In the end I found usage in one iMX6 file and
decided that it makes better sense to actually use the mxs_ existing
defines. They can be used for Vybrid as well. Except for the non core
regsiters and a few others no other difference.
I send a v2 version of the patchset based taking your suggestion into
account. The driver looks cleaner in comparison to the previous :)
IMHO. Thanks.
https://www.mail-archive.com/u-boot@lists.denx.de/msg168727.html
- Sanchayan.
+#define USBPHY_CTRL
0x0030
+#define USBPHY_CTRL_SET
0x0034
+#define USBPHY_CTRL_CLR
0x0038
+#define USBPHY_CTRL_TOG
0x003c
+
+#define USBPHY_PWD
0x
+#define USBPHY_TX
0x0010
+#define USBPHY_RX
0x0020
+#define USBPHY_DEBUG 0x0050
+#define USBPHY_CTRL_SFTRST 0x8000
+#define USBPHY_CTRL_CLKGATE0x4000
+#define USBPHY_CTRL_ENUTMILEVEL3 0x8000
+#define USBPHY_CTRL_ENUTMILEVEL2 0x4000
+#define USBPHY_CTRL_OTG_ID 0x0800
+
+#define ANADIG_PLL_CTRL_BYPASS 0x0001
+#define ANADIG_PLL_CTRL_ENABLE 0x2000
+#define ANADIG_PLL_CTRL_POWER 0x1000
+#define ANADIG_PLL_CTRL_EN_USB_CLKS0x0040
+
+#define UCTRL_OVER_CUR_POL (1 8) /* OTG Polarity of Overcurrent
*/
+#define UCTRL_OVER_CUR_DIS (1 7) /* Disable OTG Overcurrent
Detection */ +
+/* USBCMD */
+#define UCMD_RUN_STOP (1 0) /* controller run/stop */
+#define UCMD_RESET (1 1) /* controller reset */
This looks very much like the USB PHY used on MX28 , can you double-check
this please ?
MX28 IP also seems similar to the Vybrid USB IP except for a few
registers and the non core registers. Perhaps to be expected as they all
have a common chipidea IP core, though having a different version
thereof.
Yep, I agree :)
Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] ARM: remove non-generic boards.
Hi Masahiro, On Wed, Apr 8, 2015 at 10:15 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: In spite of several times alerts, there are still many boards left unconverted. This series removes some of non-generic (=unmaitained) boards. If there is a problem with this series, please speak up! Masahiro Yamada (3): ARM: at91: remove non-generic boards ARM: davinci: remove non-generic boards ARM: omap3: remove non-generic boards arch/arm/cpu/armv7/omap3/Kconfig | 21 - arch/arm/mach-at91/Kconfig | 15 - arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c |2 +- arch/arm/mach-davinci/Kconfig | 37 - arch/arm/mach-davinci/Makefile |5 - arch/arm/mach-davinci/cpu.c| 54 - arch/arm/mach-davinci/dm355.c | 30 - arch/arm/mach-davinci/dm365.c | 20 - arch/arm/mach-davinci/dm365_lowlevel.c | 460 I have a DM365 evm I can take care of it, so no need to drop it. arch/arm/mach-davinci/dm644x.c | 81 -- arch/arm/mach-davinci/dm646x.c | 26 - arch/arm/mach-davinci/include/mach/aintc_defs.h| 36 - arch/arm/mach-davinci/include/mach/emac_defs.h | 25 +- arch/arm/mach-davinci/include/mach/gpio.h |5 +- arch/arm/mach-davinci/include/mach/hardware.h | 61 -- arch/arm/mach-davinci/include/mach/psc_defs.h | 70 -- arch/arm/mach-davinci/include/mach/syscfg_defs.h | 50 - arch/arm/mach-davinci/lowlevel_init.S | 664 arch/arm/mach-davinci/psc.c| 63 -- Removing this will cause build failures for da850. Cheers, --Prabhakar Lad ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fdt: add new fdt_fixup_display function to configure display
On Thu, Apr 9, 2015 at 10:56 AM, Simon Glass s...@chromium.org wrote: Acked-by: Simon Glass s...@chromium.org Is that binding file already in U-Boot? Simon, No - I don't think it is. I see now that there is a doc/device-tree-bindings/ dir in U-Boot. Is this for bindings that U-Boot itself 'uses' as far as using a device-tree U-Boot or just that U-Boot supports for fixups when booting Linux in ways like I'm doing with this patch? Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: zynq: add default ps7_init_gpl.c/h for Zed, MicroZed, ZC70x
Hi Masahiro,
On 04/09/2015 12:04 PM, Masahiro Yamada wrote:
Due to licensing issues, the files ps7_init.c/h are not able to be
distributed with U-Boot source code. Recent Xilinx tools also
provide the GPL version (ps7_init_gpl.c/h), compatible with U-Boot
license.
Prior to this commit, we had to copy ps7_init code into
board/xilinx/zynq/ before the compile.
To be more user-friendly, let's include ps7_init_gpl.c/h for
Zedboard, MicroZed, ZC702, ZC706.
These init code have been taken from the hwplatform_templates
directory of Xilinx SDK 2014.4.
You can still use customized ps7_init code by enabling
CONFIG_ZYNQ_CUSTOM_INIT.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
arch/arm/cpu/armv7/zynq/Kconfig|10 +
board/xilinx/zynq/Makefile |22 +-
.../zynq/MicroZed_hw_platform/ps7_init_gpl.c | 12978 ++
.../zynq/MicroZed_hw_platform/ps7_init_gpl.h | 130 +
board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.c | 13311
+++
board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.h | 130 +
board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.c | 13218 ++
board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.h | 130 +
.../zynq/{ = custom_hw_platform}/.gitignore | 0
.../xilinx/zynq/{ = custom_hw_platform}/legacy.c | 0
board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.c | 12876 ++
board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.h | 130 +
12 files changed, 52931 insertions(+), 4 deletions(-)
create mode 100644 board/xilinx/zynq/MicroZed_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/MicroZed_hw_platform/ps7_init_gpl.h
create mode 100644 board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.h
create mode 100644 board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.h
rename board/xilinx/zynq/{ = custom_hw_platform}/.gitignore (100%)
rename board/xilinx/zynq/{ = custom_hw_platform}/legacy.c (100%)
create mode 100644 board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.h
We can add files for zybo and zc770 that's not a problem.
But I would like to wait for others what they think about it.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's
On Tuesday, April 07, 2015 at 09:03:45 AM, maitysancha...@gmail.com wrote:
Hello,
On 15-04-01 21:15:21, Marek Vasut wrote:
On Wednesday, April 01, 2015 at 11:54:22 AM, Sanchayan Maity wrote:
The commit message is missing, please fix in v2.
Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
[...]
+#define USB_NC_REG_OFFSET0x0800
+#define USBCx_CTRL_OFFSET0x
+#define USBCx_PHY_CTRL_OFFSET0x0018
Please define the register offsets using the regular struct {} method,
see for example struct mxs_usbphy_regs and it's usage in ehci-mxs.c .
I had a query here, just to be sure and avoid rework. The vybrid defines
would be similar to mxs. I assume I can add them to the regs-common.h
file along with a note that the VF610 also has the same _set, _clr,
_tog register? Or perhaps it would be more appropriate to have the file
have generic names which mxs, vf and imx can all leverage? Though for
now this would require reworking all the three drivers.
The USB phy definitions part is ok, as they would go in the arch
specific folder.
If these are really IMX/MXS/VF specific, then the defines should go into
arch/arm/include/asm/imx-common/ . Otherwise, you can make chipidea specific
file in include/usb/ .
+#define USBPHY_CTRL
0x0030
+#define USBPHY_CTRL_SET 0x0034
+#define USBPHY_CTRL_CLR 0x0038
+#define USBPHY_CTRL_TOG 0x003c
+
+#define USBPHY_PWD
0x
+#define USBPHY_TX
0x0010
+#define USBPHY_RX
0x0020
+#define USBPHY_DEBUG 0x0050
+#define USBPHY_CTRL_SFTRST 0x8000
+#define USBPHY_CTRL_CLKGATE 0x4000
+#define USBPHY_CTRL_ENUTMILEVEL3 0x8000
+#define USBPHY_CTRL_ENUTMILEVEL2 0x4000
+#define USBPHY_CTRL_OTG_ID 0x0800
+
+#define ANADIG_PLL_CTRL_BYPASS 0x0001
+#define ANADIG_PLL_CTRL_ENABLE 0x2000
+#define ANADIG_PLL_CTRL_POWER0x1000
+#define ANADIG_PLL_CTRL_EN_USB_CLKS 0x0040
+
+#define UCTRL_OVER_CUR_POL (1 8) /* OTG Polarity of Overcurrent
*/
+#define UCTRL_OVER_CUR_DIS (1 7) /* Disable OTG Overcurrent
Detection */ +
+/* USBCMD */
+#define UCMD_RUN_STOP(1 0) /* controller run/stop */
+#define UCMD_RESET (1 1) /* controller reset */
This looks very much like the USB PHY used on MX28 , can you double-check
this please ?
MX28 IP also seems similar to the Vybrid USB IP except for a few
registers and the non core registers. Perhaps to be expected as they all
have a common chipidea IP core, though having a different version
thereof.
Yep, I agree :)
Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Request for tutorial
On Thu, Apr 09, 2015 at 06:20:37PM +0200, drEagle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, Is there any tutorial to help integrating a new platform into mainline u-boot ? I may propose a new board upsream but the only information I have are an older refork uboot. Any advice will be welcome. No, but it depends on both how old the old fork is and what does / doesn't exist upstream already. If for example the SoC core already exists in mainline, mainly use the old code base to move the board specific part up. If the SoC isn't there in mainline, you can probably drop-in the old code base easily enough and get it building / linking, and then clean it up. But it really depends on just how old the fork is. -- 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 v5 1/2] ARM: mx5: move to a standard arch/board approach
On 08/04/2015 18:56, and...@inversepath.com wrote: From: Andrej Rosano and...@inversepath.com Move the MX5 based boards to arch/arm/cpu/armv7/mx5, following the commit: 89ebc82137bebb11a8191f8b9cbf08f2533ae8bc Signed-off-by: Andrej Rosano and...@inversepath.com Cc: Stefano Babic sba...@denx.de Cc: Vagrant Cascadian vagr...@debian.org --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Request for tutorial
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, Is there any tutorial to help integrating a new platform into mainline u-boot ? I may propose a new board upsream but the only information I have are an older refork uboot. Any advice will be welcome. Thanks ++GK -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVJqbVAAoJEIoWzNw2mnfMMQwH/1pZDYYeI1X2KYio9CiIjTgI vryijp0HP29Qt90/n1IMSTsPrE+HBLuMeatG29oKqmzSm4rAHK8O6M+zMDbeNrKF VIHGTv+YKNEf2kzOt8Zcutx3caY76tZmm/O3ccFA1E49ggw2Fr6+8E8x1xBL33/n OKMqZdie1/lNWW5oWuI2Rvlzh87WoFqgJl0DVh3rT+rja9+Jsm+k2EgFAY1uqT+r BQd3wMVUuYSDPGsNhr/BXUgEXHmUZJxHBxl9m72dLrqjzq0NSTl1CalmhAlstcON kXPjBpxdiTALhsPLuEa30xaRaoZcEq3PflC+YwJ3UxDpVsTiAfjYjK+NSWWVbCc= =z2V6 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot
Hi Tom, Michal, 2015-04-09 2:59 GMT+09:00 Michal Simek michal.si...@xilinx.com: On 04/08/2015 04:04 PM, Tom Rini wrote: On Wed, Apr 08, 2015 at 10:03:28AM +0200, Michal Simek wrote: On 04/08/2015 07:25 AM, Masahiro Yamada wrote: Since commit 326a682358c1 (malloc_f: enable SYS_MALLOC_F by default if DM is on), Zynq MMC boot hangs up after printing the following: U-Boot SPL 2015.04-rc5-00053-gadcc570 (Apr 08 2015 - 12:59:11) mmc boot reading system.dtb Prior to commit 326a682358c1, Zynq boards enabled CONFIG_DM, but not CONFIG_SYS_MALLOC_F. That commit forcibly turned on CONFIG_SYS_MALLOC_F. I have not figured out the root cause, but anyway it looks like CONFIG_SYS_MALLOC_F gave a bad impact on the Zynq MMC boot. We are planning to have the v2015.04 release in a few days. I know this is a defensive fixup, but what I can do now is to add # CONFIG_SYS_MALLOC_F is not set to every Zynq defconfig file to get back the original behavior. Tested on: - Zedboard - ZC706 board Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Cc: Michal Simek michal.si...@xilinx.com Cc: Simon Glass s...@chromium.org --- This problem is urgent! If we cannot find the better solution, please apply this patch by the v2015.04 release. ^^^ Tested-by: Michal Simek michal.si...@xilinx.com Tom: Can you please add it to your tree? Do you want to do a PR with this (or wait a bit for Simon and Masahiro to root-cause) and your maintainers update or should I just grab that directly too? Thanks! Please grab both patches directly to your tree. When Simon or Masahiro find out root cause then we can simple revert it. This seems to be the best strategy for now. I agree. -- 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] dm: core: remove type 'static' of function uclass_get_device_tail()
Hello Simon, On 04/09/2015 02:11 PM, Przemyslaw Marczak wrote: Uclass API provides a few functions for get/find the device. To provide a complete function set of uclass-internal functions, for use by the drivers, the function uclass_get_device_tail() should be non-static. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Simon Glass s...@chromium.org --- drivers/core/uclass.c| 2 +- include/dm/uclass-internal.h | 21 ++--- 2 files changed, 19 insertions(+), 4 deletions(-) This should be also added to the changes, for completeness. Best regards, -- Przemyslaw Marczak Samsung RD 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
Re: [U-Boot] [PATCH v2] fdt: add new fdt_fixup_display function to configure display
Hi Tim, On 8 April 2015 at 12:45, Tim Harvey thar...@gateworks.com wrote: Add 'fdt_fixup_display' function to fixup device-tree native-mode property of display-timings node to select timings for a specific display. This is useful if a device-tree has configurations for multiple display timings for undetectable displays. see kernel Documentation/devicetree/bindings/video/display-timing.txt Signed-off-by: Tim Harvey thar...@gateworks.com --- v2: - use explicit error code - return fdt_setprop_u32 to all error checking by caller - add comments to function prototype - added more verbosity to commit log --- common/fdt_support.c | 29 + include/fdt_support.h | 13 + 2 files changed, 42 insertions(+) Acked-by: Simon Glass s...@chromium.org Is that binding file already in U-Boot? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: support Thumb-1 with CONFIG_SYS_THUMB_BUILD
Hi Albert, On 25.02.2015 23:09, Albert ARIBAUD wrote: On Tue, 24 Feb 2015 14:53:36 +0100, Albert ARIBAUD albert.u.b...@aribaud.net wrote: When building a THumb-1-only target with CONFIG_SYS_THUMB_BUILD, some files fail to build, most of the time because they include mcr instructions, which only exist for Thumb-2. Thos patch introduces a Kconfig option CONFIG_THUMB2 and uses it to select between Thumb-2 and ARM mode for the aforementioned files. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- This patch has been build-tested and run-tested on ED Mini V2, above the edmini: switch to SPL patch, and found to reduce U-Boot size by 25% and SPL size by 14%... and to run fine. :) This patch has also been tested against side effects on the non-Thumb wireless_space target. The binaries produced with and without ths patch were found to differ only by their version string. Changes in v2: - fixed a typo in the commit message - added file arch/arm/thumb1/include/asm/proc-armv/system.h, which overrides arch/arm/include/asm/proc-armv/system.h when building for Thumb-1 and provides non-functional but Thumb-compilable IRQ and FIQ related macros and functions. Ok, this does not fare as good as I have hoped, because there are also thumb1-unfrendly macros in arch/arm/include/asm/cache.h, this time with mcr and mrc instructions. /me hates macros used as inline functions. :( I cannot just replace the macros with empty inline functions as I did with arch/arm/include/asm/proc-armv/system.h, since this would cause cache to not work. :( This leaves only one solution: when buildding for thumb1, replace the macros in cache.h with plain function prototypes, and provide simple ARM-state implementations for these. We'll lose a bit of performance as instead of a single mcr or mrc instruction, we'll have a call switching from Thumb to ARM state, the mcr/mrc instruction, and a return to Thumb state. Hopefully that won't hurt performance too much. V3 in the works. Any update on this? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's
Hi Marek,
On Wed, Apr 1, 2015 at 4:15 PM, Marek Vasut ma...@denx.de wrote:
+#define USB_NC_REG_OFFSET0x0800
+#define USBCx_CTRL_OFFSET0x
+#define USBCx_PHY_CTRL_OFFSET0x0018
Please define the register offsets using the regular struct {} method,
see for example struct mxs_usbphy_regs and it's usage in ehci-mxs.c .
I thought we were trying to get rid of the 'no register access via
offset' rule in U-boot.
https://www.marc.info/?l=u-bootm=142609602127309w=2
Please see:
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARM: zynq: include ps7_init_gpl.c/h of Zed, MicroZed, ZC702, ZC706
Masahiro Yamada (2):
ARM: zynq: use separate configuration for ZC702 and ZC706
ARM: zynq: add default ps7_init_gpl.c/h for Zed, MicroZed, ZC70x
arch/arm/cpu/armv7/zynq/Kconfig|19 +-
board/xilinx/zynq/Makefile |22 +-
.../zynq/MicroZed_hw_platform/ps7_init_gpl.c | 12978 ++
.../zynq/MicroZed_hw_platform/ps7_init_gpl.h | 130 +
board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.c | 13311 +++
board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.h | 130 +
board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.c | 13218 ++
board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.h | 130 +
.../zynq/{ = custom_hw_platform}/.gitignore | 0
.../xilinx/zynq/{ = custom_hw_platform}/legacy.c | 0
board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.c | 12876 ++
board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.h | 130 +
.../{zynq_zc70x_defconfig = zynq_zc702_defconfig} | 2 +-
configs/zynq_zc706_defconfig |11 +
doc/README.zynq|15 +-
15 files changed, 52953 insertions(+), 19 deletions(-)
create mode 100644 board/xilinx/zynq/MicroZed_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/MicroZed_hw_platform/ps7_init_gpl.h
create mode 100644 board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/ZC702_hw_platform/ps7_init_gpl.h
create mode 100644 board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/ZC706_hw_platform/ps7_init_gpl.h
rename board/xilinx/zynq/{ = custom_hw_platform}/.gitignore (100%)
rename board/xilinx/zynq/{ = custom_hw_platform}/legacy.c (100%)
create mode 100644 board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.c
create mode 100644 board/xilinx/zynq/zed_hw_platform/ps7_init_gpl.h
rename configs/{zynq_zc70x_defconfig = zynq_zc702_defconfig} (88%)
create mode 100644 configs/zynq_zc706_defconfig
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: zynq: add default ps7_init_gpl.c/h for Zed, MicroZed, ZC70x
Hi Michal, 2015-04-09 19:40 GMT+09:00 Michal Simek michal.si...@xilinx.com: We can add files for zybo and zc770 that's not a problem. But I would like to wait for others what they think about it. I looked into SDK 2014.4 installation directory, but I could not find the files for zc770 and zybo. Comments are welcome, of course. We do not have to rush to apply this series. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: axs10x - support v3 mother-board
There're 2 versions of motherboards that could be used in ARC SDP.
The only important difference for U-Boot is different NAND IC in use:
[1] v2 board (we used to support up until now) sports MT29F4G08ABADAWP
while
[2] v3 board sports MT29F4G16ABADAWP
They are almost the same except data bus width 8-bit in [1] and 16-bit
in [2]. And for proper support of 16-bit data bus we have to pass
NAND_BUSWIDTH_16 option to NAND driver core - which we do now knowing
board type we're running on.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
---
board/synopsys/axs101/axs101.c | 14 ++
board/synopsys/axs101/axs10x.h | 16
board/synopsys/axs101/nand.c | 7 +++
include/configs/axs101.h | 6 ++
4 files changed, 43 insertions(+)
create mode 100644 board/synopsys/axs101/axs10x.h
diff --git a/board/synopsys/axs101/axs101.c b/board/synopsys/axs101/axs101.c
index 7742049..8c16410 100644
--- a/board/synopsys/axs101/axs101.c
+++ b/board/synopsys/axs101/axs101.c
@@ -9,6 +9,7 @@
#include malloc.h
#include netdev.h
#include phy.h
+#include axs10x.h
DECLARE_GLOBAL_DATA_PTR;
@@ -42,3 +43,16 @@ int board_eth_init(bd_t *bis)
return 0;
}
+
+
+#define AXS_MB_CREG0xE0011000
+
+int board_early_init_f(void)
+{
+ if (readl((void __iomem *)AXS_MB_CREG + 0x234) (1 28))
+ gd-board_type = AXS_MB_V3;
+ else
+ gd-board_type = AXS_MB_V2;
+
+ return 0;
+}
diff --git a/board/synopsys/axs101/axs10x.h b/board/synopsys/axs101/axs10x.h
new file mode 100644
index 000..8e8c41f
--- /dev/null
+++ b/board/synopsys/axs101/axs10x.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2015 Synopsys, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _BOARD_SYNOPSYS_AXS10X_H
+#define _BOARD_SYNOPSYS_AXS10X_H
+
+enum {
+ AXS_MB_V2,
+ AXS_MB_V3
+};
+
+#endif /* _BOARD_SYNOPSYS_AXS10X_H */
+
diff --git a/board/synopsys/axs101/nand.c b/board/synopsys/axs101/nand.c
index ff35286..4be52e2 100644
--- a/board/synopsys/axs101/nand.c
+++ b/board/synopsys/axs101/nand.c
@@ -9,6 +9,9 @@
#include malloc.h
#include nand.h
#include asm/io.h
+#include axs10x.h
+
+DECLARE_GLOBAL_DATA_PTR;
#define BUS_WIDTH 8 /* AXI data bus width in bytes */
@@ -232,5 +235,9 @@ int board_nand_init(struct nand_chip *nand)
nand-write_buf = axs101_nand_write_buf;
nand-read_buf = axs101_nand_read_buf;
+ /* MBv3 has NAND IC with 16-bit data bus */
+ if (gd-board_type == AXS_MB_V3)
+ nand-options |= NAND_BUSWIDTH_16;
+
return 0;
}
diff --git a/include/configs/axs101.h b/include/configs/axs101.h
index 5fb8aca..8a7095c 100644
--- a/include/configs/axs101.h
+++ b/include/configs/axs101.h
@@ -34,6 +34,12 @@
#define CONFIG_SYS_LOAD_ADDR 0x8200
/*
+ * This board might be of different versions so handle it
+ */
+#define CONFIG_BOARD_TYPES
+#define CONFIG_BOARD_EARLY_INIT_F
+
+/*
* NAND Flash configuration
*/
#define CONFIG_SYS_NO_FLASH
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/2] ARM: mx5: add support for USB armory board
On 08/04/2015 19:00, Andrej Rosano wrote: Hi Stefano, On Wed, Apr 08, 2015 at 10:53:02AM +0200, Stefano Babic wrote: On 01/04/2015 13:32, Stefano Babic wrote: Hi Chris, On 01/04/2015 04:46, Chris Kuethe wrote: Any chance of this being accepted into 2015.04? checpatch reports some issues by patch 2/2. Can you please fix them and resubmit ? Thanks ! Just resubmitted the v5 version. Thanks, it is ok, I merge it ! Regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Testing u-boot-dm/next
Hello Simon, On 04/09/2015 05:07 AM, Simon Glass wrote: Hi, I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options. If anyone has time and can give it a spin on their board, it would be much appreciated! Regards, Simon I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()? Best regards, -- Przemyslaw Marczak Samsung RD 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
Re: [U-Boot] [PATCH v2] ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot
On Wed, Apr 08, 2015 at 02:25:50PM +0900, Masahiro Yamada wrote: Since commit 326a682358c1 (malloc_f: enable SYS_MALLOC_F by default if DM is on), Zynq MMC boot hangs up after printing the following: U-Boot SPL 2015.04-rc5-00053-gadcc570 (Apr 08 2015 - 12:59:11) mmc boot reading system.dtb Prior to commit 326a682358c1, Zynq boards enabled CONFIG_DM, but not CONFIG_SYS_MALLOC_F. That commit forcibly turned on CONFIG_SYS_MALLOC_F. I have not figured out the root cause, but anyway it looks like CONFIG_SYS_MALLOC_F gave a bad impact on the Zynq MMC boot. We are planning to have the v2015.04 release in a few days. I know this is a defensive fixup, but what I can do now is to add # CONFIG_SYS_MALLOC_F is not set to every Zynq defconfig file to get back the original behavior. Tested on: - Zedboard - ZC706 board Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Cc: Michal Simek michal.si...@xilinx.com Cc: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: zynq: Remove Jagan from list of maintainers
On Wed, Apr 08, 2015 at 10:07:20AM +0200, Michal Simek wrote: Email address is not longer valid that's why remove it. Signed-off-by: Michal Simek michal.si...@xilinx.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/4] dm: test: Add tests for get/find uclass devices
Hello Simon,
On 04/09/2015 03:47 AM, Simon Glass wrote:
On 8 April 2015 at 11:06, Przemyslaw Marczak p.marc...@samsung.com wrote:
This commit introduces simple tests for functions:
- uclass_find_first_device()
- uclass_find_next_device()
- uclass_first_device()
- uclass_next_device()
Tests added by this commit:
- Test: dm_test_uclass_devices_find:
* call uclass_find_first_device(), then check if: (dev != NULL), (ret == 0)
* for the rest devices, call uclass_find_next_device() and do the same check
- Test: dm_test_uclass_devices_get:
* call uclass_first_device(), then check if:
-- (dev != NULL), (ret == 0), device_active()
* for the rest devices, call uclass_next_device() and do the same check
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
Changes V3:
- new commit
---
test/dm/core.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
Acked-by: Simon Glass s...@chromium.org
See below.
diff --git a/test/dm/core.c b/test/dm/core.c
index 009ad36..3a8dd1d 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -656,9 +656,41 @@ static int dm_test_uclass_before_ready(struct
dm_test_state *dms)
return 0;
}
-
DM_TEST(dm_test_uclass_before_ready, 0);
+static int dm_test_uclass_devices_find(struct dm_test_state *dms)
+{
+ struct udevice *dev;
+ int ret;
+
+ for (ret = uclass_find_first_device(UCLASS_TEST, dev);
+dev;
+ret = uclass_find_next_device(dev)) {
+ ut_assert(!ret);
+ ut_assert(dev);
ut_assert(!device_active(dev));
If you like I can add that when I apply.
I don't think it's a good idea. Those calls above, don't probe the
device, but also don't guarantee that, the returned device was not
probed, before the call.
+ }
+
+ return 0;
+}
+DM_TEST(dm_test_uclass_devices_find, DM_TESTF_SCAN_PDATA);
+
+static int dm_test_uclass_devices_get(struct dm_test_state *dms)
+{
+ struct udevice *dev;
+ int ret;
+
+ for (ret = uclass_first_device(UCLASS_TEST, dev);
+dev;
+ret = uclass_next_device(dev)) {
+ ut_assert(!ret);
+ ut_assert(dev);
+ ut_assert(device_active(dev));
+ }
+
+ return 0;
+}
+DM_TEST(dm_test_uclass_devices_get, DM_TESTF_SCAN_PDATA);
+
static int dm_test_device_get_uclass_id(struct dm_test_state *dms)
{
struct udevice *dev;
--
1.9.1
Regards,
Simon
Best regards,
--
Przemyslaw Marczak
Samsung RD 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 1/2] ARM: zynq: use separate configuration for ZC702 and ZC706
Separate CONFIG_TARGET_ZYNQ_{ZC702,ZC706} which is necessary
for the next commit. Adjust doc/README.zynq too.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
arch/arm/cpu/armv7/zynq/Kconfig| 9 ++---
configs/{zynq_zc70x_defconfig = zynq_zc702_defconfig} | 2 +-
configs/zynq_zc706_defconfig | 11 +++
doc/README.zynq| 15 ---
4 files changed, 22 insertions(+), 15 deletions(-)
rename configs/{zynq_zc70x_defconfig = zynq_zc702_defconfig} (88%)
create mode 100644 configs/zynq_zc706_defconfig
diff --git a/arch/arm/cpu/armv7/zynq/Kconfig b/arch/arm/cpu/armv7/zynq/Kconfig
index 3a52535..ab4768a 100644
--- a/arch/arm/cpu/armv7/zynq/Kconfig
+++ b/arch/arm/cpu/armv7/zynq/Kconfig
@@ -9,8 +9,11 @@ config TARGET_ZYNQ_ZED
config TARGET_ZYNQ_MICROZED
bool Zynq MicroZed
-config TARGET_ZYNQ_ZC70X
- bool Zynq ZC702/ZC706 Board
+config TARGET_ZYNQ_ZC702
+ bool Zynq ZC702 Board
+
+config TARGET_ZYNQ_ZC706
+ bool Zynq ZC706 Board
config TARGET_ZYNQ_ZC770
bool Zynq ZC770 Board
@@ -32,7 +35,7 @@ config SYS_SOC
config SYS_CONFIG_NAME
default zynq_zed if TARGET_ZYNQ_ZED
default zynq_microzed if TARGET_ZYNQ_MICROZED
- default zynq_zc70x if TARGET_ZYNQ_ZC70X
+ default zynq_zc70x if TARGET_ZYNQ_ZC702 || TARGET_ZYNQ_ZC706
default zynq_zc770 if TARGET_ZYNQ_ZC770
default zynq_zybo if TARGET_ZYNQ_ZYBO
diff --git a/configs/zynq_zc70x_defconfig b/configs/zynq_zc702_defconfig
similarity index 88%
rename from configs/zynq_zc70x_defconfig
rename to configs/zynq_zc702_defconfig
index 44f3ae0..93641cd 100644
--- a/configs/zynq_zc70x_defconfig
+++ b/configs/zynq_zc702_defconfig
@@ -1,7 +1,7 @@
CONFIG_SPL=y
CONFIG_ARM=y
CONFIG_ZYNQ=y
-CONFIG_TARGET_ZYNQ_ZC70X=y
+CONFIG_TARGET_ZYNQ_ZC702=y
CONFIG_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE=zynq-zc702
# CONFIG_SYS_MALLOC_F is not set
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
new file mode 100644
index 000..821bd82
--- /dev/null
+++ b/configs/zynq_zc706_defconfig
@@ -0,0 +1,11 @@
+CONFIG_SPL=y
+CONFIG_ARM=y
+CONFIG_ZYNQ=y
+CONFIG_TARGET_ZYNQ_ZC706=y
+CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE=zynq-zc706
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_DM=y
diff --git a/doc/README.zynq b/doc/README.zynq
index 043c970..b89c39e 100644
--- a/doc/README.zynq
+++ b/doc/README.zynq
@@ -17,9 +17,8 @@ Xilinx Zynq-7000 All Programmable SoCs enable extensive
system level
differentiation, integration, and flexibility through hardware, software,
and I/O programmability.
-* zc70x
- - zc702 (single qspi, gem0, mmc) [1]
- - zc706 (dual parallel qspi, gem0, mmc) [2]
+* zc702 (single qspi, gem0, mmc) [1]
+* zc706 (dual parallel qspi, gem0, mmc) [2]
* zed (single qspi, gem0, mmc) [3]
* microzed (single qspi, gem0, mmc) [4]
* zc770
@@ -30,16 +29,10 @@ and I/O programmability.
3. Building
- # Configure for zc70x board
- $ make zynq_zc70x_config
- Configuring for zynq_zc70x board...
-
- # Building default dts for zc702 board
+ ex. configure and build for zc702 board
+ $ make zynq_zc702_config
$ make
- # Building specified dts for zc706 board
- $ make DEVICE_TREE=zynq-zc706
-
4. Bootmode
Zynq has a facility to read the bootmode from the slcr bootmode register
--
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 3/7] m68k: remove arch/m68k/lib/board.c
Hi Angelo, 2015-04-09 4:20 GMT+09:00 Angelo Dureghello ang...@sysam.it: Hi Masahiro and all, On 25/03/2015 04:20, Masahiro Yamada wrote: Hi Angelo, 2015-03-17 15:55 GMT+09:00 Angelo Dureghello ang...@sysam.it: On 17/03/2015 04:35, Masahiro Yamada wrote: All the M68000 boards have switched to Generic Board. This file is no longer necessary. Hi Masahiro, thanks. Afaik, me and Alison converted and tested actually only 2 boards (adding #define CONFIG_SYS_GENERIC_BOARD inside /include/configs/...) Is this a problem ? Afaik, the user going to build the board will get a warning that he needs to switch to generic board. So the same user will be the tester that all works. Correct ? As a rule of generic board, people are supposed to do run-test and then send a patch. BTW, M68K is the last architecture that adopts per-board linker script. M68K should switch to per-soc linker scripts like the other architecures. It means all the followings should be merged into the single linker script arch/m68k/cpu/u-boot.lds. board/freescale/m52277evb/u-boot.lds board/freescale/m5235evb/u-boot.lds board/cobra5272/u-boot.lds board/BuS/eb_cpu5282/u-boot.lds board/freescale/m5208evbe/u-boot.lds board/freescale/m5249evb/u-boot.lds board/freescale/m5253demo/u-boot.lds board/freescale/m5272c3/u-boot.lds board/freescale/m5275evb/u-boot.lds board/freescale/m5282evb/u-boot.lds board/sysam/amcore/u-boot.lds board/astro/mcf5373l/u-boot.lds board/freescale/m53017evb/u-boot.lds board/freescale/m5329evb/u-boot.lds board/freescale/m5373evb/u-boot.lds board/freescale/m54418twr/u-boot.lds board/freescale/m54451evb/u-boot.lds board/freescale/m54455evb/u-boot.lds board/freescale/m547xevb/u-boot.lds board/freescale/m548xevb/u-boot.lds Is this possible for you? (or for someone else?) If there is no volunteer, it would be much easier to remove all the M68K boards except the two you and Alison can maintain. Maintain or Remove! so i posted a patch for a unified m68k arch-wide linker script. Could not be the best solution but it is a solution that works. https://patchwork.ozlabs.org/patch/455952/ Let me know your comments. Great cleanup! Thank you! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: core: remove type 'static' of function uclass_get_device_tail()
Uclass API provides a few functions for get/find the device.
To provide a complete function set of uclass-internal functions,
for use by the drivers, the function uclass_get_device_tail()
should be non-static.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
---
drivers/core/uclass.c| 2 +-
include/dm/uclass-internal.h | 21 ++---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 21ab0d5..fe78cbf 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -249,7 +249,7 @@ static int uclass_find_device_by_of_offset(enum uclass_id
id, int node,
* @devp: Returns the value of 'dev' if there is no error
* @return ret, if non-zero, else the result of the device_probe() call
*/
-static int uclass_get_device_tail(struct udevice *dev, int ret,
+int uclass_get_device_tail(struct udevice *dev, int ret,
struct udevice **devp)
{
if (ret)
diff --git a/include/dm/uclass-internal.h b/include/dm/uclass-internal.h
index befbae5..4d8b409 100644
--- a/include/dm/uclass-internal.h
+++ b/include/dm/uclass-internal.h
@@ -11,12 +11,25 @@
#define _DM_UCLASS_INTERNAL_H
/**
+ * uclass_get_device_tail() - handle the end of a get_device call
+ *
+ * This handles returning an error or probing a device as needed.
+ *
+ * @dev: Device that needs to be probed
+ * @ret: Error to return. If non-zero then the device is not probed
+ * @devp: Returns the value of 'dev' if there is no error
+ * @return ret, if non-zero, else the result of the device_probe() call
+ */
+int uclass_get_device_tail(struct udevice *dev, int ret, struct udevice
**devp);
+
+/**
* uclass_find_device() - Return n-th child of uclass
* @id:Id number of the uclass
* @index: Position of the child in uclass's list
* #devp: Returns pointer to device, or NULL on error
*
- * The device is not prepared for use - this is an internal function
+ * The device is not prepared for use - this is an internal function.
+ * The function uclass_get_device_tail() can be used to probe the device.
*
* @return the uclass pointer of a child at the given index or
* return NULL on error.
@@ -28,7 +41,8 @@ int uclass_find_device(enum uclass_id id, int index, struct
udevice **devp);
* @id:Id number of the uclass
* #devp: Returns pointer to device, or NULL on error
*
- * The device is not prepared for use - this is an internal function
+ * The device is not prepared for use - this is an internal function.
+ * The function uclass_get_device_tail() can be used to probe the device.
*
* @return 0 if OK (found or not found), -1 on error
*/
@@ -39,7 +53,8 @@ int uclass_find_first_device(enum uclass_id id, struct
udevice **devp);
* @devp: On entry, pointer to device to lookup. On exit, returns pointer
* to the next device in the same uclass, or NULL if none
*
- * The device is not prepared for use - this is an internal function
+ * The device is not prepared for use - this is an internal function.
+ * The function uclass_get_device_tail() can be used to probe the device.
*
* @return 0 if OK (found or not found), -1 on error
*/
--
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] fdt: add new fdt_fixup_display function to configure display
Hi Tim, On 9 April 2015 at 12:05, Tim Harvey thar...@gateworks.com wrote: On Thu, Apr 9, 2015 at 10:56 AM, Simon Glass s...@chromium.org wrote: Acked-by: Simon Glass s...@chromium.org Is that binding file already in U-Boot? Simon, No - I don't think it is. I see now that there is a doc/device-tree-bindings/ dir in U-Boot. Is this for bindings that U-Boot itself 'uses' as far as using a device-tree U-Boot or just that U-Boot supports for fixups when booting Linux in ways like I'm doing with this patch? The former, so actually I don't think we need to add it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/9] ARM: remove mx31ads board support
Hi Fabio, 2015-04-09 0:21 GMT+09:00 Fabio Estevam feste...@gmail.com: Hi Masahiro On Tue, Mar 17, 2015 at 3:07 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: BTW, is it possible to use the common linker script instead of board/freescale/mx31ads/u-boot.lds ? Yes, I think this is a good idea. Could you do it, please? I don't have access to a mx31ads board, so I can't work on it. OK. IIRC, we are supposed to do run-test just in case when we convert a board into Generic board. So, I thought you had this board. -- 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 v5 2/2] ARM: mx5: add support for USB armory board
On 08/04/2015 18:56, and...@inversepath.com wrote: From: Andrej Rosano and...@inversepath.com Add support for Inverse Path USB armory board, an open source flash-drive sized computer based on Freescale i.MX53 SoC. http://inversepath.com/usbarmory Signed-off-by: Andrej Rosano and...@inversepath.com Cc: Stefano Babic sba...@denx.de Cc: Chris Kuethe chris.kue...@gmail.com Cc: Fabio Estevam feste...@gmail.com Cc: Vagrant Cascadian vagr...@debian.org --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Hi, Everyone. How to using Ti-edma Driver in u-boot
I add the Ti-edmaDriver reference http://lists.denx.de/pipermail/u-boot/2014-October/191345.htmlarch/arm/include/asm/ti-common/ti-edma3.hdrivers/dma/Makefile drivers/dma/ti-edma3.c My uboot Ver : U-Boot 2010.06My arch: DM8148 I want to know how to use ti-edma3.cdriverPlease give me a sample .Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
