Re: [U-Boot] [PATCH v8 0/12] Enable driver model for GPIOs on Tegra and Exynos
Hi Minkyu, On 14 September 2014 16:29, Simon Glass s...@chromium.org wrote: (Note: Tegra patches have been applied, I am resending with exynos only) Now that driver model is part of U-Boot, the task of converting drivers over to it begins. GPIO is one of the easiest to convert, since it already has a sandbox driver and a uclass driver. The Tegra GPIO driver is relatively simple since it has a linear numbering and already uses the generic GPIO framework. Each GPIO bank has a separate device. Some arguments have been made that a single device should support all the GPIO banks, but currently the driver model uclass does not work that way and it would require a second-level data structure to handle the bank feature. This driver has been tested on: - Seaboard (Tegra 20) - Beaver (Tegra 30) - Jetson-TK1 (Tegra 124). I don't have a Tegra 114 board (Dalmore seems to be the only one with U-Boot support) but I am quite confident that it works. For exynos, the pinctrl device tree files are brought in from the kernel and cut down to remove the groupings which we don't yet use. Very small additions are made to avoid replicating the awful tables that Linux has for every exynos SoC. This series sits on top of the exynos refactors. The 'gpio' command is updated to support display of only the allocated GPIOs. This is much more friendly than displaying a large table. A few related clean-ups are provided as well. This series is available at u-boot-dm.git, branch working. Changes in v8: - Adjust odroid device tree file to use #include instead of /include/ - Add missing special case reg property for exynos5420 GPX0 - Add patch containing pinctrl settings for s5p_goni - Add patch containing pinctrl settings for s5p_goni - Add new patch to move smdkc100 to generic board - Add new patch to move s5p_goni to generic board - Enable driver model for smdkc100 and s5p_goni separately Are you comfortable with me applying this series and the serial and SPI ones to dm/next (along with the contributed goni patch)? It is too late for this release and that will give us lots of testing time for 2015.01. I'd like to pull together all the driver model stuff over the next few days. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/19] [RFC] Power(full) framework based on Driver Model
Hi, On 8 October 2014 14:55, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello all, On 10/08/2014 10:48 PM, Przemyslaw Marczak wrote: [snip] I missed one thing - this should be applied on the top of the u-boot-dm/working tree, which is now: dm: gpio: Remove unused get_state() uclass method (2109ad5b8d4298d4ee9e9ba612d151c2bf65dd1a) Thanks - also is it available in a git tree somewhere please? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Dear Albert Aribaud,
Please pull u-boot-sh/rmobile into u-boot-arm/master.
The following changes since commit 4b19b7448e63bab8af17abbb30acff00d8f0dc99:
Merge remote-tracking branch 'u-boot-imx/master' (2014-10-08 21:20:49 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-sh.git rmobile
for you to fetch changes up to 88982893c4d50692b80a2155146cda9e42266c6b:
arm: rmobile: r8a7794: Skip initialize L2 cache (2014-10-09 14:45:03 +0900)
Nobuhiro Iwamatsu (11):
arm: rmobile: lager: Fix value of CONFIG_SH_SCIF_CLK_FREQ
arm: rmobile: lager: Add CONFIG_SCIF_USE_EXT_CLK
arm: rmobile: koelsch: Add CONFIG_SCIF_USE_EXT_CLK
arm: rmobile: koelsch: Update QoS initialization to version 0.334
arm: rmobile: alt: Update QoS initialization to version 0.11
arm: rmobile: lager: Update Qos setting to version 0.955
arm: rmobile: lager: Add Qos setting for ES2
arm: rmobile: lager: Fix CPU frequency setting
arm: rmobile: Remove unnecessary initialization for l2ctlr
arm: rmobile: r8a7791: Fix initialize L2 cache
arm: rmobile: r8a7794: Skip initialize L2 cache
arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S | 22 +-
board/renesas/alt/qos.c |6 +-
board/renesas/koelsch/qos.c | 41 ++--
board/renesas/lager/lager.c |8 +-
board/renesas/lager/qos.c | 1358
include/configs/koelsch.h |1 +
include/configs/lager.h |3 +-
7 files changed, 1359 insertions(+), 80 deletions(-)
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [FAT/EXT4/SANDBOX] files 2GB
Hi, On 8 October 2014 07:07, Suriyan Ramasami suriya...@gmail.com wrote: Hello, I recently saw a post about fat commands such as fatls returning -ve values under u-boot for files whose sizes are =2GB. fatsize would also not set up filesize in this case. This also effects ext4/sandbox commands. I just looked at the ones which are handled by fs/fs.c I am thinking of cleaning this up a bit. My question is, is there some kind of preexisting automated test that I can build into u-boot which adds a command which does the test for me? For example, it could use the FS/read/write commands to create files with some pattern that it knows of, reads them for various sizes to check if they are correct etc. Same procedure for the [FS]size command as well. I do have made the changes to correct the behavior. The code change touches the [FS]read part of the code, hence, I want to test it extensively to assure me that I haven't broken anything else. I am nervous about the sandbox related code as I do not know how to even use them! It's quite ad-hoc at present, but there are several things you can follow: - test/cmd_repeat.sh shows how to run sandbox, pass it a command and check the output - test/command_ut.c and test/compression.c shows how to create a new command for testing purposes - test/dm contains driver model tests - there is framework but it is driver-model-specific - test/image shows a python script that creates tests files and runs sandbox to check them - test/vboot is similar for verified boot, although it is a shell script I feel that python is probably best for non-trivial tests. Probably you want to create a filesystem using a loopback device and mkfs, then run sandbox U-Boot to perform various operations. Then you could check the output from U-Boot and/or the resulting filesystem when U-Boot is finished. It would be great to have even a basic test for filesystems. I suggest you try to make it filesystem-agnostic - i.e. implement it for ext4 but make it extensible later for other filesystems. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
Hi,
On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote:
In some cases we really want to move forward with a deregister, add a force
parameter to allow this, and replace the dev with a nulldev in this case.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
common/stdio.c | 13 ++---
common/usb_kbd.c | 2 +-
drivers/serial/serial-uclass.c | 2 +-
include/stdio_dev.h| 4 ++--
4 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/common/stdio.c b/common/stdio.c
index c878103..8232815 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -34,6 +34,9 @@ char *stdio_names[MAX_FILES] = { stdin, stdout,
stderr };
#defineCONFIG_SYS_DEVICE_NULLDEV 1
#endif
+#ifdef CONFIG_SYS_STDIO_DEREGISTER
+#defineCONFIG_SYS_DEVICE_NULLDEV 1
+#endif
#ifdef CONFIG_SYS_DEVICE_NULLDEV
void nulldev_putc(struct stdio_dev *dev, const char c)
@@ -172,7 +175,7 @@ int stdio_register(struct stdio_dev *dev)
* returns 0 if success, -1 if device is assigned and 1 if devname not found
*/
#ifdef CONFIG_SYS_STDIO_DEREGISTER
-int stdio_deregister_dev(struct stdio_dev *dev)
+int stdio_deregister_dev(struct stdio_dev *dev, int force)
{
int l;
struct list_head *pos;
@@ -181,6 +184,10 @@ int stdio_deregister_dev(struct stdio_dev *dev)
/* get stdio devices (ListRemoveItem changes the dev list) */
for (l=0 ; l MAX_FILES; l++) {
if (stdio_devices[l] == dev) {
+ if (force) {
+ strcpy(temp_names[l], nulldev);
+ continue;
+ }
/* Device is assigned - report error */
return -1;
}
@@ -202,7 +209,7 @@ int stdio_deregister_dev(struct stdio_dev *dev)
return 0;
}
-int stdio_deregister(const char *devname)
+int stdio_deregister(const char *devname, int force)
{
struct stdio_dev *dev;
@@ -211,7 +218,7 @@ int stdio_deregister(const char *devname)
if (!dev) /* device not found */
return -ENODEV;
- return stdio_deregister_dev(dev);
+ return stdio_deregister_dev(dev, force);
}
#endif /* CONFIG_SYS_STDIO_DEREGISTER */
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index d4d5f48..dcb693d 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -550,7 +550,7 @@ int drv_usb_kbd_init(void)
int usb_kbd_deregister(void)
{
#ifdef CONFIG_SYS_STDIO_DEREGISTER
- int ret = stdio_deregister(DEVNAME);
+ int ret = stdio_deregister(DEVNAME, 0);
if (ret ret != -ENODEV)
return ret;
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index d04104e..61cbdc6 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev)
#ifdef CONFIG_SYS_STDIO_DEREGISTER
struct serial_dev_priv *upriv = dev-uclass_priv;
- if (stdio_deregister_dev(upriv-sdev))
+ if (stdio_deregister_dev(upriv-sdev), 0)
That bracket seems to be in a strange place.
return -EPERM;
#endif
diff --git a/include/stdio_dev.h b/include/stdio_dev.h
index 268de8e..24da23f 100644
--- a/include/stdio_dev.h
+++ b/include/stdio_dev.h
@@ -103,8 +103,8 @@ int stdio_init(void);
void stdio_print_current_devices(void);
#ifdef CONFIG_SYS_STDIO_DEREGISTER
-intstdio_deregister(const char *devname);
-int stdio_deregister_dev(struct stdio_dev *dev);
+int stdio_deregister(const char *devname, int force);
+int stdio_deregister_dev(struct stdio_dev *dev, int force);
#endif
struct list_head* stdio_get_list(void);
struct stdio_dev* stdio_get_by_name(const char* name);
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/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 01/19] lib: errno: introduce errno_str(): returns errno related message
From: Przemyslaw Marczak p.marc...@samsung.com The functions error's numbers are standarized - but the error messages are not. The errors are often handled with unclear error messages, so why not use an errno standarized messages. Advantages: - This could decrease the binary size. Having an array of string ptrs adds some extra space needs. Each str needs a ptr and that ptr needs relocation, 8 bytes on 32 bits If you want to save space do this instead static const char const errno_message[] = Success\0Operation not permitted\0No such file or directory etc. Then count \0 to find the error msg. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena
On 09/10/2014 02:28, Marek Vasut wrote: On Thursday, October 09, 2014 at 02:13:48 AM, Nikolay Dimitrov wrote: Hi Marek, [...] @Sean: Do you have any comments on USB hub reset stuff? Should we ditch entirely the reset code, or should we modify it somehow to work properly? OK, so it's just this USB that remains, right ? That's correct. There are a bunch of non-critical things for fixing also, but we'll negotiate later about them :D. Well what are those ? Stefano, is there still any chance that a V6 of Novena would go into this release? I guess those chances are slim, right ? Right. It looks like that it is better to take the time and fixing the open issues, else having the board just quickly into the release. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel 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] [PATCH 01/49] arm: board: use __weak
Hi Jeroen,
On Wed, 8 Oct 2014 22:57:21 +0200, Jeroen Hofstee
jer...@myspectrum.nl wrote:
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
arch/arm/lib/board.c | 40
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 76adaf3..98782ca 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -63,25 +63,15 @@ extern void dataflash_print_info(void);
* May be supplied by boards if desired
*/
-inline void __coloured_LED_init(void) {}
-void coloured_LED_init(void)
- __attribute__((weak, alias(__coloured_LED_init)));
-inline void __red_led_on(void) {}
-void red_led_on(void) __attribute__((weak, alias(__red_led_on)));
-inline void __red_led_off(void) {}
-void red_led_off(void) __attribute__((weak, alias(__red_led_off)));
-inline void __green_led_on(void) {}
-void green_led_on(void) __attribute__((weak, alias(__green_led_on)));
-inline void __green_led_off(void) {}
-void green_led_off(void) __attribute__((weak, alias(__green_led_off)));
-inline void __yellow_led_on(void) {}
-void yellow_led_on(void) __attribute__((weak, alias(__yellow_led_on)));
-inline void __yellow_led_off(void) {}
-void yellow_led_off(void) __attribute__((weak, alias(__yellow_led_off)));
-inline void __blue_led_on(void) {}
-void blue_led_on(void) __attribute__((weak, alias(__blue_led_on)));
-inline void __blue_led_off(void) {}
-void blue_led_off(void) __attribute__((weak, alias(__blue_led_off)));
+__weak void coloured_LED_init(void) {}
+__weak void red_led_on(void) {}
+__weak void red_led_off(void) {}
+__weak void green_led_on(void) {}
+__weak void green_led_off(void) {}
+__weak void yellow_led_on(void) {}
+__weak void yellow_led_off(void) {}
+__weak void blue_led_on(void) {}
+__weak void blue_led_off(void) {}
/*
@@ -198,27 +188,21 @@ static int arm_pci_init(void)
*/
typedef int (init_fnc_t) (void);
-void __dram_init_banksize(void)
+__weak void dram_init_banksize(void)
{
gd-bd-bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
gd-bd-bi_dram[0].size = gd-ram_size;
}
-void dram_init_banksize(void)
- __attribute__((weak, alias(__dram_init_banksize)));
-int __arch_cpu_init(void)
+__weak int arch_cpu_init(void)
{
return 0;
}
-int arch_cpu_init(void)
- __attribute__((weak, alias(__arch_cpu_init)));
-int __power_init_board(void)
+__weak int power_init_board(void)
{
return 0;
}
-int power_init_board(void)
- __attribute__((weak, alias(__power_init_board)));
/* Record the board_init_f() bootstage (after arch_cpu_init()) */
static int mark_bootstage(void)
Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena
Hi Marek, On 06/10/2014 18:02, Marek Vasut wrote: Add support for the Kosagi Novena board. Currently supported are: - I2C busses - FEC Ethernet - MMC0, MMC1, Booting from MMC - SATA - USB ports - USB Ethernet Signed-off-by: Marek Vasut ma...@denx.de Cc: Stefano Babic sba...@denx.de Cc: Sean Cross x...@kosagi.com Cc: Nikolay Dimitrov picmas...@mail.bg --- arch/arm/Kconfig | 4 + board/kosagi/novena/Kconfig | 23 ++ board/kosagi/novena/Makefile | 11 + board/kosagi/novena/novena.c | 342 +++ board/kosagi/novena/novena_spl.c | 581 +++ board/kosagi/novena/setup.cfg| 47 configs/novena_defconfig | 4 + include/configs/imx6_spl.h | 2 +- include/configs/novena.h | 303 9 files changed, 1316 insertions(+), 1 deletion(-) create mode 100644 board/kosagi/novena/Kconfig create mode 100644 board/kosagi/novena/Makefile create mode 100644 board/kosagi/novena/novena.c create mode 100644 board/kosagi/novena/novena_spl.c create mode 100644 board/kosagi/novena/setup.cfg create mode 100644 configs/novena_defconfig create mode 100644 include/configs/novena.h V2: - Drop the tegra_keyboard_init() comment altogether - Immediatelly return from the SD controller probe function on failure - Rename PFUZE100_PMIC to just PFUZE100 - Fix the IMX OTP support with CMD_FUSE - Enabling LVDS clock is still in place, since this is coming soon. V3: - Zap rootpath builtin env V4: - Zap the checkpatch issues - Update comments V5: - Don't configure VGEN1 - Set FPGA into reset in SPL - Drop ECSPI1 and add ECSPI3 mux - Drop UART1 and add UART3, UART4 muxes - Add separate mux option for the RGMII pins which doesn't set SPEED field - Move the configuration of RGMII after they were configured in GPIO mode diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 106aed9..4da1923 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -411,6 +411,9 @@ config TARGET_GW_VENTANA config TARGET_HUMMINGBOARD bool Support hummingboard +config TARGET_KOSAGI_NOVENA + bool Support Kosagi Novena + config TARGET_TQMA6 bool TQ Systems TQMa6 board @@ -637,6 +640,7 @@ source board/imx31_phycore/Kconfig source board/isee/igep0033/Kconfig source board/jornada/Kconfig source board/karo/tx25/Kconfig +source board/kosagi/novena/Kconfig source board/logicpd/imx27lite/Kconfig source board/logicpd/imx31_litekit/Kconfig source board/mpl/vcma9/Kconfig diff --git a/board/kosagi/novena/Kconfig b/board/kosagi/novena/Kconfig new file mode 100644 index 000..4e52be9 --- /dev/null +++ b/board/kosagi/novena/Kconfig @@ -0,0 +1,23 @@ +if TARGET_KOSAGI_NOVENA + +config SYS_CPU + string + default armv7 See http://patchwork.ozlabs.org/patch/397186/. According to Masahiro, strings is not required and can be dropped. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel 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] [PATCH 39/49] arm: vectors: provide protypes from vectors.S
Hi Jeroen, On Wed, 8 Oct 2014 22:57:59 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- arch/arm/include/asm/u-boot-arm.h | 15 +++ arch/arm/lib/interrupts.c | 1 + 2 files changed, 16 insertions(+) diff --git a/arch/arm/include/asm/u-boot-arm.h b/arch/arm/include/asm/u-boot-arm.h index b16694c..f97f3dd 100644 --- a/arch/arm/include/asm/u-boot-arm.h +++ b/arch/arm/include/asm/u-boot-arm.h @@ -45,4 +45,19 @@ void reset_timer_masked (void); ulongget_timer_masked(void); void udelay_masked (unsigned long usec); +/* calls to c from vectors.S */ +void bad_mode(void); +void do_undefined_instruction(struct pt_regs *pt_regs); +void do_software_interrupt(struct pt_regs *pt_regs); +void do_prefetch_abort(struct pt_regs *pt_regs); +void do_data_abort(struct pt_regs *pt_regs); +void do_not_used(struct pt_regs *pt_regs); +#ifdef CONFIG_ARM64 +void do_fiq(struct pt_regs *pt_regs, unsigned int esr); +void do_irq(struct pt_regs *pt_regs, unsigned int esr); +#else +void do_fiq(struct pt_regs *pt_regs); +void do_irq(struct pt_regs *pt_regswq); +#endif + #endif /* _U_BOOT_ARM_H_ */ diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c index f6b7c03..9019736 100644 --- a/arch/arm/lib/interrupts.c +++ b/arch/arm/lib/interrupts.c @@ -21,6 +21,7 @@ #include common.h #include asm/proc-armv/ptrace.h +#include asm/u-boot-arm.h DECLARE_GLOBAL_DATA_PTR; Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] HACK: arndale: deinit scsi before launching Linux
On Wed, 2014-10-08 at 10:18 +0200, Wolfgang Denk wrote: Dear Ian Campbell, In message 1412690200-6630-2-git-send-email-...@hellion.org.uk you wrote: From: Ian Campbell ian.campb...@citrix.com NOT TO BE APPLIED AS IS Without this Linux fails to correctly init the phy (or something) and cannot detect the disk. Even with this we can fail to detect the disk outselves on some fraction of boots, so something else is clearly up too. Why does the Subject: say scsi when you actually mean SATA? The patch is adding scsi_deinit to mirror the existing scsi_init function, and the u-boot CLI command (and dev name to load etc) is scsi. On this platform (as with several others) it happens that scsi is backed by a sata device, that's all. Note that this is a bug fix. But as noted above and in the series cover letter (more details there) it is not a complete one. I'm hoping the maintainers might know of a correct fix, which probably means correct peripheral shutdown processs. Ian. U-Boot should _always_ shut down all peripherals it used before booting an OS, see [1] [1] http://www.denx.de/wiki/U-Boot/DesignPrinciples Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/5] mx6: crm_regs: Add bit definitions for anadig registers
Hi Nitin,
On 01/10/2014 14:41, Nitin Garg wrote:
Add bit definitons for various anadig registers as
required by various drivers.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
arch/arm/include/asm/arch-mx6/crm_regs.h | 541
++
1 file changed, 541 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index e67b5b9..5c79d0f 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -1061,4 +1061,545 @@ struct mxc_ccm_reg {
#define BF_ANADIG_PFD_528_PFD0_FRAC(v) \
(((v) 0) BM_ANADIG_PFD_528_PFD0_FRAC)
+#define HW_ANADIG_REG_1P1(0x0110)
+#define HW_ANADIG_REG_1P1_SET(0x0114)
+#define HW_ANADIG_REG_1P1_CLR(0x0118)
+#define HW_ANADIG_REG_1P1_TOG(0x011c)
+
+#define BP_ANADIG_REG_1P1_RSVD2 18
+#define BM_ANADIG_REG_1P1_RSVD2 0xFFFC
+#define BF_ANADIG_REG_1P1_RSVD2(v) \
+ (((v) 18) BM_ANADIG_REG_1P1_RSVD2)
+#define BM_ANADIG_REG_1P1_OK_VDD1P1 0x0002
+#define BM_ANADIG_REG_1P1_BO_VDD1P1 0x0001
+#define BP_ANADIG_REG_1P1_RSVD1 13
+#define BM_ANADIG_REG_1P1_RSVD1 0xE000
+#define BF_ANADIG_REG_1P1_RSVD1(v) \
+ (((v) 13) BM_ANADIG_REG_1P1_RSVD1)
+#define BP_ANADIG_REG_1P1_OUTPUT_TRG 8
+#define BM_ANADIG_REG_1P1_OUTPUT_TRG 0x1F00
+#define BF_ANADIG_REG_1P1_OUTPUT_TRG(v) \
+ (((v) 8) BM_ANADIG_REG_1P1_OUTPUT_TRG)
+#define BM_ANADIG_REG_1P1_RSVD0 0x0080
+#define BP_ANADIG_REG_1P1_BO_OFFSET 4
+#define BM_ANADIG_REG_1P1_BO_OFFSET 0x0070
+#define BF_ANADIG_REG_1P1_BO_OFFSET(v) \
+ (((v) 4) BM_ANADIG_REG_1P1_BO_OFFSET)
+#define BM_ANADIG_REG_1P1_ENABLE_PULLDOWN 0x0008
+#define BM_ANADIG_REG_1P1_ENABLE_ILIMIT 0x0004
+#define BM_ANADIG_REG_1P1_ENABLE_BO 0x0002
+#define BM_ANADIG_REG_1P1_ENABLE_LINREG 0x0001
+
+#define HW_ANADIG_REG_3P0(0x0120)
+#define HW_ANADIG_REG_3P0_SET(0x0124)
+#define HW_ANADIG_REG_3P0_CLR(0x0128)
+#define HW_ANADIG_REG_3P0_TOG(0x012c)
+
+#define BP_ANADIG_REG_3P0_RSVD2 18
+#define BM_ANADIG_REG_3P0_RSVD2 0xFFFC
+#define BF_ANADIG_REG_3P0_RSVD2(v) \
+ (((v) 18) BM_ANADIG_REG_3P0_RSVD2)
+#define BM_ANADIG_REG_3P0_OK_VDD3P0 0x0002
+#define BM_ANADIG_REG_3P0_BO_VDD3P0 0x0001
+#define BP_ANADIG_REG_3P0_RSVD1 13
+#define BM_ANADIG_REG_3P0_RSVD1 0xE000
+#define BF_ANADIG_REG_3P0_RSVD1(v) \
+ (((v) 13) BM_ANADIG_REG_3P0_RSVD1)
+#define BP_ANADIG_REG_3P0_OUTPUT_TRG 8
+#define BM_ANADIG_REG_3P0_OUTPUT_TRG 0x1F00
+#define BF_ANADIG_REG_3P0_OUTPUT_TRG(v) \
+ (((v) 8) BM_ANADIG_REG_3P0_OUTPUT_TRG)
+#define BM_ANADIG_REG_3P0_VBUS_SEL 0x0080
+#define BP_ANADIG_REG_3P0_BO_OFFSET 4
+#define BM_ANADIG_REG_3P0_BO_OFFSET 0x0070
+#define BF_ANADIG_REG_3P0_BO_OFFSET(v) \
+ (((v) 4) BM_ANADIG_REG_3P0_BO_OFFSET)
+#define BM_ANADIG_REG_3P0_RSVD0 0x0008
+#define BM_ANADIG_REG_3P0_ENABLE_ILIMIT 0x0004
+#define BM_ANADIG_REG_3P0_ENABLE_BO 0x0002
+#define BM_ANADIG_REG_3P0_ENABLE_LINREG 0x0001
+
+#define HW_ANADIG_REG_2P5(0x0130)
+#define HW_ANADIG_REG_2P5_SET(0x0134)
+#define HW_ANADIG_REG_2P5_CLR(0x0138)
+#define HW_ANADIG_REG_2P5_TOG(0x013c)
+
+#define BP_ANADIG_REG_2P5_RSVD2 19
+#define BM_ANADIG_REG_2P5_RSVD2 0xFFF8
+#define BF_ANADIG_REG_2P5_RSVD2(v) \
+ (((v) 19) BM_ANADIG_REG_2P5_RSVD2)
+#define BM_ANADIG_REG_2P5_ENABLE_WEAK_LINREG 0x0004
+#define BM_ANADIG_REG_2P5_OK_VDD2P5 0x0002
+#define BM_ANADIG_REG_2P5_BO_VDD2P5 0x0001
+#define BP_ANADIG_REG_2P5_RSVD1 13
+#define BM_ANADIG_REG_2P5_RSVD1 0xE000
+#define BF_ANADIG_REG_2P5_RSVD1(v) \
+ (((v) 13) BM_ANADIG_REG_2P5_RSVD1)
+#define BP_ANADIG_REG_2P5_OUTPUT_TRG 8
+#define BM_ANADIG_REG_2P5_OUTPUT_TRG 0x1F00
+#define BF_ANADIG_REG_2P5_OUTPUT_TRG(v) \
+ (((v) 8) BM_ANADIG_REG_2P5_OUTPUT_TRG)
+#define BM_ANADIG_REG_2P5_RSVD0 0x0080
+#define BP_ANADIG_REG_2P5_BO_OFFSET 4
+#define BM_ANADIG_REG_2P5_BO_OFFSET 0x0070
+#define BF_ANADIG_REG_2P5_BO_OFFSET(v) \
+ (((v) 4) BM_ANADIG_REG_2P5_BO_OFFSET)
+#define BM_ANADIG_REG_2P5_ENABLE_PULLDOWN 0x0008
+#define BM_ANADIG_REG_2P5_ENABLE_ILIMIT 0x0004
+#define BM_ANADIG_REG_2P5_ENABLE_BO 0x0002
+#define BM_ANADIG_REG_2P5_ENABLE_LINREG 0x0001
+
+#define HW_ANADIG_REG_CORE (0x0140)
+#define HW_ANADIG_REG_CORE_SET (0x0144)
+#define HW_ANADIG_REG_CORE_CLR (0x0148)
+#define HW_ANADIG_REG_CORE_TOG (0x014c)
+
+#define BM_ANADIG_REG_CORE_REF_SHIFT 0x8000
+#define BM_ANADIG_REG_CORE_RSVD0 0x4000
+#define BM_ANADIG_REG_CORE_FET_ODRIVE 0x2000
+#define BP_ANADIG_REG_CORE_RAMP_RATE 27
+#define BM_ANADIG_REG_CORE_RAMP_RATE
Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Hi Nobuhiro, On Thu, 9 Oct 2014 15:08:15 +0900, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: Dear Albert Aribaud, Please pull u-boot-sh/rmobile into u-boot-arm/master. The following changes since commit 4b19b7448e63bab8af17abbb30acff00d8f0dc99: Merge remote-tracking branch 'u-boot-imx/master' (2014-10-08 21:20:49 +0200) are available in the git repository at: git://git.denx.de/u-boot-sh.git rmobile for you to fetch changes up to 88982893c4d50692b80a2155146cda9e42266c6b: arm: rmobile: r8a7794: Skip initialize L2 cache (2014-10-09 14:45:03 +0900) Nobuhiro Iwamatsu (11): arm: rmobile: lager: Fix value of CONFIG_SH_SCIF_CLK_FREQ arm: rmobile: lager: Add CONFIG_SCIF_USE_EXT_CLK arm: rmobile: koelsch: Add CONFIG_SCIF_USE_EXT_CLK arm: rmobile: koelsch: Update QoS initialization to version 0.334 arm: rmobile: alt: Update QoS initialization to version 0.11 arm: rmobile: lager: Update Qos setting to version 0.955 arm: rmobile: lager: Add Qos setting for ES2 arm: rmobile: lager: Fix CPU frequency setting arm: rmobile: Remove unnecessary initialization for l2ctlr arm: rmobile: r8a7791: Fix initialize L2 cache arm: rmobile: r8a7794: Skip initialize L2 cache arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S | 22 +- board/renesas/alt/qos.c |6 +- board/renesas/koelsch/qos.c | 41 ++-- board/renesas/lager/lager.c |8 +- board/renesas/lager/qos.c | 1358 include/configs/koelsch.h |1 + include/configs/lager.h |3 +- 7 files changed, 1359 insertions(+), 80 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/23] dm: Introduce driver model for sunxi
On Wed, 2014-10-08 at 13:27 -0600, Simon Glass wrote: Any more comments on this series please? I have a few nits so could respin. I'm afraid I'm unlikely to get to look at this before the w/e. It looks like the majority of the series isn't actually about sunxi though? Without having looked at the specifics I can say I'm broadly in favour of moving towards Device Model / Device Tree. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Add deep sleep framework support for Freescale QorIQ platforms
From: Tang Yuantian yuantian.t...@freescale.com
When Freescale QorIQ SoCs wake up from deep sleep, control is
passed to the primary core that starts executing uboot. After
re-initialized some IP blocks, like DDRC, kernel will take
responsibility to continue to restore environment it leaves before.
This patch adds the deep sleep framework support for all Freescale
QorIQ platforms that use generic_board configuation.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
common/board_f.c | 10 +
drivers/ddr/fsl/arm_ddr_gen3.c | 48 +-
include/fsl_ddr_sdram.h| 2 ++
include/fsl_sleep.h| 32
4 files changed, 87 insertions(+), 5 deletions(-)
create mode 100644 include/fsl_sleep.h
diff --git a/common/board_f.c b/common/board_f.c
index e6aa298..b736d29 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -56,6 +56,9 @@
#endif
#include dm/root.h
#include linux/compiler.h
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#include fsl_sleep.h
+#endif
/*
* Pointer to initial global data area
@@ -921,6 +924,9 @@ static init_fnc_t init_sequence_f[] = {
#if defined(CONFIG_MIPS) || defined(CONFIG_PPC)
init_func_ram,
#endif
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ fsl_dp_resume,
+#endif
#ifdef CONFIG_POST
post_init_f,
#endif
@@ -1027,6 +1033,10 @@ void board_init_f(ulong boot_flags)
gd-flags = boot_flags;
gd-have_console = 0;
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ if (is_warm_boot())
+ gd-flags |= GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE;
+#endif
if (initcall_run_list(init_sequence_f))
hang();
diff --git a/drivers/ddr/fsl/arm_ddr_gen3.c b/drivers/ddr/fsl/arm_ddr_gen3.c
index 59f2fd6..1a9d82b 100644
--- a/drivers/ddr/fsl/arm_ddr_gen3.c
+++ b/drivers/ddr/fsl/arm_ddr_gen3.c
@@ -12,6 +12,9 @@
#include asm/processor.h
#include fsl_immap.h
#include fsl_ddr.h
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#include fsl_sleep.h
+#endif
#if (CONFIG_CHIP_SELECTS_PER_CTRL 4)
#error Invalid setting for CONFIG_CHIP_SELECTS_PER_CTRL
@@ -92,7 +95,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
ddr_out32(ddr-timing_cfg_0, regs-timing_cfg_0);
ddr_out32(ddr-timing_cfg_1, regs-timing_cfg_1);
ddr_out32(ddr-timing_cfg_2, regs-timing_cfg_2);
- ddr_out32(ddr-sdram_cfg_2, regs-ddr_sdram_cfg_2);
ddr_out32(ddr-sdram_mode, regs-ddr_sdram_mode);
ddr_out32(ddr-sdram_mode_2, regs-ddr_sdram_mode_2);
ddr_out32(ddr-sdram_mode_3, regs-ddr_sdram_mode_3);
@@ -105,8 +107,25 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t
*regs,
ddr_out32(ddr-sdram_interval, regs-ddr_sdram_interval);
ddr_out32(ddr-sdram_data_init, regs-ddr_data_init);
ddr_out32(ddr-sdram_clk_cntl, regs-ddr_sdram_clk_cntl);
- ddr_out32(ddr-init_addr, regs-ddr_init_addr);
- ddr_out32(ddr-init_ext_addr, regs-ddr_init_ext_addr);
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ if (is_warm_boot()) {
+ ddr_out32(ddr-sdram_cfg_2,
+ regs-ddr_sdram_cfg_2 ~SDRAM_CFG2_D_INIT);
+ ddr_out32(ddr-init_addr, CONFIG_SYS_SDRAM_BASE);
+ ddr_out32(ddr-init_ext_addr, (1 31));
+
+ /* DRAM VRef will not be trained */
+ temp_sdram_cfg = ddr_in32(ddr-ddr_cdr2);
+ temp_sdram_cfg = ~DDR_CDR2_VREF_TRAIN_EN;
+ ddr_out32(ddr-ddr_cdr2, temp_sdram_cfg);
+ } else
+#endif
+ {
+ ddr_out32(ddr-sdram_cfg_2, regs-ddr_sdram_cfg_2);
+ ddr_out32(ddr-init_addr, regs-ddr_init_addr);
+ ddr_out32(ddr-init_ext_addr, regs-ddr_init_ext_addr);
+ ddr_out32(ddr-ddr_cdr2, regs-ddr_cdr2);
+ }
ddr_out32(ddr-timing_cfg_4, regs-timing_cfg_4);
ddr_out32(ddr-timing_cfg_5, regs-timing_cfg_5);
@@ -128,7 +147,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
ddr_out32(ddr-ddr_sdram_rcw_1, regs-ddr_sdram_rcw_1);
ddr_out32(ddr-ddr_sdram_rcw_2, regs-ddr_sdram_rcw_2);
ddr_out32(ddr-ddr_cdr1, regs-ddr_cdr1);
- ddr_out32(ddr-ddr_cdr2, regs-ddr_cdr2);
ddr_out32(ddr-err_disable, regs-err_disable);
ddr_out32(ddr-err_int_en, regs-err_int_en);
for (i = 0; i 32; i++) {
@@ -167,8 +185,20 @@ step2:
udelay(500);
asm volatile(dsb sy;isb);
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ if (is_warm_boot()) {
+ /* enter self-refresh */
+ temp_sdram_cfg = ddr_in32(ddr-sdram_cfg_2);
+ temp_sdram_cfg |= SDRAM_CFG2_FRC_SR;
+ ddr_out32(ddr-sdram_cfg_2, temp_sdram_cfg);
+ /* do board specific memory setup */
+ fsl_dp_mem_setup();
+
+ temp_sdram_cfg = (ddr_in32(ddr-sdram_cfg) | SDRAM_CFG_BI);
+ } else
+#endif
+ temp_sdram_cfg = (in_be32(ddr-sdram_cfg) ~SDRAM_CFG_BI);
/* Let the
[U-Boot] [PATCH 3/4] arm: ls102xa: Fixed a register definition error
From: Tang Yuantian yuantian.t...@freescale.com
There are 8 SCFG_SPARECR registers in SCFG memory block, not one.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
- u32 sparecr;
+ u32 sparecr[8];
};
/* Clocking */
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] arm: ls1021qds: Add deep sleep support
From: Tang Yuantian yuantian.t...@freescale.com
Add deep sleep support on Freescale LS1021QDS platform.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
board/freescale/ls1021aqds/ddr.c| 7
board/freescale/ls1021aqds/ls1021aqds.c | 60 +
include/configs/ls1021aqds.h| 4 +++
3 files changed, 71 insertions(+)
diff --git a/board/freescale/ls1021aqds/ddr.c b/board/freescale/ls1021aqds/ddr.c
index 5898e33..6dad4cc 100644
--- a/board/freescale/ls1021aqds/ddr.c
+++ b/board/freescale/ls1021aqds/ddr.c
@@ -8,6 +8,9 @@
#include fsl_ddr_sdram.h
#include fsl_ddr_dimm_params.h
#include ddr.h
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#include fsl_sleep.h
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -156,6 +159,10 @@ phys_size_t initdram(int board_type)
puts(Initializing DDRusing SPD\n);
dram_size = fsl_ddr_sdram();
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ fsl_dp_ddr_restore();
+#endif
+
return dram_size;
}
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index 12e83f7..e9dce36 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -253,3 +253,63 @@ u16 flash_read16(void *addr)
return (((val) 8) 0x00ff) | (((val) 8) 0xff00);
}
+
+#ifdef CONFIG_FSL_DEEP_SLEEP
+/* determine if it is a warm boot */
+bool is_warm_boot(void)
+{
+#define DCFG_CCSR_CRSTSR_WDRFR (1 3)
+ struct ccsr_gur __iomem *gur = (void *)CONFIG_SYS_FSL_GUTS_ADDR;
+
+ if (in_be32(gur-crstsr) DCFG_CCSR_CRSTSR_WDRFR)
+ return 1;
+
+ return 0;
+}
+
+void fsl_dp_mem_setup(void)
+{
+ /* does not provide HW signals for power management */
+ QIXIS_WRITE(pwr_ctl[1], (QIXIS_READ(pwr_ctl[1]) ~0x2));
+ udelay(1);
+}
+
+void fsl_dp_ddr_restore(void)
+{
+#define DDR_BUFF_LEN 128
+ u64 *src, *dst;
+ int i;
+ struct ccsr_scfg *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+
+ if (!is_warm_boot())
+ return;
+
+ /* get the address of ddr date from SPARECR3, little endian */
+ src = (u64 *)in_le32(scfg-sparecr[2]);
+ dst = (u64 *)CONFIG_SYS_SDRAM_BASE;
+ for (i = 0; i DDR_BUFF_LEN / 8; i++)
+ *dst++ = *src++;
+}
+
+int fsl_dp_resume(void)
+{
+ u32 start_addr;
+ void (*kernel_resume)(void);
+ struct ccsr_scfg *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+
+ if (!is_warm_boot())
+ return 0;
+
+ enable_devices_ns_access(ns_dev, ARRAY_SIZE(ns_dev));
+ armv7_init_nonsec();
+ cleanup_before_linux();
+
+ /* Get the entry address and jump to kernel */
+ start_addr = in_le32(scfg-sparecr[1]);
+ debug(Entry address is 0x%08x\n, start_addr);
+ kernel_resume = (void (*)(void))start_addr;
+ secure_ram_addr(_do_nonsec_entry)(kernel_resume, 0, 0, 0);
+
+ return 0;
+}
+#endif
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index bb47813..448a07e 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -19,6 +19,10 @@
#define CONFIG_SKIP_LOWLEVEL_INIT
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_FSL_DEEP_SLEEP
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#define CONFIG_SILENT_CONSOLE
+#endif
/*
* Size of malloc() pool
*/
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: HYP/non-sec: Make armv7_init_nonsec() usable before relocation
From: Tang Yuantian yuantian.t...@freescale.com
Defining variable gic_dist_addr as a globe one prevents function
armv7_init_nonsec() from being used before relocation which is
the case in the deep sleep resume process on Freescale QorIQ SoC
platforms.
This patch removes this limitation by adding a extra same meaning
local variable. In this way, no exsiting codes get corrupts.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/cpu/armv7/virt-v7.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 651ca40..e1dfce9 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -75,6 +75,7 @@ int armv7_init_nonsec(void)
{
unsigned int reg;
unsigned itlinesnr, i;
+ unsigned long gic_base_addr;
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
@@ -89,23 +90,24 @@ int armv7_init_nonsec(void)
* any access to it will trap.
*/
- gic_dist_addr = get_gicd_base_address();
- if (gic_dist_addr == -1)
+ gic_base_addr = get_gicd_base_address();
+ gic_dist_addr = gic_base_addr;
+ if (gic_base_addr == -1)
return -1;
/* enable the GIC distributor */
- writel(readl(gic_dist_addr + GICD_CTLR) | 0x03,
- gic_dist_addr + GICD_CTLR);
+ writel(readl(gic_base_addr + GICD_CTLR) | 0x03,
+ gic_base_addr + GICD_CTLR);
/* TYPER[4:0] contains an encoded number of available interrupts */
- itlinesnr = readl(gic_dist_addr + GICD_TYPER) 0x1f;
+ itlinesnr = readl(gic_base_addr + GICD_TYPER) 0x1f;
/* set all bits in the GIC group registers to one to allow access
* from non-secure state. The first 32 interrupts are private per
* CPU and will be set later when enabling the GIC for each core
*/
for (i = 1; i = itlinesnr; i++)
- writel((unsigned)-1, gic_dist_addr + GICD_IGROUPRn + 4 * i);
+ writel((unsigned)-1, gic_base_addr + GICD_IGROUPRn + 4 * i);
#ifndef CONFIG_ARMV7_PSCI
smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1);
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/23] dm: Introduce driver model for sunxi
Hi, On 10/09/2014 09:59 AM, Ian Campbell wrote: On Wed, 2014-10-08 at 13:27 -0600, Simon Glass wrote: Any more comments on this series please? I have a few nits so could respin. I'm afraid I'm unlikely to get to look at this before the w/e. It looks like the majority of the series isn't actually about sunxi though? Right, could v2 please be split into a generic series and a sunxi series on top of that, so that Ian and I can focus on reviewing the sunxi bits, and the wider community can hopefully review the generic bits ? Without having looked at the specifics I can say I'm broadly in favour of moving towards Device Model / Device Tree. Ack. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Deep sleep patches for Freescale QorIQ platforms
From: Tang Yuantian yuantian.t...@freescale.com These patches depend on the following patches: https://patchwork.ozlabs.org/patch/389949/ https://patchwork.ozlabs.org/patch/389950/ https://patchwork.ozlabs.org/patch/389951/ https://patchwork.ozlabs.org/patch/389952/ Tang Yuantian (4): Add deep sleep framework support for Freescale QorIQ platforms ARM: HYP/non-sec: Make armv7_init_nonsec() usable before relocation arm: ls102xa: Fixed a register definition error arm: ls1021qds: Add deep sleep support arch/arm/cpu/armv7/virt-v7.c | 14 +++--- arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +- board/freescale/ls1021aqds/ddr.c | 7 +++ board/freescale/ls1021aqds/ls1021aqds.c | 60 +++ common/board_f.c | 10 drivers/ddr/fsl/arm_ddr_gen3.c| 48 -- include/configs/ls1021aqds.h | 4 ++ include/fsl_ddr_sdram.h | 2 + include/fsl_sleep.h | 32 9 files changed, 167 insertions(+), 12 deletions(-) create mode 100644 include/fsl_sleep.h -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [SoCFPGA] next steps
Hi, On 10/08/2014 10:09 PM, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote: Hi, On 10/07/2014 02:45 PM, Marek Vasut wrote: Hey, given that we now have most of the u-boot socfpga stuff in mainline, I decided it would be a good idea to list what we're still missing and we should also decide how to move on now. First thing I should probably clarify is the late acceptance of the socfpga patches. This is certainly not something we do regularly and is one of the worst possible practices to do, but this time it felt rather important to get the platform in shape, so this exception happened. Furthermore, all of the code in u-boot-socfpga should be based on u-boot-arm and should be submitted through the u-boot-arm repository, not directly to u-boot . Platform was in this shape for a while that's why I can't see the reason why this happen. Tom: Does it mean that every platform which is not in good shape can go directly to the mainline in any time? It is definitely something which is good to know. So, it's a long standing thing where for non-core changes, deferring to the relevant custodian about what's going to come in close to the release is what's done. So yes, I grilled Marek about what non-socfpga things would be impacted by the changes (RPi) and if he'd tested things there. It all had been through a few post/review cycles. There's an argument to be made that we shouldn't have let socfpga in, back in 2012 or should have pushed harder, sooner, to get more progress made on real platform support. AFAIK if platform is working in certain state and you are able to get for example console than there is no problem to be in. There is nowhere written what exactly should work that's why I can't see any problem that socfpga is in if it is not causing compilation issues and have at least minimum functionality. The question was if the problem was that Altera just failed because didn't collect patches to any repo and sending it to Albert. Or there was just misunderstanding that Albert expected that Altera will do that and Altera expected that Albert will pick it up because he is ARM custodian and none was listed for socfpga. I have to defend Altera guys because if none is listed for SocFpga the nearest maintainer is collecting patches. Then there was discussion that none did care about socfpga patches and problem was resolved by creating socfpga repository and Marek became custodian for it. Marek collected that patches to the new repo and also I believe add new one and rebased them on the top of current tree and send them out as one big 51 series which is not possible to even properly review. IMHO they should be sent separated to target exact audience which do care about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste. But I am still missing the point why that patches was that urgent that they were merged to rc3 when it was claimed that socfpga was in a wrong shape for a while. It means v2014.10 should be just another broken version for socfpga and all this mess should be solved properly in 2015.01 via socfpga repo. And because patches went into rc3 and yesterday Jeroen is reporting problem on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/) Regarding your point that all It all had been through a few post/review cycles. I don't think all things have been fixed. Personally me I have reported here http://lists.denx.de/pipermail/u-boot/2014-September/189741.html (sha1: 0ae16cbb40a2881f6dfbe00fcb023ee7b548bc5c) issue with checkpatch.pl which hasn't been fixed. Here is my ACK for one patch which is not present in mainline commit http://lists.denx.de/pipermail/u-boot/2014-September/189747.html (sha1: 2f210639c4f003b0d5310273979441f1bfc88eae) Make no sense to go through all patches but this is just an example. I think it is something what we should discuss at u-boot mini summit on Monday. I discussed this with Marek over IRC yesterday and I expect he will ping me today (because of this email :-) ). If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform 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] compulab: eeprom: add default eeprom bus
Hi Nikita, On Wed, 17 Sep 2014 15:59:25 +0300, Nikita Kiryanov nik...@compulab.co.il wrote: Add default eeprom bus setting. This addresses the trimslice compile error that was introduced with the addition of this setting. Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Nikita Kiryanov nik...@compulab.co.il --- board/compulab/common/eeprom.c | 4 1 file changed, 4 insertions(+) diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c index 85442cd..2df3ada 100644 --- a/board/compulab/common/eeprom.c +++ b/board/compulab/common/eeprom.c @@ -15,6 +15,10 @@ # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 #endif +#ifndef CONFIG_SYS_I2C_EEPROM_BUS +#define CONFIG_SYS_I2C_EEPROM_BUS0 +#endif + #define EEPROM_LAYOUT_VER_OFFSET 44 #define BOARD_SERIAL_OFFSET 20 #define BOARD_SERIAL_OFFSET_LEGACY 8 Applied to u-boot-arm/master, thanks! Unclean builds now down from 6 to 5 (openrd_client openrd_ultimate tricorder_flash openrd_base tricorder) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] imx:mx6sxsabresd add qspi support
Hi,
Any reply about this patch? It is long time since this patch was sent out.
Regards,
Peng.
On 09/11/2014 10:30 AM, Fan Peng-B51431 wrote:
Just CC Stefano Babic sba...@denx.de
Regards,
Peng.
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Peng Fan
Sent: Thursday, September 11, 2014 9:56 AM
To: Estevam Fabio-R49496; Li Ye-B37916
Cc: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/2] imx:mx6sxsabresd add qspi support
Configure the pad setting and enable qspi clock to support qspi flashes
access.
This patch has been tested on mx6sxsabresd board.
Signed-off-by: Peng Fan peng@freescale.com
---
Changelog v2:
Take Fabio's suggestion, split soc code and board code into two patches.
This patch needs 'ARM:MX6SX Add QSPI support' patch.
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 40
+
include/configs/mx6sxsabresd.h | 14 ++
2 files changed, 54 insertions(+)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 5eaec1b..f9cad5a 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -272,11 +272,51 @@ int board_mmc_init(bd_t *bis)
return fsl_esdhc_initialize(bis, usdhc_cfg[0]); }
+#ifdef CONFIG_FSL_QSPI
+
+#define QSPI_PAD_CTRL1 \
+ (PAD_CTL_SRE_FAST | PAD_CTL_SPEED_HIGH | \
+ PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_40ohm)
+
+static iomux_v3_cfg_t const quadspi_pads[] = {
+ MX6_PAD_NAND_WP_B__QSPI2_A_DATA_0 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_READY_B__QSPI2_A_DATA_1| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE0_B__QSPI2_A_DATA_2 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE1_B__QSPI2_A_DATA_3 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_ALE__QSPI2_A_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CLE__QSPI2_A_SCLK | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA07__QSPI2_A_DQS| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA01__QSPI2_B_DATA_0 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA00__QSPI2_B_DATA_1 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_WE_B__QSPI2_B_DATA_2 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_RE_B__QSPI2_B_DATA_3 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA03__QSPI2_B_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA02__QSPI2_B_SCLK | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA05__QSPI2_B_DQS| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+};
+
+int board_qspi_init(void)
+{
+ /* Set the iomux */
+ imx_iomux_v3_setup_multiple_pads(quadspi_pads,
+ ARRAY_SIZE(quadspi_pads));
+
+ /* Set the clock */
+ enable_qspi_clk(1);
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
/* Address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+#ifdef CONFIG_FSL_QSPI
+ board_qspi_init();
+#endif
+
return 0;
}
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index 1eda65e..00031ec 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -201,6 +201,20 @@
/* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH
+#define CONFIG_FSL_QSPI
+
+#ifdef CONFIG_FSL_QSPI
+#define CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SYS_FSL_QSPI_LE
+#define CONFIG_QSPI_BASE QSPI2_BASE_ADDR
+#define CONFIG_QSPI_MEMMAP_BASE QSPI2_ARB_BASE_ADDR
+#define FSL_QSPI_FLASH_SIZE SZ_16M
+#define FSL_QSPI_FLASH_NUM 2
+#endif
+
#define CONFIG_ENV_OFFSET(6 * SZ_64K)
#define CONFIG_ENV_SIZE SZ_8K
#define CONFIG_ENV_IS_IN_MMC
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm:mx6sx add QSPI support
Hi,
just ping, Any comments about this patch?
Regards,
Peng.
On 09/11/2014 09:54 AM, Peng Fan wrote:
Add QSPI support for mx6solox.
Signed-off-by: Peng Fan peng@freescale.com
---
Changelog v2:
Take Fabio's suggestion, split soc code and board code into two patches.
arch/arm/cpu/armv7/mx6/clock.c| 50
+++
arch/arm/include/asm/arch-mx6/clock.h | 3 +++
drivers/spi/fsl_qspi.c| 29
3 files changed, 82 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 820b8d5..8caa61d 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -340,6 +340,56 @@ static u32 get_mmdc_ch0_clk(void)
}
#endif
+#ifdef CONFIG_MX6SX
+/* qspi_num can be from 0 - 1 */
+void enable_qspi_clk(int qspi_num)
+{
+ u32 reg = 0;
+ /* Enable QuadSPI clock */
+ switch (qspi_num) {
+ case 0:
+ /* disable the clock gate */
+ clrbits_le32(imx_ccm-CCGR3, MXC_CCM_CCGR3_QSPI1_MASK);
+
+ /* set 50M : (50 = 396 / 2 / 4) */
+ reg = readl(imx_ccm-cscmr1);
+ reg = ~(MXC_CCM_CSCMR1_QSPI1_PODF_MASK |
+ MXC_CCM_CSCMR1_QSPI1_CLK_SEL_MASK);
+ reg |= ((1 MXC_CCM_CSCMR1_QSPI1_PODF_OFFSET) |
+ (2 MXC_CCM_CSCMR1_QSPI1_CLK_SEL_OFFSET));
+ writel(reg, imx_ccm-cscmr1);
+
+ /* enable the clock gate */
+ setbits_le32(imx_ccm-CCGR3, MXC_CCM_CCGR3_QSPI1_MASK);
+ break;
+ case 1:
+ /*
+ * disable the clock gate
+ * QSPI2 and GPMI_BCH_INPUT_GPMI_IO share the same clock gate,
+ * disable both of them.
+ */
+ clrbits_le32(imx_ccm-CCGR4, MXC_CCM_CCGR4_QSPI2_ENFC_MASK |
+
MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_MASK);
+
+ /* set 50M : (50 = 396 / 2 / 4) */
+ reg = readl(imx_ccm-cs2cdr);
+ reg = ~(MXC_CCM_CS2CDR_QSPI2_CLK_PODF_MASK |
+ MXC_CCM_CS2CDR_QSPI2_CLK_PRED_MASK |
+ MXC_CCM_CS2CDR_QSPI2_CLK_SEL_MASK);
+ reg |= (MXC_CCM_CS2CDR_QSPI2_CLK_PRED(0x1) |
+ MXC_CCM_CS2CDR_QSPI2_CLK_SEL(0x3));
+ writel(reg, imx_ccm-cs2cdr);
+
+ /*enable the clock gate*/
+ setbits_le32(imx_ccm-CCGR4, MXC_CCM_CCGR4_QSPI2_ENFC_MASK |
+
MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_MASK);
+ break;
+ default:
+ break;
+ }
+}
+#endif
+
#ifdef CONFIG_FEC_MXC
int enable_fec_anatop_clock(enum enet_freq freq)
{
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index 339c789..9d0ba7a 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -60,4 +60,7 @@ int enable_i2c_clk(unsigned char enable, unsigned i2c_num);
int enable_spi_clk(unsigned char enable, unsigned spi_num);
void enable_ipu_clock(void);
int enable_fec_anatop_clock(enum enet_freq freq);
+#ifdef CONFIG_MX6SX
+void enable_qspi_clk(int qspi_num);
+#endif
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index ba20bef..7c8d065 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -14,7 +14,11 @@
#include fsl_qspi.h
#define RX_BUFFER_SIZE 0x80
+#ifdef CONFIG_MX6SX
+#define TX_BUFFER_SIZE 0x200
+#else
#define TX_BUFFER_SIZE 0x40
+#endif
#define OFFSET_BITS_MASK 0x00ff
@@ -52,11 +56,19 @@
#endif
static unsigned long spi_bases[] = {
+#ifdef CONFIG_MX6SX
+ CONFIG_QSPI_BASE,
+#else
QSPI0_BASE_ADDR,
+#endif
};
static unsigned long amba_bases[] = {
+#ifdef CONFIG_MX6SX
+ CONFIG_QSPI_MEMMAP_BASE,
+#else
QSPI0_AMBA_BASE,
+#endif
};
struct fsl_qspi {
@@ -157,8 +169,14 @@ static void qspi_set_lut(struct fsl_qspi *qspi)
qspi_write32(regs-lut[lut_base], OPRND0(OPCODE_PP_4B) |
PAD0(LUT_PAD1) | INSTR0(LUT_CMD) | OPRND1(ADDR32BIT) |
PAD1(LUT_PAD1) | INSTR1(LUT_ADDR));
+#ifdef CONFIG_MX6SX
+ /* Use IDATSZ in IPCR to determine the size */
+ qspi_write32(regs-lut[lut_base + 1], OPRND0(0) |
+ PAD0(LUT_PAD1) | INSTR0(LUT_WRITE));
+#else
qspi_write32(regs-lut[lut_base + 1], OPRND0(TX_BUFFER_SIZE) |
PAD0(LUT_PAD1) | INSTR0(LUT_WRITE));
+#endif
qspi_write32(regs-lut[lut_base + 2], 0);
qspi_write32(regs-lut[lut_base + 3], 0);
@@ -192,6 +210,12 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
if (bus = ARRAY_SIZE(spi_bases))
return NULL;
+#ifdef CONFIG_MX6SX
+ /* cs should be 0 -
Re: [U-Boot] [PATCH v3 0/29] Introduce driver model support for SPI, SPI flash, cros_ec
On 9 October 2014 02:03, Simon Glass s...@chromium.org wrote: Hi, On 29 September 2014 13:34, Simon Glass s...@chromium.org wrote: Up until now driver model has not been used for any type of bus. Buses have some unique properties and needs, so we cannot claim that driver model can cover all the common cases unless we have converted a bus over to driver model. SPI is a reasonable choice for this next step. It has a fairly simple API and not too many dependencies. The main one is SPI flash so we may as well convert that also. Since the boards I test with have cros_ec I have also included that, for SPI only. The technique used is make use of driver model's supported data structures to hold information currently kept by each subsystem in a private data structure. Since 'struct spi_slave' relates to the slave device on the bus it is stored in the 'parent' data with each child device of the bus. Since 'struct spi_flash' is a standard interface used for each SPI flash driver, it is stored in the SPI FLash uclass's private data for each device. New defines are created to enable driver model for each subsystem. These are: CONFIG_DM_SPI CONFIG_DM_SPI_FLASH CONFIG_DM_CROS_EC This allows us to move some boards and drivers to driver model, while leaving others behind. A 'big bang' conversion of everything to driver model, even at a subsystem level, is never going to work. There is some cost in changing the uclass interface after it is created, so if you have limited time, please spend it reviewing the uclass interfaces in spi.h and spi_flash.h. These need to be supported by each driver, so changing them later may involve changing multiple drivers. To assist with the conversion of other SPI drivers, a README file is added to walk through the process. So far, sandbox, exynos and tegra drivers are converted over. As always, driver model patches are available at u-boot-dm.git branch 'working'. There is a branch for just this series called 'spi-working'. I think this has had enough time out there. So I will push this to dm/next later this week. Sorry - I need to review a lot wrt v3. I do understand that it has been in enough time, but this causes a significant changes on entire framework, please hold on for a while I need to think with respect on qspi stuff with in the spi framework. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] imx:mx6sxsabresd add qspi support
Hi Peng Fan,
Before reviewing these two patches, I'm requesting some sort work from
your side like
Can you update/fix the driver drivers/spi/fsl_qspi.c without using
flash opcodes.
Using flash opcode's with in the (q)spi driver is not recommended
please think on that
direction.
On 9 October 2014 14:37, Peng Fan b51...@freescale.com wrote:
Hi,
Any reply about this patch? It is long time since this patch was sent out.
Regards,
Peng.
On 09/11/2014 10:30 AM, Fan Peng-B51431 wrote:
Just CC Stefano Babic sba...@denx.de
Regards,
Peng.
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Peng Fan
Sent: Thursday, September 11, 2014 9:56 AM
To: Estevam Fabio-R49496; Li Ye-B37916
Cc: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/2] imx:mx6sxsabresd add qspi support
Configure the pad setting and enable qspi clock to support qspi flashes
access.
This patch has been tested on mx6sxsabresd board.
Signed-off-by: Peng Fan peng@freescale.com
---
Changelog v2:
Take Fabio's suggestion, split soc code and board code into two patches.
This patch needs 'ARM:MX6SX Add QSPI support' patch.
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 40
+
include/configs/mx6sxsabresd.h | 14 ++
2 files changed, 54 insertions(+)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 5eaec1b..f9cad5a 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -272,11 +272,51 @@ int board_mmc_init(bd_t *bis)
return fsl_esdhc_initialize(bis, usdhc_cfg[0]); }
+#ifdef CONFIG_FSL_QSPI
+
+#define QSPI_PAD_CTRL1 \
+ (PAD_CTL_SRE_FAST | PAD_CTL_SPEED_HIGH | \
+ PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_40ohm)
+
+static iomux_v3_cfg_t const quadspi_pads[] = {
+ MX6_PAD_NAND_WP_B__QSPI2_A_DATA_0 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_READY_B__QSPI2_A_DATA_1| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE0_B__QSPI2_A_DATA_2 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE1_B__QSPI2_A_DATA_3 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_ALE__QSPI2_A_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CLE__QSPI2_A_SCLK | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA07__QSPI2_A_DQS| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA01__QSPI2_B_DATA_0 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA00__QSPI2_B_DATA_1 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_WE_B__QSPI2_B_DATA_2 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_RE_B__QSPI2_B_DATA_3 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA03__QSPI2_B_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA02__QSPI2_B_SCLK | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA05__QSPI2_B_DQS| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+};
+
+int board_qspi_init(void)
+{
+ /* Set the iomux */
+ imx_iomux_v3_setup_multiple_pads(quadspi_pads,
+ ARRAY_SIZE(quadspi_pads));
+
+ /* Set the clock */
+ enable_qspi_clk(1);
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
/* Address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+#ifdef CONFIG_FSL_QSPI
+ board_qspi_init();
+#endif
+
return 0;
}
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index 1eda65e..00031ec 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -201,6 +201,20 @@
/* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH
+#define CONFIG_FSL_QSPI
+
+#ifdef CONFIG_FSL_QSPI
+#define CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SYS_FSL_QSPI_LE
+#define CONFIG_QSPI_BASE QSPI2_BASE_ADDR
+#define CONFIG_QSPI_MEMMAP_BASE QSPI2_ARB_BASE_ADDR
+#define FSL_QSPI_FLASH_SIZE SZ_16M
+#define FSL_QSPI_FLASH_NUM 2
+#endif
+
#define CONFIG_ENV_OFFSET(6 * SZ_64K)
#define CONFIG_ENV_SIZE SZ_8K
#define CONFIG_ENV_IS_IN_MMC
--
1.8.4
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] spi, sf: add mtdparts feature to spi and sf commands
On 8 October 2014 11:01, Heiko Schocher h...@denx.de wrote:
Hello Jagannadha Sutradharudu Teki,
Am 05.09.2014 07:38, schrieb Heiko Schocher:
This patchserie add the popssibility to define mtd partitions on
spi nor flash, and use this settings with the sf commands.
steps:
- add MTD layer driver for spi, original patch from:
http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commitdiff;h=bb246819cdc90493dd7089eaa51b9e639765cced
and addapted it to current mainline.
- move common functions to get offset and size from
cmdline nand command to extract offset and size from
a mtd partition to common place drivers/mtd/mtd_uboot.c
maybe another place is better?
- add to the sf command the possibility to use offset and size from
the settings in mtdparts
With this patchset, the sf command looks now:
= sf
sf - SPI flash sub-system
Usage:
sf probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus
and chip select
sf read addr offset|partition len - read `len' bytes starting at
`offset' to memory at `addr'
sf write addr offset|partition len - write `len' bytes from memory
at `addr' to flash at `offset'
sf erase offset|partition [+]len- erase `len' bytes from `offset'
`+len' round up `len' to block
size
sf update addr offset|partition len - erase and write `len' bytes from
memory
at `addr' to flash at `offset'
=
for example env is defined in mtdparts:
= sf read 1300 env
device 0 offset 0xd, size 0x1
SF: 65536 bytes @ 0xd Read: OK
=
There are the followings checkpatch warnings:
CHECK: Alignment should match open parenthesis
#153: FILE: common/cmd_nand.c:217:
+ if (arg_off(argv[2],idx,addr,maxsize,maxsize,
+ MTD_DEV_TYPE_NAND, nand_info[idx].size)) {
CHECK: Alignment should match open parenthesis
#179: FILE: common/cmd_nand.c:557:
+ if (arg_off(argv[3],dev,off,size,maxsize,
+ MTD_DEV_TYPE_NAND, nand_info[dev].size))
CHECK: Alignment should match open parenthesis
#193: FILE: common/cmd_nand.c:576:
+ if (arg_off_size(argc - 3, argv +
3,dev,off,size,
+maxsize, MTD_DEV_TYPE_NAND,
total: 0 errors, 0 warnings, 3 checks, 361 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE
USLEEP_RANGE
20140714_ml_mtdparts/0002-mtd-nand-move-common-functions-from-cmd_nand.c-to-co.patch
has style problems, please review.
I see not, why this warning pops up ...
- changes for v2:
- mtd-spi-add-MTD-layer-driver.patch
- add comment from Daniel Schwierzeck:
fix compile error from original patch with
static inline rather than static __maybe_unused
- changes for v3:
- rebase with d6c1ffc7d23f4fe4ae8c91101861055b8e1501b6
- add comments from scott wood:
- align MTD_DEV_TYPE_NAND correct
- remove unnecessary inline
- rework jffs2 header problem later
Cc: Scott Woodscottw...@freescale.com
Cc: Tom Rinitr...@ti.com
Cc: Daniel Schwierzeckdaniel.schwierz...@gmail.com
Cc: Jagannadha Sutradharudu Tekijagannadh.t...@gmail.com
ping? Do you have any objections against this patchseries, or do you
think it is ok?
Please wait for dm-spi to be happen first, so-that we sync again this mtd on top
of that.
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [SoCFPGA] next steps
On 9 October 2014 14:07, Michal Simek mon...@monstr.eu wrote: Hi, On 10/08/2014 10:09 PM, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote: Hi, On 10/07/2014 02:45 PM, Marek Vasut wrote: Hey, given that we now have most of the u-boot socfpga stuff in mainline, I decided it would be a good idea to list what we're still missing and we should also decide how to move on now. First thing I should probably clarify is the late acceptance of the socfpga patches. This is certainly not something we do regularly and is one of the worst possible practices to do, but this time it felt rather important to get the platform in shape, so this exception happened. Furthermore, all of the code in u-boot-socfpga should be based on u-boot-arm and should be submitted through the u-boot-arm repository, not directly to u-boot . Platform was in this shape for a while that's why I can't see the reason why this happen. Tom: Does it mean that every platform which is not in good shape can go directly to the mainline in any time? It is definitely something which is good to know. So, it's a long standing thing where for non-core changes, deferring to the relevant custodian about what's going to come in close to the release is what's done. So yes, I grilled Marek about what non-socfpga things would be impacted by the changes (RPi) and if he'd tested things there. It all had been through a few post/review cycles. There's an argument to be made that we shouldn't have let socfpga in, back in 2012 or should have pushed harder, sooner, to get more progress made on real platform support. AFAIK if platform is working in certain state and you are able to get for example console than there is no problem to be in. There is nowhere written what exactly should work that's why I can't see any problem that socfpga is in if it is not causing compilation issues and have at least minimum functionality. The question was if the problem was that Altera just failed because didn't collect patches to any repo and sending it to Albert. Or there was just misunderstanding that Albert expected that Altera will do that and Altera expected that Albert will pick it up because he is ARM custodian and none was listed for socfpga. I have to defend Altera guys because if none is listed for SocFpga the nearest maintainer is collecting patches. Then there was discussion that none did care about socfpga patches and problem was resolved by creating socfpga repository and Marek became custodian for it. Marek collected that patches to the new repo and also I believe add new one and rebased them on the top of current tree and send them out as one big 51 series which is not possible to even properly review. IMHO they should be sent separated to target exact audience which do care about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste. But I am still missing the point why that patches was that urgent that they were merged to rc3 when it was claimed that socfpga was in a wrong shape for a while. It means v2014.10 should be just another broken version for socfpga and all this mess should be solved properly in 2015.01 via socfpga repo. And because patches went into rc3 and yesterday Jeroen is reporting problem on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/) Regarding your point that all It all had been through a few post/review cycles. I don't think all things have been fixed. Personally me I have reported here http://lists.denx.de/pipermail/u-boot/2014-September/189741.html (sha1: 0ae16cbb40a2881f6dfbe00fcb023ee7b548bc5c) issue with checkpatch.pl which hasn't been fixed. Here is my ACK for one patch which is not present in mainline commit http://lists.denx.de/pipermail/u-boot/2014-September/189747.html (sha1: 2f210639c4f003b0d5310273979441f1bfc88eae) Make no sense to go through all patches but this is just an example. I think it is something what we should discuss at u-boot mini summit on Monday. I discussed this with Marek over IRC yesterday and I expect he will ping me today (because of this email :-) ). If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? I think this traversing the actual development process in a different direction and it must be a valid point that need to discuss. Apart from this, I'm experienced an another isuue where some of the subsystem patches (say for example spi stuff) are pushed in a different direction. http://patchwork.ozlabs.org/patch/346015/ These are the qspi stuff from freescale, and I didn't understand why these goes into u-boot-arm/master. And there is no intimation of mine as well. Issue is that the driver itself is not in a proper shape, why does subsystem patches were pushed without the the review tag from a respective custodians. Please try to discuss
[U-Boot] [PATCH v2 1/2] net: Add a command to access the EEPROM from ethernet devices
Many ethernet devices use an EEPROM to store various settings, most
commonly the device MAC address. But on some devices it can contains
a lot more, for example USB device might also have many USB related
parameters.
This commit add a set of commands to read/write this EEPROM, write a
default configuration and read/write the device MAC address. The
defaults command allow priming the EEPROM for devices that need more
than just a MAC address in the EEPROM.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
v2: * No changes since v1
---
common/cmd_net.c | 134 +++
include/net.h| 28
net/eth.c| 46 +++
3 files changed, 208 insertions(+)
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 09489d4..f4952d5 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -445,3 +445,137 @@ U_BOOT_CMD(
);
#endif /* CONFIG_CMD_LINK_LOCAL */
+
+#if defined(CONFIG_CMD_ETH_EEPROM)
+static int do_eth_eeprom_rw(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ ulong addr, offset, length = 1;
+
+ if (argc 4)
+ return CMD_RET_USAGE;
+
+ addr = simple_strtoul(argv[2], NULL, 16);
+ offset = simple_strtoul(argv[3], NULL, 16);
+ if (argc 4)
+ length = simple_strtoul(argv[4], NULL, 16);
+
+ if (!strcmp(argv[0], write)) {
+ if (eth_eeprom_write(dev, offset, length, (void *)addr)) {
+ printf(EEPROM write failed\n);
+ return CMD_RET_FAILURE;
+ }
+ return CMD_RET_SUCCESS;
+ } else if (!strcmp(argv[0], read)) {
+ if (eth_eeprom_read(dev, offset, length, (void *)addr)) {
+ printf(EEPROM read failed\n);
+ return CMD_RET_FAILURE;
+ }
+ return CMD_RET_SUCCESS;
+ }
+
+ return CMD_RET_USAGE;
+}
+
+static int do_eth_eeprom_defaults(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ if (eth_eeprom_defaults(dev)) {
+ printf(EEPROM write failed\n);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_eth_eeprom_set_mac(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ u8 mac[6];
+
+ if (argc 3)
+ return CMD_RET_USAGE;
+
+ eth_parse_enetaddr(argv[2], mac);
+ if (!is_valid_ether_addr(mac)) {
+ printf(Invalid mac address given\n);
+ return CMD_RET_FAILURE;
+ }
+
+ printf(Writing MAC to EEPROM \n);
+ if (eth_eeprom_write_mac(dev, mac)) {
+ printf(EEPROM write failed\n);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_eth_eeprom_show_mac(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ u8 data[6];
+
+ if (eth_eeprom_read_mac(dev, data)) {
+ printf(EEPROM read failed\n);
+ return CMD_RET_FAILURE;
+ }
+
+ printf(%pM\n, data);
+ if (!is_valid_ether_addr(data))
+ printf(Warning: MAC address is not valid!\n);
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_eth_eeprom(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ struct eth_device *dev;
+ char *endp = NULL;
+ int index;
+
+ if (argc 3)
+ return CMD_RET_USAGE;
+
+ /* Get the ethernet device, by ID or by name */
+ index = (int) simple_strtoul(argv[2], endp, 16);
+ if (endp argv[2])
+ dev = eth_get_dev_by_index(index);
+ else
+ dev = eth_get_dev_by_name(argv[2]);
+
+ if (!dev) {
+ printf(Ethernet device not found\n);
+ return CMD_RET_FAILURE;
+ }
+
+ if (!strcmp(argv[1], read) || !strcmp(argv[1], write))
+ return do_eth_eeprom_rw(dev, argc - 1, argv + 1);
+ if (!strcmp(argv[1], defaults))
+ return do_eth_eeprom_defaults(dev, argc - 1, argv + 1);
+ if (!strcmp(argv[1], set_mac))
+ return do_eth_eeprom_set_mac(dev, argc - 1, argv + 1);
+ if (!strcmp(argv[1], show_mac))
+ return do_eth_eeprom_show_mac(dev, argc - 1, argv + 1);
+
+ printf(Unknown sub command: %s\n, argv[1]);
+
+ return CMD_RET_USAGE;
+}
+
+U_BOOT_CMD(
+ eth_eeprom, 6, 0, do_eth_eeprom,
+ access the EEPROM of ethernet devices,
+ read dev addr off [size]\n
+ - read 'size' bytes starting at offset 'off' to memory address
'addr'.\n
+ eth_eeprom write dev addr off [size]\n
+ - write 'size' bytes starting at offset 'off' from memory address
'addr'.\n
+ eth_eeprom defaults dev\n
+ - write default
[U-Boot] [PATCH v2 2/2] usb: eth: smsc95xx: Add EEPROM access support for LAN9514
Use the new ethernet eeprom API to allow the user to read/write the
EEPROM.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
v2: * Rework the defaults implementation to use the proper config
depending on the device type.
* Allow the board to override the defaults data.
* Use the proper defaults instead of the Tamonten config.
* Fix style error in usb_ether.h
* Add a comment to explain why the default MAC has all bits set
This patch is based on earlier work from Thierry Reding, I assumed
that the default config was derived from the datasheet. However it
turned out that this config had been customized for the Tamonten
boards. I restored the config according to the defaults found in the
datasheet. Sadly the datasheet doesn't properly document all the
fields from the EEPROM, so it may still have a few bugs as I don't
have the default values for all fields.
---
drivers/usb/eth/smsc95xx.c | 246 +++--
include/usb_ether.h| 8 ++
2 files changed, 247 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index 6bca34d..4e06be7 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -59,6 +59,8 @@
#define E2P_CMD0x30
#define E2P_CMD_BUSY_ 0x8000
+#define E2P_CMD_EWEN_ 0x2000
+#define E2P_CMD_WRITE_ 0x3000
#define E2P_CMD_READ_ 0x
#define E2P_CMD_TIMEOUT_ 0x0400
#define E2P_CMD_LOADED_0x0200
@@ -146,6 +148,155 @@ struct smsc95xx_private {
int have_hwaddr; /* 1 if we have a hardware MAC address */
};
+#ifdef CONFIG_CMD_ETH_EEPROM
+struct smsc95xx_eeprom_device {
+ unsigned short vendor;
+ unsigned short product;
+ struct smsc95xx_eeprom_defaults *defaults;
+};
+
+/* Default values as used by the controller when the EEPROM hasn't
+ * been programmed yet. Note that when unset the MAC address has
+ * all bits set instead of all bits cleared as is usual in u-boot. */
+static u8 smsc9514_eeprom_defaults_data[] = {
+ /* 0x00 */
+ 0xA5, /* Signature */
+ 0xFF, 0xFF, /* MAC bytes 0-1 */
+ 0xFF, 0xFF, /* MAC bytes 2-3 */
+ 0xFF, 0xFF, /* MAC bytes 4-5 */
+ 0x01, /* FS Polling Interval for Interrupt Endpoint */
+ 0x04, /* HS Polling Interval for Interrupt Endpoint */
+ 0x05, /* Configuration Flags */
+ 0x09, 0x04, /* Language ID */
+ 0x0a, /* Manufacturer ID String Descriptor Length (bytes) */
+ 0x2f, /* Manufacturer ID String Descriptor EEPROM Word Offset
*/
+ 0x10, /* Product Name String Descriptor Length (bytes) */
+ 0x34, /* Product Name String Descriptor EEPROM Word Offset */
+ /* 0x10 */
+ 0x12, /* Serial Number String Descriptor Length (bytes) */
+ 0x3c, /* Serial Number String Descriptor EEPROM Word Offset */
+ 0x08, /* Configuration String Descriptor Length (bytes) */
+ 0x45, /* Configuration String Descriptor Word Offset */
+ 0x08, /* Interface String Descriptor Length (bytes) */
+ 0x49, /* Interface String Descriptor Word Offset */
+ 0x12, /* Hi-Speed Device Descriptor Length (bytes) */
+ 0x1d, /* Hi-Speed Device Descriptor Word Offset */
+ 0x12, /* Hi-Speed Configuration and Interface Descriptor
Length (bytes) */
+ 0x26, /* Hi-Speed Configuration and Interface Descriptor Word
Offset */
+ 0x12, /* Full-Speed Device Descriptor Length (bytes) */
+ 0x1d, /* Full-Speed Device Descriptor Word Offset */
+ 0x12, /* Full-Speed Configuration and Interface Descriptor
Length (bytes) */
+ 0x26, /* Full-Speed Configuration and Interface Descriptor
Word Offset */
+ 0x00, 0x00, /* RESERVED */
+ /* 0x20 */
+ 0x24, 0x04, /* Vendor ID */
+ 0x14, 0x95, /* Product ID */
+ 0x00, 0x01, /* Device ID */
+ 0x9b, /* Config Data Byte 1 Register (CFG1) */
+ 0x18, /* Config Data Byte 2 Register (CFG2) */
+ 0x00, /* Config Data Byte 3 Register (CFG3) */
+ 0x02, /* Non-Removable Devices Register (NRD) */
+ 0x00, /* Port Disable (Self) Register (PDS) */
+ 0x00, /* Port Disable (Bus) Register (PDB) */
+ 0x01, /* Max Power (Self) Register (MAXPS) */
+ 0x00, /* Max Power (Bus) Register (MAXPB) */
+ 0x01, /* Hub Controller Max Current (Self) Register (HCMCS) */
+ 0x00, /* Hub Controller Max Current (Bus) Register (HCMCB) */
+ /* 0x30 */
+ 0x32, /* Power-on Time Register (PWRT)
Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena
Hi Sean, On 10/09/2014 08:38 AM, Sean Cross wrote: I'll be sure to have Bunnie post a new schematic when he returns tomorrow. For now, the ECO on our wiki is the authoritative source. This is curently the only ECO for the final PVT2 board: http://www.kosagi.com/w/index.php?title=Novena_PVT2_ECO_List#ECO22:_swap_audio_control_option Thanks for sharing the link to ECO list, it will definitely help (well, shame on me that I didn't find this earler, doh). Still, if you think it's possible to release at some point an updated PDF schematic that integrates all currently approved ECOs, it will be even better. Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Device tree for Atmel SAMA5D31
This isn't strictly a U-Boot issue but I am hoping that there are
appropriately knowledgeable people here who will be able to help!
I am working on a Linux driver for an I2C RTC device and need to add the
correct definitions into the device tree for the SAMA5D31 to be passed to
the kernel at boot time. I have added:
i2c0: i2c@f0014000 {
status = okay;
rv8523c3@68 {
compatible = mc,rv8523c3;
reg = 0x68;
};
};
This sets up enough to allow the basic clock functions within the RTC to
work correctly and the hwclock command within Busybox to work correctly. I
need to add in the definitions for a GPIO (PE31) to be used as the alarm
interrupt pin and can't get my head around the definitions needed within the
device tree. I have tried adding the following
interrupt-parent = pioE;
interrupts = 31;
When the RTC driver is loaded by Linux the client-irq variable in the probe
function doesn't contain a value 0 and so doesn't setup an interrupt.
Any ideas on the correct definitions needed?
Thanks (and apologies for the noise),
Andy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v3 6/6] keystone2: k2l-evm: add board support
From: Hao Zhang hzh...@ti.com
This patch adds Keystone II Lammar (K2L) EVM board support.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
v3..v2
Add maintainers information
arch/arm/cpu/armv7/keystone/Kconfig| 3 ++
arch/arm/include/asm/arch-keystone/clock-k2l.h | 6 +++
board/ti/ks2_evm/Kconfig | 16 +++
board/ti/ks2_evm/MAINTAINERS | 2 +
board/ti/ks2_evm/Makefile | 2 +
board/ti/ks2_evm/board_k2l.c | 60 ++
board/ti/ks2_evm/ddr3_cfg.c| 36
board/ti/ks2_evm/ddr3_cfg.h| 3 ++
board/ti/ks2_evm/ddr3_k2l.c| 43 ++
configs/k2l_evm_defconfig | 3 ++
include/configs/k2l_evm.h | 37
11 files changed, 211 insertions(+)
create mode 100644 board/ti/ks2_evm/board_k2l.c
create mode 100644 board/ti/ks2_evm/ddr3_k2l.c
create mode 100644 configs/k2l_evm_defconfig
create mode 100644 include/configs/k2l_evm.h
diff --git a/arch/arm/cpu/armv7/keystone/Kconfig
b/arch/arm/cpu/armv7/keystone/Kconfig
index 24d0cbe..91211fd 100644
--- a/arch/arm/cpu/armv7/keystone/Kconfig
+++ b/arch/arm/cpu/armv7/keystone/Kconfig
@@ -9,6 +9,9 @@ config TARGET_K2HK_EVM
config TARGET_K2E_EVM
bool TI Keystone 2 Edison EVM
+config TARGET_K2L_EVM
+ bool TI Keystone 2 Lamar EVM
+
endchoice
config SYS_CPU
diff --git a/arch/arm/include/asm/arch-keystone/clock-k2l.h
b/arch/arm/include/asm/arch-keystone/clock-k2l.h
index 8cacee0..b3f4e71 100644
--- a/arch/arm/include/asm/arch-keystone/clock-k2l.h
+++ b/arch/arm/include/asm/arch-keystone/clock-k2l.h
@@ -69,7 +69,9 @@ enum {
#define CORE_PLL_799 {CORE_PLL, 13, 1, 2}
#define CORE_PLL_983 {CORE_PLL, 16, 1, 2}
+#define CORE_PLL_1000 {CORE_PLL, 114, 7, 2}
#define CORE_PLL_1167 {CORE_PLL, 19, 1, 2}
+#define CORE_PLL_1198 {CORE_PLL, 39, 2, 2}
#define CORE_PLL_1228 {CORE_PLL, 20, 1, 2}
#define PASS_PLL_1228 {PASS_PLL, 20, 1, 2}
#define PASS_PLL_983 {PASS_PLL, 16, 1, 2}
@@ -78,8 +80,12 @@ enum {
#define TETRIS_PLL_737 {TETRIS_PLL, 12, 1, 2}
#define TETRIS_PLL_799 {TETRIS_PLL, 13, 1, 2}
#define TETRIS_PLL_983 {TETRIS_PLL, 16, 1, 2}
+#define TETRIS_PLL_1000{TETRIS_PLL, 114, 7, 2}
#define TETRIS_PLL_1167{TETRIS_PLL, 19, 1, 2}
+#define TETRIS_PLL_1198{TETRIS_PLL, 39, 2, 2}
#define TETRIS_PLL_1228{TETRIS_PLL, 20, 1, 2}
+#define TETRIS_PLL_1352{TETRIS_PLL, 22, 1, 2}
+#define TETRIS_PLL_1401{TETRIS_PLL, 114, 5, 2}
#define DDR3_PLL_200 {DDR3_PLL, 4, 1, 2}
#define DDR3_PLL_400 {DDR3_PLL, 16, 1, 4}
#define DDR3_PLL_800 {DDR3_PLL, 16, 1, 2}
diff --git a/board/ti/ks2_evm/Kconfig b/board/ti/ks2_evm/Kconfig
index 3108782..36c31ff 100644
--- a/board/ti/ks2_evm/Kconfig
+++ b/board/ti/ks2_evm/Kconfig
@@ -29,3 +29,19 @@ config SYS_CONFIG_NAME
default k2hk_evm
endif
+
+if TARGET_K2L_EVM
+
+config SYS_BOARD
+ string
+ default ks2_evm
+
+config SYS_VENDOR
+ string
+ default ti
+
+config SYS_CONFIG_NAME
+ string
+ default k2l_evm
+
+endif
diff --git a/board/ti/ks2_evm/MAINTAINERS b/board/ti/ks2_evm/MAINTAINERS
index 595a80a..87c36c9 100644
--- a/board/ti/ks2_evm/MAINTAINERS
+++ b/board/ti/ks2_evm/MAINTAINERS
@@ -6,3 +6,5 @@ F: include/configs/k2hk_evm.h
F: configs/k2hk_evm_defconfig
F: include/configs/k2e_evm.h
F: configs/k2e_evm_defconfig
+F: include/configs/k2l_evm.h
+F: configs/k2l_evm_defconfig
diff --git a/board/ti/ks2_evm/Makefile b/board/ti/ks2_evm/Makefile
index 00f1164..071dbee 100644
--- a/board/ti/ks2_evm/Makefile
+++ b/board/ti/ks2_evm/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_K2HK_EVM) += board_k2hk.o
obj-$(CONFIG_K2HK_EVM) += ddr3_k2hk.o
obj-$(CONFIG_K2E_EVM) += board_k2e.o
obj-$(CONFIG_K2E_EVM) += ddr3_k2e.o
+obj-$(CONFIG_K2L_EVM) += board_k2l.o
+obj-$(CONFIG_K2L_EVM) += ddr3_k2l.o
diff --git a/board/ti/ks2_evm/board_k2l.c b/board/ti/ks2_evm/board_k2l.c
new file mode 100644
index 000..b8faff6
--- /dev/null
+++ b/board/ti/ks2_evm/board_k2l.c
@@ -0,0 +1,60 @@
+/*
+ * K2L EVM : Board initialization
+ *
+ * (C) Copyright 2014
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/ddr3.h
+#include asm/arch/hardware.h
+#include asm/ti-common/ti-aemif.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+unsigned int external_clk[ext_clk_count] = {
+ [sys_clk] = 12288,
+ [alt_core_clk] = 1,
+ [pa_clk]= 12288,
+ [tetris_clk]= 12288,
+ [ddr3_clk] = 1,
+ [pcie_clk] = 1,
+ [sgmii_clk] = 15625,
+ [usb_clk] = 1,
+};
+
+static struct pll_init_data core_pll_config[] = {
+
Re: [U-Boot] [SoCFPGA] next steps
On Thursday, October 09, 2014 at 01:20:23 PM, Jagan Teki wrote: On 9 October 2014 14:07, Michal Simek mon...@monstr.eu wrote: Hi, On 10/08/2014 10:09 PM, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote: Hi, On 10/07/2014 02:45 PM, Marek Vasut wrote: Hey, given that we now have most of the u-boot socfpga stuff in mainline, I decided it would be a good idea to list what we're still missing and we should also decide how to move on now. First thing I should probably clarify is the late acceptance of the socfpga patches. This is certainly not something we do regularly and is one of the worst possible practices to do, but this time it felt rather important to get the platform in shape, so this exception happened. Furthermore, all of the code in u-boot-socfpga should be based on u-boot-arm and should be submitted through the u-boot-arm repository, not directly to u-boot . Platform was in this shape for a while that's why I can't see the reason why this happen. Tom: Does it mean that every platform which is not in good shape can go directly to the mainline in any time? It is definitely something which is good to know. So, it's a long standing thing where for non-core changes, deferring to the relevant custodian about what's going to come in close to the release is what's done. So yes, I grilled Marek about what non-socfpga things would be impacted by the changes (RPi) and if he'd tested things there. It all had been through a few post/review cycles. There's an argument to be made that we shouldn't have let socfpga in, back in 2012 or should have pushed harder, sooner, to get more progress made on real platform support. AFAIK if platform is working in certain state and you are able to get for example console than there is no problem to be in. There is nowhere written what exactly should work that's why I can't see any problem that socfpga is in if it is not causing compilation issues and have at least minimum functionality. The question was if the problem was that Altera just failed because didn't collect patches to any repo and sending it to Albert. Or there was just misunderstanding that Albert expected that Altera will do that and Altera expected that Albert will pick it up because he is ARM custodian and none was listed for socfpga. I have to defend Altera guys because if none is listed for SocFpga the nearest maintainer is collecting patches. Then there was discussion that none did care about socfpga patches and problem was resolved by creating socfpga repository and Marek became custodian for it. Marek collected that patches to the new repo and also I believe add new one and rebased them on the top of current tree and send them out as one big 51 series which is not possible to even properly review. IMHO they should be sent separated to target exact audience which do care about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste. But I am still missing the point why that patches was that urgent that they were merged to rc3 when it was claimed that socfpga was in a wrong shape for a while. It means v2014.10 should be just another broken version for socfpga and all this mess should be solved properly in 2015.01 via socfpga repo. And because patches went into rc3 and yesterday Jeroen is reporting problem on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/) Regarding your point that all It all had been through a few post/review cycles. I don't think all things have been fixed. Personally me I have reported here http://lists.denx.de/pipermail/u-boot/2014-September/189741.html (sha1: 0ae16cbb40a2881f6dfbe00fcb023ee7b548bc5c) issue with checkpatch.pl which hasn't been fixed. Here is my ACK for one patch which is not present in mainline commit http://lists.denx.de/pipermail/u-boot/2014-September/189747.html (sha1: 2f210639c4f003b0d5310273979441f1bfc88eae) Make no sense to go through all patches but this is just an example. I think it is something what we should discuss at u-boot mini summit on Monday. I discussed this with Marek over IRC yesterday and I expect he will ping me today (because of this email :-) ). If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? I think this traversing the actual development process in a different direction and it must be a valid point that need to discuss. Apart from this, I'm experienced an another isuue where some of the subsystem patches (say for example spi stuff) are pushed in a different direction. http://patchwork.ozlabs.org/patch/346015/ These are the qspi stuff from freescale, and I didn't understand why these goes into u-boot-arm/master. And there is no intimation of mine as
[U-Boot] Discussion topics / issues
On Thursday, October 09, 2014 at 10:37:52 AM, Michal Simek wrote: Hi, Hi! I changed the subject, since it long didn't match the topic. On 10/08/2014 10:09 PM, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote: Hi, On 10/07/2014 02:45 PM, Marek Vasut wrote: Hey, given that we now have most of the u-boot socfpga stuff in mainline, I decided it would be a good idea to list what we're still missing and we should also decide how to move on now. First thing I should probably clarify is the late acceptance of the socfpga patches. This is certainly not something we do regularly and is one of the worst possible practices to do, but this time it felt rather important to get the platform in shape, so this exception happened. Furthermore, all of the code in u-boot-socfpga should be based on u-boot-arm and should be submitted through the u-boot-arm repository, not directly to u-boot . Platform was in this shape for a while that's why I can't see the reason why this happen. Tom: Does it mean that every platform which is not in good shape can go directly to the mainline in any time? It is definitely something which is good to know. So, it's a long standing thing where for non-core changes, deferring to the relevant custodian about what's going to come in close to the release is what's done. So yes, I grilled Marek about what non-socfpga things would be impacted by the changes (RPi) and if he'd tested things there. It all had been through a few post/review cycles. There's an argument to be made that we shouldn't have let socfpga in, back in 2012 or should have pushed harder, sooner, to get more progress made on real platform support. AFAIK if platform is working in certain state and you are able to get for example console than there is no problem to be in. There is nowhere written what exactly should work that's why I can't see any problem that socfpga is in if it is not causing compilation issues and have at least minimum functionality. This was not the case in here. The platform was completely unusable. The question was if the problem was that Altera just failed because didn't collect patches to any repo and sending it to Albert. Or there was just misunderstanding that Albert expected that Altera will do that and Altera expected that Albert will pick it up because he is ARM custodian and none was listed for socfpga. I have to defend Altera guys because if none is listed for SocFpga the nearest maintainer is collecting patches. It was not Altera guys who started submitting patches to put this thing in shape. Altera only realized that things started to move after Pavel sent the initial blob-of-a-patch . Since then, we are moving forward. Then there was discussion that none did care about socfpga patches and problem was resolved by creating socfpga repository and Marek became custodian for it. Marek collected that patches to the new repo and also I believe add new one and rebased them on the top of current tree and send them out as one big 51 series which is not possible to even properly review. Patches which were contained to the architecture for the most part, mind you. The rest were fixes for issues which appeared during this development, thus fixing issues in U-Boot. IMHO they should be sent separated to target exact audience which do care about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste. I fully agree on this part. But I am still missing the point why that patches was that urgent that they were merged to rc3 when it was claimed that socfpga was in a wrong shape for a while. It means v2014.10 should be just another broken version for socfpga and all this mess should be solved properly in 2015.01 via socfpga repo. Yes, this would mean that another broken version would be released even though the fixes were available. This doesn't sound right to me. And because patches went into rc3 and yesterday Jeroen is reporting problem on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/) This problem was discovered in a patch which was first posted to the list on Feb. 19 ( http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/180797 ), which is before 2014.04 release and was not discovered through the review process. Regarding your point that all It all had been through a few post/review cycles. I don't think all things have been fixed. Personally me I have reported here http://lists.denx.de/pipermail/u-boot/2014-September/189741.html (sha1: 0ae16cbb40a2881f6dfbe00fcb023ee7b548bc5c) issue with checkpatch.pl which hasn't been fixed. And I explicitly noted that the FPGA stuff still has a couple of checkpatch issues right in the subsequent email [1] . Processing all the checkpatch issues of that file would make the resulting patch a horrid mess instead of producing a well contained set of patches. [1]
Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena
On Thursday, October 09, 2014 at 09:31:35 AM, Stefano Babic wrote: On 09/10/2014 02:28, Marek Vasut wrote: On Thursday, October 09, 2014 at 02:13:48 AM, Nikolay Dimitrov wrote: Hi Marek, [...] @Sean: Do you have any comments on USB hub reset stuff? Should we ditch entirely the reset code, or should we modify it somehow to work properly? OK, so it's just this USB that remains, right ? That's correct. There are a bunch of non-critical things for fixing also, but we'll negotiate later about them :D. Well what are those ? Stefano, is there still any chance that a V6 of Novena would go into this release? I guess those chances are slim, right ? Right. It looks like that it is better to take the time and fixing the open issues, else having the board just quickly into the release. Works for me either way, thanks! 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 V5] ARM: mx6: Add support for Kosagi Novena
On Thursday, October 09, 2014 at 09:36:13 AM, Stefano Babic wrote: Hi Marek, On 06/10/2014 18:02, Marek Vasut wrote: Add support for the Kosagi Novena board. Currently supported are: - I2C busses - FEC Ethernet - MMC0, MMC1, Booting from MMC - SATA - USB ports - USB Ethernet Signed-off-by: Marek Vasut ma...@denx.de Cc: Stefano Babic sba...@denx.de Cc: Sean Cross x...@kosagi.com Cc: Nikolay Dimitrov picmas...@mail.bg --- arch/arm/Kconfig | 4 + board/kosagi/novena/Kconfig | 23 ++ board/kosagi/novena/Makefile | 11 + board/kosagi/novena/novena.c | 342 +++ board/kosagi/novena/novena_spl.c | 581 +++ board/kosagi/novena/setup.cfg | 47 configs/novena_defconfig | 4 + include/configs/imx6_spl.h | 2 +- include/configs/novena.h | 303 9 files changed, 1316 insertions(+), 1 deletion(-) create mode 100644 board/kosagi/novena/Kconfig create mode 100644 board/kosagi/novena/Makefile create mode 100644 board/kosagi/novena/novena.c create mode 100644 board/kosagi/novena/novena_spl.c create mode 100644 board/kosagi/novena/setup.cfg create mode 100644 configs/novena_defconfig create mode 100644 include/configs/novena.h V2: - Drop the tegra_keyboard_init() comment altogether - Immediatelly return from the SD controller probe function on failure - Rename PFUZE100_PMIC to just PFUZE100 - Fix the IMX OTP support with CMD_FUSE - Enabling LVDS clock is still in place, since this is coming soon. V3: - Zap rootpath builtin env V4: - Zap the checkpatch issues - Update comments V5: - Don't configure VGEN1 - Set FPGA into reset in SPL - Drop ECSPI1 and add ECSPI3 mux - Drop UART1 and add UART3, UART4 muxes - Add separate mux option for the RGMII pins which doesn't set SPEED field - Move the configuration of RGMII after they were configured in GPIO mode diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 106aed9..4da1923 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -411,6 +411,9 @@ config TARGET_GW_VENTANA config TARGET_HUMMINGBOARD bool Support hummingboard +config TARGET_KOSAGI_NOVENA + bool Support Kosagi Novena + config TARGET_TQMA6 bool TQ Systems TQMa6 board @@ -637,6 +640,7 @@ source board/imx31_phycore/Kconfig source board/isee/igep0033/Kconfig source board/jornada/Kconfig source board/karo/tx25/Kconfig +source board/kosagi/novena/Kconfig source board/logicpd/imx27lite/Kconfig source board/logicpd/imx31_litekit/Kconfig source board/mpl/vcma9/Kconfig diff --git a/board/kosagi/novena/Kconfig b/board/kosagi/novena/Kconfig new file mode 100644 index 000..4e52be9 --- /dev/null +++ b/board/kosagi/novena/Kconfig @@ -0,0 +1,23 @@ +if TARGET_KOSAGI_NOVENA + +config SYS_CPU + string + default armv7 See http://patchwork.ozlabs.org/patch/397186/. According to Masahiro, strings is not required and can be dropped. Dropped, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
On 10/09/2014 04:03 PM, Marek Vasut wrote: On Thursday, October 09, 2014 at 10:37:52 AM, Michal Simek wrote: Hi, Hi! I changed the subject, since it long didn't match the topic. On 10/08/2014 10:09 PM, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote: Hi, On 10/07/2014 02:45 PM, Marek Vasut wrote: Hey, given that we now have most of the u-boot socfpga stuff in mainline, I decided it would be a good idea to list what we're still missing and we should also decide how to move on now. First thing I should probably clarify is the late acceptance of the socfpga patches. This is certainly not something we do regularly and is one of the worst possible practices to do, but this time it felt rather important to get the platform in shape, so this exception happened. Furthermore, all of the code in u-boot-socfpga should be based on u-boot-arm and should be submitted through the u-boot-arm repository, not directly to u-boot . Platform was in this shape for a while that's why I can't see the reason why this happen. Tom: Does it mean that every platform which is not in good shape can go directly to the mainline in any time? It is definitely something which is good to know. So, it's a long standing thing where for non-core changes, deferring to the relevant custodian about what's going to come in close to the release is what's done. So yes, I grilled Marek about what non-socfpga things would be impacted by the changes (RPi) and if he'd tested things there. It all had been through a few post/review cycles. There's an argument to be made that we shouldn't have let socfpga in, back in 2012 or should have pushed harder, sooner, to get more progress made on real platform support. AFAIK if platform is working in certain state and you are able to get for example console than there is no problem to be in. There is nowhere written what exactly should work that's why I can't see any problem that socfpga is in if it is not causing compilation issues and have at least minimum functionality. This was not the case in here. The platform was completely unusable. I think that doesn't matter too much now because it was just merged in. Also I think that a lot of platforms are in u-boot and only one person has tested it. For completely new platform this is likely the case. Simply we have to trust to submitter than this is working. The question was if the problem was that Altera just failed because didn't collect patches to any repo and sending it to Albert. Or there was just misunderstanding that Albert expected that Altera will do that and Altera expected that Albert will pick it up because he is ARM custodian and none was listed for socfpga. I have to defend Altera guys because if none is listed for SocFpga the nearest maintainer is collecting patches. It was not Altera guys who started submitting patches to put this thing in shape. Altera only realized that things started to move after Pavel sent the initial blob-of-a-patch . Since then, we are moving forward. Progress is important but should be done in a way which is standard. Then there was discussion that none did care about socfpga patches and problem was resolved by creating socfpga repository and Marek became custodian for it. Marek collected that patches to the new repo and also I believe add new one and rebased them on the top of current tree and send them out as one big 51 series which is not possible to even properly review. Patches which were contained to the architecture for the most part, mind you. The rest were fixes for issues which appeared during this development, thus fixing issues in U-Boot. IMHO they should be sent separated to target exact audience which do care about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste. I fully agree on this part. great. But I am still missing the point why that patches was that urgent that they were merged to rc3 when it was claimed that socfpga was in a wrong shape for a while. It means v2014.10 should be just another broken version for socfpga and all this mess should be solved properly in 2015.01 via socfpga repo. Yes, this would mean that another broken version would be released even though the fixes were available. This doesn't sound right to me. Aug 2 merge windows was closed and Pavel sent RFC to mailing list Sep 3. And Sep 8 I have replied to him to move things to drivers/fpga. http://lists.denx.de/pipermail/u-boot/2014-September/188311.html That's why I don't think that at least fpga part was sent to the mailing list at proper time. Maybe I am just wrong and you will find out any really ancient commit with fpga code that I have no problem to admit that I was wrong with fpga part. And because patches went into rc3 and yesterday Jeroen is reporting problem on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/) This problem was discovered in a patch
[U-Boot] [PATCH] am335x_evm: Correct raw portions of DFU alt into
Signed-off-by: Tom Rini tr...@ti.com --- include/configs/am335x_evm.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 163eadc..8aedc95 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -343,10 +343,10 @@ boot part 0 1; \ rootfs part 0 2; \ MLO fat 0 1; \ - MLO.raw mmc 0x100 0x100; \ - u-boot.img.raw mmc 0x300 0x400; \ - spl-os-args.raw mmc 0x80 0x80; \ - spl-os-image.raw mmc 0x900 0x2000; \ + MLO.raw raw 0x100 0x100; \ + u-boot.img.raw raw 0x300 0x400; \ + spl-os-args.raw raw 0x80 0x80; \ + spl-os-image.raw raw 0x900 0x2000; \ spl-os-args fat 0 1; \ spl-os-image fat 0 1; \ u-boot.img fat 0 1; \ @@ -373,7 +373,7 @@ fdt ram 0x80F8 0x8; \ ramdisk ram 0x8100 0x400\0 #define DFUARGS \ - dfu_alt_info_emmc=rawemmc mmc 0 3751936\0 \ + dfu_alt_info_emmc=rawemmc raw 0 3751936\0 \ DFU_ALT_INFO_MMC \ DFU_ALT_INFO_RAM \ DFU_ALT_INFO_NAND -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/19] [RFC] Power(full) framework based on Driver Model
Hello, On 10/09/2014 08:05 AM, Simon Glass wrote: Hi, On 8 October 2014 14:55, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello all, On 10/08/2014 10:48 PM, Przemyslaw Marczak wrote: [snip] I missed one thing - this should be applied on the top of the u-boot-dm/working tree, which is now: dm: gpio: Remove unused get_state() uclass method (2109ad5b8d4298d4ee9e9ba612d151c2bf65dd1a) Thanks - also is it available in a git tree somewhere please? Regards, Simon No problem, it is available here: https://bobenst...@github.com/bobenstein/u-boot.git branch: dm-working-pmic 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] Discussion topics / issues
On Thu, Oct 09, 2014 at 04:45:07PM +0200, Michal Simek wrote: On 10/09/2014 04:03 PM, Marek Vasut wrote: On Thursday, October 09, 2014 at 10:37:52 AM, Michal Simek wrote: Hi, Hi! I changed the subject, since it long didn't match the topic. [snip] If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? I don't this Albert is the problem, I am starting to suspect we simply lack custodian manpower in general. And I also suspect we're not quite inviting and attractive crowd, which is something we should discuss too ... +1 on this. Yes, lets talk more about this. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] net: Add a command to access the EEPROM from ethernet devices
On Thursday, October 09, 2014 at 01:42:49 PM, Alban Bedel wrote: Many ethernet devices use an EEPROM to store various settings, most commonly the device MAC address. But on some devices it can contains a lot more, for example USB device might also have many USB related parameters. This commit add a set of commands to read/write this EEPROM, write a default configuration and read/write the device MAC address. The defaults command allow priming the EEPROM for devices that need more than just a MAC address in the EEPROM. Signed-off-by: Alban Bedel alban.be...@avionic-design.de I will not comment on the code yet, but would like to discuss the concept instead. I wonder, can we not have a more generic command here? One which can manage the ethernet device altogether, not just adjust it's eeprom? Something like 'ethtool' in Linux ... What do you think please ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
On Thursday, October 09, 2014 at 05:57:47 PM, Tom Rini wrote: On Thu, Oct 09, 2014 at 04:45:07PM +0200, Michal Simek wrote: On 10/09/2014 04:03 PM, Marek Vasut wrote: On Thursday, October 09, 2014 at 10:37:52 AM, Michal Simek wrote: Hi, Hi! I changed the subject, since it long didn't match the topic. [snip] If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? I don't this Albert is the problem, I am starting to suspect we simply lack custodian manpower in general. And I also suspect we're not quite inviting and attractive crowd, which is something we should discuss too ... +1 on this. Yes, lets talk more about this. Also a CI would really help. Vadim was already proposing one last year too, we should certainly review the outcome on that. 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 fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? 2) Can either of you guys please prepare a patch? 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] net: asix: Add support for AX88772B
On Thursday, October 09, 2014 at 05:43:30 AM, Alexandre Courbot wrote: This USB device works as-is on this driver. Signed-off-by: Alexandre Courbot acour...@nvidia.com Acked-by: Marek Vasut ma...@denx.de It's a network device, but it's also USB. Joe, do you want to pick this up please? Alexandre, please keep an eye on the patch and if it doesn't get picked up for a week or so, poke me and I'll pick it through USB. I would be even OK if such a trivial thing made it into 2014.10, but I'm not in position to vouch on that right now. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [SoCFPGA] next steps
On 9 October 2014 19:12, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 01:20:23 PM, Jagan Teki wrote: On 9 October 2014 14:07, Michal Simek mon...@monstr.eu wrote: Hi, On 10/08/2014 10:09 PM, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:58:24AM +0200, Michal Simek wrote: Hi, On 10/07/2014 02:45 PM, Marek Vasut wrote: Hey, given that we now have most of the u-boot socfpga stuff in mainline, I decided it would be a good idea to list what we're still missing and we should also decide how to move on now. First thing I should probably clarify is the late acceptance of the socfpga patches. This is certainly not something we do regularly and is one of the worst possible practices to do, but this time it felt rather important to get the platform in shape, so this exception happened. Furthermore, all of the code in u-boot-socfpga should be based on u-boot-arm and should be submitted through the u-boot-arm repository, not directly to u-boot . Platform was in this shape for a while that's why I can't see the reason why this happen. Tom: Does it mean that every platform which is not in good shape can go directly to the mainline in any time? It is definitely something which is good to know. So, it's a long standing thing where for non-core changes, deferring to the relevant custodian about what's going to come in close to the release is what's done. So yes, I grilled Marek about what non-socfpga things would be impacted by the changes (RPi) and if he'd tested things there. It all had been through a few post/review cycles. There's an argument to be made that we shouldn't have let socfpga in, back in 2012 or should have pushed harder, sooner, to get more progress made on real platform support. AFAIK if platform is working in certain state and you are able to get for example console than there is no problem to be in. There is nowhere written what exactly should work that's why I can't see any problem that socfpga is in if it is not causing compilation issues and have at least minimum functionality. The question was if the problem was that Altera just failed because didn't collect patches to any repo and sending it to Albert. Or there was just misunderstanding that Albert expected that Altera will do that and Altera expected that Albert will pick it up because he is ARM custodian and none was listed for socfpga. I have to defend Altera guys because if none is listed for SocFpga the nearest maintainer is collecting patches. Then there was discussion that none did care about socfpga patches and problem was resolved by creating socfpga repository and Marek became custodian for it. Marek collected that patches to the new repo and also I believe add new one and rebased them on the top of current tree and send them out as one big 51 series which is not possible to even properly review. IMHO they should be sent separated to target exact audience which do care about spi/i2c/watchdog/fpga/soc etc. But maybe that's just matter of taste. But I am still missing the point why that patches was that urgent that they were merged to rc3 when it was claimed that socfpga was in a wrong shape for a while. It means v2014.10 should be just another broken version for socfpga and all this mess should be solved properly in 2015.01 via socfpga repo. And because patches went into rc3 and yesterday Jeroen is reporting problem on FreeBSD because of this merge.(http://patchwork.ozlabs.org/patch/397453/) Regarding your point that all It all had been through a few post/review cycles. I don't think all things have been fixed. Personally me I have reported here http://lists.denx.de/pipermail/u-boot/2014-September/189741.html (sha1: 0ae16cbb40a2881f6dfbe00fcb023ee7b548bc5c) issue with checkpatch.pl which hasn't been fixed. Here is my ACK for one patch which is not present in mainline commit http://lists.denx.de/pipermail/u-boot/2014-September/189747.html (sha1: 2f210639c4f003b0d5310273979441f1bfc88eae) Make no sense to go through all patches but this is just an example. I think it is something what we should discuss at u-boot mini summit on Monday. I discussed this with Marek over IRC yesterday and I expect he will ping me today (because of this email :-) ). If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? I think this traversing the actual development process in a different direction and it must be a valid point that need to discuss. Apart from this, I'm experienced an another isuue where some of the subsystem patches (say for example spi stuff) are pushed in a different direction. http://patchwork.ozlabs.org/patch/346015/ These are the qspi stuff from freescale, and I didn't understand why these goes into u-boot-arm/master. And
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
Hi Marek, On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? If you have CONFIG_SYS_STDIO_DEREGISTER, CONFIG_DM and CONFIG_DM_SERIAL set then I'm not sure. I made sure that sandbox has all of these but it might be the only board. 2) Can either of you guys please prepare a patch? Best regards, Marek Vasut Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
On Thursday, October 09, 2014 at 06:11:37 PM, Jagan Teki wrote: [...] These are the qspi stuff from freescale, and I didn't understand why these goes into u-boot-arm/master. And there is no intimation of mine as well. Did you comment on them at all please ? While I disagree with them bypassing your tree, I see they were rotting on the ML for a month and then Albert then picked those. This is not a question of commenting - but - about the process. Yes, I asked the author to test the changes later for a while this got pushed. I never thought this could happen so suddenly without any ping or something. I guess some times it happens few of the patches will rotted for a while on ML due to some delays, but taking them with/out any ping causes over head if the respective owner will look at the code for later modifications. I agree with you that there is a problem where custodians get bypassed and that such a thing happened to me as well. This is sporadic, but apparently annoying enough, so this should be added. Issue is that the driver itself is not in a proper shape, why does subsystem patches were pushed without the the review tag from a respective custodians. I produced a hypothesis above. Can you retroactively comment on them and ask the author to fix the code? Yes - I asked the author for fixing those for few of the patches against that change. Thanks! Please try to discuss this point as well Each subsystem patch(es) should be pushed if and only if the respective custodian should marked the review tag I agree we have an issue here, but I would suggest we move this discussion into a separate thread now. The subject of the email does not match the topic of the thread by far. Agreed - I mentioned this on this tread only for listing item on meeting, that it. Will you join us as well? (sorry, I lost track of who will and who won't) 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 fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
On Thu, Oct 09, 2014 at 05:12:03PM +0200, Marek Vasut wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? Because only sandbox uses this right now I think. But I'm unhappy that I can't seem to make repeated runs of: $ ./tools/buildman/buildman -b master -c 1 -ve -T 1 -j 9 \ 'arc|blackfin|microblaze|m68k|nds32|sparc|x86|aarch64|sandbox|mips|avr32|arm|powerpc' $ ./tools/buildman/buildman -b master -c 1 -ve -T 1 -j 9 \ 'arc|blackfin|microblaze|m68k|nds32|sparc|x86|aarch64|sandbox|mips|avr32|arm|powerpc' \ -svel Show me just new problems from the last time I did it. I must be doing something wrong, Simon? -- 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] Discussion topics / issues
On Thu, Oct 09, 2014 at 06:10:12PM +0200, Marek Vasut wrote: On Thursday, October 09, 2014 at 05:57:47 PM, Tom Rini wrote: On Thu, Oct 09, 2014 at 04:45:07PM +0200, Michal Simek wrote: On 10/09/2014 04:03 PM, Marek Vasut wrote: On Thursday, October 09, 2014 at 10:37:52 AM, Michal Simek wrote: Hi, Hi! I changed the subject, since it long didn't match the topic. [snip] If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? I don't this Albert is the problem, I am starting to suspect we simply lack custodian manpower in general. And I also suspect we're not quite inviting and attractive crowd, which is something we should discuss too ... +1 on this. Yes, lets talk more about this. Also a CI would really help. Vadim was already proposing one last year too, we should certainly review the outcome on that. I don't think anything went too far on that, but in a follow-up elsewhere I'm not having buildman do something I thought it did, but perhaps I imagined, which was only show me new problems since the last time it ran. -- 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 01/19] lib: errno: introduce errno_str(): returns errno related message
Hello Joakim, On 10/09/2014 08:46 AM, Joakim Tjernlund wrote: From: Przemyslaw Marczak p.marc...@samsung.com The functions error's numbers are standarized - but the error messages are not. The errors are often handled with unclear error messages, so why not use an errno standarized messages. Advantages: - This could decrease the binary size. Having an array of string ptrs adds some extra space needs. Each str needs a ptr and that ptr needs relocation, 8 bytes on 32 bits If you want to save space do this instead static const char const errno_message[] = Success\0Operation not permitted\0No such file or directory etc. Then count \0 to find the error msg. Jocke Is this really a problem to add some array with the pointers? You are right, this array requires some additional space, but this is not the main reason of introducing this function. This can be enabled optional, so maybe for the less memory and slower devices this shouldn't be used - but in the other way, we see many text messages in the code that could be replaced with the one from that array. So, which is better? This helps me sometimes, so I added this as some extra feature. 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] u-boot, fsl_espi.c driver
Dear Joakim,
Thanks for raising a concern.
It's not fair to blame the last person who submitted a patch. We are all working
to make it better as an opensource comminuty. You have done a good job to hack
it to work. Would it be nicer if you can submit this or improved patch to u-boot
community for further review and testing, after putting informing commit
message? The mailing list address is CC'ed.
York
On 10/09/2014 09:14 AM, Joakim Tjernlund wrote:
Guys, I noticed you have added to the fsl eSPI driver and you work for
Freescale.
This driver is broken beyond words, just look what I had to hack to load a
FPGA over SPI(below).
I hope you can take the time to fix the driver.
From e73b8bd36b42e39ee9e22b48deca3a54fbffe4ac Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund joakim.tjernl...@transmode.se
Date: Mon, 3 Mar 2014 16:30:35 +0100
Subject: [PATCH] Fast fixes to make eSPI driver work.
The whole driver stinks, needs to be rewritten.
---
drivers/spi/fsl_espi.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
index ae0fe58..f5a8fcc 100644
--- a/drivers/spi/fsl_espi.c
+++ b/drivers/spi/fsl_espi.c
@@ -45,6 +45,8 @@ struct fsl_spi_slave {
#define ESPI_COM_CS(x) ((x) 30)
#define ESPI_COM_TRANLEN(x)((x) 0)
+#define ESPI_COM_TO (1 (31 - 4))
+
#define ESPI_CSMODE_CI_INACTIVEHIGH(1 31)
#define ESPI_CSMODE_CP_BEGIN_EDGCLK(1 30)
@@ -165,8 +167,9 @@ int spi_claim_bus(struct spi_slave *slave)
| ESPI_CSMODE_CI_INACTIVEHIGH);
/* Character bit order: msb first */
- out_be32(espi-csmode[cs], in_be32(espi-csmode[cs])
- | ESPI_CSMODE_REV_MSB_FIRST);
+ if (!(mode SPI_LSB_FIRST))
+ out_be32(espi-csmode[cs], in_be32(espi-csmode[cs])
+| ESPI_CSMODE_REV_MSB_FIRST);
/* Character length in bits, between 0x3~0xf, i.e. 4bits~16bits */
out_be32(espi-csmode[cs], in_be32(espi-csmode[cs])
@@ -302,14 +305,15 @@ int spi_xfer(struct spi_slave *slave, unsigned int
bitlen, const void *data_out,
*(uint *)data_out, data_out, *(uint *)data_in, data_in,
len);
num_chunks = DIV_ROUND_UP(data_len, max_tran_len);
+ dout = buffer;
while (num_chunks--) {
if (data_in)
din = buffer + rx_offset;
- dout = buffer;
tran_len = min(data_len , max_tran_len);
num_blks = DIV_ROUND_UP(tran_len + cmd_len, 4);
num_bytes = (tran_len + cmd_len) % 4;
fsl-data_len = tran_len + cmd_len;
+ data_len -= tran_len;
spi_cs_activate(slave);
/* Clear all eSPI events */
@@ -320,12 +324,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int
bitlen, const void *data_out,
if (event ESPI_EV_TNF) {
fsl_espi_tx(fsl, dout);
/* Set up the next iteration */
- if (len 4) {
- len -= 4;
- dout += 4;
- }
+ len -= 4;
+ dout += 4;
}
+ num_blks--;
event = in_be32(espi-event);
if (event ESPI_EV_RNE) {
rf_cnt = ((event ESPI_EV_RFCNT_MASK)
@@ -338,7 +341,6 @@ int spi_xfer(struct spi_slave *slave, unsigned int
bitlen, const void *data_out,
continue;
if (fsl_espi_rx(fsl, din, rx_bytes)
== rx_bytes) {
- num_blks--;
if (din)
din = (unsigned char *)din
+ rx_bytes;
@@ -374,6 +376,7 @@ void spi_cs_activate(struct spi_slave *slave)
com = ~(ESPI_COM_CS(0x3) | ESPI_COM_TRANLEN(0x));
com |= ESPI_COM_CS(slave-cs);
+ com |= ESPI_COM_TO;
com |= ESPI_COM_TRANLEN(data_len - 1);
out_be32(espi-com, com);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote: Hi Marek, On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? If you have CONFIG_SYS_STDIO_DEREGISTER, CONFIG_DM and CONFIG_DM_SERIAL set then I'm not sure. I made sure that sandbox has all of these but it might be the only board. I see, error on my end then. I will start building sandbox for the USB tree. Thank you for pointing this out! This also stresses my point that U-Boot project does need a proper CI (which we could have had thanks to Vadim, but we didn't persudate that, dang again). I think this CI stuff should be added to the agenda of the U-Boot minisummit discussion. Another point to the CI discussion could be that we could prepare a docker image with all the toolchains preinstalled, so one can run buildman easily in a well defined environment on his/her own. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
On Thursday, October 09, 2014 at 06:25:30 PM, Tom Rini wrote: On Thu, Oct 09, 2014 at 06:10:12PM +0200, Marek Vasut wrote: On Thursday, October 09, 2014 at 05:57:47 PM, Tom Rini wrote: On Thu, Oct 09, 2014 at 04:45:07PM +0200, Michal Simek wrote: On 10/09/2014 04:03 PM, Marek Vasut wrote: On Thursday, October 09, 2014 at 10:37:52 AM, Michal Simek wrote: Hi, Hi! I changed the subject, since it long didn't match the topic. [snip] If there is a problem because Albert is just too busy we should at least try to find out any reasonable way how to handle this. Like in Linux ARM-SOC custodian? I don't this Albert is the problem, I am starting to suspect we simply lack custodian manpower in general. And I also suspect we're not quite inviting and attractive crowd, which is something we should discuss too ... +1 on this. Yes, lets talk more about this. Also a CI would really help. Vadim was already proposing one last year too, we should certainly review the outcome on that. I don't think anything went too far on that, but in a follow-up elsewhere I'm not having buildman do something I thought it did, but perhaps I imagined, which was only show me new problems since the last time it ran. Tom, I think we should start building a list for the discussion. There seem to be an awful lot of ideas on what to discuss spurring here, but is anyone taking notes ? Should I or shall we start logging this into some wiki ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
On 9 October 2014 21:45, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 06:11:37 PM, Jagan Teki wrote: [...] These are the qspi stuff from freescale, and I didn't understand why these goes into u-boot-arm/master. And there is no intimation of mine as well. Did you comment on them at all please ? While I disagree with them bypassing your tree, I see they were rotting on the ML for a month and then Albert then picked those. This is not a question of commenting - but - about the process. Yes, I asked the author to test the changes later for a while this got pushed. I never thought this could happen so suddenly without any ping or something. I guess some times it happens few of the patches will rotted for a while on ML due to some delays, but taking them with/out any ping causes over head if the respective owner will look at the code for later modifications. I agree with you that there is a problem where custodians get bypassed and that such a thing happened to me as well. This is sporadic, but apparently annoying enough, so this should be added. Ok - thanks. Issue is that the driver itself is not in a proper shape, why does subsystem patches were pushed without the the review tag from a respective custodians. I produced a hypothesis above. Can you retroactively comment on them and ask the author to fix the code? Yes - I asked the author for fixing those for few of the patches against that change. Thanks! Please try to discuss this point as well Each subsystem patch(es) should be pushed if and only if the respective custodian should marked the review tag I agree we have an issue here, but I would suggest we move this discussion into a separate thread now. The subject of the email does not match the topic of the thread by far. Agreed - I mentioned this on this tread only for listing item on meeting, that it. Will you join us as well? (sorry, I lost track of who will and who won't) I'm unable to join this, hope you guys have more fun than last year :) thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot, fsl_espi.c driver
On 9 October 2014 21:55, York Sun york...@freescale.com wrote:
Dear Joakim,
Thanks for raising a concern.
It's not fair to blame the last person who submitted a patch. We are all
working
to make it better as an opensource comminuty. You have done a good job to hack
it to work. Would it be nicer if you can submit this or improved patch to
u-boot
community for further review and testing, after putting informing commit
message? The mailing list address is CC'ed.
Could you please elaborate the issue?
On 10/09/2014 09:14 AM, Joakim Tjernlund wrote:
Guys, I noticed you have added to the fsl eSPI driver and you work for
Freescale.
This driver is broken beyond words, just look what I had to hack to load a
FPGA over SPI(below).
I hope you can take the time to fix the driver.
From e73b8bd36b42e39ee9e22b48deca3a54fbffe4ac Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund joakim.tjernl...@transmode.se
Date: Mon, 3 Mar 2014 16:30:35 +0100
Subject: [PATCH] Fast fixes to make eSPI driver work.
The whole driver stinks, needs to be rewritten.
---
drivers/spi/fsl_espi.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
index ae0fe58..f5a8fcc 100644
--- a/drivers/spi/fsl_espi.c
+++ b/drivers/spi/fsl_espi.c
@@ -45,6 +45,8 @@ struct fsl_spi_slave {
#define ESPI_COM_CS(x) ((x) 30)
#define ESPI_COM_TRANLEN(x)((x) 0)
+#define ESPI_COM_TO (1 (31 - 4))
+
#define ESPI_CSMODE_CI_INACTIVEHIGH(1 31)
#define ESPI_CSMODE_CP_BEGIN_EDGCLK(1 30)
@@ -165,8 +167,9 @@ int spi_claim_bus(struct spi_slave *slave)
| ESPI_CSMODE_CI_INACTIVEHIGH);
/* Character bit order: msb first */
- out_be32(espi-csmode[cs], in_be32(espi-csmode[cs])
- | ESPI_CSMODE_REV_MSB_FIRST);
+ if (!(mode SPI_LSB_FIRST))
+ out_be32(espi-csmode[cs], in_be32(espi-csmode[cs])
+| ESPI_CSMODE_REV_MSB_FIRST);
/* Character length in bits, between 0x3~0xf, i.e. 4bits~16bits */
out_be32(espi-csmode[cs], in_be32(espi-csmode[cs])
@@ -302,14 +305,15 @@ int spi_xfer(struct spi_slave *slave, unsigned int
bitlen, const void *data_out,
*(uint *)data_out, data_out, *(uint *)data_in, data_in,
len);
num_chunks = DIV_ROUND_UP(data_len, max_tran_len);
+ dout = buffer;
while (num_chunks--) {
if (data_in)
din = buffer + rx_offset;
- dout = buffer;
tran_len = min(data_len , max_tran_len);
num_blks = DIV_ROUND_UP(tran_len + cmd_len, 4);
num_bytes = (tran_len + cmd_len) % 4;
fsl-data_len = tran_len + cmd_len;
+ data_len -= tran_len;
spi_cs_activate(slave);
/* Clear all eSPI events */
@@ -320,12 +324,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int
bitlen, const void *data_out,
if (event ESPI_EV_TNF) {
fsl_espi_tx(fsl, dout);
/* Set up the next iteration */
- if (len 4) {
- len -= 4;
- dout += 4;
- }
+ len -= 4;
+ dout += 4;
}
+ num_blks--;
event = in_be32(espi-event);
if (event ESPI_EV_RNE) {
rf_cnt = ((event ESPI_EV_RFCNT_MASK)
@@ -338,7 +341,6 @@ int spi_xfer(struct spi_slave *slave, unsigned int
bitlen, const void *data_out,
continue;
if (fsl_espi_rx(fsl, din, rx_bytes)
== rx_bytes) {
- num_blks--;
if (din)
din = (unsigned char *)din
+ rx_bytes;
@@ -374,6 +376,7 @@ void spi_cs_activate(struct spi_slave *slave)
com = ~(ESPI_COM_CS(0x3) | ESPI_COM_TRANLEN(0x));
com |= ESPI_COM_CS(slave-cs);
+ com |= ESPI_COM_TO;
com |= ESPI_COM_TRANLEN(data_len - 1);
out_be32(espi-com, com);
}
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
Hi Tom, On 9 October 2014 10:23, Tom Rini tr...@ti.com wrote: On Thu, Oct 09, 2014 at 05:12:03PM +0200, Marek Vasut wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? Because only sandbox uses this right now I think. But I'm unhappy that I can't seem to make repeated runs of: $ ./tools/buildman/buildman -b master -c 1 -ve -T 1 -j 9 \ 'arc|blackfin|microblaze|m68k|nds32|sparc|x86|aarch64|sandbox|mips|avr32|arm|powerpc' $ ./tools/buildman/buildman -b master -c 1 -ve -T 1 -j 9 \ 'arc|blackfin|microblaze|m68k|nds32|sparc|x86|aarch64|sandbox|mips|avr32|arm|powerpc' \ -svel Show me just new problems from the last time I did it. I must be doing something wrong, Simon? I don't really see anything obviously wrong. But I'm not sure what you are expecting. This is going to just build the top commit in branch master, and if the commit hash has changed it will remove any previous results for that commit before starting the build. So you will always get a full list of errors, not a delta from last time. If you want that you could add a second commit with your fixes and not adjust the first commit in the branch (and use -c2). If you leave off '-b master -c1' it would have about the same effect, assuming that you have 'master' checked out. In the second line you are specifying -ve twice but that doesn't matter. Why are you changing the thread/jobs defaults? Does that speed it up? Also you don't need the quotes and the | between archs. Also note there is --step to avoid building every commit. For example, this will build the upstream commit and your branch's top commit (only) assuming that master tracks upstream/master. buildman -b master --step 0 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
Hi Marek, On 9 October 2014 10:27, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote: Hi Marek, On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? If you have CONFIG_SYS_STDIO_DEREGISTER, CONFIG_DM and CONFIG_DM_SERIAL set then I'm not sure. I made sure that sandbox has all of these but it might be the only board. I see, error on my end then. I will start building sandbox for the USB tree. Thank you for pointing this out! This also stresses my point that U-Boot project does need a proper CI (which we could have had thanks to Vadim, but we didn't persudate that, dang again). What is a Cl? Do you mean his gerrit code review stuff? I think this CI stuff should be added to the agenda of the U-Boot minisummit discussion. Another point to the CI discussion could be that we could prepare a docker image with all the toolchains preinstalled, so one can run buildman easily in a well defined environment on his/her own. Best regards, Marek Vasut Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
On Thu, Oct 09, 2014 at 11:03:02AM -0600, Simon Glass wrote: Hi Tom, On 9 October 2014 10:23, Tom Rini tr...@ti.com wrote: On Thu, Oct 09, 2014 at 05:12:03PM +0200, Marek Vasut wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? Because only sandbox uses this right now I think. But I'm unhappy that I can't seem to make repeated runs of: $ ./tools/buildman/buildman -b master -c 1 -ve -T 1 -j 9 \ 'arc|blackfin|microblaze|m68k|nds32|sparc|x86|aarch64|sandbox|mips|avr32|arm|powerpc' $ ./tools/buildman/buildman -b master -c 1 -ve -T 1 -j 9 \ 'arc|blackfin|microblaze|m68k|nds32|sparc|x86|aarch64|sandbox|mips|avr32|arm|powerpc' \ -svel Show me just new problems from the last time I did it. I must be doing something wrong, Simon? I don't really see anything obviously wrong. But I'm not sure what you are expecting. This is going to just build the top commit in branch master, and if the commit hash has changed it will remove any previous results for that commit before starting the build. So you will always get a full list of errors, not a delta from last time. If you want that you could add a second commit with your fixes and not adjust the first commit in the branch (and use -c2). Ah, OK, this got me going towards what I wanted. I was assuming for some incorrect reason that with -c1 it would just implicitly compare vs the last build it had available. I really want -c2 as I should have a full build from the last go-round (which is to say really, last merge). This is what I wanted (a simplified build): trini@bill-the-cat:~/work/u-boot/u-boot (32d0192...)$ ./tools/buildman/buildman -b HEAD -c 2 -ve -T 1 -j 9 'sandbox|sparc' -svel boards.cfg is up to date. Nothing to do. Summary of 2 commits for 6 boards (1 thread, 9 jobs per thread) 01: usb: kbd: Remove check for already being registered sparc: + grsim_leon2 gr_cpci_ax2000 gr_xc3s_1500 grsim gr_ep2s60 +(grsim_leon2,gr_cpci_ax2000,gr_xc3s_1500,grsim,gr_ep2s60) disk/part.c: In function `get_device': +(grsim_leon2,gr_cpci_ax2000,gr_xc3s_1500,grsim,gr_ep2s60) disk/part.c:454: warning: 'hwpart' might be used uninitialized in this function 02: stdio: Add force parameter to stdio_deregister sandbox: + sandbox +(sandbox) drivers/serial/serial-uclass.c: In function ‘serial_pre_remove’: +(sandbox) drivers/serial/serial-uclass.c:201:2: error: too few arguments to function ‘stdio_deregister_dev’ +(sandbox) include/stdio_dev.h:107:5: note: declared here +(sandbox) make[2]: *** [drivers/serial/serial-uclass.o] Error 1 +(sandbox) make[1]: *** [drivers/serial] Error 2 +(sandbox) make: *** [sub-make] Error 2 w+(sandbox) drivers/serial/serial-uclass.c:201:39: warning: left-hand operand of comma expression has no effect [-Wunused-value] And I don't care about the stuff around 01 (it was like that before), I care about 02 which is new problems. If you leave off '-b master -c1' it would have about the same effect, assuming that you have 'master' checked out. In the second line you are specifying -ve twice but that doesn't matter. Why are you changing the thread/jobs defaults? Does that speed it up? We have some race condition still on very large machines that I haven't been able to track down. Doing it that way was less problematic I think. Also you don't need the quotes and the | between archs. Oh, interesting. Also note there is --step to avoid building every commit. For example, this will build the upstream commit and your branch's top commit (only) assuming that master tracks upstream/master. buildman -b master --step 0 I think this is what I really wanted, yes. -- 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 v1 1/1] fs: fat/ext4/sandbox: Deal with files 2GB in ls and size commands
+Tom for the question below re return values
Hi,
On 8 October 2014 15:54, Suriyan Ramasami suriya...@gmail.com wrote:
On Wed, Oct 8, 2014 at 1:44 PM, Simon Glass s...@chromium.org wrote:
Hi Suriyan,
On 8 October 2014 14:23, Suriyan Ramasami suriya...@gmail.com wrote:
The commands fatls/ext4ls give -ve values when dealing with files 2GB.
The commands fatsize/ext4size do not update the variable filesize for
these files.
To deal with this, the functions *_size have been modified to take a second
parameter of type * off_t which is then populated. The return value of
the
*_size function is then only used to determine error conditions.
That seems like a sensible idea to me.
Hello Simon,
I got the reply from Pavel as I was writing this. So, what do you
think of just changing the return value of these functions to off64_t
?
I don't have strong views on this but I believe it is slightly better
to use a consistent error return value from all functions (int) as you
have done and put loff_t or whatever as a parameter. Even for the size
functions this seems better once we move to handling 2GB or 4GB.
But yes a 64-bit value seems prudent despite the overhead.
Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
arch/sandbox/cpu/os.c| 14 +--
arch/sandbox/cpu/state.c | 6 ++---
common/board_f.c | 6 ++---
fs/ext4/ext4_common.c| 13 +--
fs/ext4/ext4fs.c | 21 ++---
fs/fat/fat.c | 61
fs/fs.c | 15 ++--
fs/sandbox/sandboxfs.c | 23 --
include/ext4fs.h | 4 ++--
include/fat.h| 2 +-
include/fs.h | 2 +-
include/os.h | 2 +-
include/sandboxfs.h | 2 +-
13 files changed, 103 insertions(+), 68 deletions(-)
Thanks for doing this. Do you think you could also add a test for this
(perhaps in test/fs). It could create a temporary ext2 filesystem, put
a large file in it and then check a few operations.
Thanks for pointing out the test directory. I was unaware of its
existence. I shall indeed add some test cases.
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 1c4aa3f..9b052ee 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -385,15 +385,15 @@ const char *os_dirent_get_typename(enum os_dirent_t
type)
return os_dirent_typename[OS_FILET_UNKNOWN];
}
-ssize_t os_get_filesize(const char *fname)
+int os_get_filesize(const char *fname, off_t *size)
{
struct stat buf;
int ret;
ret = stat(fname, buf);
- if (ret)
- return ret;
- return buf.st_size;
+ if (ret == 0)
+ *size = buf.st_size;
+ return ret;
}
void os_putc(int ch)
@@ -427,10 +427,10 @@ int os_read_ram_buf(const char *fname)
{
struct sandbox_state *state = state_get_current();
int fd, ret;
- int size;
+ off_t size;
- size = os_get_filesize(fname);
- if (size 0)
+ ret = os_get_filesize(fname, size);
+ if (ret 0)
return -ENOENT;
Should you return ret instead here (and in other cases below)?
I wanted to keep the return values as consistent with the original, so
as to preserve same behavior before this code change.
os_get_filesize() calls the stat() function in sandbox, and that has
quite a many failure return values. I did not check if they are
handled by the callers of os_read_ram_buf().
I am OK to change it, but then have to follow up on all the callers of
os_read_ram_buf() to see if they are indeed gracefully handling the
error conditions.
Yes you can change it, there is only one caller and it doesn't check
the specific error.
This is also the reasoning (potentially flawed) in general that I
followed when the *_size() functions are being used by calls which do
the actual read from the file. In those cases, I have reverted to
previous behavior where I return an int as before, assuming that a
call to read more than 2G of data might not be issued.
I am assuming, to be clean, more effort in consistently using size_t
would be apt all across the code. Right?
if (size != state-ram_size)
return -ENOSPC;
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index 59adad6..e0d119a 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -49,12 +49,12 @@ static int state_ensure_space(int extra_size)
static int state_read_file(struct sandbox_state *state, const char *fname)
{
- int size;
+ off_t size;
int ret;
int fd;
- size = os_get_filesize(fname);
- if (size 0) {
+ ret = os_get_filesize(fname, size);
+ if (ret 0) {
printf(Cannot find
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
On Thursday, October 09, 2014 at 07:03:42 PM, Simon Glass wrote: Hi Marek, On 9 October 2014 10:27, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote: Hi Marek, On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? If you have CONFIG_SYS_STDIO_DEREGISTER, CONFIG_DM and CONFIG_DM_SERIAL set then I'm not sure. I made sure that sandbox has all of these but it might be the only board. I see, error on my end then. I will start building sandbox for the USB tree. Thank you for pointing this out! This also stresses my point that U-Boot project does need a proper CI (which we could have had thanks to Vadim, but we didn't persudate that, dang again). What is a Cl? Do you mean his gerrit code review stuff? I mean more continuous integration (build testing) of the code before a PR is submitted to the ML. Right now, we all do our own thing when it comes to testing before PR, but it would be nice to have one easy way of doing the build testing before submitting the PR, don't you think ? This might apply to Linux too. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot, fsl_espi.c driver
York Sun york...@freescale.com wrote on 2014/10/09 18:25:40:
Dear Joakim,
Thanks for raising a concern.
It's not fair to blame the last person who submitted a patch. We are all
working
No of course not, I just noticed you guys had been in there and patched up
some problem
so I hoped you would be interested to fix the remaining problems. This
driver should never
have been committed in the first place.
to make it better as an opensource comminuty. You have done a good job
to hack
it to work. Would it be nicer if you can submit this or improved patch
to u-boot
community for further review and testing, after putting informing commit
message? The mailing list address is CC'ed.
Main problem with this driver is that TX does not work for:
len max_tran_len (nor does RX)
does not TX the last odd bytes(len % 4 != 0)
Does not work with TX only(RX buf == NULL)
Silently ignores SPI_LSB_FIRST
On top of that it uses malloc all over and copies data back and forth for
no good
reason, image a big SPI transfer with many MB(like my FPGA load).
I am not in a good position fix this properly as my FPGA is TX only so I
cannot test
RX at all(which is broken by my hack)
Finally, just to illustrate the merits of this driver, after transmission
is done
there is:
if (*buffer == 0x0b) {
data_in += tran_len;
data_len -= tran_len;
*(int *)buffer += tran_len;
}
what is the magic 0x0b test all about?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
Hi Marek, On 9 October 2014 11:32, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 07:03:42 PM, Simon Glass wrote: Hi Marek, On 9 October 2014 10:27, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote: Hi Marek, On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote: Hi, On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote: In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede hdego...@redhat.com [...] diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d04104e..61cbdc6 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -197,7 +197,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev)) + if (stdio_deregister_dev(upriv-sdev), 0) That bracket seems to be in a strange place. Good find, thanks! I have two questions: 1) How come I did not notice this and my build didn't spit? If you have CONFIG_SYS_STDIO_DEREGISTER, CONFIG_DM and CONFIG_DM_SERIAL set then I'm not sure. I made sure that sandbox has all of these but it might be the only board. I see, error on my end then. I will start building sandbox for the USB tree. Thank you for pointing this out! This also stresses my point that U-Boot project does need a proper CI (which we could have had thanks to Vadim, but we didn't persudate that, dang again). What is a Cl? Do you mean his gerrit code review stuff? I mean more continuous integration (build testing) of the code before a PR is submitted to the ML. Right now, we all do our own thing when it comes to testing before PR, but it would be nice to have one easy way of doing the build testing before submitting the PR, don't you think ? This might apply to Linux too. Sure it would be useful. Before submitting my pull request I get all the patches in a branch and run: ./tools/buildman/buildman -b x86-push This checks every commit for every board that I build, and gives me good confidence that no patch introduces new breakages. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot, fsl_espi.c driver
Dear Joakim,
On 10/09/2014 10:43 AM, Joakim Tjernlund wrote:
York Sun york...@freescale.com wrote on 2014/10/09 18:25:40:
Dear Joakim,
Thanks for raising a concern.
It's not fair to blame the last person who submitted a patch. We are all
working
No of course not, I just noticed you guys had been in there and patched up
some problem
so I hoped you would be interested to fix the remaining problems. This
driver should never
have been committed in the first place.
to make it better as an opensource comminuty. You have done a good job
to hack
it to work. Would it be nicer if you can submit this or improved patch
to u-boot
community for further review and testing, after putting informing commit
message? The mailing list address is CC'ed.
Main problem with this driver is that TX does not work for:
len max_tran_len (nor does RX)
does not TX the last odd bytes(len % 4 != 0)
Does not work with TX only(RX buf == NULL)
Silently ignores SPI_LSB_FIRST
On top of that it uses malloc all over and copies data back and forth for
no good
reason, image a big SPI transfer with many MB(like my FPGA load).
I am not in a good position fix this properly as my FPGA is TX only so I
cannot test
RX at all(which is broken by my hack)
Finally, just to illustrate the merits of this driver, after transmission
is done
there is:
if (*buffer == 0x0b) {
data_in += tran_len;
data_len -= tran_len;
*(int *)buffer += tran_len;
}
what is the magic 0x0b test all about?
Thanks for the report. Driver maintainer (CC'ed) will take a look.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/49] cti_flash.c: use __weak when requested
On 08-10-14 22:57, Jeroen Hofstee wrote: For performance reason there seems to be a CONFIG_xyz. Introduce a __maybe_weak to allow using __weak directly instead of relying on aliases. Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- drivers/mtd/cfi_flash.c | 50 - 1 file changed, 16 insertions(+), 34 deletions(-) As a reminder to myself, CONFIG_xyz should be CONFIG_CFI_FLASH_USE_WEAK_ACCESSOR. And you seem to need to opt-in for it, not opt-out. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/49] i2c: use __weak
Hello Heiko, On 09-10-14 07:00, Heiko Schocher wrote: Am 08.10.2014 22:57, schrieb Jeroen Hofstee: Signed-off-by: Jeroen Hofsteejer...@myspectrum.nl --- arch/arm/cpu/arm926ejs/cache.c | 5 + This change seems to have nothing to do with the subject ... could you please split this? No problem, I likely accidentally squashed them. I will repost this patch with out it and append a new one. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [FAT/EXT4/SANDBOX] files 2GB
Hello Simon, On Wed, Oct 8, 2014 at 11:16 PM, Simon Glass s...@chromium.org wrote: Hi, On 8 October 2014 07:07, Suriyan Ramasami suriya...@gmail.com wrote: Hello, I recently saw a post about fat commands such as fatls returning -ve values under u-boot for files whose sizes are =2GB. fatsize would also not set up filesize in this case. This also effects ext4/sandbox commands. I just looked at the ones which are handled by fs/fs.c I am thinking of cleaning this up a bit. My question is, is there some kind of preexisting automated test that I can build into u-boot which adds a command which does the test for me? For example, it could use the FS/read/write commands to create files with some pattern that it knows of, reads them for various sizes to check if they are correct etc. Same procedure for the [FS]size command as well. I do have made the changes to correct the behavior. The code change touches the [FS]read part of the code, hence, I want to test it extensively to assure me that I haven't broken anything else. I am nervous about the sandbox related code as I do not know how to even use them! It's quite ad-hoc at present, but there are several things you can follow: - test/cmd_repeat.sh shows how to run sandbox, pass it a command and check the output - test/command_ut.c and test/compression.c shows how to create a new command for testing purposes - test/dm contains driver model tests - there is framework but it is driver-model-specific - test/image shows a python script that creates tests files and runs sandbox to check them - test/vboot is similar for verified boot, although it is a shell script I feel that python is probably best for non-trivial tests. Probably you want to create a filesystem using a loopback device and mkfs, then run sandbox U-Boot to perform various operations. Then you could check the output from U-Boot and/or the resulting filesystem when U-Boot is finished. It would be great to have even a basic test for filesystems. I suggest you try to make it filesystem-agnostic - i.e. implement it for ext4 but make it extensible later for other filesystems. Thank you for the specifics and the details. I shall go over them and implement some kind of basic filesystem testing framework. - Regards - Suriyan Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 49/49] i2c: designware: add an implement i2c protos
Hello Heiko, On 09-10-14 07:05, Heiko Schocher wrote: Hello Jeroen, Am 08.10.2014 22:58, schrieb Jeroen Hofstee: Include the i2c header and change the non confirming functions to do so. Cc: Heiko Schocherh...@denx.de Signed-off-by: Jeroen Hofsteejer...@myspectrum.nl --- drivers/i2c/designware_i2c.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) Acked-by: Heiko Schocher h...@denx.de (It would be nice to see this driver also moved to the CONFIG_SYS_I2C framework ... seeing a CONFIG_I2C_MULTI_BUS define in it is very bad ...) Likely, but I happily leave that to someone who can actually test the code and has a better understanding of the (new?) i2c model ;) Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch] configs:ks2_evm: update defconfigs to support SPL
From: Murali Karicheri m-kariche...@ti.com The K2HK and K2E boards support SPL by default, so add CONFIG_SPL option. Also export CONFIG_ARM, CONFIG_ARCH_KEYSTONE and TARGET_K2*_EVM options to spl/.config as they are the same. So now it's convinient to build gph images using only two commands: make k2hk_evm_defconfig make u-boot-spi.gph Acked-By: Murali Karicheri m-kariche...@ti.com Signed-off-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- configs/k2e_evm_defconfig | 7 --- configs/k2hk_evm_defconfig | 7 --- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig index be8d2ee..9e70219 100644 --- a/configs/k2e_evm_defconfig +++ b/configs/k2e_evm_defconfig @@ -1,3 +1,4 @@ -CONFIG_ARM=y -CONFIG_ARCH_KEYSTONE=y -CONFIG_TARGET_K2E_EVM=y +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_KEYSTONE=y ++S:CONFIG_TARGET_K2E_EVM=y diff --git a/configs/k2hk_evm_defconfig b/configs/k2hk_evm_defconfig index eee3335..e04e315 100644 --- a/configs/k2hk_evm_defconfig +++ b/configs/k2hk_evm_defconfig @@ -1,3 +1,4 @@ -CONFIG_ARM=y -CONFIG_ARCH_KEYSTONE=y -CONFIG_TARGET_K2HK_EVM=y +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_KEYSTONE=y ++S:CONFIG_TARGET_K2HK_EVM=y -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch] ks2_evm: readme: align according to actual sources
Update readme file for Keystone II EVM boards to actual sources.
Also correct some typos. For now the Edison evaluation board is
added, README for K2E is mostly the same, so update README to
contain information also for K2E evm. Rename file to README as
it contains information for all keystone evm boards.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
board/ti/ks2_evm/{README_K2HK = README} | 75 +++-
1 file changed, 44 insertions(+), 31 deletions(-)
rename board/ti/ks2_evm/{README_K2HK = README} (68%)
diff --git a/board/ti/ks2_evm/README_K2HK b/board/ti/ks2_evm/README
similarity index 68%
rename from board/ti/ks2_evm/README_K2HK
rename to board/ti/ks2_evm/README
index 7426b8d..a551e28 100644
--- a/board/ti/ks2_evm/README_K2HK
+++ b/board/ti/ks2_evm/README
@@ -1,46 +1,56 @@
-U-Boot port for Texas Instruments XTCIEVMK2X
-
+U-Boot port for Texas Instruments Keystone II EVM boards
+
Author: Murali Karicheri m-kariche...@ti.com
-This README has information on the u-boot port for XTCIEVMK2X EVM board.
+This README has information on the u-boot port for K2HK, K2E boards.
Documentation for this board can be found at
- http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
+http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
+https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
-The board is based on Texas Instruments Keystone2 family of SoCs : K2H, K2K.
+The K2HK board is based on Texas Instruments Keystone2 family of SoCs: K2H,
K2K.
More details on these SoCs are available at company websites
K2K: http://www.ti.com/product/tci6638k2k
K2H: http://www.ti.com/product/tci6638k2h
+The K2E SoC details are available at
+ K2E http://www.ti.com/lit/ds/symlink/66ak2e05.pdf
+
Board configuration:
-Some of the peripherals that are configured by u-boot are:-
+Some of the peripherals that are configured by u-boot
++--+---+---+---+---+---+---++
+| |DDR3 |NAND |MSM SRAM |ETH ports |UART |I2C|SPI |
++--+---+---+---+---+---+---++
+|K2HK |2 |512MB |6MB |4(2) |2 |3 |3 |
+|K2E |4 |512MB |2MB |8(2) |2 |3 |3 |
++--+---+---+---+---+---+---++
-1. 2GB DDR3 (can support 8GB SO DIMM as well)
-2. 512M NAND (over ti emif16 bus)
-3. 6MB MSM SRAM (part of the SoC)
-4. two 1GBit Ethernet ports (SoC supports upto 4)
-5. two UART ports
-6. three i2c interfaces
-7. three spi interfaces (only 1 interface supported in driver)
+There are only 2 eth port installed on the boards.
-There are seperate PLLs to drive clocks to Tetris ARM and Peripherals.
+There are separate PLLs to drive clocks to Tetris ARM and Peripherals.
To bring up SMP Linux on this board, there is a boot monitor
code that will be installed in MSMC SRAM. There is command available
to install this image from u-boot.
The port related files can be found at following folders
keystone2 SoC related files: arch/arm/cpu/armv7/keystone/
- K2HK evm board files: board/ti/k2hk_evm/
+ EVMs board files: board/ti/k2s_evm/
+
+Board configuration files:
+include/configs/k2hk_evm.h
+include/configs/k2e_evm.h
-board configuration file: include/configs/k2hk_evm.h
+As u-boot is migrating to Kconfig there is also board defconfig files
+configs/k2e_evm_defconfig
+configs/k2hk_evm_defconfig
Supported boot modes:
- SPI NOR boot
- AEMIF NAND boot
-Supported image formats:-
+Supported image formats:
- u-boot.bin: for loading and running u-boot.bin through Texas instruments
code composure studio (CCS)
- u-boot-spi.gph: gpimage for programming SPI NOR flash for SPI NOR boot
@@ -48,29 +58,32 @@ Supported image formats:-
Build instructions:
===
+Examples for k2hk, for k2e just replace k2hk prefix accordingly.
+Don't forget to add ARCH=arm and CROSS_COMPILE.
To build u-boot.bin
- make k2hk_evm_config
+ make k2hk_evm_defconfig
make u-boot-spi.gph
To build u-boot-spi.gph
- make k2hk_evm_config
+ make k2hk_evm_defconfig
make u-boot-spi.gph
To build u-boot-nand.gph
- make k2hk_evm_config
+ make k2hk_evm_defconfig
make u-boot-nand.gph
-Load and Run U-Boot on K2HK EVM using CCS
+Load and Run U-Boot on keystone EVMs using CCS
=
Need Code Composer Studio (CCS) installed on a PC to load and run u-boot.bin
on EVM. See instructions at below link for installing CCS on a Windows PC.
http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Getting_Started#
Installing_Code_Composer_Studio
-Use u-boot.bin from the build folder for loading annd running u-boot binary
+Use u-boot.bin from the build folder for loading and running u-boot binary
on EVM. Follow instructions at
Re: [U-Boot] [PATCH v2 2/2] usb: eth: smsc95xx: Add EEPROM access support for LAN9514
On Thu 2014-10-09 13:42:50, Alban Bedel wrote: Use the new ethernet eeprom API to allow the user to read/write the EEPROM. Signed-off-by: Alban Bedel alban.be...@avionic-design.de Acked-by: Pavel Machek pa...@denx.de -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot, fsl_espi.c driver
York Sun york...@freescale.com wrote on 2014/10/09 20:06:31:
Dear Joakim,
On 10/09/2014 10:43 AM, Joakim Tjernlund wrote:
York Sun york...@freescale.com wrote on 2014/10/09 18:25:40:
Dear Joakim,
Thanks for raising a concern.
It's not fair to blame the last person who submitted a patch. We are
all
working
No of course not, I just noticed you guys had been in there and
patched up
some problem
so I hoped you would be interested to fix the remaining problems. This
driver should never
have been committed in the first place.
to make it better as an opensource comminuty. You have done a good
job
to hack
it to work. Would it be nicer if you can submit this or improved
patch
to u-boot
community for further review and testing, after putting informing
commit
message? The mailing list address is CC'ed.
Main problem with this driver is that TX does not work for:
len max_tran_len (nor does RX)
does not TX the last odd bytes(len % 4 != 0)
Does not work with TX only(RX buf == NULL)
Silently ignores SPI_LSB_FIRST
On top of that it uses malloc all over and copies data back and forth
for
no good
reason, image a big SPI transfer with many MB(like my FPGA load).
I am not in a good position fix this properly as my FPGA is TX only so
I
cannot test
RX at all(which is broken by my hack)
Finally, just to illustrate the merits of this driver, after
transmission
is done
there is:
if (*buffer == 0x0b) {
data_in += tran_len;
data_len -= tran_len;
*(int *)buffer += tran_len;
}
what is the magic 0x0b test all about?
Thanks for the report. Driver maintainer (CC'ed) will take a look.
Great, I do have some ideas on what to do ishould there be any interest.
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
Hi! I don't this Albert is the problem, I am starting to suspect we simply lack custodian manpower in general. And I also suspect we're not quite inviting and attractive crowd, which is something we should discuss too ... As I said privately, I believe we have way too many custodians... Anyway, u-boot code looks similar to kernel code, but patch submission rules are really different. Something like this could help..? Pavel --- /dev/null 2014-10-09 01:15:57.354292026 +0200 +++ doc/SubmittingPatches 2014-10-09 23:58:53.058883776 +0200 @@ -0,0 +1,11 @@ +Differences from kernel: + +* SPDX license headers are required. + +* puts() is preffered over single-argument prinf() + +* later versions of patch should come with diff changelog below --- + +* subject should begin with tags, such as arm: socfpga: + +* should pass checkpatch \ No newline at end of file -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/1] odroid: Turn blue LED on in u-boot
To indicate that u-boot is active turn on the blue LED. Signed-off-by: Suriyan Ramasami suriya...@gmail.com --- board/samsung/odroid/odroid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c index fd5d2d2..391a287 100644 --- a/board/samsung/odroid/odroid.c +++ b/board/samsung/odroid/odroid.c @@ -374,6 +374,9 @@ static void board_gpio_init(void) gpio_set_pull(EXYNOS4X12_GPIO_X31, S5P_GPIO_PULL_UP); gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X); gpio_direction_input(EXYNOS4X12_GPIO_X31); + + /* Enable blue LED */ + gpio_direction_output(EXYNOS4X12_GPIO_C10, 0); } static int pmic_init_max77686(void) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
Dear Pavel, In message 20141009221154.GA24774@amd you wrote: Something like this could help..? Pavel --- /dev/null 2014-10-09 01:15:57.354292026 +0200 +++ doc/SubmittingPatches 2014-10-09 23:58:53.058883776 +0200 Is there anything wrong with [1] ? [1] http://www.denx.de/wiki/U-Boot/Patches Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One possible reason that things aren't going according to plan is that there never was a plan in the first place. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mtd: denali: support NAND_CMD_RNDOUT command
On Fri, 2014-10-03 at 20:03 +0900, Masahiro Yamada wrote: The function nand_flash_detect_ext_param_page() requires NAND_CMD_RNDOUT command supported. It is necessary to detect some types of ONFi-compliant devices. Without it, the error message unsupported command received 0x5 is shown. Let's support this command on the Denali NAND controller driver. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- drivers/mtd/nand/denali.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c index d9abc7e..308b784 100644 --- a/drivers/mtd/nand/denali.c +++ b/drivers/mtd/nand/denali.c @@ -1072,6 +1072,13 @@ static void denali_cmdfunc(struct mtd_info *mtd, unsigned int cmd, int col, if (cmd == NAND_CMD_PARAM) udelay(50); break; + case NAND_CMD_RNDOUT: + addr = MODE_11 | BANK(denali-flash_bank); + index_addr(denali, addr | 0, cmd); + index_addr(denali, addr | 1, col 0xFF); + index_addr(denali, addr | 1, col 8); + index_addr(denali, addr | 0, NAND_CMD_RNDOUTSTART); + break; This usage of RNDOUT is a regression for other drivers as well, such as fsl_ifc_nand... I really wish emulating a simple controller weren't the API used to talk to higher level drivers. :-( -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm: pxa: use common timer functions
From: Andrew Ruder andrew.ru...@elecsyscorp.com
This patch moves pxa to the common timer functions added in commit
8dfafdd - Introduce common timer functions Rob Herring
The (removed) pxa timer code (specifically __udelay()) could deadlock at
the 32-bit boundary of get_ticks(). get_ticks() returned a 32-bit value
cast up to a 64-bit value. If get_ticks() + tmo in __udelay() crossed
the 32-bit boundary, the while condition became unconditionally true and
locked the processor. Rather than patch the specific pxa issues, simply
move everything over to the common code.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
---
FIRST VERSION AVAILABLE AT:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/192978
I missed some compile-testing last time and didn't notice that not
every board includes configs/pxa-common.h. Rather than try to fix-up
every board config (and possibly break out of tree ones, etc.), add a
PXA-specific config.h. In any case, it must be something included via
common.h as the generic time framework requires the
CONFIG_SYS_TIMER_COUNTER definition.
One potential gotcha here is that now pxa-regs gets included via
common.h which adds lots of short register names to the global
namespace. Compile-tested every PXA board from the generated
boards.cfg and didn't see any issues. Board-tested the PXA270.
checkpatch output:
total: 0 errors, 0 warnings, 0 checks, 75 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE USLEEP_RANGE
0001-arm-pxa-use-common-timer-functions.patch has no obvious style problems and
is ready for submission.
arch/arm/cpu/pxa/timer.c | 69 +-
arch/arm/include/asm/arch-pxa/config.h | 25
arch/arm/include/asm/config.h | 5 ++-
3 files changed, 30 insertions(+), 69 deletions(-)
create mode 100644 arch/arm/include/asm/arch-pxa/config.h
diff --git a/arch/arm/cpu/pxa/timer.c b/arch/arm/cpu/pxa/timer.c
index c4717de..11fefd5 100644
--- a/arch/arm/cpu/pxa/timer.c
+++ b/arch/arm/cpu/pxa/timer.c
@@ -6,80 +6,13 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#include asm/arch/pxa-regs.h
#include asm/io.h
#include common.h
-#include div64.h
DECLARE_GLOBAL_DATA_PTR;
-#defineTIMER_LOAD_VAL 0x
-
-#definetimestamp (gd-arch.tbl)
-#definelastinc (gd-arch.lastinc)
-
-#if defined(CONFIG_CPU_PXA27X) || defined(CONFIG_CPU_MONAHANS)
-#defineTIMER_FREQ_HZ 325
-#elif defined(CONFIG_CPU_PXA25X)
-#defineTIMER_FREQ_HZ 3686400
-#else
-#error Timer frequency unknown - please config PXA CPU type
-#endif
-
-static unsigned long long tick_to_time(unsigned long long tick)
-{
- return lldiv(tick * CONFIG_SYS_HZ, TIMER_FREQ_HZ);
-}
-
-static unsigned long long us_to_tick(unsigned long long us)
-{
- return lldiv(us * TIMER_FREQ_HZ, 100);
-}
-
int timer_init(void)
{
- writel(0, OSCR);
+ writel(0, CONFIG_SYS_TIMER_COUNTER);
return 0;
}
-
-unsigned long long get_ticks(void)
-{
- /* Current tick value */
- uint32_t now = readl(OSCR);
-
- if (now = lastinc) {
- /*
-* Normal mode (non roll)
-* Move stamp forward with absolute diff ticks
-*/
- timestamp += (now - lastinc);
- } else {
- /* We have rollover of incrementer */
- timestamp += (TIMER_LOAD_VAL - lastinc) + now;
- }
-
- lastinc = now;
- return timestamp;
-}
-
-ulong get_timer(ulong base)
-{
- return tick_to_time(get_ticks()) - base;
-}
-
-void __udelay(unsigned long usec)
-{
- unsigned long long tmp;
- ulong tmo;
-
- tmo = us_to_tick(usec);
- tmp = get_ticks() + tmo;/* get current timestamp */
-
- while (get_ticks() tmp) /* loop till event */
-/*NOP*/;
-}
-
-ulong get_tbclk(void)
-{
- return TIMER_FREQ_HZ;
-}
diff --git a/arch/arm/include/asm/arch-pxa/config.h
b/arch/arm/include/asm/arch-pxa/config.h
new file mode 100644
index 000..5836945
--- /dev/null
+++ b/arch/arm/include/asm/arch-pxa/config.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2014 Andrew Ruder andrew.ru...@elecsyscorp.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_ARM_PXA_CONFIG_
+#define _ASM_ARM_PXA_CONFIG_
+
+#include asm/arch/pxa-regs.h
+
+/*
+ * Generic timer support
+ */
+#if defined(CONFIG_CPU_PXA27X) || defined(CONFIG_CPU_MONAHANS)
+#defineCONFIG_SYS_TIMER_RATE 325
+#elif defined(CONFIG_CPU_PXA25X)
+#defineCONFIG_SYS_TIMER_RATE 3686400
+#else
+#error Timer frequency unknown - please config PXA CPU type
+#endif
+
+#define CONFIG_SYS_TIMER_COUNTER OSCR
+
+#endif /* _ASM_ARM_PXA_CONFIG_ */
diff --git a/arch/arm/include/asm/config.h
Re: [U-Boot] [PATCH 01/19] lib: errno: introduce errno_str(): returns errno related message
On 9 October 2014 10:23, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello Joakim, On 10/09/2014 08:46 AM, Joakim Tjernlund wrote: From: Przemyslaw Marczak p.marc...@samsung.com The functions error's numbers are standarized - but the error messages are not. The errors are often handled with unclear error messages, so why not use an errno standarized messages. Advantages: - This could decrease the binary size. Having an array of string ptrs adds some extra space needs. Each str needs a ptr and that ptr needs relocation, 8 bytes on 32 bits If you want to save space do this instead static const char const errno_message[] = Success\0Operation not permitted\0No such file or directory etc. Then count \0 to find the error msg. Jocke Is this really a problem to add some array with the pointers? You are right, this array requires some additional space, but this is not the main reason of introducing this function. This can be enabled optional, so maybe for the less memory and slower devices this shouldn't be used - but in the other way, we see many text messages in the code that could be replaced with the one from that array. So, which is better? This helps me sometimes, so I added this as some extra feature. I think it looks good as it is as it is simple. My only suggestion is that the CONFIG should not remove the function, merely make it return an empty string or Error strings unavailable. Otherwise you will force #ifdefs in the code. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
Hi! Something like this could help..? Pavel --- /dev/null 2014-10-09 01:15:57.354292026 +0200 +++ doc/SubmittingPatches 2014-10-09 23:58:53.058883776 +0200 Is there anything wrong with [1] ? [1] http://www.denx.de/wiki/U-Boot/Patches It should really go into tree. It does not mention puts() vs. printf(), if it is indeed meant to be u-boot policy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm: pxa: use common timer functions
This patch moves pxa to the common timer functions added in commit
8dfafdd - Introduce common timer functions Rob Herring
The (removed) pxa timer code (specifically __udelay()) could deadlock at
the 32-bit boundary of get_ticks(). get_ticks() returned a 32-bit value
cast up to a 64-bit value. If get_ticks() + tmo in __udelay() crossed
the 32-bit boundary, the while condition became unconditionally true and
locked the processor. Rather than patch the specific pxa issues, simply
move everything over to the common code.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
---
FIRST VERSION AVAILABLE AT:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/192978
I missed some compile-testing last time and didn't notice that not
every board includes configs/pxa-common.h. Rather than try to fix-up
every board config (and possibly break out of tree ones, etc.), add a
PXA-specific config.h. In any case, it must be something included via
common.h as the generic time framework requires the
CONFIG_SYS_TIMER_COUNTER definition.
One potential gotcha here is that now pxa-regs gets included via
common.h which adds lots of short register names to the global
namespace. Compile-tested every PXA board from the generated
boards.cfg and didn't see any issues. Board-tested the PXA270.
checkpatch output:
total: 0 errors, 0 warnings, 0 checks, 75 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE USLEEP_RANGE
0001-arm-pxa-use-common-timer-functions.patch has no obvious style problems and
is ready for submission.
arch/arm/cpu/pxa/timer.c | 69 +-
arch/arm/include/asm/arch-pxa/config.h | 25
arch/arm/include/asm/config.h | 5 ++-
3 files changed, 30 insertions(+), 69 deletions(-)
create mode 100644 arch/arm/include/asm/arch-pxa/config.h
diff --git a/arch/arm/cpu/pxa/timer.c b/arch/arm/cpu/pxa/timer.c
index c4717de..11fefd5 100644
--- a/arch/arm/cpu/pxa/timer.c
+++ b/arch/arm/cpu/pxa/timer.c
@@ -6,80 +6,13 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#include asm/arch/pxa-regs.h
#include asm/io.h
#include common.h
-#include div64.h
DECLARE_GLOBAL_DATA_PTR;
-#defineTIMER_LOAD_VAL 0x
-
-#definetimestamp (gd-arch.tbl)
-#definelastinc (gd-arch.lastinc)
-
-#if defined(CONFIG_CPU_PXA27X) || defined(CONFIG_CPU_MONAHANS)
-#defineTIMER_FREQ_HZ 325
-#elif defined(CONFIG_CPU_PXA25X)
-#defineTIMER_FREQ_HZ 3686400
-#else
-#error Timer frequency unknown - please config PXA CPU type
-#endif
-
-static unsigned long long tick_to_time(unsigned long long tick)
-{
- return lldiv(tick * CONFIG_SYS_HZ, TIMER_FREQ_HZ);
-}
-
-static unsigned long long us_to_tick(unsigned long long us)
-{
- return lldiv(us * TIMER_FREQ_HZ, 100);
-}
-
int timer_init(void)
{
- writel(0, OSCR);
+ writel(0, CONFIG_SYS_TIMER_COUNTER);
return 0;
}
-
-unsigned long long get_ticks(void)
-{
- /* Current tick value */
- uint32_t now = readl(OSCR);
-
- if (now = lastinc) {
- /*
-* Normal mode (non roll)
-* Move stamp forward with absolute diff ticks
-*/
- timestamp += (now - lastinc);
- } else {
- /* We have rollover of incrementer */
- timestamp += (TIMER_LOAD_VAL - lastinc) + now;
- }
-
- lastinc = now;
- return timestamp;
-}
-
-ulong get_timer(ulong base)
-{
- return tick_to_time(get_ticks()) - base;
-}
-
-void __udelay(unsigned long usec)
-{
- unsigned long long tmp;
- ulong tmo;
-
- tmo = us_to_tick(usec);
- tmp = get_ticks() + tmo;/* get current timestamp */
-
- while (get_ticks() tmp) /* loop till event */
-/*NOP*/;
-}
-
-ulong get_tbclk(void)
-{
- return TIMER_FREQ_HZ;
-}
diff --git a/arch/arm/include/asm/arch-pxa/config.h
b/arch/arm/include/asm/arch-pxa/config.h
new file mode 100644
index 000..5836945
--- /dev/null
+++ b/arch/arm/include/asm/arch-pxa/config.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2014 Andrew Ruder andrew.ru...@elecsyscorp.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_ARM_PXA_CONFIG_
+#define _ASM_ARM_PXA_CONFIG_
+
+#include asm/arch/pxa-regs.h
+
+/*
+ * Generic timer support
+ */
+#if defined(CONFIG_CPU_PXA27X) || defined(CONFIG_CPU_MONAHANS)
+#defineCONFIG_SYS_TIMER_RATE 325
+#elif defined(CONFIG_CPU_PXA25X)
+#defineCONFIG_SYS_TIMER_RATE 3686400
+#else
+#error Timer frequency unknown - please config PXA CPU type
+#endif
+
+#define CONFIG_SYS_TIMER_COUNTER OSCR
+
+#endif /* _ASM_ARM_PXA_CONFIG_ */
diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
index be80434..1cfc83b 100644
---
Re: [U-Boot] Parsing of multi-line env vars broken
Hi, On 26 September 2014 02:24, Wolfgang Denk w...@denx.de wrote: HI, this is just a heads up: the handling of multi-line environment variables is broken in recent versions of U-Boot (and probably has been broken for some longer time - can't tell exactly as I have a bit of a problem to bisect across the MAKEALL / Kconfig changes): Test case: - Set multi-line var: = setenv foo 'echo line 1 echo line 2 echo line 3' OK - Print multi-line var: = print foo foo=echo line 1 echo line 2 echo line 3 OK - Run multi-line var: = run foo line 1 ERROR. Only the first line gets executed, the rest is missing. Only the first line gets parded by the hush shell... As a follow-up, please see this potential patch: http://patchwork.ozlabs.org/patch/397428/ 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: pxa: use common timer functions
Please ignore this one as it has the messed up From: line without the author name. Sorry for the noise. - Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
On Fri 2014-10-10 00:24:46, Wolfgang Denk wrote: Dear Pavel, In message 20141009221154.GA24774@amd you wrote: Something like this could help..? Pavel --- /dev/null 2014-10-09 01:15:57.354292026 +0200 +++ doc/SubmittingPatches 2014-10-09 23:58:53.058883776 +0200 Is there anything wrong with [1] ? [1] http://www.denx.de/wiki/U-Boot/Patches ..and actually... it makes submitting patches rather hard. [PATCH] fix compilation on socfpga Please add tags to the subject [PATCHv2] arm: socfpga: fix compilation on socfpga Please add diff from previous version [PATCHv3] arm: socfpga: fix compilation on socfpga --- v2: added tags to the subject v3: added diffs to previous version . (From memory, but IIRC something very similar to this happened before). This scares of all but the most determined patch submitters, and does not really improve code quality. I'd argue that if only changelog is updated, it is _not_ a new version of patch, and does not need changelog diff. Or maybe be less strict policy / less strict enforcement of the policy in trivial cases. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SUNXI NAND CONTROLLER Driver Model (WIP)
Hi Yassin, On 8 October 2014 18:36, Yassin Jaffer yassinjaf...@gmail.com wrote: Hi I'm developing a u-boot driver for the sunxi nand controller https://github.com/yassinjaffer/u-boot. My work is based on bbrezillon mainline driver https://github.com/bbrezillon/linux-sunxi. I would like to move the driver to use the DM framework so I'm wondering if someone could kindly give some suggestions on how to accomplish this. I do know that DM is still WIP but I believe that the nand driver can take advantage of the DM since I'm using the FDT for the run-time configuration. Here are my thoughts. Please be aware that until you actually get into it it's hard to know exactly which path to take. Also I think you need to be careful about this as some of the files are synced with the Linux kernel and that limits your options. You don't want to turn the code into spaghetti. I think there is a path forward though, but I suggest starting cautiously. Start with the 'nand' command, which makes mtd calls. You can see the calls that it makes and work from there testing as you go. Add CONFIG_DM_MTD and use that to change between the old code and the driver model code. Add a uclass for a NAND driver. I think this corresponds to struct nand_chip. Then struct nand_chip should become the uclass_priv data for each device (e.g. the sunxi nand controller). You can see how this was done with SPI by looking at the SPI uclass. That means that every device will have this information. The nand operations should really go in a separate 'ops' structure that is private to the device, so you could #ifdef those out of struct nand_chip. Once you have an approach please check in with the NAND maintainer too. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V6] ARM: mx6: Add support for Kosagi Novena
Add support for the Kosagi Novena board. Currently supported are:
- I2C busses
- FEC Ethernet
- MMC0, MMC1, Booting from MMC
- SATA
- USB ports
- USB Ethernet
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Sean Cross x...@kosagi.com
Cc: Nikolay Dimitrov picmas...@mail.bg
---
arch/arm/Kconfig | 4 +
board/kosagi/novena/Kconfig | 18 ++
board/kosagi/novena/Makefile | 11 +
board/kosagi/novena/novena.c | 339 +++
board/kosagi/novena/novena_spl.c | 580 +++
board/kosagi/novena/setup.cfg| 47
configs/novena_defconfig | 4 +
include/configs/imx6_spl.h | 2 +-
include/configs/novena.h | 302
9 files changed, 1306 insertions(+), 1 deletion(-)
create mode 100644 board/kosagi/novena/Kconfig
create mode 100644 board/kosagi/novena/Makefile
create mode 100644 board/kosagi/novena/novena.c
create mode 100644 board/kosagi/novena/novena_spl.c
create mode 100644 board/kosagi/novena/setup.cfg
create mode 100644 configs/novena_defconfig
create mode 100644 include/configs/novena.h
V2: - Drop the tegra_keyboard_init() comment altogether
- Immediatelly return from the SD controller probe function on failure
- Rename PFUZE100_PMIC to just PFUZE100
- Fix the IMX OTP support with CMD_FUSE
- Enabling LVDS clock is still in place, since this is coming soon.
V3: - Zap rootpath builtin env
V4: - Zap the checkpatch issues
- Update comments
V5: - Don't configure VGEN1
- Set FPGA into reset in SPL
- Drop ECSPI1 and add ECSPI3 mux
- Drop UART1 and add UART3, UART4 muxes
- Add separate mux option for the RGMII pins which doesn't set SPEED field
- Move the configuration of RGMII after they were configured in GPIO mode
V6: - Drop 'string' prop from Kconfig
- Zap uSD card detect
- Add bigSD write-protect detection
- Zap USB hub reset GPIO
- Remove unnecessary zeroing of GD in SPL
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 106aed9..4da1923 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -411,6 +411,9 @@ config TARGET_GW_VENTANA
config TARGET_HUMMINGBOARD
bool Support hummingboard
+config TARGET_KOSAGI_NOVENA
+ bool Support Kosagi Novena
+
config TARGET_TQMA6
bool TQ Systems TQMa6 board
@@ -637,6 +640,7 @@ source board/imx31_phycore/Kconfig
source board/isee/igep0033/Kconfig
source board/jornada/Kconfig
source board/karo/tx25/Kconfig
+source board/kosagi/novena/Kconfig
source board/logicpd/imx27lite/Kconfig
source board/logicpd/imx31_litekit/Kconfig
source board/mpl/vcma9/Kconfig
diff --git a/board/kosagi/novena/Kconfig b/board/kosagi/novena/Kconfig
new file mode 100644
index 000..4ba6399
--- /dev/null
+++ b/board/kosagi/novena/Kconfig
@@ -0,0 +1,18 @@
+if TARGET_KOSAGI_NOVENA
+
+config SYS_CPU
+ default armv7
+
+config SYS_BOARD
+ default novena
+
+config SYS_VENDOR
+ default kosagi
+
+config SYS_SOC
+ default mx6
+
+config SYS_CONFIG_NAME
+ default novena
+
+endif
diff --git a/board/kosagi/novena/Makefile b/board/kosagi/novena/Makefile
new file mode 100644
index 000..6fba177
--- /dev/null
+++ b/board/kosagi/novena/Makefile
@@ -0,0 +1,11 @@
+#
+# Copyright (C) 2014 Marek Vasut ma...@denx.de
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y := novena_spl.o
+else
+obj-y := novena.o
+endif
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
new file mode 100644
index 000..d25a5f1
--- /dev/null
+++ b/board/kosagi/novena/novena.c
@@ -0,0 +1,339 @@
+/*
+ * Novena board support
+ *
+ * Copyright (C) 2014 Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/errno.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/clock.h
+#include asm/arch/crm_regs.h
+#include asm/arch/imx-regs.h
+#include asm/arch/iomux.h
+#include asm/arch/mxc_hdmi.h
+#include asm/arch/sys_proto.h
+#include asm/imx-common/boot_mode.h
+#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
+#include asm/imx-common/sata.h
+#include asm/imx-common/video.h
+#include fsl_esdhc.h
+#include i2c.h
+#include input.h
+#include ipu_pixfmt.h
+#include linux/fb.h
+#include linux/input.h
+#include malloc.h
+#include micrel.h
+#include miiphy.h
+#include mmc.h
+#include netdev.h
+#include power/pmic.h
+#include power/pfuze100_pmic.h
+#include stdio_dev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define NOVENA_BUTTON_GPIO IMX_GPIO_NR(4, 14)
+#define NOVENA_SD_WP IMX_GPIO_NR(1, 2)
+#define NOVENA_SD_CD IMX_GPIO_NR(1, 4)
+
+/*
+ * GPIO button
+ */
+#ifdef CONFIG_KEYBOARD
+static struct input_config button_input;
+
+static int novena_gpio_button_read_keys(struct input_config *input)
+{
+ int key = KEY_ENTER;
+ if (gpio_get_value(NOVENA_BUTTON_GPIO))
+ return 0;
+
Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena
On Thursday, October 09, 2014 at 03:04:49 AM, Nikolay Dimitrov wrote: Hi Marek, Hi! On 10/09/2014 03:28 AM, Marek Vasut wrote: On Thursday, October 09, 2014 at 02:13:48 AM, Nikolay Dimitrov wrote: Hi Marek, [...] @Sean: Do you have any comments on USB hub reset stuff? Should we ditch entirely the reset code, or should we modify it somehow to work properly? OK, so it's just this USB that remains, right ? That's correct. There are a bunch of non-critical things for fixing also, but we'll negotiate later about them :D. Well what are those ? Stuff like removing GD memset from Novena code, as it's now handled by crt0.S, removing microSD CD pin definition as it's not used at all, I fixed those two, thanks! improve PHY reset (both timing and signal conflicts), and about 5-6 similar things which I can't remember, need to check again your patch. As I said, I feel bad for torturing you anyway, and tried to think which are the critical things, which will break stuff if not fixed. The other fixes need another round of more discussions, so can be pushed later. OK, but don't worry about the discussion. That's really perfectly OK. Thank you! 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] arm: pxa: use common timer functions
On Friday, October 10, 2014 at 01:00:38 AM, Andrew Ruder wrote: This patch moves pxa to the common timer functions added in commit 8dfafdd - Introduce common timer functions Rob Herring The (removed) pxa timer code (specifically __udelay()) could deadlock at the 32-bit boundary of get_ticks(). get_ticks() returned a 32-bit value cast up to a 64-bit value. If get_ticks() + tmo in __udelay() crossed the 32-bit boundary, the while condition became unconditionally true and locked the processor. Rather than patch the specific pxa issues, simply move everything over to the common code. Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com Cc: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com Reviewed-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm: socfpga: add MAINTAINERS entry
From: Pavel Machek pa...@denx.de Add MAINTAINERS entry. Signed-off-by: Pavel Machek pa...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de Cc: Pavel Machek pa...@denx.de --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index af194ca..7a3dbbd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -65,6 +65,13 @@ S: Maintained T: git git://git.denx.de/u-boot-arm.git F: arch/arm/ +ARM ALTERA SOCFPGA +M: Marek Vasut ma...@denx.de +S: Maintainted +T: git git://git.denx.de/u-boot-socfpga.git +F: arch/arm/cpu/armv7/socfpga/ +F: board/altera/socfpga/ + ARM ATMEL AT91 M: Andreas Bießmann andreas.de...@googlemail.com S: Maintained -- 2.0.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: socfpga: Use EMAC1 on SoCDK
The SoCDK uses EMAC1, not EMAC0. This patch fixes the issue. Signed-off-by: Marek Vasut ma...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de Cc: Pavel Machek pa...@denx.de --- include/configs/socfpga_cyclone5.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Dinh/Chin, can you please confirm this? diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h index 8d54bf8..60d7e20 100644 --- a/include/configs/socfpga_cyclone5.h +++ b/include/configs/socfpga_cyclone5.h @@ -53,7 +53,7 @@ /* Ethernet on SoC (EMAC) */ #if defined(CONFIG_CMD_NET) -#define CONFIG_EMAC_BASE SOCFPGA_EMAC0_ADDRESS +#define CONFIG_EMAC_BASE SOCFPGA_EMAC1_ADDRESS #define CONFIG_PHY_INTERFACE_MODE PHY_INTERFACE_MODE_RGMII #define CONFIG_EPHY0_PHY_ADDR 0 -- 2.0.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
On Thursday, October 09, 2014 at 08:04:29 PM, Simon Glass wrote: Hi Marek, Hi Simon, [..] I mean more continuous integration (build testing) of the code before a PR is submitted to the ML. Right now, we all do our own thing when it comes to testing before PR, but it would be nice to have one easy way of doing the build testing before submitting the PR, don't you think ? This might apply to Linux too. Sure it would be useful. Before submitting my pull request I get all the patches in a branch and run: ./tools/buildman/buildman -b x86-push This checks every commit for every board that I build, and gives me good confidence that no patch introduces new breakages. I agree that buildman solves the CI part nicely, but we also have the part where one has to install the myriad of toolchains for all the architectures to be able to do the compile testing. I wonder if this cannot be made easy in some way -- maybe through a re-usable docker image with all the parts in it already. 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] ARM: mx6: Add support for Kosagi Novena
On Thursday, October 02, 2014 at 08:16:25 AM, Sean Cross wrote: Hi Sean, OK on the FPGA bit. [...] We just received final boards on Monday. I will try this out and report back. You should try one of the never patches . I have built it and gotten it working on Novena. A few notes: USB works, but appears to take a very long time to enumerate. I suspect one of the hubs is still in reset. It finds the Asix Ethernet device, but doesn't find a USB keyboard I have plugged in. Instead, running usb start gives EHCI timed out on TD - token=0x80008c80, and the keyboard shows up as Hub (12 Mb/s, 40mA) -- Lite-On Tech USB 1.1 2 port downstream low-p. I suspect this has to do with the keyboard being USB 1.1 , I see such a problem with my USB 1.1 keyboard too. USB 2.0 devices do work, right? I will have to look into this USB 1.1 flub soon. [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
On Fri, Oct 10, 2014 at 12:11:54AM +0200, Pavel Machek wrote: Hi! I don't this Albert is the problem, I am starting to suspect we simply lack custodian manpower in general. And I also suspect we're not quite inviting and attractive crowd, which is something we should discuss too ... As I said privately, I believe we have way too many custodians... I think perhaps I need to better spell out custodian expectations. But as to having too many? No, I need some convincing in that direction. Anyway, u-boot code looks similar to kernel code, but patch submission rules are really different. Something like this could help..? Pavel --- /dev/null 2014-10-09 01:15:57.354292026 +0200 +++ doc/SubmittingPatches 2014-10-09 23:58:53.058883776 +0200 @@ -0,0 +1,11 @@ +Differences from kernel: Perhaps. If not in tree, a concice reminder to follow all of the rules spelled out on the wiki to avoid the ping-ponging you noted in a follow up later. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi, On 09/10/14 04:13, Albert ARIBAUD wrote: Hi Minkyu, On Wed, 08 Oct 2014 20:36:34 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit 6dd0e7c00bfa5ce861a72b8e4a3ef9e787306125: git-mailrc: add me as a maintainer of UniPhier platform (2014-10-05 14:10:09 +0900) are available in the git repository at: http://git.denx.de/u-boot-samsung for you to fetch changes up to b219773957d2ee8fedb56f0fcb19288eb72d4867: odroid: clock: set aclk_cores to 200MHz (2014-10-08 19:48:43 +0900) Hmm, commit b219773957d2ee8fedb56f0fcb19288eb72d4867 does not seem to exist at all in current u-boot-samsung repo. Can you check this PR? Sorry, I forgot pushing. Please retry! Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The RNDOUT patch addresses a regression in the mtd uprev. The PARAM change is a fix to a driver introduced in this release. The following changes since commit dd0204e48d05f41480743a798b94d5484b664639: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-10-07 07:38:39 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to ed3c980bee74dc1bd599dd44b41b2c32ee78c0a8: mtd: denali: support NAND_CMD_RNDOUT command (2014-10-09 17:33:26 -0500) Masahiro Yamada (2): mtd: denali: fix NAND_CMD_PARAM command mtd: denali: support NAND_CMD_RNDOUT command drivers/mtd/nand/denali.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6] ARM: mx6: Add support for Kosagi Novena
Hi Marek,
The usual stuff follows :D.
On 10/10/2014 02:22 AM, Marek Vasut wrote:
+#define NOVENA_BUTTON_GPIO IMX_GPIO_NR(4, 14)
+#define NOVENA_SD_WP IMX_GPIO_NR(1, 2)
+#define NOVENA_SD_CD IMX_GPIO_NR(1, 4)
NOVENA_BUTTON_GPIO is initialized as input in this source file, but the
NOVENA_SD_WP and NOVENA_SD_CD are not. They're initialized only in
novena_spl.c, and if you change the SPL configuration, they won't be
explicitly initialized.
While by pure luck the iomuxc reset values are those of the GPIO pins, I
would vote for explicit initialization of WP CD.
And btw, it's cool that you added the WP pin, I totally missed this out
last time I was staring at the schematic.
+/*
+ * USB
+ */
+#ifdef CONFIG_USB_EHCI_MX6
+static iomux_v3_cfg_t usb_pads[] = {
+ MX6_PAD_GPIO_17__GPIO7_IO12 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static void novena_spl_setup_iomux_usb(void)
+{
+ imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
+}
+#else
+static void novena_spl_setup_iomux_usb(void) {}
+#endif
The patch comments are saying this is gone :).
+/*
+ * called from C runtime startup code (arch/arm/lib/crt0.S:_main)
+ * - we have a stack and a place to store GD, both in SRAM
+ * - no variable global data is available
+ */
+void board_init_f(ulong dummy)
+{
+ /*
+* Zero out global data:
+* - this should be done by crt0.S
+* - failure to zero it will cause i2c_setup to fail
+*/
+ memset((void *)gd, 0, sizeof(struct global_data));
Same here.
+/*
+ * Environment is on MMC, starting at offset 64KiB from start of the card.
+ * Please place first partition at offset 1MiB from the start of the card
+ * as recommended by GNU/fdisk. See below for details:
+ *
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/disc-partition-alignment.html
+ */
+#ifdef CONFIG_CMD_MMC
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 0
+#define CONFIG_ENV_OFFSET (512 * 1024)
Please fix either the comment saying offset is 64KiB from start, or fix
the CONFIG_ENV_OFFSET.
Reviewed-by: Nikolay Dimitrov picmas...@mail.bg
Marek, would you agree that after finishing this patch which enables the
initial Novena support, to handle all other fixes by separate
independent patches, which are easier to review, resubmit, test, etc?
Kind regards,
Nikolay
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Device tree for Atmel SAMA5D31
Hi Andy,
I suggest this question go to linux arm kernel mailing list.
On 10/09/2014 08:24 PM, Andy Pont wrote:
This isn't strictly a U-Boot issue but I am hoping that there are
appropriately knowledgeable people here who will be able to help!
I am working on a Linux driver for an I2C RTC device and need to add the
correct definitions into the device tree for the SAMA5D31 to be passed to
the kernel at boot time. I have added:
i2c0: i2c@f0014000 {
status = okay;
rv8523c3@68 {
compatible = mc,rv8523c3;
reg = 0x68;
};
};
This sets up enough to allow the basic clock functions within the RTC to
work correctly and the hwclock command within Busybox to work correctly. I
need to add in the definitions for a GPIO (PE31) to be used as the alarm
interrupt pin and can't get my head around the definitions needed within the
device tree. I have tried adding the following
interrupt-parent = pioE;
interrupts = 31;
When the RTC driver is loaded by Linux the client-irq variable in the probe
function doesn't contain a value 0 and so doesn't setup an interrupt.
Any ideas on the correct definitions needed?
Please take this file arch/arm/boot/dts/sama5d3xdm.dtsi as a
reference, qt1070 use GPIO PIOE 31 as interrupt. it conflict with your
setting.
Thanks (and apologies for the noise),
Andy.
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] imx:mx6sxsabresd add qspi support
Hi,
On 10/09/2014 06:37 PM, Jagan Teki wrote:
Hi Peng Fan,
Before reviewing these two patches, I'm requesting some sort work from
your side like
Can you update/fix the driver drivers/spi/fsl_qspi.c without using
flash opcodes.
Using flash opcode's with in the (q)spi driver is not recommended
please think on that
direction.
Yeah, many OPCODE_XX are used in this driver.
There is a LUT table containing 16 entries in the QSPI Controller.
The Look-up-table or LUT consists of a number of pre-programmed sequences. Each
sequence is basically a sequence of instruction-operand pairs which when
executed
sequentially generates a valid serial flash transaction. Each sequence can have
a
maximum of 8 instruction-operand pairs.
The instruction holds the flash opcode that should be pre-programmed, and the
qspi_set_lut in drivers/spi/fsl_qspi.c does this work.
It is not easy to program the lut dynamically in the driver without using the
flash opcodes.
So I wonder whether CMD_xxx in drivers/mtd/spi/sf_internal.h can be used or
not. Or,
can QSPI_CMD_xxx be used but not OPCODE_xx? Actually if QSPI_CMD_xx can be
used, the value
QSPI_CMD_xx is the same with OPCODE_xx, just different macro names.
Regards,
Peng.
On 9 October 2014 14:37, Peng Fan b51...@freescale.com wrote:
Hi,
Any reply about this patch? It is long time since this patch was sent out.
Regards,
Peng.
On 09/11/2014 10:30 AM, Fan Peng-B51431 wrote:
Just CC Stefano Babic sba...@denx.de
Regards,
Peng.
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Peng Fan
Sent: Thursday, September 11, 2014 9:56 AM
To: Estevam Fabio-R49496; Li Ye-B37916
Cc: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/2] imx:mx6sxsabresd add qspi support
Configure the pad setting and enable qspi clock to support qspi flashes
access.
This patch has been tested on mx6sxsabresd board.
Signed-off-by: Peng Fan peng@freescale.com
---
Changelog v2:
Take Fabio's suggestion, split soc code and board code into two patches.
This patch needs 'ARM:MX6SX Add QSPI support' patch.
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 40
+
include/configs/mx6sxsabresd.h | 14 ++
2 files changed, 54 insertions(+)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 5eaec1b..f9cad5a 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -272,11 +272,51 @@ int board_mmc_init(bd_t *bis)
return fsl_esdhc_initialize(bis, usdhc_cfg[0]); }
+#ifdef CONFIG_FSL_QSPI
+
+#define QSPI_PAD_CTRL1 \
+ (PAD_CTL_SRE_FAST | PAD_CTL_SPEED_HIGH | \
+ PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_40ohm)
+
+static iomux_v3_cfg_t const quadspi_pads[] = {
+ MX6_PAD_NAND_WP_B__QSPI2_A_DATA_0 |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_READY_B__QSPI2_A_DATA_1|
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE0_B__QSPI2_A_DATA_2 |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE1_B__QSPI2_A_DATA_3 |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_ALE__QSPI2_A_SS0_B |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CLE__QSPI2_A_SCLK |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA07__QSPI2_A_DQS|
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA01__QSPI2_B_DATA_0 |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA00__QSPI2_B_DATA_1 |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_WE_B__QSPI2_B_DATA_2 |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_RE_B__QSPI2_B_DATA_3 |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA03__QSPI2_B_SS0_B |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA02__QSPI2_B_SCLK |
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA05__QSPI2_B_DQS|
MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+};
+
+int board_qspi_init(void)
+{
+ /* Set the iomux */
+ imx_iomux_v3_setup_multiple_pads(quadspi_pads,
+ ARRAY_SIZE(quadspi_pads));
+
+ /* Set the clock */
+ enable_qspi_clk(1);
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
/* Address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+#ifdef CONFIG_FSL_QSPI
+ board_qspi_init();
+#endif
+
return 0;
}
diff --git a/include/configs/mx6sxsabresd.h
b/include/configs/mx6sxsabresd.h index 1eda65e..00031ec 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -201,6 +201,20 @@
/* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH
+#define CONFIG_FSL_QSPI
+
+#ifdef CONFIG_FSL_QSPI
+#define CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_SPI_FLASH_STMICRO
Re: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
Hi Marek, On 9 October 2014 17:59, Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 08:04:29 PM, Simon Glass wrote: Hi Marek, Hi Simon, [..] I mean more continuous integration (build testing) of the code before a PR is submitted to the ML. Right now, we all do our own thing when it comes to testing before PR, but it would be nice to have one easy way of doing the build testing before submitting the PR, don't you think ? This might apply to Linux too. Sure it would be useful. Before submitting my pull request I get all the patches in a branch and run: ./tools/buildman/buildman -b x86-push This checks every commit for every board that I build, and gives me good confidence that no patch introduces new breakages. I agree that buildman solves the CI part nicely, but we also have the part where one has to install the myriad of toolchains for all the architectures to be able to do the compile testing. I wonder if this cannot be made easy in some way -- maybe through a re-usable docker image with all the parts in it already. It would be create if we could download all the toolchains from one place. Maybe we need a toolchain maintainer? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Addition of new board Peach-Pi
Hi Akshay, On 8 October 2014 02:10, Akshay Saraswat aksha...@samsung.com wrote: Now we are adding a new Peach-Pi board which is a variant of Peach-Pit and is based on Exynos5800. Exynos5800 itself is a variant of Exynos5420, hence, most of the hardware config and settings are reused for this board. Akshay Saraswat (5): Exynos5800: Introduce new proid for Exynos5800 Exynos5800: Add DTS for new board Peach-Pi Config: Exynos5800: Enable build for Peach-Pi Config: Exynos5420: Refactor SDRAM Bank and Size Exynos5: ddr3: Choose between single or double channel config Alim Akhtar (1): DMC: Exynos5: Enable update mode for DREX controller I was not able to apply this to samsung/master. I fiddled a bit and got it to build (see u-boot-x86.git branch pi-working) but it would not boot over USB A-A. It hung in SPL. I may have used an incorrect option though. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/29] Introduce driver model support for SPI, SPI flash, cros_ec
Hi Jagan, On 9 October 2014 04:33, Jagan Teki jagannadh.t...@gmail.com wrote: On 9 October 2014 02:03, Simon Glass s...@chromium.org wrote: Hi, On 29 September 2014 13:34, Simon Glass s...@chromium.org wrote: Up until now driver model has not been used for any type of bus. Buses have some unique properties and needs, so we cannot claim that driver model can cover all the common cases unless we have converted a bus over to driver model. SPI is a reasonable choice for this next step. It has a fairly simple API and not too many dependencies. The main one is SPI flash so we may as well convert that also. Since the boards I test with have cros_ec I have also included that, for SPI only. The technique used is make use of driver model's supported data structures to hold information currently kept by each subsystem in a private data structure. Since 'struct spi_slave' relates to the slave device on the bus it is stored in the 'parent' data with each child device of the bus. Since 'struct spi_flash' is a standard interface used for each SPI flash driver, it is stored in the SPI FLash uclass's private data for each device. New defines are created to enable driver model for each subsystem. These are: CONFIG_DM_SPI CONFIG_DM_SPI_FLASH CONFIG_DM_CROS_EC This allows us to move some boards and drivers to driver model, while leaving others behind. A 'big bang' conversion of everything to driver model, even at a subsystem level, is never going to work. There is some cost in changing the uclass interface after it is created, so if you have limited time, please spend it reviewing the uclass interfaces in spi.h and spi_flash.h. These need to be supported by each driver, so changing them later may involve changing multiple drivers. To assist with the conversion of other SPI drivers, a README file is added to walk through the process. So far, sandbox, exynos and tegra drivers are converted over. As always, driver model patches are available at u-boot-dm.git branch 'working'. There is a branch for just this series called 'spi-working'. I think this has had enough time out there. So I will push this to dm/next later this week. Sorry - I need to review a lot wrt v3. I do understand that it has been in enough time, but this causes a significant changes on entire framework, please hold on for a while I need to think with respect on qspi stuff with in the spi framework. Well I'm not sure it supports setting of the flags that are needed for that. I don't have a platform to test with anyway. On the other hand adding that support to driver model could easily be a separate effort. I don't see a good reason to hold up the core SPI / SPI flash support. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
