Re: [U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels
On Mon, 2015-03-02 at 00:07 +0200, Siarhei Siamashka wrote: Just one suggestion. It would be really nice if the Debian installer could present itself on all the available consoles, so that the user can use any of them for providing input to the installer. There is some reason why d-i doesn't do this by default. I think it's to do with bricking or otherwise interfering with devices attached to serial ports e.g I think Braille terminals were mentioned, but I suppose any random device might not like getting random strings of characters. Otherwise there will be a need to provide separate SD card images for the HDMI console (for the Raspberry Pi wannable competitors), the UART serial console (A10/A20 development boards without HDMI) and the USB OTG serial gadget console (for the tablets without HDMI). Instead of just having only a single SD card image to handle everything automatically. I've backported DT the /chosen/stdout-path support to the kernel a while ago and I thought together with Hans' u-boot patches to populate this field with the right thing then console selection would Just Work(tm). At least for HDMI vs. UART since I'm not quite sure how the OTG gadget console is presented to Linux and whether it falls into this stuff correctly. Oh, and one more suggestion. The SD card partitioning could be also improved in order to make it more user friendly. Right now the user may be confused by the Debian installer regarding what to do with the existing partition on the SD card (yes, it can be safely erased since the installer is running from RAM and does not rely on the data from that partition anymore). I leave this one to Karsten who looks after the SD card images. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode
On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote: On Fri, 27 Feb 2015 16:39:45 + Ian Campbell ijc+ub...@hellion.org.uk wrote: On Tue, 2015-02-24 at 04:48 +0200, Siarhei Siamashka wrote: In order to fully support booting the whole system over USB OTG without relying on anything else (MMC, SATA, USB sticks, ...), it is possible to upload the 'boot.scr' file to DRAM using the 'fel' tool. But U-Boot still needs to be able to pick it up there before checking any other boot media. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- The patch might be not the best way to implement this. But it would be great if U-Boot had out of the box support for: http://linux-sunxi.org/index.php?title=FEL/USBBootoldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 One of the bad things about this patch is that the scriptaddr variable needs to be hardcoded and protected agaist modifications (if this address is to be used from the SPL). Perhaps use a separate dedicated/hardcoded address for the FEL boot script to avoid adding unusual semantics to $scriptaddr (which might surprise users not using fel)? Making something that is FEL-boot specific and diverges from the normal configuration is not great. Is there a real practical need for anyone to override $scriptaddr and the other similar variables in the environment? If not, marking them as read-only (similar to how the MAC address is handled) may be a reasonable solution. I've certainly had to mess with $*addr in order to workaround issues with older versions of Xen booting on the cubietruck. More generally I think diverging from the norm with a sunxi specific variable is preferable to changing the semantics of existing variables to make them r/o, which will make sunxi inconsistent with other u-boot platforms. If the FEL address has to be 0x4310 for compatibility with existing instructions/tools that might mean moving the current scriptaddr elsewhere. I think we can live with that. There was an idea to make mksunxiboot tool store all these magic addresses into the bootable image, so that the fel tool could find them there. Some of such ideas are listed here: http://linux-sunxi.org/FEL/USBBoot#Potential_future_improvements_for_u-boot_v2015.07 This can only work if these addresses become compile time constants and can't be overridden by the environment. I'm afraid that won't fly, $fooaddr are not r/o variables. When felbooting there doesn't seem to be any particular reason why you have to use $fooaddr from the environment, they could just as well be addresses set by the boot.scr itself, whether derived from the eGON header or not. Also I'm not sure how this all could fit into the config_distro_bootcmd.h model, so I even have not tried that yet. Just at a quick glance, based on the PXE entry something like: #define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \ bootcmd_fel=source ...\0 i.e. all the magic params are irrelevant in this case. Perhaps bootcmd_#devtypel=...\0 but I don't think that's needed in this instance. BOOTENV_DEV_PXE doesn't bother at least. Then in BOOT_TARGET_DEVICES include func(FEL, fel, na) Well, in fact I'm not a big fan of the C preprocessor based approach used there. And if I understand it correctly, this is already causing some troubles for the A80 (sun9i) support: https://patchwork.ozlabs.org/patch/429463/ This has nothing much todo with the config_distro_bootcmd.h stuff, except the bootcmd stuff requires some of those variables to be set. The C preprocessor surely can be used, but such code is barely maintainable. Regardless, the above BOOTENV_DEV type stuff is how the common config_distro_bootcmd.h setup for adding a boot device works and should be used. Or you can try and convince the maintainers it should be done some other way globally, the important thing is that sunxi shouldn't be more special than necessary. IMHO all the necessary adjustments to the environment variables can be done at runtime in the misc_init_r() function. For example, pre-pending fel to the boot_targets variable can be done based on a runtime check and activated only for the FEL mode. This means the user cannot adjust things to suit their local needs, either disabling the fel script support or inserting it into the boot order wherever they want. Hardcoding that stuff in C is not a solution here I'm afraid. So, please integrate properly with the common bootcmd stuff used on other platforms instead of inventing sunxi specific ways to do things. If needed for this infrastructure to work well then IMHO it would be acceptable to either provide a function or set a variable on boot which indicates whether or not the system was fel booted so e.g you could write if $fel_booted; then source $feladdr; fi as bootcmd_fel. Unless there is some existing how was
Re: [U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size
+Tom Hi Jagan, On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On 12 January 2015 at 09:12, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On 17 December 2014 at 13:32, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On 15 December 2014 at 19:21, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Bin, On 11 December 2014 at 08:34, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Bin, On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote: This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K. Changes in v3: - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params Thanks for the updates - have you verified these changes? I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST. Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon. Let me know your inputs? I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support. Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4. I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd. You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong. Yes - about testing. Ping? What about your test results about this patch series? Some were pending - Will comment, pls- wait. thanks! -- I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series? Could you respond this? I wonder if this series could be merged in before MW is closed. I feel that you did not work on this. Can you please respond with any comments? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 13/13] dm: sunxi: Use driver model for Ethernet on Linksprite pcDuino3
On Sun, 2015-03-01 at 09:33 -0700, Simon Glass wrote: Switch this board over to use driver model for Ethernet Cover-letter RFC: dm: net: Conversion patches for sunxi driver model Ethernet This series is for Joe Hershberger. It is based on his RFC driver model Ethernet implementation, and enables it for the pcDuino3. END Did you intend to put this somewhere else? Signed-off-by: Simon Glass s...@chromium.org --- configs/Linksprite_pcDuino3_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/Linksprite_pcDuino3_defconfig b/configs/Linksprite_pcDuino3_defconfig index b5ff120..776588d 100644 --- a/configs/Linksprite_pcDuino3_defconfig +++ b/configs/Linksprite_pcDuino3_defconfig @@ -19,3 +19,4 @@ CONFIG_SYS_MALLOC_F_LEN=0x400 CONFIG_ETH_DESIGNWARE=y CONFIG_NETDEVICES=y CONFIG_NET=y +CONFIG_DM_ETH=y Also remove SUNXI_GMAC from CONFIG_SYS_EXTRA_OPTIONS? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 6/6] ti: armv7: am33xx: Move SPL SDRAM into the correct place
Hi Tom, On 3 March 2015 at 08:15, Tom Rini tr...@konsulko.com wrote: On Tue, Mar 03, 2015 at 08:03:02AM -0700, Simon Glass wrote: Currently SDRAM is set up before global_data is available. This will soon not work. Adjust the ordering to cope, using the new CONFIG_SPL_STACK_R option to ensure that the stack is still in SDRAM once baord_init_r() starts in SPL. Signed-off-by: Simon Glass s...@chromium.org It's good that we're on the same path :) I think we should stick this into the config files as part of getting people used to that. What I've got locally will also remove a bunch of CONFIG_SPL_STACK settings that don't do anything now (since they pointed back up to CONFIG_SYS_INIT_SP_ADDR). I'm going to test the hard case (falcon mode poking at env for settings). Agreed, I was nervous about doing that for things not in Kconfig. But I'm going to grab your patch as the base since keeping board_early_init_f() around will keep the am335x+NOR case closer to working. Please do whatever suits and thanks for sorting this out. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/6] dm: tegra: Enable driver model in SPL and adjust the GPIO driver
Use the full driver model GPIO and serial drivers in SPL now that these are
supported. Since device tree is not available they will use platform data.
Remove the special SPL GPIO function as it is no longer needed.
This is all in one commit to maintain bisectability.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6: None
Changes in v5: None
Changes in v4:
- Rebase on top of dm/master
Changes in v3:
- Drop extra blank line
Changes in v2:
- Rebase on top of the SPI series
arch/arm/mach-tegra/Kconfig | 3 +++
board/nvidia/seaboard/seaboard.c | 4 +---
drivers/gpio/Makefile| 4
drivers/gpio/tegra_gpio.c| 27 +++
include/configs/tegra-common.h | 6 --
5 files changed, 19 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 8615248..fccfd79 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -29,6 +29,9 @@ config USE_PRIVATE_LIBGCC
config DM
default y
+config SPL_DM
+ default y
+
config DM_SERIAL
default y
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index 11472eb..25480e4 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -20,10 +20,8 @@
void gpio_early_init_uart(void)
{
/* Enable UART via GPIO_PI3 (port 8, bit 3) so serial console works */
-#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI3, NULL);
-#endif
- tegra_spl_gpio_direction_output(GPIO_PI3, 0);
+ gpio_direction_output(GPIO_PI3, 0);
}
#endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index aa11f15..fe9a3b2 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -8,6 +8,10 @@
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_DM_GPIO) += gpio-uclass.o
endif
+/* TODO(s...@chromium.org): Only tegra supports driver model in SPL */
+ifdef CONFIG_TEGRA_GPIO
+obj-$(CONFIG_DM_GPIO) += gpio-uclass.o
+endif
obj-$(CONFIG_AT91_GPIO)+= at91_gpio.o
obj-$(CONFIG_INTEL_ICH6_GPIO) += intel_ich6_gpio.o
diff --git a/drivers/gpio/tegra_gpio.c b/drivers/gpio/tegra_gpio.c
index 43928b8..f870cdb 100644
--- a/drivers/gpio/tegra_gpio.c
+++ b/drivers/gpio/tegra_gpio.c
@@ -132,21 +132,6 @@ static void set_level(unsigned gpio, int high)
writel(u, bank-gpio_out[GPIO_PORT(gpio)]);
}
-/* set GPIO pin 'gpio' as an output, with polarity 'value' */
-int tegra_spl_gpio_direction_output(int gpio, int value)
-{
- /* Configure as a GPIO */
- set_config(gpio, 1);
-
- /* Configure GPIO output value. */
- set_level(gpio, value);
-
- /* Configure GPIO direction as output. */
- set_direction(gpio, 1);
-
- return 0;
-}
-
/*
* Generic_GPIO primitives.
*/
@@ -338,12 +323,19 @@ static int gpio_tegra_bind(struct udevice *parent)
int bank_count;
int bank;
int ret;
- int len;
/* If this is a child device, there is nothing to do here */
if (plat)
return 0;
+ /* TODO(s...@chromium.org): Remove once SPL supports device tree */
+#ifdef CONFIG_SPL_BUILD
+ ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE;
+ bank_count = TEGRA_GPIO_BANKS;
+#else
+ {
+ int len;
+
/*
* This driver does not make use of interrupts, other than to figure
* out the number of GPIO banks
@@ -353,6 +345,8 @@ static int gpio_tegra_bind(struct udevice *parent)
bank_count = len / 3 / sizeof(u32);
ctlr = (struct gpio_ctlr *)fdtdec_get_addr(gd-fdt_blob,
parent-of_offset, reg);
+ }
+#endif
for (bank = 0; bank bank_count; bank++) {
int port;
@@ -388,4 +382,5 @@ U_BOOT_DRIVER(gpio_tegra) = {
.probe = gpio_tegra_probe,
.priv_auto_alloc_size = sizeof(struct tegra_port_info),
.ops= gpio_tegra_ops,
+ .flags = DM_FLAG_PRE_RELOC,
};
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index 005fc6a..fa6ccc1 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -43,13 +43,7 @@
/*
* NS16550 Configuration
*/
-#ifdef CONFIG_SPL_BUILD
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE(-4)
-#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
-#else
#define CONFIG_TEGRA_SERIAL
-#endif
#define CONFIG_SYS_NS16550
/*
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/6] arm: spl: Avoid setting up a duplicate global data structure
This is already set up in crt0.S. We don't need a new structure and don't really want one in the 'data' section of the image, since it will be empty and crt0.S's changes will be ignored. As an interim measure, remove it only if CONFIG_DM is not defined. This allows us to press ahead with driver model in SPL and allow the stragglers to catch up. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v6: None Changes in v5: None Changes in v4: - Squash the gdata revert patch into this one - Allow gdata to survive unless CONFIG_DM is defined, for now Changes in v3: None Changes in v2: - Remove gdata definition from ARM spl header file also arch/arm/include/asm/spl.h | 2 ++ arch/arm/lib/spl.c | 4 2 files changed, 6 insertions(+) diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h index 17b6f54..6db405d 100644 --- a/arch/arm/include/asm/spl.h +++ b/arch/arm/include/asm/spl.h @@ -37,6 +37,8 @@ void spl_board_load_image(void); /* Linker symbols. */ extern char __bss_start[], __bss_end[]; +#ifndef CONFIG_DM extern gd_t gdata; +#endif #endif diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c index c41850a..bd8c7d2 100644 --- a/arch/arm/lib/spl.c +++ b/arch/arm/lib/spl.c @@ -13,6 +13,7 @@ #include image.h #include linux/compiler.h +#ifndef CONFIG_DM /* Pointer to as well as the global data structure for SPL */ DECLARE_GLOBAL_DATA_PTR; @@ -21,6 +22,7 @@ DECLARE_GLOBAL_DATA_PTR; * pafches that rely on it. The global_data area is set up in crt0.S. */ gd_t gdata __attribute__ ((section(.data))); +#endif /* * In the context of SPL, board_init_f must ensure that any clocks/etc for @@ -33,8 +35,10 @@ void __weak board_init_f(ulong dummy) /* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start); +#ifndef CONFIG_DM /* TODO: Remove settings of the global data pointer here */ gd = gdata; +#endif board_init_r(NULL, 0); } -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 6/6] ti: armv7: am33xx: Move SPL SDRAM into the correct place
Currently SDRAM is set up before global_data is available. This will soon
not work. Adjust the ordering to cope, using the new CONFIG_SPL_STACK_R
option to ensure that the stack is still in SDRAM once baord_init_r()
starts in SPL.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Add new patch for TI boards to avoid gdata
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/cpu/armv7/am33xx/board.c | 13 +
include/configs/ti_armv7_common.h | 3 ++-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 81477aa..67bef23 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -275,6 +275,14 @@ static void watchdog_disable(void)
;
}
+#ifdef CONFIG_SPL_BUILD
+void board_init_f(ulong dummy)
+{
+ board_early_init_f();
+ sdram_init();
+}
+#endif
+
void s_init(void)
{
/*
@@ -290,6 +298,7 @@ void s_init(void)
setup_clocks_for_console();
uart_soft_reset();
#if defined(CONFIG_NOR_BOOT) || defined(CONFIG_QSPI_BOOT)
+ /* TODO: This does not work, gd is not available yet */
gd-baudrate = CONFIG_BAUDRATE;
serial_init();
gd-have_console = 1;
@@ -298,9 +307,5 @@ void s_init(void)
/* Enable RTC32K clock */
rtc32k_enable();
#endif
-#ifdef CONFIG_SPL_BUILD
- board_early_init_f();
- sdram_init();
-#endif
}
#endif
diff --git a/include/configs/ti_armv7_common.h
b/include/configs/ti_armv7_common.h
index 2bd1164..9e7d94a 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -216,7 +216,8 @@
* end of the BSS area. We place our stack at 32MiB after the start of
* DRAM to allow room for all of the above.
*/
-#define CONFIG_SPL_STACK (CONFIG_SYS_SDRAM_BASE + (32 20))
+#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
+#define CONFIG_SPL_STACK_R (CONFIG_SYS_SDRAM_BASE + (32 20))
#ifndef CONFIG_SYS_TEXT_BASE
#define CONFIG_SYS_TEXT_BASE 0x8080
#endif
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 5/6] Make export interface support CONFIG_SYS_MALLOC_SIMPLE
When CONFIG_SYS_MALLOC_SIMPLE is defined, free() is a static inline. Make sure that the export interface still builds in this case. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v6: None Changes in v5: None Changes in v4: - Add new patch to make the export interface support CONFIG_SYS_MALLOC_SIMPLE Changes in v3: None Changes in v2: None include/_exports.h | 2 ++ include/exports.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/include/_exports.h b/include/_exports.h index 5944703..279017e 100644 --- a/include/_exports.h +++ b/include/_exports.h @@ -23,7 +23,9 @@ EXPORT_FUNC(dummy, void, free_hdlr, void) #endif EXPORT_FUNC(malloc, void *, malloc, size_t) +#ifndef CONFIG_SYS_MALLOC_SIMPLE EXPORT_FUNC(free, void, free, void *) +#endif EXPORT_FUNC(udelay, void, udelay, unsigned long) EXPORT_FUNC(get_timer, unsigned long, get_timer, unsigned long) EXPORT_FUNC(vprintf, int, vprintf, const char *, va_list) diff --git a/include/exports.h b/include/exports.h index 205affe..1a01e43 100644 --- a/include/exports.h +++ b/include/exports.h @@ -15,7 +15,9 @@ int printf(const char* fmt, ...); void install_hdlr(int, interrupt_handler_t, void*); void free_hdlr(int); void *malloc(size_t); +#ifndef CONFIG_SYS_MALLOC_SIMPLE void free(void*); +#endif void __udelay(unsigned long); unsigned long get_timer(unsigned long); int vprintf(const char *, va_list); -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 4/6] arm: spl: Allow board_init_r() to run with a larger stack
At present SPL uses a single stack, either CONFIG_SPL_STACK or CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and environment) require a lot of stack, some boards set CONFIG_SPL_STACK to point into SDRAM. They then set up SDRAM very early, before board_init_f(), so that the larger stack can be used. This is an abuse of lowlevel_init(). That function should only be used for essential start-up code which cannot be delayed. An example of a valid use is when only part of the SPL code is visible/executable, and the SoC must be set up so that board_init_f() can be reached. It should not be used for SDRAM init, console init, etc. Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new address before board_init_r() is called in SPL. The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README. Signed-off-by: Simon Glass s...@chromium.org For version 1: Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Reviewed-by: Stefan Roese s...@denx.de Tested-by: Bo Shen voice.s...@atmel.com Acked-by: Bo Shen voice.s...@atmel.com Acked-by: Heiko Schocher h...@denx.de Tested-by: Heiko Schocher h...@denx.de --- Changes in v6: None Changes in v5: - Rebase to master Changes in v4: - Adjust README to mention that lowlevel_init() should have no stack Changes in v3: None Changes in v2: - Move docs to top-level README file and expand them to cover U-Boot proper - Add Kconfig settings Kconfig | 18 ++ README | 69 + arch/arm/lib/crt0.S | 13 +++--- common/spl/spl.c| 35 +++ 4 files changed, 132 insertions(+), 3 deletions(-) diff --git a/Kconfig b/Kconfig index 91a0618..8de731d 100644 --- a/Kconfig +++ b/Kconfig @@ -96,6 +96,24 @@ config SPL help If you want to build SPL as well as the normal image, say Y. +config CONFIG_SPL_STACK_R + depends on SPL + bool Enable SDRAM location for SPL stack + help + SPL starts off execution in SRAM and thus typically has only a small + stack available. Since SPL sets up DRAM while in its board_init_f() + function, it is possible for the stack to move there before + board_init_r() is reached. This option enables a special SDRAM + location for the SPL stack. U-Boot SPL switches to this after + board_init_f() completes, and before board_init_r() starts. + +config CONFIG_SPL_STACK_R_ADDR + depends on CONFIG_SPL_STACK_R + hex SDRAM location for SPL stack + help + Specify the address in SDRAM for the SPL stack. This will be set up + before board_init_r() is called. + config TPL bool depends on SPL SUPPORT_TPL diff --git a/README b/README index febefb5..3547ead 100644 --- a/README +++ b/README @@ -273,6 +273,75 @@ run some of U-Boot's tests. See board/sandbox/README.sandbox for more details. +Board Initialisation Flow: +-- + +This is the intended start-up flow for boards. This should apply for both +SPL and U-Boot proper (i.e. they both follow the same rules). At present SPL +mostly uses a separate code path, but the funtion names and roles of each +function are the same. Some boards or architectures may not conform to this. +At least most ARM boards which use CONFIG_SPL_FRAMEWORK conform to this. + +Execution starts with start.S with three functions called during init after +that. The purpose and limitations of each is described below. + +lowlevel_init(): + - purpose: essential init to permit execution to reach board_init_f() + - no global_data or BSS + - there is no stack (ARMv7 may have one but it will soon be removed) + - must not set up SDRAM or use console + - must only do the bare minimum to allow execution to continue to + board_init_f() + - this is almost never needed + - return normally from this function + +board_init_f(): + - purpose: set up the machine ready for running board_init_r(): + i.e. SDRAM and serial UART + - global_data is available + - stack is in SRAM + - BSS is not available, so you cannot use global/static variables, + only stack variables and global_data + + Non-SPL-specific notes: + - dram_init() is called to set up DRAM. If already done in SPL this + can do nothing + + SPL-specific notes: + - you can override the entire board_init_f() function with your own + version as needed. + - preloader_console_init() can be called here in extremis + - should set up SDRAM, and anything needed to make the UART work + - these is no need to clear BSS, it will be done by crt0.S + - must return normally from this function (don't call board_init_r() + directly) + +Here the BSS is cleared. For SPL, if CONFIG_SPL_STACK_R is defined, then at +this point the
Re: [U-Boot] [PATCH v5 0/5] Clean out SPL and enable driver model
Hi Tom,
On 3 March 2015 at 07:48, Tom Rini tr...@konsulko.com wrote:
On Tue, Mar 03, 2015 at 09:06:15AM -0500, Tom Rini wrote:
On Mon, Mar 02, 2015 at 09:39:37PM -0700, Simon Glass wrote:
Hi Tom,
On 2 March 2015 at 17:51, Tom Rini tr...@konsulko.com wrote:
On Mon, Mar 02, 2015 at 03:19:05PM -0700, Simon Glass wrote:
Hi,
On 26 February 2015 at 10:26, Simon Glass s...@chromium.org wrote:
This series includes a few more patches aimed at getting rid of
gdata, the
parallel global_data structure introduced on some ARM boards.
It also collects together the other patches which have been sent
previously,
so that everything is in one place.
I would like get this agreed and applied to u-boot-dm this week if
possible
so that we will at last have driver model available in SPL.
This series is available at u-boot-dm/spl-working.
Changes in v5:
- Rebase to master
Are there any more comments on this? I know Albert was looking at
applying it, but I am tempted to bring it through the u-boot-dm tree
and get it in. RC3 is soon!
Did you have something that switched beaglebone black over to this?
Thanks!
I think I sent patches at the time but they were too radical. I'm even
nervous about the current set which is why I want time for people to
test this.
I'll dig this up and send a v6.
I recall you had something radical before but I solved those problems (I
thought!) differently and that brought us back to the need to add
CONFIG_SPL_STACK_R which shouldn't be a big deal. I'm kicking at the
problem again differently this morning (aside, conmux + XMODEM is broken
in conmux it seem which breaks my workflow on some boards pretty bad).
OK, yeah, it's not _that_ bad:
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 81477aa..4436413 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -204,18 +204,20 @@ int arch_misc_init(void)
}
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
+#ifdef CONFIG_SPL_BUILD
/*
* In the case of non-SPL based booting we'll want to call these
* functions a tiny bit later as it will require gd to be set and cleared
* and that's not true in s_init in this case so we cannot do it there.
*/
-int board_early_init_f(void)
+void board_init_f(ulong dummy)
{
prcm_init();
set_mux_conf_regs();
- return 0;
+ sdram_init();
}
+#endif
/*
* This function is the place to do per-board things such as ramp up the
@@ -298,9 +300,5 @@ void s_init(void)
/* Enable RTC32K clock */
rtc32k_enable();
#endif
-#ifdef CONFIG_SPL_BUILD
- board_early_init_f();
- sdram_init();
-#endif
}
#endif
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 2e5aeaa..deecf95 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -1,4 +1,6 @@
CONFIG_SPL=y
+CONFIG_CONFIG_SPL_STACK_R=y
+CONFIG_CONFIG_SPL_STACK_R_ADDR=0x8200
CONFIG_SYS_EXTRA_OPTIONS=NAND
CONFIG_CONS_INDEX=1
+S:CONFIG_ARM=y
diff --git a/include/configs/ti_armv7_common.h
b/include/configs/ti_armv7_common.h
index 2bd1164..1882073 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -216,7 +216,6 @@
* end of the BSS area. We place our stack at 32MiB after the start of
* DRAM to allow room for all of the above.
*/
-#define CONFIG_SPL_STACK (CONFIG_SYS_SDRAM_BASE + (32 20))
#ifndef CONFIG_SYS_TEXT_BASE
#define CONFIG_SYS_TEXT_BASE 0x8080
#endif
I might even go so far as to say that's a clean-up. I do need to put
this through it's paces tho on am335x and then work on converting the
rest of the families.
Yes this looks similar to what I was fiddling with this morning. It's
at u-boot-dm/spl-working. It's just finished a run through buildman so
I'll resend v6. I made a change to the first patch to keep gdata
around for non-DM boards (seems prudent just in case).
But, Albert, shall we put this in right after -rc3?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 0/6] Clean out SPL and enable driver model
This series includes a few more patches aimed at getting rid of gdata, the parallel global_data structure introduced on some ARM boards. It also collects together the other patches which have been sent previously, so that everything is in one place. I would like get this agreed and applied to u-boot-dm this week if possible so that we will at last have driver model available in SPL. This series is available at u-boot-dm/spl-working. Changes in v6: - Make changes only when CONFIG_DM is defined, just in case - Add new patch for TI boards to avoid gdata Changes in v5: - Rebase to master Changes in v4: - Squash the gdata revert patch into this one - Allow gdata to survive unless CONFIG_DM is defined, for now - Rebase on top of dm/master - Adjust README to mention that lowlevel_init() should have no stack - Add new patch to make the export interface support CONFIG_SYS_MALLOC_SIMPLE Changes in v3: - Drop extra blank line Changes in v2: - Remove gdata definition from ARM spl header file also - Rebase on top of the SPI series - Move docs to top-level README file and expand them to cover U-Boot proper - Add Kconfig settings Simon Glass (6): arm: Reduce the scope of lowlevel_init() arm: spl: Avoid setting up a duplicate global data structure dm: tegra: Enable driver model in SPL and adjust the GPIO driver arm: spl: Allow board_init_r() to run with a larger stack Make export interface support CONFIG_SYS_MALLOC_SIMPLE ti: armv7: am33xx: Move SPL SDRAM into the correct place Kconfig| 18 ++ README | 69 ++ arch/arm/cpu/armv7/am33xx/board.c | 13 --- arch/arm/cpu/armv7/lowlevel_init.S | 22 ++-- arch/arm/include/asm/spl.h | 2 ++ arch/arm/lib/crt0.S| 13 +-- arch/arm/lib/spl.c | 4 +++ arch/arm/mach-tegra/Kconfig| 3 ++ board/nvidia/seaboard/seaboard.c | 4 +-- common/spl/spl.c | 35 +++ drivers/gpio/Makefile | 4 +++ drivers/gpio/tegra_gpio.c | 27 ++- include/_exports.h | 2 ++ include/configs/tegra-common.h | 6 include/configs/ti_armv7_common.h | 3 +- include/exports.h | 2 ++ 16 files changed, 192 insertions(+), 35 deletions(-) -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/6] arm: Reduce the scope of lowlevel_init()
This function has grown into something of a monster. Some boards are setting
up a console and DRAM here in SPL. This requires global_data which should be
set up in one place (crt0.S).
There is no need for SPL to use s_init() for anything since board_init_f()
is called immediately afterwards.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Make changes only when CONFIG_DM is defined, just in case
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/cpu/armv7/lowlevel_init.S | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/lowlevel_init.S
b/arch/arm/cpu/armv7/lowlevel_init.S
index f1aea05..427b0b1 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -17,10 +17,17 @@
ENTRY(lowlevel_init)
/*
-* Setup a temporary stack
+* Setup a temporary stack. Global data is not available yet.
*/
ldr sp, =CONFIG_SYS_INIT_SP_ADDR
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
+#ifdef CONFIG_DM
+ mov r9, #0
+#else
+ /*
+* Set up global data for boards that still need it. This will be
+* removed soon.
+*/
#ifdef CONFIG_SPL_BUILD
ldr r9, =gdata
#else
@@ -28,13 +35,24 @@ ENTRY(lowlevel_init)
bic sp, sp, #7
mov r9, sp
#endif
+#endif
/*
* Save the old lr(passed in ip) and the current lr to stack
*/
push{ip, lr}
/*
-* go setup pll, mux, memory
+* Call the very early init function. This should do only the
+* absolute bare minimum to get started. It should not:
+*
+* - set up DRAM
+* - use global_data
+* - clear BSS
+* - try to start a console
+*
+* For boards with SPL this should be empty since SPL can do all of
+* this init in the SPL board_init_f() function which is called
+* immediately after this.
*/
bl s_init
pop {ip, pc}
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 6/6] ti: armv7: am33xx: Move SPL SDRAM into the correct place
On Tue, Mar 03, 2015 at 08:03:02AM -0700, Simon Glass wrote: Currently SDRAM is set up before global_data is available. This will soon not work. Adjust the ordering to cope, using the new CONFIG_SPL_STACK_R option to ensure that the stack is still in SDRAM once baord_init_r() starts in SPL. Signed-off-by: Simon Glass s...@chromium.org It's good that we're on the same path :) I think we should stick this into the config files as part of getting people used to that. What I've got locally will also remove a bunch of CONFIG_SPL_STACK settings that don't do anything now (since they pointed back up to CONFIG_SYS_INIT_SP_ADDR). I'm going to test the hard case (falcon mode poking at env for settings). But I'm going to grab your patch as the base since keeping board_early_init_f() around will keep the am335x+NOR case closer to working. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 03/13] sunxi: Replace the pcDuino3 config with FDT version
On Sun, 2015-03-01 at 09:33 -0700, Simon Glass wrote: We currently have Linksprite_pcDuino3 and Linksprite_pcDuino3_fdt. Drop the former in favour of the latter. Signed-off-by: Simon Glass s...@chromium.org Is the FDT version a drop in replacement now? I didn't receive the whole series but I see that e.g. patch #13 is switching to driver model for Ethernet on this platform. Shouldn't this patch therefore come at the end of the series after that groundwork has been laid? _If_ I'm mistaken and this change at this point in the series is no functional change then: Acked-by: Ian Campbell i...@hellion.org.uk Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/4] ARM: DRA7XX: Add config file for Android with fastboot support
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
arch/arm/cpu/armv7/omap5/Kconfig | 5 +
board/ti/dra7xx/Kconfig | 13 ++
board/ti/dra7xx/MAINTAINERS | 2 +
configs/dra7xx_evm_android_defconfig | 5 +
include/configs/dra7xx_evm_android.h | 313 +++
5 files changed, 338 insertions(+)
create mode 100644 configs/dra7xx_evm_android_defconfig
create mode 100644 include/configs/dra7xx_evm_android.h
diff --git a/arch/arm/cpu/armv7/omap5/Kconfig b/arch/arm/cpu/armv7/omap5/Kconfig
index aca862d..d8e9b2d 100644
--- a/arch/arm/cpu/armv7/omap5/Kconfig
+++ b/arch/arm/cpu/armv7/omap5/Kconfig
@@ -12,6 +12,11 @@ config TARGET_OMAP5_UEVM
config TARGET_DRA7XX_EVM
bool TI DRA7XX
+config TARGET_DRA7XX_EVM_ANDROID
+ bool TI DRA7XX ANDROID
+ ---help---
+ TI DRA7XX build for Android. Enables Fastboot.
+
config TARGET_BEAGLE_X15
bool BeagleBoard X15
diff --git a/board/ti/dra7xx/Kconfig b/board/ti/dra7xx/Kconfig
index 3bbd866..6837998 100644
--- a/board/ti/dra7xx/Kconfig
+++ b/board/ti/dra7xx/Kconfig
@@ -10,3 +10,16 @@ config SYS_CONFIG_NAME
default dra7xx_evm
endif
+
+if TARGET_DRA7XX_EVM_ANDROID
+
+config SYS_BOARD
+ default dra7xx
+
+config SYS_VENDOR
+ default ti
+
+config SYS_CONFIG_NAME
+ default dra7xx_evm_android
+
+endif
diff --git a/board/ti/dra7xx/MAINTAINERS b/board/ti/dra7xx/MAINTAINERS
index 5ec6769..efd4f81 100644
--- a/board/ti/dra7xx/MAINTAINERS
+++ b/board/ti/dra7xx/MAINTAINERS
@@ -6,3 +6,5 @@ F: include/configs/dra7xx_evm.h
F: configs/dra7xx_evm_defconfig
F: configs/dra7xx_evm_qspiboot_defconfig
F: configs/dra7xx_evm_uart3_defconfig
+F: include/configs/dra7xx_evm_android.h
+F: configs/dra7xx_evm_android_defconfig
diff --git a/configs/dra7xx_evm_android_defconfig
b/configs/dra7xx_evm_android_defconfig
new file mode 100644
index 000..64ae4b3
--- /dev/null
+++ b/configs/dra7xx_evm_android_defconfig
@@ -0,0 +1,5 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=CONS_INDEX=1
++S:CONFIG_ARM=y
++S:CONFIG_OMAP54XX=y
++S:CONFIG_TARGET_DRA7XX_EVM_ANDROID=y
diff --git a/include/configs/dra7xx_evm_android.h
b/include/configs/dra7xx_evm_android.h
new file mode 100644
index 000..68e7eec
--- /dev/null
+++ b/include/configs/dra7xx_evm_android.h
@@ -0,0 +1,313 @@
+/*
+ * (C) Copyright 2013
+ * Texas Instruments Incorporated.
+ * Lokesh Vutla lokeshvu...@ti.com
+ *
+ * Configuration settings for the TI DRA7XX board.
+ * See ti_omap5_common.h for omap5 common settings.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_DRA7XX_EVM_ANDROID_H
+#define __CONFIG_DRA7XX_EVM_ANDROID_H
+
+#define CONFIG_DRA7XX
+#define CONFIG_BOARD_EARLY_INIT_F
+
+#ifndef CONFIG_QSPI_BOOT
+/* MMC ENV related defines */
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
+#define CONFIG_ENV_SIZE(128 10)
+#define CONFIG_ENV_OFFSET 0xE
+#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#endif
+#define CONFIG_CMD_SAVEENV
+
+#if (CONFIG_CONS_INDEX == 1)
+#define CONSOLEDEV ttyO0
+#elif (CONFIG_CONS_INDEX == 3)
+#define CONSOLEDEV ttyO2
+#endif
+#define CONFIG_SYS_NS16550_COM1UART1_BASE /* Base EVM has
UART0 */
+#define CONFIG_SYS_NS16550_COM2UART2_BASE /* UART2 */
+#define CONFIG_SYS_NS16550_COM3UART3_BASE /* UART3 */
+#define CONFIG_BAUDRATE115200
+
+#define CONFIG_SYS_OMAP_ABE_SYSCK
+
+/* Define the default GPT table for eMMC */
+#define PARTS_DEFAULT \
+ uuid_disk=${uuid_gpt_disk}; \
+ name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
+
+#ifdef CONFIG_NAND
+/* Define NAND information. */
+#define NANDARGS \
+ mtdids= MTDIDS_DEFAULT \0 \
+ mtdparts= MTDPARTS_DEFAULT \0 \
+ nandargs=setenv bootargs console=${console} \
+ ${optargs} \
+ root=${nandroot} \
+ rootfstype=${nandrootfstype}\0 \
+ nandroot=ubi0:rootfs rw ubi.mtd=NAND.file-system,2048\0 \
+ nandrootfstype=ubifs rootwait=1\0 \
+ nandboot=echo Booting from nand ...; \
+ run nandargs; \
+ nand read ${fdtaddr} NAND.u-boot-spl-os; \
+ nand read ${loadaddr} NAND.kernel; \
+ bootz ${loadaddr} - ${fdtaddr}\0
+#define NANDBOOT run nandboot;
+#endif
+
+#define DFU_ALT_INFO_MMC \
+ dfu_alt_info_mmc= \
+ boot part 0 1; \
+ rootfs part 0 2; \
+ MLO fat 0 1; \
+ spl-os-args fat 0 1; \
+ spl-os-image fat 0 1; \
+ u-boot.img fat 0 1; \
+ uEnv.txt fat 0 1\0
+
+#define DFU_ALT_INFO_EMMC \
+ dfu_alt_info_emmc= \
+ MLO raw 0x100 0x100 mmcpart 0; \
+
[U-Boot] [PATCH] ls1021atwr: add hwconfig setting to do pin mux
The Freescale LS1021ATWR share some pins, so Add the hwconfig option
that allows the user to choose which the function he wants.
Signed-off-by: Yuan Yao yao.y...@freescale.com
---
board/freescale/ls1021atwr/ls1021atwr.c | 78 +
1 file changed, 78 insertions(+)
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
b/board/freescale/ls1021atwr/ls1021atwr.c
index fb8525f..90aaa27 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -13,6 +13,7 @@
#include asm/arch/fsl_serdes.h
#include asm/arch/ls102xa_stream_id.h
#include asm/pcie_layerscape.h
+#include hwconfig.h
#include mmc.h
#include fsl_esdhc.h
#include fsl_ifc.h
@@ -54,6 +55,17 @@ DECLARE_GLOBAL_DATA_PTR;
#define KEEP_STATUS0x0
#define NEED_RESET 0x1
+#define SOFT_MUX_ON_I2C3_IFC 0x2
+#define SOFT_MUX_ON_CAN3_USB2 0x8
+#define SOFT_MUX_ON_QE_LCD 0x10
+
+#define PIN_I2C3_IFC_MUX_I2C3 0x0
+#define PIN_I2C3_IFC_MUX_IFC 0x1
+#define PIN_CAN3_USB2_MUX_USB2 0x0
+#define PIN_CAN3_USB2_MUX_CAN3 0x1
+#define PIN_QE_LCD_MUX_LCD 0x0
+#define PIN_QE_LCD_MUX_QE 0x1
+
struct cpld_data {
u8 cpld_ver;/* cpld revision */
u8 cpld_ver_sub;/* cpld sub revision */
@@ -260,6 +272,68 @@ int config_serdes_mux(void)
}
#endif
+#ifndef CONFIG_QSPI_BOOT
+int config_board_mux(void)
+{
+ struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
+ int conflict_flag;
+
+ conflict_flag = 0;
+ if (hwconfig(i2c3)) {
+ conflict_flag++;
+ cpld_data-soft_mux_on |= SOFT_MUX_ON_I2C3_IFC;
+ cpld_data-i2c3_ifc_mux = PIN_I2C3_IFC_MUX_I2C3;
+ }
+
+ if (hwconfig(ifc)) {
+ conflict_flag++;
+ /* some signals can not enable simultaneous*/
+ if (conflict_flag 1)
+ goto conflict;
+ cpld_data-soft_mux_on |= SOFT_MUX_ON_I2C3_IFC;
+ cpld_data-i2c3_ifc_mux = PIN_I2C3_IFC_MUX_IFC;
+ }
+
+ conflict_flag = 0;
+ if (hwconfig(usb2)) {
+ conflict_flag++;
+ cpld_data-soft_mux_on |= SOFT_MUX_ON_CAN3_USB2;
+ cpld_data-can3_usb2_mux = PIN_CAN3_USB2_MUX_USB2;
+ }
+
+ if (hwconfig(can3)) {
+ conflict_flag++;
+ /* some signals can not enable simultaneous*/
+ if (conflict_flag 1)
+ goto conflict;
+ cpld_data-soft_mux_on |= SOFT_MUX_ON_CAN3_USB2;
+ cpld_data-can3_usb2_mux = PIN_CAN3_USB2_MUX_CAN3;
+ }
+
+ conflict_flag = 0;
+ if (hwconfig(lcd)) {
+ conflict_flag++;
+ cpld_data-soft_mux_on |= SOFT_MUX_ON_QE_LCD;
+ cpld_data-qe_lcd_mux = PIN_QE_LCD_MUX_LCD;
+ }
+
+ if (hwconfig(qe)) {
+ conflict_flag++;
+ /* some signals can not enable simultaneous*/
+ if (conflict_flag 1)
+ goto conflict;
+ cpld_data-soft_mux_on |= SOFT_MUX_ON_QE_LCD;
+ cpld_data-qe_lcd_mux = PIN_QE_LCD_MUX_QE;
+ }
+
+ return 0;
+
+conflict:
+ printf(WARNING: pin conflict! MUX setting may failed!\n);
+ return 0;
+}
+#endif
+
int board_early_init_f(void)
{
struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
@@ -465,6 +539,10 @@ int board_init(void)
#if defined(CONFIG_MISC_INIT_R)
int misc_init_r(void)
{
+#ifndef CONFIG_QSPI_BOOT
+ config_board_mux();
+#endif
+
#ifdef CONFIG_FSL_CAAM
return sec_init();
#endif
--
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 v2 2/4] fastboot: call board_usb_init() to enable usb
g_dnl_gadget_register() fails for dra7xx dwc3 gadget
when running cmd_fastboot.
Calling board_usb_init() fixes this.
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
common/cmd_fastboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
index 346ab80..d7b8f6d 100644
--- a/common/cmd_fastboot.c
+++ b/common/cmd_fastboot.c
@@ -10,11 +10,13 @@
#include common.h
#include command.h
#include g_dnl.h
+#include usb.h
static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const
argv[])
{
int ret;
+ board_usb_init(0, USB_INIT_DEVICE);
g_dnl_clear_detach();
ret = g_dnl_register(usb_dnl_fastboot);
if (ret)
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] ARM: DRA7: Set serial number environment variable
Adds the registers to get the serial number of dra7xx boards.
Serial# environment variable will be set if not done already.
This will be useful to show correct information in
fastboot devices commands.
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
arch/arm/cpu/armv7/omap5/prcm-regs.c | 2 ++
arch/arm/include/asm/omap_common.h | 2 ++
board/ti/dra7xx/evm.c| 11 +++
3 files changed, 15 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 0745d42..020a964 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -440,6 +440,8 @@ struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
.control_wkup_ldovbb_mpu_voltage_ctrl = 0x4AE0C158,
+ .control_std_fuse_die_id_3 = 0x4AE0C210,
+ .control_std_fuse_prod_id_0 = 0x4AE0C214,
.control_padconf_mode = 0x4AE0C5A0,
.control_xtal_oscillator= 0x4AE0C5A4,
.control_i2c_2 = 0x4AE0C5A8,
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 323952f..b329803 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -362,6 +362,8 @@ struct omap_sys_ctrl_regs {
u32 control_core_control_io1;
u32 control_core_control_io2;
u32 control_id_code;
+ u32 control_std_fuse_die_id_3;
+ u32 control_std_fuse_prod_id_0;
u32 control_std_fuse_opp_bgap;
u32 control_ldosram_iva_voltage_ctrl;
u32 control_ldosram_mpu_voltage_ctrl;
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 6522241..e20d950 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -88,10 +88,21 @@ int board_init(void)
int board_late_init(void)
{
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ char serialno[72];
+ uint32_t serialno_lo, serialno_hi;
+
if (omap_revision() == DRA722_ES1_0)
setenv(board_name, dra72x);
else
setenv(board_name, dra7xx);
+
+ if (!getenv(serial#)) {
+ printf(serial# not set, setting...\n);
+ serialno_lo = readl((*ctrl)-control_std_fuse_die_id_3);
+ serialno_hi = readl((*ctrl)-control_std_fuse_prod_id_0);
+ sprintf(serialno, %08x%08x, serialno_hi, serialno_lo);
+ setenv(serial#, serialno);
+ }
#endif
return 0;
}
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 4/4] ARM: DRA7: fastboot: Implement reboot-bootloader command - Implemented fb_set_reboot_flag() for DRA7 - Defined a weak function, fb_check_reboot_flag() - Implemented for DRA7
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
board/ti/dra7xx/Makefile | 1 +
board/ti/dra7xx/fastboot.c | 45
common/cmd_bootm.c | 5
drivers/usb/gadget/f_fastboot.c | 5
include/configs/dra7xx_evm_android.h | 14 +++
5 files changed, 70 insertions(+)
create mode 100644 board/ti/dra7xx/fastboot.c
diff --git a/board/ti/dra7xx/Makefile b/board/ti/dra7xx/Makefile
index 434e8d1..ae730ae 100644
--- a/board/ti/dra7xx/Makefile
+++ b/board/ti/dra7xx/Makefile
@@ -6,3 +6,4 @@
#
obj-y := evm.o
+obj-$(CONFIG_CMD_FASTBOOT) += fastboot.o
diff --git a/board/ti/dra7xx/fastboot.c b/board/ti/dra7xx/fastboot.c
new file mode 100644
index 000..e05010d
--- /dev/null
+++ b/board/ti/dra7xx/fastboot.c
@@ -0,0 +1,45 @@
+/*
+ * (C) Copyright 2013
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * Lokesh Vutla lokeshvu...@ti.com
+ *
+ * Based on previous work by:
+ * Aneesh V ane...@ti.com
+ * Steve Sakoman st...@sakoman.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include asm/io.h
+#include asm-generic/gpio.h
+#include config.h
+
+
+int fb_set_reboot_flag(void)
+{
+ /* clear all reset events */
+ __raw_writel(DRA7XX_PRM_RSTST_CLR, PRM_RSTST);
+ strncpy((char *)DRA7XX_PUBLIC_SAR_RAM_1_FREE, bootloader,
+ DRA7XX_REBOOT_REASON_SIZE - 1);
+ *(((char *)DRA7XX_PUBLIC_SAR_RAM_1_FREE) +
+ DRA7XX_REBOOT_REASON_SIZE - 1) = '\0';
+ /* trigger warm reset */
+ __raw_writel(DRA7XX_PRM_RSTCTRL_RESET_WARM_BIT, DRA7XX_PRM_RSTCTRL);
+
+ return 0;
+}
+
+int fb_check_reboot_flag(void)
+{
+ /* Check if we are coming from a warm reset */
+ if (__raw_readl(DRA7XX_PRM_RSTST) DRA7XX_PRM_RSTST_RESET_WARM_BIT)
+ if (!strncmp((const char *)DRA7XX_PUBLIC_SAR_RAM_1_FREE,
+ bootloader, DRA7XX_REBOOT_REASON_SIZE)) {
+ strncpy((char *)DRA7XX_PUBLIC_SAR_RAM_1_FREE, ,
+ DRA7XX_REBOOT_REASON_SIZE);
+ return 0;
+ }
+
+ return 1;
+}
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 48199bf..00791be 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -729,6 +729,11 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
{
int ret;
+#if defined(CONFIG_CMD_FASTBOOT)
+ if (!fb_check_reboot_flag())
+ do_fastboot(cmdtp, flag, argc, argv);
+#endif
+
/* Consume 'booti' */
argc--; argv++;
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 206b6d1..a450357 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -332,6 +332,11 @@ int __weak fb_set_reboot_flag(void)
return -ENOSYS;
}
+int __weak fb_check_reboot_flag(void)
+{
+ return -ENOSYS;
+}
+
static void cb_reboot(struct usb_ep *ep, struct usb_request *req)
{
char *cmd = req-buf;
diff --git a/include/configs/dra7xx_evm_android.h
b/include/configs/dra7xx_evm_android.h
index 68e7eec..2038e00 100644
--- a/include/configs/dra7xx_evm_android.h
+++ b/include/configs/dra7xx_evm_android.h
@@ -310,4 +310,18 @@
#endif
#endif /* NOR support */
+#define DRA7XX_PUBLIC_SAR_RAM_1_FREE (0x4AE26000 + 0xFE0)
+#define DRA7XX_PRM_RSTCTRL_RESET_WARM_BIT (10)
+#define DRA7XX_PRM_RSTST_RESET_WARM_BIT(11)
+#define DRA7XX_PRM_RSTST 0x4AE07D04
+#define DRA7XX_PRM_RSTCTRL 0x4AE07D00
+#define DRA7XX_PRM_RSTST_CLR 0xfff
+#define DRA7XX_REBOOT_REASON_SIZE 0xf
+
+#define CONFIG_BOARD_MACH_TYPE 4070
+#define MEMORY_BASE 0x8000
+#define CONFIG_ADDR_ATAGS (MEMORY_BASE + 0x100)
+#define CONFIG_ADDR_DOWNLOAD(MEMORY_BASE + 0x0200)
+#define DEVICE_TREE 0x82f8
+
#endif /* __CONFIG_DRA7XX_EVM_ANDROID_H */
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/12] dm: device: add function device_get_first_child_by_uclass_id()
To implement functionality for devices connected by some external
interface, sometimes there is need to implement more then one,
and different uclass type drivers.
But only one i2c/spi dm chip can exists, per each bus i2c address
or spi select. Then, it seems to be useful, to get the child device
by uclass type, for the parent with known chip address.
So, this change will be useful for the pmic case:
|- i2c bus
'- pmic i2c chip (parent)
'- uclass regulator (child 1)
'- uclass charger (child 2)
This will allow to get the regulator or charger device if knows only parent
i2c/spi address.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- new commit
---
drivers/core/device.c | 15 +++
include/dm/device.h | 16
2 files changed, 31 insertions(+)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 73c3e07..76b22cf 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -397,6 +397,21 @@ int device_find_child_by_of_offset(struct udevice *parent,
int of_offset,
return -ENODEV;
}
+int device_get_first_child_by_uclass_id(struct udevice *parent, int uclass_id,
+ struct udevice **devp)
+{
+ struct udevice *dev;
+
+ *devp = NULL;
+
+ list_for_each_entry(dev, parent-child_head, sibling_node) {
+ if (dev-driver-id == uclass_id)
+ return device_get_device_tail(dev, 0, devp);
+ }
+
+ return -ENODEV;
+}
+
int device_get_child_by_of_offset(struct udevice *parent, int seq,
struct udevice **devp)
{
diff --git a/include/dm/device.h b/include/dm/device.h
index 7a48eb8..9f0d6ce 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -335,6 +335,22 @@ int device_get_child_by_of_offset(struct udevice *parent,
int seq,
struct udevice **devp);
/**
+ * device_get_first_child_by_uclass_id() - Get the first child device based
+ * on UCLASS_ID
+ *
+ * Locates a child device by its uclass id.
+ *
+ * The device is probed to activate it ready for use.
+ *
+ * @parent: Parent device
+ * @uclass_id: child uclass id
+ * @devp: Returns pointer to device if found, otherwise this is set to NULL
+ * @return 0 if OK, -ve on error
+ */
+int device_get_first_child_by_uclass_id(struct udevice *parent, int uclass_id,
+ struct udevice **devp);
+
+/**
* device_find_first_child() - Find the first child of a device
*
* @parent: Parent device to search
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 03/12] dm: pmic: add implementation of driver model pmic uclass
This is an introduction to driver-model multi uclass PMIC support.
It starts with UCLASS_PMIC - a common PMIC devices uclass type
to provide device read/write operations only.
Beside two basic operations the pmic platform data is introduced,
which provides basic informations about the pmic device I/O interface
and is shared with all childs (and should also for childs new uclass
types in the future).
Usually PMIC devices provides various functionalities with single
or multiple I/O interfaces.
Using this new framework and new uclass types introduced in the future,
it can be handle like this:
_ root device
|
|_ BUS 0 device (e.g. I2C0)- UCLASS_I2C/SPI/...
| |_ PMIC device 1 (read/write ops)- UCLASS_PMIC
| |_ REGULATOR device (ldo/buck/... ops) - UCLASS_REGULATOR
| |_ CHARGER device (charger ops)- UCLASS_CHARGER (in the future)
| |_ MUIC device (microUSB con ops) - UCLASS_MUIC(in the future)
| |_ ...
|
|_ BUS 1 device (e.g. I2C1)- UCLASS_I2C/SPI/...
|_ PMIC device 2 (read/write ops)- UCLASS_PMIC
|_ RTC device (rtc ops)- UCLASS_MUIC (in the future)
For each PMIC device interface, new UCLASS_PMIC device is bind with proper
pmic driver, and it's child devices provides some specified operations.
All new definitions can be found in file:
- 'include/power/pmic.h'
Uclass file:
- pmic-uclass.c - provides a common code for UCLASS_PMIC device drivers
The old pmic framework is still kept and is independent.
Changes:
- new uclass-id: UCLASS_PMIC
- new config: CONFIG_DM_PMIC
New pmic api is documented in: doc/README.power-framework-dm
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- pmic uclass: adjust uclass code to the mainline changes
- pmic uclass: remove pmic_i2c and pmic_spi
- pmic uclass: modify pmic_platdata
- pmic uclass: add pmic_if_* functions
- pmic uclass: remove pmic_init_dm()
- pmic uclass: cleanup
- pmic.h: define pmic ops structure (read/write operations)
- pmic.h: add comments to functions
---
drivers/power/Makefile | 1 +
drivers/power/pmic-uclass.c | 191 +++
include/dm/uclass-id.h | 3 +
include/power/pmic.h| 265
4 files changed, 460 insertions(+)
create mode 100644 drivers/power/pmic-uclass.c
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 2145652..5c9a189 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_DIALOG_POWER) += power_dialog.o
obj-$(CONFIG_POWER_FSL) += power_fsl.o
obj-$(CONFIG_POWER_I2C) += power_i2c.o
obj-$(CONFIG_POWER_SPI) += power_spi.o
+obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
diff --git a/drivers/power/pmic-uclass.c b/drivers/power/pmic-uclass.c
new file mode 100644
index 000..309463e
--- /dev/null
+++ b/drivers/power/pmic-uclass.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include linux/types.h
+#include fdtdec.h
+#include dm.h
+#include power/pmic.h
+#include dm/device-internal.h
+#include dm/uclass-internal.h
+#include dm/root.h
+#include dm/lists.h
+#include compiler.h
+#include errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static char * const pmic_interfaces[] = {
+ I2C,
+ SPI,
+ --,
+};
+
+const char *pmic_if_str(struct udevice *pmic)
+{
+ int if_types = ARRAY_SIZE(pmic_interfaces);
+ int if_type;
+
+ if_type = pmic_if_type(pmic);
+ if (if_type 0 || if_type = if_types)
+ return pmic_interfaces[if_types - 1];
+
+ return pmic_interfaces[if_type];
+}
+
+int pmic_if_type(struct udevice *pmic)
+{
+ struct pmic_platdata *pl = pmic-platdata;
+
+ return pl-if_type;
+}
+
+int pmic_if_bus_num(struct udevice *pmic)
+{
+ struct pmic_platdata *pl = pmic-platdata;
+
+ return pl-if_bus_num;
+}
+
+int pmic_if_addr_cs(struct udevice *pmic)
+{
+ struct pmic_platdata *pl = pmic-platdata;
+
+ return pl-if_addr_cs;
+}
+
+int pmic_if_max_offset(struct udevice *pmic)
+{
+ struct pmic_platdata *pl = pmic-platdata;
+
+ return pl-if_max_offset;
+}
+
+int pmic_read(struct udevice *pmic, unsigned reg, unsigned char *val)
+{
+ const struct dm_pmic_ops *ops;
+
+ ops = pmic_get_uclass_ops(pmic, UCLASS_PMIC);
+ if (!ops)
+ return -ENODEV;
+
+ if (!ops-read)
+ return -EPERM;
+
+ if (ops-read(pmic, reg, val))
+ return -EIO;
+
+ return 0;
+}
+
+int pmic_write(struct udevice *pmic, unsigned reg, unsigned char val)
+{
+ const struct dm_pmic_ops *ops;
+
+ ops = pmic_get_uclass_ops(pmic, UCLASS_PMIC);
+ if (!ops)
+ return -ENODEV;
+
+ if (!ops-write)
+ return -EPERM;
+
+ if (ops-write(pmic, reg, val))
+ return -EIO;
+
+ return
[U-Boot] [PATCH v2 11/12] odroid: dts: add 'voltage-regulators' description to max77686 node
Adding regulators subnode to fdt max77686 node allows properly init
regulators descriptors from by the max77686 regulator driver.
This enables the complete functionality of the regulator command.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- odroid: dts: remove pmic alias
---
arch/arm/dts/exynos4412-odroid.dts | 249 -
1 file changed, 248 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 582f6e5..6408c6f 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -35,11 +35,258 @@
samsung,i2c-max-bus-freq = 10;
status = okay;
- max77686_pmic@09 {
+ max77686 {
compatible = maxim,max77686_pmic;
interrupts = 7 0;
reg = 0x09 0 0;
#clock-cells = 1;
+
+ voltage-regulators {
+ ldo1_reg: ldo1 {
+ regulator-compatible = LDO1;
+ regulator-name = VDD_ALIVE_1.0V;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-compatible = LDO2;
+ regulator-name = VDDQ_VM1M2_1.2V;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-compatible = LDO3;
+ regulator-name = VCC_1.8V_AP;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-compatible = LDO4;
+ regulator-name = VDDQ_MMC2_2.8V;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-compatible = LDO5;
+ regulator-name = VDDQ_MMC0/1/3_1.8V;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-compatible = LDO6;
+ regulator-name = VMPLL_1.0V;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-compatible = LDO7;
+ regulator-name = VPLL_1.1V;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-compatible = LDO8;
+ regulator-name = VDD_MIPI/HDMI_1.0V;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-compatible = LDO9;
+ regulator-name = nc;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo10_reg: ldo10 {
+ regulator-compatible = LDO10;
+ regulator-name = VDD_MIPI/HDMI_1.8V;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
+ ldo11_reg: ldo11 {
+ regulator-compatible = LDO11;
+ regulator-name = VDD_ABB1_1.8V;
+
[U-Boot] [PATCH v2 12/12] odroid: config: enable dm pmic, dm regulator and max77686 driver
This change enables the configs required to init and setup max77686 regulator driver, using the new driver model pmic API. Enabled configs: - CONFIG_DM_PMIC_I2C - CONFIG_DM_PMIC_MAX77686 - CONFIG_DM_REGULATOR - CONFIG_DM_REGULATOR_MAX77686 And removes the unused: - CONFIG_DM_I2C_COMPAT - CONFIG_POWER - CONFIG_POWER_I2C - CONFIG_POWER_MAX77686 Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes V2: - config: enable dm i2c; cleanup - remove CONFIG_DM_I2C_COMPAT - enable regulator command --- configs/odroid_defconfig | 1 - include/configs/odroid.h | 9 ++--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig index 816a3fa..4116137 100644 --- a/configs/odroid_defconfig +++ b/configs/odroid_defconfig @@ -4,4 +4,3 @@ CONFIG_TARGET_ODROID=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=exynos4412-odroid CONFIG_DM_I2C=y -CONFIG_DM_I2C_COMPAT=y diff --git a/include/configs/odroid.h b/include/configs/odroid.h index 8b47537..d2bc7ee 100644 --- a/include/configs/odroid.h +++ b/include/configs/odroid.h @@ -182,9 +182,12 @@ #define CONFIG_SYS_I2C_S3C24X0_SLAVE 0 /* POWER */ -#define CONFIG_POWER -#define CONFIG_POWER_I2C -#define CONFIG_POWER_MAX77686 +#define CONFIG_DM_PMIC +#define CONFIG_DM_PMIC_CMD +#define CONFIG_DM_PMIC_MAX77686 +#define CONFIG_DM_REGULATOR +#define CONFIG_DM_REGULATOR_CMD +#define CONFIG_DM_REGULATOR_MAX77686 /* GPT */ #define CONFIG_RANDOM_UUID -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/12] exynos5: fix build break by adding CONFIG_POWER
Move the configs listed below from exynos5-dt-common.h to exynos5-common.h: - CONFIG_POWER - CONFIG_POWER_I2C fixes build break for Arndale and Smdk5250 boards. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- include/configs/exynos5-common.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index 3ab8d55..3ee9482 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -149,6 +149,10 @@ #define CONFIG_OF_SPI #endif +/* Power */ +#define CONFIG_POWER +#define CONFIG_POWER_I2C + #ifdef CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_ENV_SPI_MODESPI_MODE_0 #define CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 08/12] doc: driver-model: pmic and regulator uclass documentation
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes v2: - update documentation with the framework api changes --- doc/driver-model/dm-pmic-framework.txt | 367 + 1 file changed, 367 insertions(+) create mode 100644 doc/driver-model/dm-pmic-framework.txt diff --git a/doc/driver-model/dm-pmic-framework.txt b/doc/driver-model/dm-pmic-framework.txt new file mode 100644 index 000..f2fb4ac --- /dev/null +++ b/doc/driver-model/dm-pmic-framework.txt @@ -0,0 +1,367 @@ +# +# (C) Copyright 2014-2015 Samsung Electronics +# Przemyslaw Marczak p.marc...@samsung.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +PMIC framework based on Driver Model + +TOC: +1. Introduction +2. How does it work +3. Pmic driver api +4. Pmic driver +5. Pmic command +6. Regulator driver api +7. Design limitations +8. Regulator driver +9. Regulator command + +1. Introduction +=== +This is an introduction to driver-model multi uclass PMIC devices support. +At present it is based on two uclass types: + +- UCLASS_PMIC - basic uclass type for PMIC I/O, which provides common read/write +interface. + +- UCLASS_PMIC_REGULATOR - additional uclass type for specific PMIC features, + which are various voltage regulators. + +New files: +UCLASS_PMIC: +- drivers/power/pmic-uclass.c +- include/power/pmic.h +UCLASS_PMIC_REGULATOR: +- drivers/power/regulator-uclass.c +- include/power/regulator.h + +Commands: +- drivers/power/cmd_pmic.c (pmic; regulator) + +2. How doees it work + +The Power Management Integrated Circuits (PMIC) are used in embedded systems +to provide stable, precise and specific voltage power source with over-voltage +and thermal protection circuits. + +The single PMIC can provide various functionalities with single or multiple +interfaces, like in the example below. + +-- SoC + | + |__ + | BUS 0 | Multi interface PMIC IC|-- LDO out 1 + | e.g.I2C0 | |-- LDO out N + |---| PMIC device 0 (READ/WRITE ops) | + | or SPI0 ||_ REGULATOR device (ldo/... ops) |-- BUCK out 1 + | ||_ CHARGER device (charger ops) |-- BUCK out M + | ||_ MUIC device (microUSB con ops) | + | BUS 1 ||_ ...|--- BATTERY + | e.g.I2C1 | | + |---| PMIC device 1 (READ/WRITE ops) |--- USB in 1 + . or SPI1 ||_ RTC device (rtc ops) |--- USB in 2 + . |__|--- USB out + . + +Since U-Boot provides driver model features for I2C and SPI bus drivers, +the PMIC devices should also support this. With the new basic uclass types +for PMIC I/O and regulator features, PMIC drivers can simply provide common +features, with multiple interface and instance support. + +Basic design assumptions: + +- Common I/O api - UCLASS_PMIC +The main assumption is to use UCLASS_PMIC device to provide I/O interface, +for devices other uclass types. It is no matter what is the type of device +physical I/O interface. Usually PMIC devices are using SPI or I2C interface, +but use of any other interface (e.g. when PMIC is not directly connected +to the SoC) - is now possible. Drivers can use the same read/write api. + +- Common regulator api - UCLASS_REGULATOR +For setting the attributes of verious types of regulators with common api, +this uclass can be implemented. This allows to drive the each regulator output +value, on/off state and custom defined operation modes. It also provides the +user interface for all operations. +For the very simple implementation, the regulator drivers are not required, +so the code could base on pmic read/write only. + +When board device-tree file includes pmic subnode and the U_Boot compatible +driver exists, then the pmic device bind should looks like this: + +|_ root - will bind the device for I2C/SPI bus node + |_ i2c/spi - should bind a device for pmic node +|_ pmic (parent) - should bind child devices for its features + |_ regulator (child) + |_ charger (child) + |_ other (child) + +Usually PMIC design provides: + - single I/O interface (single UCLASS_PMIC driver) + Then UCLASS_PMIC device should be a parent of all pmic devices, where each + is usually different uclass type, but need to access the same interface + + - multiple I/O interfaces (UCLASS_PMIC driver for each) + For each interface the UCLASS_PMIC device should be a parent of only those + devices (different uclass types), which needs to access the specified + interface. + +3. Pmic driver api +=== +To use the pmic API, config: CONFIG_DM_PMIC is required. +The new driver API is very simple and is based on 'struct dm_pmic_ops', +which define two basic operations: device read and write. + +The platform data is
[U-Boot] [PATCH v2 05/12] dm: pmic: new commands: pmic and regulator
This introduces new commands:
- pmic (new) - CONFIG_DM_PMIC_CMD
- regulator - CONFIG_DM_REGULATOR_CMD
Both uses a common code and dm pmic api.
To avoid code mess the old pmic command is kept without changes.
Command pmic
The new pmic command uses driver model pmic api. The previous pmic
I/O functionality is keept. And now read/write is the main pmic command
feature. This command can be used only for UCLASS_PMIC devices,
since this uclass is designed for pmic I/O operations only and provides
pmic platform data.
Command options (pmic [option]):
- list - list available PMICs
- dev id - set id to current pmic device
- pmic dump- dump registers
- pmic read reg - read register
- pmic write reg value - write register
The user interface is changed. Before any operation, first the device
should be chosen.
Command regulator
It uses the same code, but provides user interface for regulator devices.
This was designed to access the regulator device without it's documentation.
It is possible, if driver implements uclass features, e.g. output descriptors.
Available commands:
- list - list UCLASS regulator devices
- dev [id] - show or set current regulator device
- dump - dump registers of current regulator device
- [ldo/buck/dvs][N] [name/state/desc]- print regulator(s) info
- [ldoN/buckN/dvsN] [setval/setmode] [mV/modeN] [-f] - set val (mV)
or mode - only if descriptor exists
The regulator descriptor 'min' and 'max' limits prevents setting
unsafe value. But sometimes it is useful to change the regulator
value for some test - so the force option (-f) is available.
This option is not available for change the mode, since this depends
on pmic device design.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes v2:
- remove errno_str() call
- pmic command: move some code to pmic uclass
- pmic command: code cleanup
- fix data types
- add command line, regulator on/off setting feature
- adjust to new pmic api
- cleanup
---
drivers/power/Makefile | 2 +
drivers/power/cmd_pmic.c | 820 +++
2 files changed, 822 insertions(+)
create mode 100644 drivers/power/cmd_pmic.c
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index a6b7012..943b38f 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -22,4 +22,6 @@ obj-$(CONFIG_POWER_FSL) += power_fsl.o
obj-$(CONFIG_POWER_I2C) += power_i2c.o
obj-$(CONFIG_POWER_SPI) += power_spi.o
obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
+obj-$(CONFIG_DM_PMIC_CMD) += cmd_pmic.o
obj-$(CONFIG_DM_REGULATOR) += regulator-uclass.o
+obj-$(CONFIG_DM_REGULATOR_CMD) += cmd_pmic.o
diff --git a/drivers/power/cmd_pmic.c b/drivers/power/cmd_pmic.c
new file mode 100644
index 000..996bfe7
--- /dev/null
+++ b/drivers/power/cmd_pmic.c
@@ -0,0 +1,820 @@
+/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include linux/types.h
+#include linux/ctype.h
+#include fdtdec.h
+#include dm.h
+#include power/pmic.h
+#include power/regulator.h
+#include dm/device-internal.h
+#include dm/uclass-internal.h
+#include dm/root.h
+#include dm/lists.h
+#include i2c.h
+#include compiler.h
+#include errno.h
+
+#define LINE_BUF_LIMIT 80
+#define STR_BUF_LEN26
+#define ID_STR_LIMIT 4
+#define UC_STR_LIMIT 16
+#define DRV_STR_LIMIT 26
+#define IF_STR_LIMIT 12
+
+static struct udevice *pmic_curr;
+static struct udevice *reg_curr;
+
+#ifdef CONFIG_DM_REGULATOR_CMD
+#define TYPE_INFO(_id, _name) { \
+ .id = _id, \
+ .len = ARRAY_SIZE(_name) - 1, \
+ .name = _name, \
+}
+
+enum display_info {
+ INFO_NAME,
+ INFO_STATE,
+ INFO_DESC,
+ INFO_DESC_MODE,
+ INFO_DESC_VAL,
+};
+
+struct regulator_type_info {
+ int id;
+ int len;
+ char *name;
+};
+
+static struct regulator_type_info type_info[] = {
+ TYPE_INFO(REGULATOR_TYPE_LDO, ldo),
+ TYPE_INFO(REGULATOR_TYPE_BUCK, buck),
+ TYPE_INFO(REGULATOR_TYPE_DVS, dvs),
+};
+
+char *regulator_type_str(int regulator_type)
+{
+ switch (regulator_type) {
+ case REGULATOR_TYPE_LDO:
+ case REGULATOR_TYPE_BUCK:
+ case REGULATOR_TYPE_DVS:
+ return type_info[regulator_type].name;
+ default:
+ return NULL;
+ }
+}
+#endif /* CONFIG_DM_REGULATOR_CMD */
+
+static int set_curr_dev(struct udevice *dev)
+{
+ if (!dev)
+ return -EINVAL;
+
+ if (!dev-driver)
+ return -EINVAL;
+
+ switch (dev-driver-id) {
+ case UCLASS_PMIC:
+ pmic_curr = dev;
+ break;
+ case UCLASS_PMIC_REGULATOR:
+ reg_curr = dev;
+ break;
+ default:
+ error(Bad driver uclass!\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct udevice *get_curr_dev(int
[U-Boot] [PATCH v2 09/12] dm: board:samsung: power_init_board: add requirement of CONFIG_DM_PMIC
In the power_init_board function call, regulator driver init is called,
so before compile, make sure that any power framework is defined.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
board/samsung/common/board.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index da2245f..c16e847 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -21,9 +21,9 @@
#include asm/arch/pinmux.h
#include asm/arch/power.h
#include asm/arch/system.h
-#include power/pmic.h
#include asm/arch/sromc.h
#include lcd.h
+#include i2c.h
#include samsung/misc.h
DECLARE_GLOBAL_DATA_PTR;
@@ -162,7 +162,7 @@ int board_early_init_f(void)
}
#endif
-#if defined(CONFIG_POWER)
+#if defined(CONFIG_POWER) || defined(CONFIG_DM_PMIC)
int power_init_board(void)
{
set_ps_hold_ctrl();
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 0/11] ARM: OMAP3-DRA7: CP15 erratum workarounds and improvements
On 03/03/2015 12:45 AM, Siarhei Siamashka wrote: [...] In one way, this can be verified by just checking that the necessary bits in the system registers are properly set according to the recommendations from the errata lists. AFAIK, only writes to these registers are restricted, so that it has to be done in an OMAP specific way using the SMC calls. But reading them somewhere early in the Linux kernel and doing printk should be fine. http://paste.ubuntu.org.cn/2522971 a quick patch on v4.0-rc1 to do the same. Sorry, test farm I have access to, is a bit wonky at the moment. (use omap2plus_defconfig) few of the boards I could cajole logs out are as follows (uses legacy bootloaders, not completely controlled source etc.. and are in a remote location that I cannot update easily): am335x-evm.txt:[0.00] o3_dump_arm_regs:CPUID=0x413fc082 ACR=0x0042 L2AUXCR=0x0042 am335x-sk.txt:[0.00] o3_dump_arm_regs:CPUID=0x413fc082 ACR=0x0042 L2AUXCR=0x0042 am3517-evm.txt:[0.00] o3_dump_arm_regs:CPUID=0x411fc087 ACR=0x00e2 L2AUXCR=0x0042 am37x-evm.txt:[0.00] o3_dump_arm_regs:CPUID=0x413fc082 ACR=0x00e2 L2AUXCR=0x0042 am57xx-evm.txt:[0.00] o5_dump_arm_regs:CPUID=0x412fc0f2 L2CTLR=0x01800083 L2ACLR=0x L2PFR=0x09b0 ACTLR=0x0040 beagleboard.txt:[0.00] o3_dump_arm_regs:CPUID=0x413fc082 ACR=0x00e2 L2AUXCR=0x0042 beaglebone-black.txt:[0.00] o3_dump_arm_regs:CPUID=0x413fc082 ACR=0x0042 L2AUXCR=0x0042 beaglebone.txt:[0.00] o3_dump_arm_regs:CPUID=0x413fc082 ACR=0x0042 L2AUXCR=0x0042 dra72x-evm.txt:[0.00] o5_dump_arm_regs:CPUID=0x412fc0f2 L2CTLR=0x00800083 L2ACLR=0x L2PFR=0x09b0 ACTLR=0x0040 dra7xx-evm.txt:[0.00] o5_dump_arm_regs:CPUID=0x412fc0f2 L2CTLR=0x01800083 L2ACLR=0x L2PFR=0x09b0 ACTLR=0x0040 omap5-evm.txt:[0.00] o5_dump_arm_regs:CPUID=0x412fc0f2 L2CTLR=0x01800083 L2ACLR=0x L2PFR=0x09b0 ACTLR=0x0040 -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 10/12] odroid: board: add support to dm pmic api
This commit change the old pmic framework calls with the new ones.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes v2:
- remove board_init_i2c() call
- update regulator calls
- update headers
- samsung/misc.c: include required header
---
board/samsung/common/misc.c | 1 +
board/samsung/odroid/odroid.c | 52 ++-
2 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 4538ac7..18d71e8 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -16,6 +16,7 @@
#include asm/arch/cpu.h
#include asm/gpio.h
#include linux/input.h
+#include dm.h
#include power/pmic.h
#include mmc.h
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index bff6ac9..2448cde 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -12,7 +12,9 @@
#include asm/arch/gpio.h
#include asm/gpio.h
#include asm/arch/cpu.h
+#include dm.h
#include power/pmic.h
+#include power/regulator.h
#include power/max77686_pmic.h
#include errno.h
#include usb.h
@@ -402,15 +404,23 @@ static void board_gpio_init(void)
static int pmic_init_max77686(void)
{
- struct pmic *p = pmic_get(MAX77686_PMIC);
+ struct udevice *reg;
+ int type;
- if (pmic_probe(p))
+ if (regulator_get(max77686, reg)) {
+ error(Regulator get error\n);
return -ENODEV;
+ }
/* Set LDO Voltage */
- max77686_set_ldo_voltage(p, 20, 180); /* LDO20 eMMC */
- max77686_set_ldo_voltage(p, 21, 280); /* LDO21 SD */
- max77686_set_ldo_voltage(p, 22, 280); /* LDO22 eMMC */
+ type = REGULATOR_TYPE_LDO;
+ regulator_set_value(reg, type, 20, 180);/* LDO20 eMMC */
+ regulator_set_value(reg, type, 21, 280);/* LDO21 SD */
+ regulator_set_value(reg, type, 22, 280);/* LDO22 eMMC */
+
+ regulator_set_mode(reg, type, 20, OPMODE_ON);
+ regulator_set_mode(reg, type, 21, OPMODE_ON);
+ regulator_set_mode(reg, type, 22, OPMODE_ON);
return 0;
}
@@ -435,7 +445,6 @@ int exynos_init(void)
int exynos_power_init(void)
{
- pmic_init(0);
pmic_init_max77686();
return 0;
@@ -444,19 +453,21 @@ int exynos_power_init(void)
#ifdef CONFIG_USB_GADGET
static int s5pc210_phy_control(int on)
{
- struct pmic *p_pmic;
+ struct udevice *reg;
+ int type;
- p_pmic = pmic_get(MAX77686_PMIC);
- if (!p_pmic)
+ if (regulator_get(max77686, reg)) {
+ error(Regulator get error\n);
return -ENODEV;
+ }
- if (pmic_probe(p_pmic))
- return -1;
+ type = REGULATOR_TYPE_LDO;
if (on)
- return max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
+ return regulator_set_mode(reg, type, 12, OPMODE_ON);
else
- return max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
+ return regulator_set_mode(reg, type, 12, OPMODE_LPM);
+
}
struct s3c_plat_otg_data s5pc210_otg_data = {
@@ -473,7 +484,8 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
int board_usb_init(int index, enum usb_init_type init)
{
#ifdef CONFIG_CMD_USB
- struct pmic *p_pmic;
+ struct udevice *reg;
+ int type, ret;
/* Set Ref freq 0 = 24MHz, 1 = 26MHz*/
/* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
@@ -491,14 +503,14 @@ int board_usb_init(int index, enum usb_init_type init)
/* Power off and on BUCK8 for LAN9730 */
debug(LAN9730 - Turning power buck 8 OFF and ON.\n);
- p_pmic = pmic_get(MAX77686_PMIC);
- if (p_pmic !pmic_probe(p_pmic)) {
- max77686_set_buck_voltage(p_pmic, 8, 75);
- max77686_set_buck_voltage(p_pmic, 8, 330);
+ if (regulator_get(max77686, reg)) {
+ type = REGULATOR_TYPE_BUCK;
+ ret = regulator_set_value(reg, type, 8, 75);
+ ret |= regulator_set_value(reg, type, 8, 330);
+ if (ret)
+ error(Can't set regulator\n);
}
-
#endif
-
debug(USB_udc_probe\n);
return s3c_udc_probe(s5pc210_otg_data);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/14] usb: dwc3: gadget: add common endpoint configuration for dwc3 udc driver
From: Marek Szyprowski m.szyprow...@samsung.com
This patch adds code to select standard, commonly used usb endpoint
configuration (ep1in-bulk, ep2out-bulk, ep3in-int) to dwc3 driver. This
ensures compatibility with old userspace and windows drivers, which
expects hardcoded endpoint numbers.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/gadget/epautoconf.c | 24 +++-
drivers/usb/gadget/gadget_chips.h | 8
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 0df4b2a..6ddbe83 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -220,7 +220,7 @@ struct usb_ep *usb_ep_autoconfig(
struct usb_endpoint_descriptor *desc
)
{
- struct usb_ep *ep;
+ struct usb_ep *ep = NULL;
u8 type;
type = desc-bmAttributes USB_ENDPOINT_XFERTYPE_MASK;
@@ -261,6 +261,28 @@ struct usb_ep *usb_ep_autoconfig(
ep = find_ep(gadget, ep1-bulk);
if (ep ep_matches(gadget, ep, desc))
return ep;
+ } else if (gadget_is_dwc3(gadget)) {
+ const char *name = NULL;
+ /*
+* First try standard, common configuration: ep1in-bulk,
+* ep2out-bulk, ep3in-int to match other udc drivers to avoid
+* confusion in already deployed software (endpoint numbers
+* hardcoded in userspace software/drivers)
+*/
+ if ((desc-bEndpointAddress USB_DIR_IN)
+ type == USB_ENDPOINT_XFER_BULK)
+ name = ep1in;
+ else if ((desc-bEndpointAddress USB_DIR_IN) == 0
+type == USB_ENDPOINT_XFER_BULK)
+ name = ep2out;
+ else if ((desc-bEndpointAddress USB_DIR_IN)
+type == USB_ENDPOINT_XFER_INT)
+ name = ep3in;
+
+ if (name)
+ ep = find_ep(gadget, name);
+ if (ep ep_matches(gadget, ep, desc))
+ return ep;
}
/* Second, look at endpoints until an unclaimed one looks usable */
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index cc94771..c859df2 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -156,6 +156,14 @@
#define gadget_is_fotg210(g)0
#endif
+#ifdef CONFIG_USB_DWC3_GADGET
+#define gadget_is_dwc3(g)(!strcmp(dwc3-gadget, (g)-name))
+#else
+#define gadget_is_dwc3(g)0
+#endif
+
+
+
/*
* CONFIG_USB_GADGET_SX2
* CONFIG_USB_GADGET_AU1X00
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/12] Power(full) framework based on Driver Model
And the patchset on github: https://github.com/bobenstein/u-boot/tree/dm-pmic-v2 Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/12] dm: pmic: add implementation of driver model regulator uclass
This is the implementation of driver model regulator uclass api.
To use it, the CONFIG_DM_PMIC is required with driver implementation,
since it provides pmic devices basic I/O API.
The regulator framework is based on a 'struct dm_regulator_ops'.
It provides a common function calls, for it's basic features:
- regulator_get_cnt()- number of outputs each type
- regulator_get_value_desc() - describe output value limits
- regulator_get_mode_desc() - describe output operation modes
- regulator_get/set_value() - output value (uV)
- regulator_get/set_state() - output on/off state
- regulator_get/set_mode() - output operation mode
To get the regulator device:
- regulator_get() - by name only
- regulator_i2c_get() - by i2c bus address (of pmic parent)
- regulator_spi_get() - by spi bus address (of pmic parent)
An optional and useful regulator framework features are two descriptors:
- struct regulator_desc - describes the regulator name and output value limits
should be defined by device driver for each regulator output.
- struct regulator_mode_desc - (array) describes a number of operation modes
supported by each regulator output.
The regulator framework features are described in file:
- include/power/regulator.h
Main files:
- drivers/power/regulator-uclass.c - provides regulator common functions api
- include/power/regulator.h - define all structures required by the regulator
Changes:
- new uclass-id: UCLASS_PMIC_REGULATOR
- new config: CONFIG_DM_REGULATOR
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- new operations for regulator uclass:
-- get/set output state - for output on/off setting
--- add enum: REGULATOR_OFF, REGULATOR_ON
- regulator uclass code rework and cleanup:
-- change name of:
--- enum 'regulator_desc_type' to 'regulator_type'
--- add type DVS
--- struct 'regulator_desc' to 'regulator_value_desc'
-- regulator ops function calls:
--- remove 'ldo/buck' from naming
--- add new argument 'type' for define regulator type
-- regulator.h - update comments
---
drivers/power/Makefile | 1 +
drivers/power/regulator-uclass.c | 227
include/dm/uclass-id.h | 1 +
include/power/regulator.h| 310 +++
4 files changed, 539 insertions(+)
create mode 100644 drivers/power/regulator-uclass.c
create mode 100644 include/power/regulator.h
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 5c9a189..a6b7012 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_POWER_FSL) += power_fsl.o
obj-$(CONFIG_POWER_I2C) += power_i2c.o
obj-$(CONFIG_POWER_SPI) += power_spi.o
obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
+obj-$(CONFIG_DM_REGULATOR) += regulator-uclass.o
diff --git a/drivers/power/regulator-uclass.c b/drivers/power/regulator-uclass.c
new file mode 100644
index 000..6b5c678
--- /dev/null
+++ b/drivers/power/regulator-uclass.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include linux/types.h
+#include fdtdec.h
+#include dm.h
+#include power/pmic.h
+#include power/regulator.h
+#include compiler.h
+#include dm/device.h
+#include dm/lists.h
+#include dm/device-internal.h
+#include errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int regulator_get_cnt(struct udevice *dev, int type, int *cnt)
+{
+ const struct dm_regulator_ops *ops;
+
+ ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
+ if (!ops)
+ return -ENODEV;
+
+ if (!ops-get_cnt)
+ return -EPERM;
+
+ return ops-get_cnt(dev, type, cnt);
+}
+
+int regulator_get_value_desc(struct udevice *dev, int type, int number,
+struct regulator_value_desc **desc)
+{
+ const struct dm_regulator_ops *ops;
+
+ ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
+ if (!ops)
+ return -ENXIO;
+
+ if (!ops-get_value_desc)
+ return -EPERM;
+
+ return ops-get_value_desc(dev, type, number, desc);
+}
+
+int regulator_get_mode_desc(struct udevice *dev, int type, int number,
+ int *mode_cnt, struct regulator_mode_desc **desc)
+{
+ const struct dm_regulator_ops *ops;
+
+ ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
+ if (!ops)
+ return -ENXIO;
+
+ if (!ops-get_mode_desc_array)
+ return -EPERM;
+
+ return ops-get_mode_desc_array(dev, type, number, mode_cnt, desc);
+}
+
+int regulator_get_value(struct udevice *dev, int type, int number, int *value)
+{
+ const struct dm_regulator_ops *ops;
+
+ ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
+ if (!ops)
+ return -ENODEV;
+
+ if (!ops-get_value)
+ return -EPERM;
+
+ return ops-get_value(dev, type, number,
[U-Boot] [PATCH v2 06/12] dm: pmic: add max77686 pmic driver
This is the implementation of driver model uclass pmic driver.
The max77686 pmic driver implements read/write operations and driver
bind method - to bind other pmic uclass devices as a parent pmic device.
This driver provides pmic_platdata for also for child regulator.
This driver will try to bind the regulator device with regulator driver.
This should succeed if regulator driver is compiled.
If no regulator driver found, then the pmic can still provide read/write
operations, and can be used with pmic framework function calls.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- add implementation of pmic read/write
- max77686: add new operations
- max77686: header: change PMIC_NUM_OF_REGS to MAX77686_NUM_OF_REGS
---
drivers/power/pmic/Makefile| 1 +
drivers/power/pmic/max77686.c | 102 +
drivers/power/pmic/pmic_max77686.c | 2 +-
include/power/max77686_pmic.h | 2 +-
4 files changed, 105 insertions(+), 2 deletions(-)
create mode 100644 drivers/power/pmic/max77686.c
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 985cfdb..242c767 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
obj-$(CONFIG_POWER_TPS65090_I2C) += pmic_tps65090.o
obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
diff --git a/drivers/power/pmic/max77686.c b/drivers/power/pmic/max77686.c
new file mode 100644
index 000..01867ac
--- /dev/null
+++ b/drivers/power/pmic/max77686.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fdtdec.h
+#include i2c.h
+#include dm.h
+#include power/pmic.h
+#include dm/device-internal.h
+#include dm/uclass-internal.h
+#include dm/root.h
+#include dm/lists.h
+#include power/max77686_pmic.h
+#include errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int max77686_write(struct udevice *pmic, unsigned reg, unsigned char
val)
+{
+ unsigned char buf[4] = { 0 };
+
+ buf[0] = cpu_to_le32(val) 0xff;
+
+ if (dm_i2c_write(pmic, reg, buf, 1)) {
+ error(write error to device: %p register: %#x!, pmic, reg);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int max77686_read(struct udevice *pmic, unsigned reg, unsigned char
*val)
+{
+ unsigned char buf[4] = { 0 };
+
+ if (dm_i2c_read(pmic, reg, buf, 1)) {
+ error(read error from device: %p register: %#x!, pmic, reg);
+ return -EIO;
+ }
+
+ *val = le32_to_cpu(buf[0]);
+
+ return 0;
+}
+
+static int max77686_bind(struct udevice *pmic)
+{
+ struct dm_i2c_chip *i2c_chip = dev_get_parent_platdata(pmic);
+ struct pmic_platdata *pl = pmic-platdata;
+ struct udevice *reg_dev;
+ struct driver *reg_drv;
+ int ret;
+
+ /* The same platdata is used for the regulator driver */
+ pl-if_type = PMIC_I2C;
+ pl-if_bus_num = pmic-parent-req_seq;
+ pl-if_addr_cs = i2c_chip-chip_addr;
+ pl-if_max_offset = MAX77686_NUM_OF_REGS;
+
+ reg_drv = lists_driver_lookup_name(max77686 regulator);
+ if (!reg_drv) {
+ error(PMIC: %s regulator driver not found!\n, pmic-name);
+ return 0;
+ }
+
+ /**
+* Try bind the child regulator driver
+* |-- I2C bus
+* '---max77686 pmic I/O driver
+* '--max77686 regulator driver
+*/
+ ret = device_bind(pmic, reg_drv, pmic-name, pmic-platdata,
+ pmic-of_offset, reg_dev);
+ if (ret)
+ error(%s regulator bind failed, pmic-name);
+
+ /* Always return success for this device */
+ return 0;
+}
+
+static struct dm_pmic_ops max77686_ops = {
+ .read = max77686_read,
+ .write = max77686_write,
+};
+
+static const struct udevice_id max77686_ids[] = {
+ { .compatible = maxim,max77686_pmic},
+ { }
+};
+
+U_BOOT_DRIVER(pmic_max77686) = {
+ .name = max77686 pmic,
+ .id = UCLASS_PMIC,
+ .of_match = max77686_ids,
+ .bind = max77686_bind,
+ .ops = max77686_ops,
+ .platdata_auto_alloc_size = sizeof(struct pmic_platdata),
+};
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index 95b1a57..1ad810a 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -295,7 +295,7 @@ int pmic_init(unsigned char bus)
p-name = name;
p-interface = PMIC_I2C;
- p-number_of_regs = PMIC_NUM_OF_REGS;
+ p-number_of_regs =
Re: [U-Boot] [PATCH V3 01/11] ARM: Introduce erratum workaround for 798870
On 02/25/2015 02:55 PM, Nishanth Menon wrote:
Add workaround for Cortex-A15 ARM erratum 798870 which says
If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock.
Implementations for SoC families such as Exynos, OMAP5/DRA7 etc
will be widely different.
Every SoC has slightly different manner of setting up access to L2ACLR
and similar registers since the Secure Monitor handling of Secure
Monitor Call(smc) is diverse. Hence an weak function is introduced
which may be overriden to implement SoC specific accessor implementation.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Signed-off-by: Nishanth Menon n...@ti.com
---
README |5 +
arch/arm/cpu/armv7/Makefile |2 +-
arch/arm/cpu/armv7/cp15.c| 23 +++
arch/arm/cpu/armv7/start.S | 20
arch/arm/include/asm/armv7.h |3 +++
5 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/cp15.c
diff --git a/README b/README
index a28ff133ee05..11ec37ba4a00 100644
--- a/README
+++ b/README
@@ -621,6 +621,11 @@ The following options need to be configured:
exists, unlike the similar options in the Linux kernel. Do not
set these options unless they apply!
+ NOTE: The following can be machine specific errata. These
+ do have ability to provide rudimentary version and machine
+ specific checks, but expect no product checks.
+ CONFIG_ARM_ERRATA_798870
+
- Driver Model
Driver model is a new framework for devices in U-Boot
introduced in early 2014. U-Boot is being progressively
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 409e6f5651b6..43da3e586f71 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -9,7 +9,7 @@ extra-y := start.o
obj-y+= cache_v7.o
-obj-y+= cpu.o
+obj-y+= cpu.o cp15.o
obj-y+= syslib.o
ifneq
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_SUNXI),)
diff --git a/arch/arm/cpu/armv7/cp15.c b/arch/arm/cpu/armv7/cp15.c
new file mode 100644
index ..8ac81c9ba147
--- /dev/null
+++ b/arch/arm/cpu/armv7/cp15.c
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2015 Texas Insturments
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/*
+ * CP15 specific code
+ */
+
+#include common.h
+#include command.h
+#include asm/system.h
+#include asm/cache.h
+#include asm/armv7.h
+#include linux/compiler.h
+
+void __weak v7_arch_cp15_set_l2aux_ctrl(u32 l2actlr, u32 cpu_midr,
+ u32 cpu_rev_comb, u32 cpu_variant,
+ u32 cpu_rev)
+{
+ asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(l2actlr));
+}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 70048c10aee6..ec46cec9cb1c 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -163,6 +163,26 @@ ENTRY(cpu_init_cp15)
mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register
#endif
+ mrc p15, 0, r1, c0, c0, 0 @ r1 has Read Main ID Register (MIDR)
+ mov r3, r1, lsr #20 @ get variant field
+ and r3, r3, #0xf@ r3 has CPU variant
+ and r4, r1, #0xf@ r4 has CPU revision
+ mov r2, r3, lsl #4 @ shift variant field for combined value
+ orr r2, r4, r2 @ r2 has combined CPU variant + revision
I think I should move these to beyond r3 as r0-r3 could be corrupted
in c invocation OR SMC invocation...
+
+#ifdef CONFIG_ARM_ERRATA_798870
+ cmp r2, #0x30 @ Applies to lower than R3p0
+ bge skip_errata_798870 @ skip if not affected rev
+ cmp r2, #0x20 @ Applies to including and above R2p0
+ blt skip_errata_798870 @ skip if not affected rev
+
+ mrc p15, 1, r0, c15, c0, 0 @ read l2 aux ctrl reg
+ orr r0, r0, #1 7 @ Enable hazard-detect timeout
+ b v7_arch_cp15_set_l2aux_ctrl
+ isb @ Recommended ISB after l2actlr update
+skip_errata_798870:
+#endif
+
mov pc, lr @ back to my caller
ENDPROC(cpu_init_cp15)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a13da23cf172..30e0cc3cf3d5 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -93,6 +93,9 @@ extern char __secure_end[];
#endif
Re: [U-Boot] [PATCH v2 00/12] Power(full) framework based on Driver Model
Hello, On 03/03/2015 05:24 PM, Przemyslaw Marczak wrote: Hello, Here is the second RFC version of the new PMIC framework. The changes made in this version are described below each commit. So again, a quick summary of: Framework: - Add new uclass types: -- UCLASS_PMIC(for device I/O) -- UCLASS_PMIC_REGULATOR (for common regulator ops) - Two uclass drivers for the above types - A common regulator operations - will easy cover the real devices design - V2: pmic: add read/write ops - V2: regulator: use regulator type as an argument - not as function name Drivers: - Introduce new PMIC API for drivers - now everything base on struct udevice - Introduce Regulator Voltage descriptors and Operation Mode descriptors which are usually taken from the device tree (board dependent data) - Two uclass device drivers for MAX77686(PMIC+REGULATOR) - V2: don't use the 'hw union' from old pmic - V2: remove the files: pmic_i2c.c/pmic_spi.c - now using bus drivers - V2: cleanup the pmic_get() functions - V2: add pmic_io_dev() function for getting the proper I/O dev for devices - V2: add function calls for getting pmic devices platdata - V2: remove regulator type from regulator operations function calls, use type as an argument User Interface: - command pmic, unchanged functionality and ported to the driver model - command regulator(NEW) for safe regulator setup from commandline, - now can check output Voltage and operation mode of the regulators, - also can check the board Voltage limits and driver available modes - V2: simplify the code after remove the regulator type from function naming - V2: add on/off command Supported boards: - Odroid U3 - V2: drop the commits for Trats2 - wait for charger and muic uclass types The assumptions of this work is: - Add new code to independent files - Keep two Frameworks as independent and without conflicts - Don't mix OLD/NEW Framework code - for the readability The future plans: - Add additional uclass types: MUIC, CHARGER, BATTERY, MFD and maybe more. - Port all U-Boot drivers to the new Framework - Remove the old drivers and the old PMIC Framework code Need help: - After merge this, it is welcome to help with driver porting - Every new driver should be tested on real hardware Best regards Przemyslaw Marczak (12): exynos5: fix build break by adding CONFIG_POWER dm: device: add function device_get_first_child_by_uclass_id() dm: pmic: add implementation of driver model pmic uclass dm: pmic: add implementation of driver model regulator uclass dm: pmic: new commands: pmic and regulator dm: pmic: add max77686 pmic driver dm: regulator: add max77686 regulator driver doc: driver-model: pmic and regulator uclass documentation dm: board:samsung: power_init_board: add requirement of CONFIG_DM_PMIC odroid: board: add support to dm pmic api odroid: dts: add 'voltage-regulators' description to max77686 node odroid: config: enable dm pmic, dm regulator and max77686 driver Makefile | 1 + arch/arm/dts/exynos4412-odroid.dts | 249 - board/samsung/common/board.c | 4 +- board/samsung/common/misc.c| 1 + board/samsung/odroid/odroid.c | 52 +- configs/odroid_defconfig | 1 - doc/driver-model/dm-pmic-framework.txt | 367 + drivers/core/device.c | 15 + drivers/power/Makefile | 5 +- drivers/power/cmd_pmic.c | 820 + drivers/power/pmic-uclass.c| 191 +++ drivers/power/pmic/Makefile| 1 + drivers/power/pmic/max77686.c | 102 drivers/power/pmic/pmic_max77686.c | 2 +- drivers/power/regulator-uclass.c | 227 drivers/power/regulator/Makefile | 8 + drivers/power/regulator/max77686.c | 926 + include/configs/exynos5-common.h | 4 + include/configs/odroid.h | 9 +- include/dm/device.h| 16 + include/dm/uclass-id.h | 4 + include/power/max77686_pmic.h | 26 +- include/power/pmic.h | 265 ++ include/power/regulator.h | 310 +++ 24 files changed, 3573 insertions(+), 33 deletions(-) create mode 100644 doc/driver-model/dm-pmic-framework.txt create mode 100644 drivers/power/cmd_pmic.c create mode 100644 drivers/power/pmic-uclass.c create mode 100644 drivers/power/pmic/max77686.c create mode 100644 drivers/power/regulator-uclass.c create mode 100644 drivers/power/regulator/Makefile create mode 100644 drivers/power/regulator/max77686.c create mode 100644 include/power/regulator.h Missed one e-mail: +cc: tr...@konsulko.com Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list
[U-Boot] [PATCH 08/14] usb: dwc3: add a workaround for too small OUT requests
From: Marek Szyprowski m.szyprow...@samsung.com DWC3 hangs on OUT requests smaller than maxpacket size, so HACK the request length to be at least equal to maxpacket size. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- drivers/usb/dwc3/gadget.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index a497fbb..737cb3e 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -973,6 +973,14 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req) req-epnum = dep-number; /* +* DWC3 hangs on OUT requests smaller than maxpacket size, +* so HACK the request length +*/ + if (dep-direction == 0 + req-request.length dep-endpoint.maxpacket) + req-request.length = dep-endpoint.maxpacket; + + /* * We only add to our list of requests now and * start consuming the list once we get XferNotReady * IRQ. -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/14] usb: dwc3: optimize interrupt loop
From: Marek Szyprowski m.szyprow...@samsung.com
There is no point in calling dwc3_thread_interrupt() if no event is
pending. There is also no point in flushing event cache in EVERY loop
iteration.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc3/core.c | 7 ---
drivers/usb/dwc3/gadget.c | 15 +--
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 45bb724..d067ef3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -766,18 +766,11 @@ void dwc3_uboot_exit(int index)
void dwc3_uboot_handle_interrupt(int index)
{
struct dwc3 *dwc = NULL;
- int i;
- struct dwc3_event_buffer *evt;
list_for_each_entry(dwc, dwc3_list, list) {
if (dwc-index != index)
continue;
- for (i = 0; i dwc-num_event_buffers; i++) {
- evt = dwc-ev_buffs[i];
- dwc3_flush_cache((int)evt-buf, evt-length);
- }
-
dwc3_gadget_uboot_handle_interrupt(dwc);
break;
}
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 737cb3e..d5dc70c 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2681,6 +2681,17 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
*/
void dwc3_gadget_uboot_handle_interrupt(struct dwc3 *dwc)
{
- dwc3_interrupt(0, dwc);
- dwc3_thread_interrupt(0, dwc);
+ int ret = dwc3_interrupt(0, dwc);
+
+ if (ret == IRQ_WAKE_THREAD) {
+ int i;
+ struct dwc3_event_buffer *evt;
+
+ for (i = 0; i dwc-num_event_buffers; i++) {
+ evt = dwc-ev_buffs[i];
+ dwc3_flush_cache((int)evt-buf, evt-length);
+ }
+
+ dwc3_thread_interrupt(0, dwc);
+ }
}
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 07/12] dm: regulator: add max77686 regulator driver
This commit adds support to max77686 regulator driver
based on a uclass regulator driver-model api, which
provides implementation of all uclass regulator api
function calls.
New file: drivers/power/regulator/max77686.c
New config: CONFIG_DM_REGULATOR_MAX77686
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V2:
- change debug() to error()
- code cleanup
- fix data types
- ldo/buck state implementation
- adjust to new uclass api
---
Makefile | 1 +
drivers/power/Makefile | 1 -
drivers/power/regulator/Makefile | 8 +
drivers/power/regulator/max77686.c | 926 +
include/power/max77686_pmic.h | 24 +-
5 files changed, 956 insertions(+), 4 deletions(-)
create mode 100644 drivers/power/regulator/Makefile
create mode 100644 drivers/power/regulator/max77686.c
diff --git a/Makefile b/Makefile
index 6da4215..fcb37ae 100644
--- a/Makefile
+++ b/Makefile
@@ -627,6 +627,7 @@ libs-y += drivers/power/ \
drivers/power/fuel_gauge/ \
drivers/power/mfd/ \
drivers/power/pmic/ \
+ drivers/power/regulator/ \
drivers/power/battery/
libs-y += drivers/spi/
libs-$(CONFIG_FMAN_ENET) += drivers/net/fm/
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 943b38f..7ff1baa 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_TPS6586X_POWER) += tps6586x.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030.o
obj-$(CONFIG_TWL6030_POWER)+= twl6030.o
obj-$(CONFIG_PALMAS_POWER) += palmas.o
-
obj-$(CONFIG_POWER) += power_core.o
obj-$(CONFIG_DIALOG_POWER) += power_dialog.o
obj-$(CONFIG_POWER_FSL) += power_fsl.o
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
new file mode 100644
index 000..9d282e3
--- /dev/null
+++ b/drivers/power/regulator/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2014 Samsung Electronics
+# Przemyslaw Marczak p.marc...@samsung.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
diff --git a/drivers/power/regulator/max77686.c
b/drivers/power/regulator/max77686.c
new file mode 100644
index 000..711c19c
--- /dev/null
+++ b/drivers/power/regulator/max77686.c
@@ -0,0 +1,926 @@
+/*
+ * Copyright (C) 2012-2015 Samsung Electronics
+ *
+ * Rajeshwari Shinde rajeshwar...@samsung.com
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fdtdec.h
+#include i2c.h
+#include dm.h
+#include power/pmic.h
+#include power/regulator.h
+#include power/max77686_pmic.h
+#include errno.h
+#include dm.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct max77686_regulator_info {
+ int ldo_cnt;
+ int buck_cnt;
+ struct regulator_value_desc ldo_desc[MAX77686_LDO_NUM + 1];
+ struct regulator_value_desc buck_desc[MAX77686_BUCK_NUM + 1];
+};
+
+#define MODE(_mode, _val, _name) { \
+ .mode = _mode, \
+ .register_value = _val, \
+ .name = _name, \
+}
+
+/* LDO: 1,3,4,5,9,17,18,19,20,21,22,23,24,26,26,27 */
+static struct regulator_mode_desc max77686_ldo_mode_standby1[] = {
+ MODE(OPMODE_OFF, MAX77686_LDO_MODE_OFF, OFF),
+ MODE(OPMODE_LPM, MAX77686_LDO_MODE_LPM, LPM),
+ MODE(OPMODE_STANDBY_LPM, MAX77686_LDO_MODE_STANDBY_LPM, ON/LPM),
+ MODE(OPMODE_ON, MAX77686_LDO_MODE_ON, ON),
+};
+
+/* LDO: 2,6,7,8,10,11,12,14,15,16 */
+static struct regulator_mode_desc max77686_ldo_mode_standby2[] = {
+ MODE(OPMODE_OFF, MAX77686_LDO_MODE_OFF, OFF),
+ MODE(OPMODE_STANDBY, MAX77686_LDO_MODE_STANDBY, ON/OFF),
+ MODE(OPMODE_STANDBY_LPM, MAX77686_LDO_MODE_STANDBY_LPM, ON/LPM),
+ MODE(OPMODE_ON, MAX77686_LDO_MODE_ON, ON),
+};
+
+/* Buck: 1 */
+static struct regulator_mode_desc max77686_buck_mode_standby[] = {
+ MODE(OPMODE_OFF, MAX77686_BUCK_MODE_OFF, OFF),
+ MODE(OPMODE_STANDBY, MAX77686_BUCK_MODE_STANDBY, ON/OFF),
+ MODE(OPMODE_ON, MAX77686_BUCK_MODE_ON, ON),
+};
+
+/* Buck: 2,3,4 */
+static struct regulator_mode_desc max77686_buck_mode_lpm[] = {
+ MODE(OPMODE_OFF, MAX77686_BUCK_MODE_OFF, OFF),
+ MODE(OPMODE_STANDBY, MAX77686_BUCK_MODE_STANDBY, ON/OFF),
+ MODE(OPMODE_LPM, MAX77686_BUCK_MODE_LPM, LPM),
+ MODE(OPMODE_ON, MAX77686_BUCK_MODE_ON, ON),
+};
+
+/* Buck: 5,6,7,8,9 */
+static struct regulator_mode_desc max77686_buck_mode_onoff[] = {
+ MODE(OPMODE_OFF, MAX77686_BUCK_MODE_OFF, OFF),
+ MODE(OPMODE_ON, MAX77686_BUCK_MODE_ON, ON),
+};
+
+static const char max77686_buck_addr[] = {
+ 0xff, 0x10, 0x12, 0x1c, 0x26, 0x30, 0x32, 0x34, 0x36, 0x38
+};
+
+static int max77686_buck_volt2hex(int buck, int uV)
+{
+ unsigned int hex = 0;
+ unsigned int hex_max = 0;
+
+ switch (buck) {
+ case 2:
+ case 3:
+ case 4:
+ /* hex = (uV - 60) / 12500; */
+ hex = (uV - MAX77686_BUCK_UV_LMIN) /
[U-Boot] [PATCH v2 00/12] Power(full) framework based on Driver Model
Hello, Here is the second RFC version of the new PMIC framework. The changes made in this version are described below each commit. So again, a quick summary of: Framework: - Add new uclass types: -- UCLASS_PMIC(for device I/O) -- UCLASS_PMIC_REGULATOR (for common regulator ops) - Two uclass drivers for the above types - A common regulator operations - will easy cover the real devices design - V2: pmic: add read/write ops - V2: regulator: use regulator type as an argument - not as function name Drivers: - Introduce new PMIC API for drivers - now everything base on struct udevice - Introduce Regulator Voltage descriptors and Operation Mode descriptors which are usually taken from the device tree (board dependent data) - Two uclass device drivers for MAX77686(PMIC+REGULATOR) - V2: don't use the 'hw union' from old pmic - V2: remove the files: pmic_i2c.c/pmic_spi.c - now using bus drivers - V2: cleanup the pmic_get() functions - V2: add pmic_io_dev() function for getting the proper I/O dev for devices - V2: add function calls for getting pmic devices platdata - V2: remove regulator type from regulator operations function calls, use type as an argument User Interface: - command pmic, unchanged functionality and ported to the driver model - command regulator(NEW) for safe regulator setup from commandline, - now can check output Voltage and operation mode of the regulators, - also can check the board Voltage limits and driver available modes - V2: simplify the code after remove the regulator type from function naming - V2: add on/off command Supported boards: - Odroid U3 - V2: drop the commits for Trats2 - wait for charger and muic uclass types The assumptions of this work is: - Add new code to independent files - Keep two Frameworks as independent and without conflicts - Don't mix OLD/NEW Framework code - for the readability The future plans: - Add additional uclass types: MUIC, CHARGER, BATTERY, MFD and maybe more. - Port all U-Boot drivers to the new Framework - Remove the old drivers and the old PMIC Framework code Need help: - After merge this, it is welcome to help with driver porting - Every new driver should be tested on real hardware Best regards Przemyslaw Marczak (12): exynos5: fix build break by adding CONFIG_POWER dm: device: add function device_get_first_child_by_uclass_id() dm: pmic: add implementation of driver model pmic uclass dm: pmic: add implementation of driver model regulator uclass dm: pmic: new commands: pmic and regulator dm: pmic: add max77686 pmic driver dm: regulator: add max77686 regulator driver doc: driver-model: pmic and regulator uclass documentation dm: board:samsung: power_init_board: add requirement of CONFIG_DM_PMIC odroid: board: add support to dm pmic api odroid: dts: add 'voltage-regulators' description to max77686 node odroid: config: enable dm pmic, dm regulator and max77686 driver Makefile | 1 + arch/arm/dts/exynos4412-odroid.dts | 249 - board/samsung/common/board.c | 4 +- board/samsung/common/misc.c| 1 + board/samsung/odroid/odroid.c | 52 +- configs/odroid_defconfig | 1 - doc/driver-model/dm-pmic-framework.txt | 367 + drivers/core/device.c | 15 + drivers/power/Makefile | 5 +- drivers/power/cmd_pmic.c | 820 + drivers/power/pmic-uclass.c| 191 +++ drivers/power/pmic/Makefile| 1 + drivers/power/pmic/max77686.c | 102 drivers/power/pmic/pmic_max77686.c | 2 +- drivers/power/regulator-uclass.c | 227 drivers/power/regulator/Makefile | 8 + drivers/power/regulator/max77686.c | 926 + include/configs/exynos5-common.h | 4 + include/configs/odroid.h | 9 +- include/dm/device.h| 16 + include/dm/uclass-id.h | 4 + include/power/max77686_pmic.h | 26 +- include/power/pmic.h | 265 ++ include/power/regulator.h | 310 +++ 24 files changed, 3573 insertions(+), 33 deletions(-) create mode 100644 doc/driver-model/dm-pmic-framework.txt create mode 100644 drivers/power/cmd_pmic.c create mode 100644 drivers/power/pmic-uclass.c create mode 100644 drivers/power/pmic/max77686.c create mode 100644 drivers/power/regulator-uclass.c create mode 100644 drivers/power/regulator/Makefile create mode 100644 drivers/power/regulator/max77686.c create mode 100644 include/power/regulator.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/14] usb: gadget: thor: Invoke board specific USB cleanup interface
From: Inha Song ideal.s...@samsung.com This patch invokes board-specific USB cleanup (board_usb_cleanup) function in the thor gadget. Signed-off-by: Inha Song ideal.s...@samsung.com --- common/cmd_thordown.c | 1 + 1 file changed, 1 insertion(+) diff --git a/common/cmd_thordown.c b/common/cmd_thordown.c index 8ed1dc6..436b7f5 100644 --- a/common/cmd_thordown.c +++ b/common/cmd_thordown.c @@ -56,6 +56,7 @@ int do_thor_down(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) exit: g_dnl_unregister(); + board_usb_cleanup(controller_index, USB_INIT_DEVICE); done: dfu_free_entities(); -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14/14] usb: gadget: thor: Claim EP after allocating it in thor gadget
From: Marek Szyprowski m.szyprow...@samsung.com
Storing thor device struct as an EP private data. It is necessary for
DWC3 operation.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/gadget/f_thor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 1fd41ff..6346370 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -806,6 +806,7 @@ static int thor_func_bind(struct usb_configuration *c,
struct usb_function *f)
}
dev-in_ep = ep; /* Store IN EP for enabling @ setup */
+ ep-driver_data = dev;
ep = usb_ep_autoconfig(gadget, fs_out_desc);
if (!ep) {
@@ -818,6 +819,7 @@ static int thor_func_bind(struct usb_configuration *c,
struct usb_function *f)
fs_out_desc.bEndpointAddress;
dev-out_ep = ep; /* Store OUT EP for enabling @ setup */
+ ep-driver_data = dev;
ep = usb_ep_autoconfig(gadget, fs_int_desc);
if (!ep) {
@@ -826,6 +828,7 @@ static int thor_func_bind(struct usb_configuration *c,
struct usb_function *f)
}
dev-int_ep = ep;
+ ep-driver_data = dev;
if (gadget_is_dualspeed(gadget)) {
hs_int_desc.bEndpointAddress =
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl_mem_init.c : Added support for mDDR in SPL for i.MX28
Hi Marco, On 23/02/2015 15:34, Marco Cavallini wrote: Signed-off-by: Marco Cavallini m.cavall...@koansoftware.com --- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index a744e5d..9e11288 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -315,9 +315,27 @@ static void mx28_mem_init(void) debug(SPL: Initialising mx28 SDRAM Controller\n); +#ifndef CONFIG_SYS_MXS_mDDR /* Set DDR2 mode */ writel(PINCTRL_EMI_DS_CTRL_DDR_MODE_DDR2, pinctrl_regs-hw_pinctrl_emi_ds_ctrl_set); +#else + /* Set mDDR mode */ + writel( PINCTRL_EMI_DS_CTRL_ADDRESS_MA_MASK | + PINCTRL_EMI_DS_CTRL_CONTROL_MA_MASK | + PINCTRL_EMI_DS_CTRL_DUALPAD_MA_MASK | + PINCTRL_EMI_DS_CTRL_SLICE3_MA_MASK | + PINCTRL_EMI_DS_CTRL_SLICE2_MA_MASK | + PINCTRL_EMI_DS_CTRL_SLICE1_MA_MASK | + PINCTRL_EMI_DS_CTRL_SLICE0_MA_MASK, + pinctrl_regs-hw_pinctrl_emi_ds_ctrl); + + /* Configure Pins 0-15 as EMI pins */ + writel(0, pinctrl_regs-hw_pinctrl_muxsel10); + writel(0, pinctrl_regs-hw_pinctrl_muxsel11); + writel(0, pinctrl_regs-hw_pinctrl_muxsel12); + writel(0, pinctrl_regs-hw_pinctrl_muxsel13); +#endif The thing is that there is no use case in mainline, because no board is using it. To avoid that the issue is completely hidden, I suggest to add at least documentation for CONFIG_SYS_MXS_mDDR in README. If someone else will use mDDR, it will be easy to find how. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 03/13] sunxi: Replace the pcDuino3 config with FDT version
Hi, On 03-03-15 09:34, Ian Campbell wrote: On Sun, 2015-03-01 at 09:33 -0700, Simon Glass wrote: We currently have Linksprite_pcDuino3 and Linksprite_pcDuino3_fdt. Drop the former in favour of the latter. Signed-off-by: Simon Glass s...@chromium.org Is the FDT version a drop in replacement now? AFAIK yes, this change was actually proposed by me since having 2 versions makes no sense and in the long run we want to move everything to devicetree. I didn't receive the whole series but I see that e.g. patch #13 is switching to driver model for Ethernet on this platform. Shouldn't this patch therefore come at the end of the series after that groundwork has been laid? _If_ I'm mistaken and this change at this point in the series is no functional change then: Acked-by: Ian Campbell i...@hellion.org.uk And also: Acked-by: Hans de Goede hdego...@redhat.com Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] warp: Add a README file
On Mon, Mar 2, 2015 at 3:22 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Mon, Mar 2, 2015 at 3:14 PM, Fabio Estevam feste...@gmail.com wrote: Hi Otavio, On Mon, Mar 2, 2015 at 3:12 PM, Otavio Salvador ota...@ossystems.com.br wrote: Well this README is covering WaRP so we ought to cover WaRP specifics there. What is the exact part of the README that has problems? Sorry, I am not able to get your point. Please be specific. Sorry; now it is clear. You need the env to DFU to work. Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Ask for help: Compulab CM-510 U-boot version: Load Kernel from SD-Card
Hello, I am trying to boot the kernel image from SD-CARD (mmc0) in the CM-510 SoM(provided by Compulab) using the u-boot image provided by Compulab: http://www.compulab.co.il/products/computer-on-modules/cm-a510/#devres By default, it seems SD-Card is not enabled, so I think I have to configure right the MPP option. I have searched over and over in the code sources, I have change some arrays defined in some files that are related to the MPP (pinmux) but nothing happens: ./board/marvell/mv_dove/dove_family/boardEnv/mvBoardEnvSpec.h: * DB-88F6781-BP B0 */ #define DB_88AP510BP_B_MPP0_7 0x #define DB_88AP510BP_B_MPP8_15 0x00442000 #define DB_88AP510BP_B_MPP16_23 0x32334043 --- #define DB_88AP510BP_B_MPP24_31 0x #define DB_88AP510BP_B_MPP32_39 0x #define DB_88AP510BP_B_MPP40_47 0x --- #define DB_88AP510BP_B_MPP48_55 0x #define DB_88AP510BP_B_MPP56_63 0x0011 #define DB_88AP510BP_B_OE_LOW (~((BIT1)|(BIT2)|(BIT5)|(BIT7)|(BIT8)|(BIT10)|(BIT11)|(BIT14)|(BIT15)|(BIT16)|(BIT18)|(BIT19))) #define DB_88AP510BP_B_OE_HIGH 0x0FFF #define DB_88AP510BP_B_OE_VAL_LOW ((BIT1)|(BIT2)|(BIT5)|(BIT7)|(BIT8)|(BIT10)|(BIT11)|(BIT16)|(BIT18)|(BIT19)) #define DB_88AP510BP_B_OE_VAL_HIGH 0x0 ./board/marvell/mv_dove/dove_family/boardEnv/mvBoardEnvSpec.c: MV_BOARD_MPP_INFO db88f6781bpbInfoBoardMppConfigValue[] = DB_88AP510BP_B_MPP0_7, DB_88AP510BP_B_MPP8_15, DB_88AP510BP_B_MPP16_23, DB_88AP510BP_B_MPP40_47 --- ; Anyone has faced this problem before? I really appreciate some kind of help. Best regards, Gabriel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/14] usb: board: samsung: Add default board_usb_cleanup() definition for Exynos SoCs
This definition is necessary for Exynos based boards to work properly.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
board/samsung/common/board.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 6c7f59b..7b10877 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -25,6 +25,7 @@
#include asm/arch/sromc.h
#include lcd.h
#include samsung/misc.h
+#include usb.h
DECLARE_GLOBAL_DATA_PTR;
@@ -380,3 +381,8 @@ void reset_misc(void)
dm_gpio_set_value(gpio, 1);
}
}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+ return 0;
+}
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/14] usb: dwc3: make dwc3_set_mode to static
From: Joonyoung Shim jy0922.s...@samsung.com
This commit makes the dwc3_set_mode() as static, to prevent collisions.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/usb/dwc3/core.c | 2 +-
drivers/usb/dwc3/core.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index aebebb4..45bb724 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -30,7 +30,7 @@
static LIST_HEAD(dwc3_list);
/* --
*/
-void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
+static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
{
u32 reg;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 5288a18..72d2fcd 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -987,7 +987,6 @@ struct dwc3_gadget_ep_cmd_params {
#define DWC3_HAS_OTG BIT(3)
/* prototypes */
-void dwc3_set_mode(struct dwc3 *dwc, u32 mode);
int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
#ifdef CONFIG_USB_DWC3_HOST
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/14] usb: dwc3: Fixes and improvements for DWC3 driver
This patch set should be applied on top of recent Kishon Vijay Abraham I work (v2) regarding providing dwc3 support to u-boot as well as clean up of the linux-compat header file. For the whole patch set please refer to -dfu u-boot repo, branch (devel/dwc3_gadget): http://git.denx.de/?p=u-boot/u-boot-dfu.git;a=shortlog;h=refs/heads/devel/dwc3_gadget This patch set fixes things, so all Samsung boards compile after applying DWC3 support. Tests and comments are welcome. Inha Song (2): usb: gadget: UMS: Invoke board specific USB cleanup interface usb: gadget: thor: Invoke board specific USB cleanup interface Joonyoung Shim (1): usb: dwc3: make dwc3_set_mode to static Marek Szyprowski (4): usb: dwc3: add a workaround for too small OUT requests usb: dwc3: gadget: add common endpoint configuration for dwc3 udc driver usb: dwc3: optimize interrupt loop usb: gadget: thor: Claim EP after allocating it in thor gadget Łukasz Majewski (7): usb: board: samsung: Add default board_usb_cleanup() definition for Exynos SoCs usb: board: goni: Add default board_usb_cleanup() definition for Goni board usb: composite: Add .reset callback to usb_gadget_driver structure usb: dwc3: Remove BIT(x) macro from DWC3's gadget code usb: dwc3: gadget: Set all ctrl fields of Transfer Control Blocks (TRB) to be LST usb: dwc3: gadget: Set non EP0 max packet limit to 512B usb: dwc3: Correct clean up code for requests board/samsung/common/board.c | 6 +++ board/samsung/goni/goni.c | 5 +++ common/cmd_thordown.c | 1 + common/cmd_usb_mass_storage.c | 1 + drivers/usb/dwc3/core.c | 9 + drivers/usb/dwc3/core.h | 3 +- drivers/usb/dwc3/gadget.c | 80 +++ drivers/usb/gadget/composite.c| 1 + drivers/usb/gadget/epautoconf.c | 24 +++- drivers/usb/gadget/f_thor.c | 3 ++ drivers/usb/gadget/gadget_chips.h | 8 11 files changed, 89 insertions(+), 52 deletions(-) -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/14] usb: dwc3: Remove BIT(x) macro from DWC3's gadget code
The BIT() macro is used only in those places, so it is reasonable to
replace it by a constant value.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/usb/dwc3/core.h | 2 +-
drivers/usb/dwc3/gadget.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index c5debf7..5288a18 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -392,7 +392,7 @@ struct dwc3_event_buffer {
unsigned intcount;
unsigned intflags;
-#define DWC3_EVENT_PENDING BIT(0)
+#define DWC3_EVENT_PENDING (1UL 0)
dma_addr_t dma;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4be4d99..a497fbb 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2365,7 +2365,7 @@ static void dwc3_gadget_linksts_change_interrupt(struct
dwc3 *dwc,
static void dwc3_gadget_hibernation_interrupt(struct dwc3 *dwc,
unsigned int evtinfo)
{
- unsigned int is_ss = evtinfo BIT(4);
+ unsigned int is_ss = evtinfo (1UL 4);
/**
* WORKAROUND: DWC3 revison 2.20a with hibernation support
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/14] usb: dwc3: Correct clean up code for requests
For u-boot dwc3 driver the scatter gather list support has been removed
from original linux code. It is correct, since we try to send one request
at a time.
However, the cleanup left spurious break, which caused early exit from
loop at dwc3_cleanup_done_reqs() function. As a result the
dwc3_gadget_giveback()
wasn't called and caused USB Mass Storage to hang.
This commit removes this problem and refactor the code to remove superfluous
do { } while(1) loop.
Test HW: Odroid XU3 (with ./test/ums/ums_gadget_test.sh)
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/usb/dwc3/gadget.c | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index b282f6a..763c951 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1753,33 +1753,23 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
struct dwc3_request *req;
struct dwc3_trb *trb;
unsigned intslot;
- int ret;
-
- do {
- req = next_request(dep-req_queued);
- if (!req) {
- WARN_ON_ONCE(1);
- return 1;
- }
-
- slot = req-start_slot;
- if ((slot == DWC3_TRB_NUM - 1)
- usb_endpoint_xfer_isoc(dep-endpoint.desc))
- slot++;
- slot %= DWC3_TRB_NUM;
- trb = dep-trb_pool[slot];
- dwc3_flush_cache((int)trb, sizeof(*trb));
- ret = __dwc3_cleanup_done_trbs(dwc, dep, req, trb,
- event, status);
- if (ret)
- break;
+ req = next_request(dep-req_queued);
+ if (!req) {
+ WARN_ON_ONCE(1);
+ return 1;
+ }
- dwc3_gadget_giveback(dep, req, status);
+ slot = req-start_slot;
+ if ((slot == DWC3_TRB_NUM - 1)
+ usb_endpoint_xfer_isoc(dep-endpoint.desc))
+ slot++;
+ slot %= DWC3_TRB_NUM;
+ trb = dep-trb_pool[slot];
- if (ret)
- break;
- } while (1);
+ dwc3_flush_cache((int)trb, sizeof(*trb));
+ __dwc3_cleanup_done_trbs(dwc, dep, req, trb, event, status);
+ dwc3_gadget_giveback(dep, req, status);
if (usb_endpoint_xfer_isoc(dep-endpoint.desc)
list_empty(dep-req_queued)) {
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/14] usb: composite: Add .reset callback to usb_gadget_driver structure
DWC3 UDC driver requires presence of .reset callback in a composite driver.
This setting is similar to the one nowadays present in linux kernel.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/usb/gadget/composite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 729a0fa..d96296c 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1052,6 +1052,7 @@ static struct usb_gadget_driver composite_driver = {
.unbind = composite_unbind,
.setup = composite_setup,
+ .reset = composite_disconnect,
.disconnect = composite_disconnect,
.suspend= composite_suspend,
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] watchdog/imx_watchdog: do not set WCR_WDW
with WCR_WDW set, the watchdog won't trigger if we bootet linux and idle
around while the watchdog is not triggered. It seems the timer makes
progress very slowly if at all. I managed to remain 20minutes alive
while the timeout was set to 60secs. It reboots within 60secs if I start
a busyloop in userland (something like while (1) { }).
While I don't see a reason why the WDT should not be running while the
CPU is in idle, I'm dropping this bit.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/watchdog/imx_watchdog.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
index d5993b4d26d6..1d18d4b269f8 100644
--- a/drivers/watchdog/imx_watchdog.c
+++ b/drivers/watchdog/imx_watchdog.c
@@ -20,7 +20,6 @@ struct watchdog_regs {
#define WCR_WDE0x04/* WDOG enable */
#define WCR_WDT0x08
#define WCR_SRS0x10
-#define WCR_WDW0x80
#define SET_WCR_WT(x) (x 8)
#ifdef CONFIG_IMX_WATCHDOG
@@ -47,7 +46,7 @@ void hw_watchdog_init(void)
#endif
timeout = (CONFIG_WATCHDOG_TIMEOUT_MSECS / 500) - 1;
writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
- WCR_WDW | SET_WCR_WT(timeout), wdog-wcr);
+ SET_WCR_WT(timeout), wdog-wcr);
hw_watchdog_reset();
}
#endif
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 05/11] ARM: OMAP: Change set_pl310_ctrl_reg to be generic
On 03/03/2015 11:08 AM, Tom Rini wrote:
On Wed, Feb 25, 2015 at 02:55:13PM -0600, Nishanth Menon wrote:
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The
only difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add
a data barrier which is necessary as per recommendation.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 13 -
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h|5 -
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e4217478..9b24369e4dc1 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -22,11 +22,14 @@ ENTRY(save_boot_params)
bx lr
ENDPROC(save_boot_params)
-ENTRY(set_pl310_ctrl_reg)
-PUSH{r4-r11, lr}@ save registers - ROM code may pollute
+ENTRY(omap_smc1)
+PUSH{r4-r12, lr}@ save registers - ROM code may pollute
@ our registers
-LDR r12, =0x102 @ Set PL310 control register - value in R0
+MOV r12, r0 @ Service
+MOV r0, r1 @ Argument
+DSB
+DMB
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
Lets stop hand-crafting that call, we just call smc #0 elsewhere in the
code base these days.
And we dont care about: -march=armv5 any-longer?
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot][PATCH] keystone2: add support for UART download
On 02/18/2015 09:35 AM, menon.nisha...@gmail.com wrote: On Wed, Feb 18, 2015 at 7:12 AM, Vitaly Andrianov vita...@ti.com wrote: On 02/17/2015 05:47 PM, Nishanth Menon wrote: On Tue, Feb 17, 2015 at 4:27 PM, Murali Karicheri m-kariche...@ti.com wrote: is complete the boot-loader sets the PC to the first MSMC address 0x0c00. The u-boot.bin is linked to the address 0x0c001000. why not just shift u-boot.bin to start of MSMC address? What is wrong with the current implementation? NAND and SPI NOR boot modes use the GPH headers that has the load address defined. But in the case of UART, RBL So it GPH header has the load address defined, it does mean that we could infact change the start address to 0xc00 (instead of current 0xc001000) and appropriately update the GPH headers to point there? that way we can use 0xc00 without padding on UART, as well as use the same in NAND/SPI as well? correct? loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction at the start of the memory to jump to 0xc001000. This way we can keep the same start address across all boot modes. Padding a 4kbytes (1K NOP at 32bits each) just because there is a difference between linked address and start address in a specific mode makes one wonder. This probably is not definitely a uniquely KS2 issue - we probably have similar behavior on other platforms as well. what if we chose a link address 2MB away (as an example)? agreed that the specific usage has no such size story in place, but conceptually we might be able to do better. In order to use the u-boot.bin as an image for UART download, we need to add 4K zeros prefix that act as 1K NOP instructions before reaching 0xc001000. OR, add a relocation logic which saves the 1k NOP and resultant load time? What saving are you talking about? Miliseconds? seconds? Maintainability? lets say we change link address tomorrow, we have to adjust padding appropriately, further we just dont need padding when we can just relocate self by being position independent in the first place!. we have learnt that over years OMAP3 link address has gone through a few transitions as we discovered better ways to do things. doing padding based on link address does, on the first look, seem unnecessary, makes sense only if all of the following are wrong: a) cannot change start address to the common start address for all boot modes. b) cannot add relocation and position independent u-boot code. And even when we do need to add padding, it is not a good idea to hard code the pad size, instead do it algorithmically (basically query the start and add the delta) allowing changes to link address to be something folks can do at a later point in time without unintentionally breaking uart boot. [...] As I've already mentioned this patch is not about improving or changing current u-boot.bin, but just providing a way to download it over UART port. Any improvements, if they are required, shall be done in other patches. We would not need a u-boot.uart if current u-boot.bin can do the job, do we? I just noticed this: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.arm-relocation;h=645b3746c8a88fe25f7c9a33cd9b8b17aa7b5a57;hb=HEAD#l37 without relocation capability, a board might be liable for removal? -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/14] usb: gadget: UMS: Invoke board specific USB cleanup interface
From: Inha Song ideal.s...@samsung.com This patch invokes board-specific USB cleanup (board_usb_cleanup) function in the mass storage gadget Signed-off-by: Inha Song ideal.s...@samsung.com --- common/cmd_usb_mass_storage.c | 1 + 1 file changed, 1 insertion(+) diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c index c5f909d..ccd4cc5 100644 --- a/common/cmd_usb_mass_storage.c +++ b/common/cmd_usb_mass_storage.c @@ -154,6 +154,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag, } exit: g_dnl_unregister(); + board_usb_cleanup(controller_index, USB_INIT_DEVICE); return CMD_RET_SUCCESS; } -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/14] usb: board: goni: Add default board_usb_cleanup() definition for Goni board
This definition is necessary for S5PC110 based GONI board to work properly.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
board/samsung/goni/goni.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index 58cf96e..d943d63 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -206,3 +206,8 @@ int misc_init_r(void)
return 0;
}
#endif
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+ return 0;
+}
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/14] usb: dwc3: gadget: Set all ctrl fields of Transfer Control Blocks (TRB) to be LST
It turned out that current dwc3 gadget code is preparing multiple TRBs
for a transfer. Unfortunately, when multiple requests are in the same
queue, only for the last one the LST (last) ctrl bit is set.
Due to that dwc3 HW executes all TRBs up till the one marked as last.
Unfortunately, UMS requires call of -complete callback after any send TRB.
This is the reason for hangs in executing UMS.
This code simplifies this situation and set each TRB's ctrl field bit to be
last (LST bit).
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/usb/dwc3/gadget.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index d5dc70c..0c7082c 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -787,7 +787,6 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
struct dwc3_request *req, *n;
u32 trbs_left;
u32 max;
- unsigned intlast_one = 0;
BUILD_BUG_ON_NOT_POWER_OF_2(DWC3_TRB_NUM);
@@ -837,24 +836,14 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
list_for_each_entry_safe(req, n, dep-request_list, list) {
unsignedlength;
dma_addr_t dma;
- last_one = false;
dma = req-request.dma;
length = req-request.length;
- trbs_left--;
-
- if (!trbs_left)
- last_one = 1;
-
- /* Is this the last request? */
- if (list_is_last(req-list, dep-request_list))
- last_one = 1;
dwc3_prepare_one_trb(dep, req, dma, length,
- last_one, false, 0);
+true, false, 0);
- if (last_one)
- break;
+ break;
}
}
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 05/11] ARM: OMAP: Change set_pl310_ctrl_reg to be generic
On Wed, Feb 25, 2015 at 02:55:13PM -0600, Nishanth Menon wrote:
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The
only difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add
a data barrier which is necessary as per recommendation.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 13 -
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h|5 -
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e4217478..9b24369e4dc1 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -22,11 +22,14 @@ ENTRY(save_boot_params)
bx lr
ENDPROC(save_boot_params)
-ENTRY(set_pl310_ctrl_reg)
- PUSH{r4-r11, lr}@ save registers - ROM code may pollute
+ENTRY(omap_smc1)
+ PUSH{r4-r12, lr}@ save registers - ROM code may pollute
@ our registers
- LDR r12, =0x102 @ Set PL310 control register - value in R0
+ MOV r12, r0 @ Service
+ MOV r0, r1 @ Argument
+ DSB
+ DMB
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
Lets stop hand-crafting that call, we just call smc #0 elsewhere in the
code base these days.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 05/11] ARM: OMAP: Change set_pl310_ctrl_reg to be generic
On 03/03/2015 11:12 AM, Nishanth Menon wrote:
On 03/03/2015 11:08 AM, Tom Rini wrote:
On Wed, Feb 25, 2015 at 02:55:13PM -0600, Nishanth Menon wrote:
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The
only difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add
a data barrier which is necessary as per recommendation.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 13 -
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h|5 -
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e4217478..9b24369e4dc1 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -22,11 +22,14 @@ ENTRY(save_boot_params)
bx lr
ENDPROC(save_boot_params)
-ENTRY(set_pl310_ctrl_reg)
- PUSH{r4-r11, lr}@ save registers - ROM code may pollute
+ENTRY(omap_smc1)
+ PUSH{r4-r12, lr}@ save registers - ROM code may pollute
@ our registers
- LDR r12, =0x102 @ Set PL310 control register - value in R0
+ MOV r12, r0 @ Service
+ MOV r0, r1 @ Argument
+ DSB
+ DMB
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
Lets stop hand-crafting that call, we just call smc #0 elsewhere in the
code base these days.
And we dont care about: -march=armv5 any-longer?
:( replacing this - causes build breakage:
Building omap3_overo board...
arch/arm/cpu/armv7/omap-common/lowlevel_init.S:34: Error: selected processor
does not support ARM mode `smc #0'
make[2]: *** [arch/arm/cpu/armv7/omap-common/lowlevel_init.o] Error 1
make[1]: *** [arch/arm/cpu/armv7/omap-common] Error 2
make: *** [arch/arm/cpu/armv7] Error 2
arch/arm/cpu/armv7/omap-common/lowlevel_init.S: Assembler messages:
arch/arm/cpu/armv7/omap-common/lowlevel_init.S:34: Error: selected processor
does not support ARM mode `smc #0'
make[2]: *** [arch/arm/cpu/armv7/omap-common/lowlevel_init.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/cpu/armv7/omap-common] Error 2
make: *** [arch/arm/cpu/armv7] Error 2
make: *** Waiting for unfinished jobs
I will retain the hand assembled value for now, if that is ok?
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] mx31pdk: Use the default CONFIG_SYS_PBSIZE
Hi On 2 March 2015 at 18:14, Fabio Estevam fabio.este...@freescale.com wrote: Entering the maximum number of characters defined by CONFIG_SYS_CBSIZE into the console and hitting enter afterwards, causes a hang in the system because CONFIG_SYS_PBSIZE is not capable of storing the extra characters of the error message: Unknown command '' - try 'help'. Use the default CONFIG_SYS_PBSIZE definition from config_fallbacks.h to solve this problem. Cc: Magnus Lilja lilja.mag...@gmail.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx31pdk.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h index 2a3e53c..1282a6e 100644 --- a/include/configs/mx31pdk.h +++ b/include/configs/mx31pdk.h @@ -121,9 +121,6 @@ */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ -/* Print Buffer Size */ -#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ - sizeof(CONFIG_SYS_PROMPT)+16) /* max number of command args */ #define CONFIG_SYS_MAXARGS 16 /* Boot Argument Buffer Size */ -- Looks ok to me. Acked-by: Magnus Lilja lilja.mag...@gmail.com /Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot][PATCH] keystone2: add support for UART download
On 03/03/2015 12:27 PM, Nishanth Menon wrote: On 02/18/2015 09:35 AM, menon.nisha...@gmail.com wrote: On Wed, Feb 18, 2015 at 7:12 AM, Vitaly Andrianov vita...@ti.com wrote: On 02/17/2015 05:47 PM, Nishanth Menon wrote: On Tue, Feb 17, 2015 at 4:27 PM, Murali Karicheri m-kariche...@ti.com wrote: is complete the boot-loader sets the PC to the first MSMC address 0x0c00. The u-boot.bin is linked to the address 0x0c001000. why not just shift u-boot.bin to start of MSMC address? What is wrong with the current implementation? NAND and SPI NOR boot modes use the GPH headers that has the load address defined. But in the case of UART, RBL So it GPH header has the load address defined, it does mean that we could infact change the start address to 0xc00 (instead of current 0xc001000) and appropriately update the GPH headers to point there? that way we can use 0xc00 without padding on UART, as well as use the same in NAND/SPI as well? correct? loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction at the start of the memory to jump to 0xc001000. This way we can keep the same start address across all boot modes. Padding a 4kbytes (1K NOP at 32bits each) just because there is a difference between linked address and start address in a specific mode makes one wonder. This probably is not definitely a uniquely KS2 issue - we probably have similar behavior on other platforms as well. what if we chose a link address 2MB away (as an example)? agreed that the specific usage has no such size story in place, but conceptually we might be able to do better. In order to use the u-boot.bin as an image for UART download, we need to add 4K zeros prefix that act as 1K NOP instructions before reaching 0xc001000. OR, add a relocation logic which saves the 1k NOP and resultant load time? What saving are you talking about? Miliseconds? seconds? Maintainability? lets say we change link address tomorrow, we have to adjust padding appropriately, further we just dont need padding when we can just relocate self by being position independent in the first place!. we have learnt that over years OMAP3 link address has gone through a few transitions as we discovered better ways to do things. doing padding based on link address does, on the first look, seem unnecessary, makes sense only if all of the following are wrong: a) cannot change start address to the common start address for all boot modes. b) cannot add relocation and position independent u-boot code. And even when we do need to add padding, it is not a good idea to hard code the pad size, instead do it algorithmically (basically query the start and add the delta) allowing changes to link address to be something folks can do at a later point in time without unintentionally breaking uart boot. [...] As I've already mentioned this patch is not about improving or changing current u-boot.bin, but just providing a way to download it over UART port. Any improvements, if they are required, shall be done in other patches. We would not need a u-boot.uart if current u-boot.bin can do the job, do we? I just noticed this: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.arm-relocation;h=645b3746c8a88fe25f7c9a33cd9b8b17aa7b5a57;hb=HEAD#l37 without relocation capability, a board might be liable for removal? The k2 u-boot is relocatable. It just simply cannot work w/o all required memory segments and its first instruction cannot be placed at the beginning of the available memory. You may want to look to common u-boot code for the reason. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/6] arm: spl: Allow board_init_r() to run with a larger stack
Hi Tom,
On 3 March 2015 at 10:49, Tom Rini tr...@konsulko.com wrote:
On Tue, Mar 03, 2015 at 08:03:00AM -0700, Simon Glass wrote:
At present SPL uses a single stack, either CONFIG_SPL_STACK or
CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
point into SDRAM. They then set up SDRAM very early, before board_init_f(),
so that the larger stack can be used.
This is an abuse of lowlevel_init(). That function should only be used for
essential start-up code which cannot be delayed. An example of a valid use is
when only part of the SPL code is visible/executable, and the SoC must be set
up so that board_init_f() can be reached. It should not be used for SDRAM
init, console init, etc.
Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
address before board_init_r() is called in SPL.
The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README.
Signed-off-by: Simon Glass s...@chromium.org
For version 1:
Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net
Reviewed-by: Stefan Roese s...@denx.de
Tested-by: Bo Shen voice.s...@atmel.com
Acked-by: Bo Shen voice.s...@atmel.com
Acked-by: Heiko Schocher h...@denx.de
Tested-by: Heiko Schocher h...@denx.de
---
Changes in v6: None
Changes in v5:
- Rebase to master
Changes in v4:
- Adjust README to mention that lowlevel_init() should have no stack
Changes in v3: None
Changes in v2:
- Move docs to top-level README file and expand them to cover U-Boot proper
- Add Kconfig settings
Kconfig | 18 ++
README | 69
+
arch/arm/lib/crt0.S | 13 +++---
common/spl/spl.c| 35 +++
4 files changed, 132 insertions(+), 3 deletions(-)
[snip]
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 22df3e5..7939ced 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -113,7 +113,14 @@ here:
/* Set up final (full) environment */
bl c_runtime_cpu_setup /* we still call old routine here */
-
+#endif
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK)
+# ifdef CONFIG_SPL_BUILD
+ /* Use a DRAM stack for the rest of SPL, if requested */
+ bl spl_relocate_stack_gd
+ cmp r0, #0
+ movne sp, r0
+# endif
ldr r0, =__bss_start/* this is auto-relocated! */
ldr r1, =__bss_end /* this is auto-relocated! */
@@ -124,9 +131,10 @@ clbss_l:cmp r0, r1 /* while not
at end of BSS */
addlo r0, r0, #4 /* move to next */
blo clbss_l
+#if ! defined(CONFIG_SPL_BUILD)
bl coloured_LED_init
bl red_led_on
-
+#endif
/* call board_init_r(gd_t *id, ulong dest_addr) */
mov r0, r9 /* gd_t */
ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
@@ -134,7 +142,6 @@ clbss_l:cmp r0, r1 /* while not
at end of BSS */
ldr pc, =board_init_r /* this is auto-relocated! */
/* we should not return here. */
-
#endif
ENDPROC(_main)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index ded0f30..cd75bbc 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -281,3 +281,38 @@ void preloader_console_init(void)
spl_display_print();
#endif
}
+
+/**
+ * spl_relocate_stack_gd() - Relocate stack ready for board_init_r()
execution
+ *
+ * Sometimes board_init_f() runs with a stack in SRAM but we want to use
SDRAM
+ * for the main board_init_r() execution. This is typically because we need
+ * more stack space for things like the MMC sub-system.
+ *
+ * This function calculates the stack position, copies the global_data into
+ * place and returns the new stack position. The caller is responsible for
+ * setting up the sp register.
+ *
+ * @return new stack location, or 0 to use the same stack
+ */
+ulong spl_relocate_stack_gd(void)
+{
+#ifdef CONFIG_SPL_STACK_R
+ gd_t *new_gd;
+ ulong ptr;
+
+ /* Get stack position: use 8-byte alignment for ABI compliance */
+ ptr = CONFIG_SPL_STACK_R - sizeof(gd_t);
+ ptr = ~7;
+ new_gd = (gd_t *)ptr;
+ memcpy(new_gd, (void *)gd, sizeof(gd_t));
+ gd = new_gd;
+
+ /* Clear the BSS. */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ return ptr;
+#else
+ return 0;
+#endif
+}
All of this _does_ move gd into where CONFIG_SPL_STACK_R points. It
does _not_ move the stack itself into where CONFIG_SPL_STACK_R points so
the big use case (am335x_boneblack for example where
CONFIG_SPL_ENV_SUPPORT is set) doesn't work and blows up as we overflow
the area for stack.
OK I'll have to test more. What sort of problem should i see?
The return value from spl_relocate_stack_gd() should be shoved into
sp. Does that not happen?
Regards,
Re: [U-Boot] [PATCH v6 4/6] arm: spl: Allow board_init_r() to run with a larger stack
On Tue, Mar 03, 2015 at 08:03:00AM -0700, Simon Glass wrote:
At present SPL uses a single stack, either CONFIG_SPL_STACK or
CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
point into SDRAM. They then set up SDRAM very early, before board_init_f(),
so that the larger stack can be used.
This is an abuse of lowlevel_init(). That function should only be used for
essential start-up code which cannot be delayed. An example of a valid use is
when only part of the SPL code is visible/executable, and the SoC must be set
up so that board_init_f() can be reached. It should not be used for SDRAM
init, console init, etc.
Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
address before board_init_r() is called in SPL.
The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README.
Signed-off-by: Simon Glass s...@chromium.org
For version 1:
Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net
Reviewed-by: Stefan Roese s...@denx.de
Tested-by: Bo Shen voice.s...@atmel.com
Acked-by: Bo Shen voice.s...@atmel.com
Acked-by: Heiko Schocher h...@denx.de
Tested-by: Heiko Schocher h...@denx.de
---
Changes in v6: None
Changes in v5:
- Rebase to master
Changes in v4:
- Adjust README to mention that lowlevel_init() should have no stack
Changes in v3: None
Changes in v2:
- Move docs to top-level README file and expand them to cover U-Boot proper
- Add Kconfig settings
Kconfig | 18 ++
README | 69
+
arch/arm/lib/crt0.S | 13 +++---
common/spl/spl.c| 35 +++
4 files changed, 132 insertions(+), 3 deletions(-)
[snip]
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 22df3e5..7939ced 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -113,7 +113,14 @@ here:
/* Set up final (full) environment */
bl c_runtime_cpu_setup /* we still call old routine here */
-
+#endif
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK)
+# ifdef CONFIG_SPL_BUILD
+ /* Use a DRAM stack for the rest of SPL, if requested */
+ bl spl_relocate_stack_gd
+ cmp r0, #0
+ movne sp, r0
+# endif
ldr r0, =__bss_start/* this is auto-relocated! */
ldr r1, =__bss_end /* this is auto-relocated! */
@@ -124,9 +131,10 @@ clbss_l:cmp r0, r1 /* while not at
end of BSS */
addlo r0, r0, #4 /* move to next */
blo clbss_l
+#if ! defined(CONFIG_SPL_BUILD)
bl coloured_LED_init
bl red_led_on
-
+#endif
/* call board_init_r(gd_t *id, ulong dest_addr) */
mov r0, r9 /* gd_t */
ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
@@ -134,7 +142,6 @@ clbss_l:cmp r0, r1 /* while not at
end of BSS */
ldr pc, =board_init_r /* this is auto-relocated! */
/* we should not return here. */
-
#endif
ENDPROC(_main)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index ded0f30..cd75bbc 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -281,3 +281,38 @@ void preloader_console_init(void)
spl_display_print();
#endif
}
+
+/**
+ * spl_relocate_stack_gd() - Relocate stack ready for board_init_r()
execution
+ *
+ * Sometimes board_init_f() runs with a stack in SRAM but we want to use
SDRAM
+ * for the main board_init_r() execution. This is typically because we need
+ * more stack space for things like the MMC sub-system.
+ *
+ * This function calculates the stack position, copies the global_data into
+ * place and returns the new stack position. The caller is responsible for
+ * setting up the sp register.
+ *
+ * @return new stack location, or 0 to use the same stack
+ */
+ulong spl_relocate_stack_gd(void)
+{
+#ifdef CONFIG_SPL_STACK_R
+ gd_t *new_gd;
+ ulong ptr;
+
+ /* Get stack position: use 8-byte alignment for ABI compliance */
+ ptr = CONFIG_SPL_STACK_R - sizeof(gd_t);
+ ptr = ~7;
+ new_gd = (gd_t *)ptr;
+ memcpy(new_gd, (void *)gd, sizeof(gd_t));
+ gd = new_gd;
+
+ /* Clear the BSS. */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ return ptr;
+#else
+ return 0;
+#endif
+}
All of this _does_ move gd into where CONFIG_SPL_STACK_R points. It
does _not_ move the stack itself into where CONFIG_SPL_STACK_R points so
the big use case (am335x_boneblack for example where
CONFIG_SPL_ENV_SUPPORT is set) doesn't work and blows up as we overflow
the area for stack.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 05/11] ARM: OMAP: Change set_pl310_ctrl_reg to be generic
On Tue, Mar 03, 2015 at 11:12:33AM -0600, Nishanth Menon wrote:
On 03/03/2015 11:08 AM, Tom Rini wrote:
On Wed, Feb 25, 2015 at 02:55:13PM -0600, Nishanth Menon wrote:
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The
only difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add
a data barrier which is necessary as per recommendation.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 13 -
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h|5 -
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e4217478..9b24369e4dc1 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -22,11 +22,14 @@ ENTRY(save_boot_params)
bx lr
ENDPROC(save_boot_params)
-ENTRY(set_pl310_ctrl_reg)
- PUSH{r4-r11, lr}@ save registers - ROM code may pollute
+ENTRY(omap_smc1)
+ PUSH{r4-r12, lr}@ save registers - ROM code may pollute
@ our registers
- LDR r12, =0x102 @ Set PL310 control register - value in R0
+ MOV r12, r0 @ Service
+ MOV r0, r1 @ Argument
+ DSB
+ DMB
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
Lets stop hand-crafting that call, we just call smc #0 elsewhere in the
code base these days.
And we dont care about: -march=armv5 any-longer?
No, that's not a use-case for these boards any longer, toolchains old
enough to not know -march=armv7t are going to have other problems.
--
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] mx6sabre_common.h: remove deprecated mmc open/close
On Tue, Mar 3, 2015 at 11:48 AM, Maxin B. John maxin.j...@enea.com wrote: Replace mmc open/close with mmc dev in mx6sabre_common.h as those commands were removed with this commit: 614b2bf1c9bf80dbad24f5e5ce1d115bf24a831d cmd_mmc.c: Drop open/close mmc sub-commands Signed-off-by: Maxin B. John maxin.j...@enea.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] usb: dwc3: Fixes and improvements for DWC3 driver
On Tuesday, March 03, 2015 at 05:32:02 PM, Lukasz Majewski wrote: This patch set should be applied on top of recent Kishon Vijay Abraham I work (v2) regarding providing dwc3 support to u-boot as well as clean up of the linux-compat header file. For the whole patch set please refer to -dfu u-boot repo, branch (devel/dwc3_gadget): http://git.denx.de/?p=u-boot/u-boot-dfu.git;a=shortlog;h=refs/heads/devel/d wc3_gadget This patch set fixes things, so all Samsung boards compile after applying DWC3 support. I picked this all into the topic/dwc3 branch and replaced the old patches. Please let me know if there's something broken. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 02/11] ARM: Introduce erratum workaround for 454179
454179: Stale prediction may inhibit target address misprediction on
next predicted taken branch
Impacts: Every Cortex-A8 processors with revision lower than r2p1
Work around: Set IBE and disable branch size mispredict to 1
Also provide a hook for SoC specific handling to take place if needed.
Based on ARM errata Document revision 20.0 (13 Nov 2010)
Signed-off-by: Nishanth Menon n...@ti.com
---
README |1 +
arch/arm/cpu/armv7/cp15.c|6 ++
arch/arm/cpu/armv7/start.S | 13 +
arch/arm/include/asm/armv7.h |2 ++
4 files changed, 22 insertions(+)
diff --git a/README b/README
index 11ec37ba4a00..e538cf061286 100644
--- a/README
+++ b/README
@@ -624,6 +624,7 @@ The following options need to be configured:
NOTE: The following can be machine specific errata. These
do have ability to provide rudimentary version and machine
specific checks, but expect no product checks.
+ CONFIG_ARM_ERRATA_454179
CONFIG_ARM_ERRATA_798870
- Driver Model
diff --git a/arch/arm/cpu/armv7/cp15.c b/arch/arm/cpu/armv7/cp15.c
index 8ac81c9ba147..b44c9f94a822 100644
--- a/arch/arm/cpu/armv7/cp15.c
+++ b/arch/arm/cpu/armv7/cp15.c
@@ -21,3 +21,9 @@ void __weak v7_arch_cp15_set_l2aux_ctrl(u32 l2actlr, u32
cpu_midr,
{
asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(l2actlr));
}
+
+void __weak v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+u32 cpu_variant, u32 cpu_rev)
+{
+ asm volatile (mcr p15, 0, %0, c1, c0, 1\n\t : : r(acr));
+}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 6fbc44e5bf74..1516ed675dac 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -185,6 +185,19 @@ ENTRY(cpu_init_cp15)
skip_errata_798870:
#endif
+#ifdef CONFIG_ARM_ERRATA_454179
+ cmp r2, #0x21 @ Only on r2p1
+ bge skip_errata_454179
+
+ mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+ orr r0, r0, #(0x3 6) @ Set DBSM(BIT7) and IBE(BIT6) bits
+ push{r1-r4} @ Save the cpu info registers
+ b v7_arch_cp15_set_acr
+ pop {r1-r4} @ Restore the cpu info - fall through
+
+skip_errata_454179:
+#endif
+
mov pc, lr @ back to my caller
ENDPROC(cpu_init_cp15)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 30e0cc3cf3d5..434b34de0ce9 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -96,6 +96,8 @@ extern char __secure_end[];
void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
u32 cpu_rev_comb, u32 cpu_variant,
u32 cpu_rev);
+void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+ u32 cpu_variant, u32 cpu_rev);
#endif /* ! __ASSEMBLY__ */
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 03/11] ARM: Introduce erratum workaround for 430973
430973: Stale prediction on replaced inter working branch causes
Cortex-A8 to execute in the wrong ARM/Thumb state
Impacts: Every Cortex-A8 processors with revision lower than r2p1
Work around: Set IBE to 1
Based on ARM errata Document revision 20.0 (13 Nov 2010)
Signed-off-by: Nishanth Menon n...@ti.com
---
README |1 +
arch/arm/cpu/armv7/start.S | 13 +
2 files changed, 14 insertions(+)
diff --git a/README b/README
index e538cf061286..484ae9ee39a8 100644
--- a/README
+++ b/README
@@ -624,6 +624,7 @@ The following options need to be configured:
NOTE: The following can be machine specific errata. These
do have ability to provide rudimentary version and machine
specific checks, but expect no product checks.
+ CONFIG_ARM_ERRATA_430973
CONFIG_ARM_ERRATA_454179
CONFIG_ARM_ERRATA_798870
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 1516ed675dac..99220ce76a25 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -198,6 +198,19 @@ skip_errata_798870:
skip_errata_454179:
#endif
+#ifdef CONFIG_ARM_ERRATA_430973
+ cmp r2, #0x21 @ Only on r2p1
+ bge skip_errata_430973
+
+ mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+ orr r0, r0, #(0x1 6) @ Set IBE bit
+ push{r1-r4} @ Save the cpu info registers
+ b v7_arch_cp15_set_acr
+ pop {r1-r4} @ Restore the cpu info - fall through
+
+skip_errata_430973:
+#endif
+
mov pc, lr @ back to my caller
ENDPROC(cpu_init_cp15)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 08/11] ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870
From: Praveen Rao p...@ti.com
This patch enables the workaround for ARM errata 798870 for OMAP5 /
DRA7 which says If back-to-back speculative cache line fills (fill
A and fill B) are issued from the L1 data cache of a CPU to the
L2 cache, the second request (fill B) is then cancelled, and the
second request would have detected a hazard against a recent write or
eviction (write B) to the same cache line as fill B then the L2 logic
might deadlock.
An l2auxctlr accessor implementation for OMAP5 and DRA7 is introduced
here as well.
Signed-off-by: Praveen Rao p...@ti.com
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c |7 +++
arch/arm/include/asm/arch-omap5/sys_proto.h |4
include/configs/ti_omap5_common.h |3 +++
3 files changed, 14 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index a8a474a88be9..f8060555b680 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -381,3 +381,10 @@ void setup_warmreset_time(void)
rst_val |= rst_time;
writel(rst_val, (*prcm)-prm_rsttime);
}
+
+void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
+u32 cpu_rev_comb, u32 cpu_variant,
+u32 cpu_rev)
+{
+ omap_smc1(OMAP5_SERVICE_L2ACTLR_SET, l2auxctrl);
+}
diff --git a/arch/arm/include/asm/arch-omap5/sys_proto.h
b/arch/arm/include/asm/arch-omap5/sys_proto.h
index 103830319a41..37dc9925eae2 100644
--- a/arch/arm/include/asm/arch-omap5/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap5/sys_proto.h
@@ -66,4 +66,8 @@ static inline u32 usec_to_32k(u32 usec)
{
return div_round_up(32768 * usec, 100);
}
+
+void omap_smc1(u32 service, u32 val);
+#define OMAP5_SERVICE_L2ACTLR_SET0x104
+
#endif
diff --git a/include/configs/ti_omap5_common.h
b/include/configs/ti_omap5_common.h
index 925cb42dd38d..09f05f18a75d 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -21,6 +21,9 @@
#define CONFIG_DISPLAY_BOARDINFO
#define CONFIG_ARCH_CPU_INIT
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_798870
+
#define CONFIG_SYS_CACHELINE_SIZE 64
/* Use General purpose timer 1 */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 01/11] ARM: Introduce erratum workaround for 798870
Add workaround for Cortex-A15 ARM erratum 798870 which says
If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock.
Implementations for SoC families such as Exynos, OMAP5/DRA7 etc
will be widely different.
Every SoC has slightly different manner of setting up access to L2ACLR
and similar registers since the Secure Monitor handling of Secure
Monitor Call(smc) is diverse. Hence an weak function is introduced
which may be overriden to implement SoC specific accessor implementation.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Signed-off-by: Nishanth Menon n...@ti.com
---
README |5 +
arch/arm/cpu/armv7/Makefile |2 +-
arch/arm/cpu/armv7/cp15.c| 23 +++
arch/arm/cpu/armv7/start.S | 22 ++
arch/arm/include/asm/armv7.h |3 +++
5 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/cp15.c
diff --git a/README b/README
index a28ff133ee05..11ec37ba4a00 100644
--- a/README
+++ b/README
@@ -621,6 +621,11 @@ The following options need to be configured:
exists, unlike the similar options in the Linux kernel. Do not
set these options unless they apply!
+ NOTE: The following can be machine specific errata. These
+ do have ability to provide rudimentary version and machine
+ specific checks, but expect no product checks.
+ CONFIG_ARM_ERRATA_798870
+
- Driver Model
Driver model is a new framework for devices in U-Boot
introduced in early 2014. U-Boot is being progressively
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 409e6f5651b6..43da3e586f71 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -9,7 +9,7 @@ extra-y := start.o
obj-y += cache_v7.o
-obj-y += cpu.o
+obj-y += cpu.o cp15.o
obj-y += syslib.o
ifneq
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_SUNXI),)
diff --git a/arch/arm/cpu/armv7/cp15.c b/arch/arm/cpu/armv7/cp15.c
new file mode 100644
index ..8ac81c9ba147
--- /dev/null
+++ b/arch/arm/cpu/armv7/cp15.c
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2015 Texas Insturments
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * CP15 specific code
+ */
+
+#include common.h
+#include command.h
+#include asm/system.h
+#include asm/cache.h
+#include asm/armv7.h
+#include linux/compiler.h
+
+void __weak v7_arch_cp15_set_l2aux_ctrl(u32 l2actlr, u32 cpu_midr,
+u32 cpu_rev_comb, u32 cpu_variant,
+u32 cpu_rev)
+{
+ asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(l2actlr));
+}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 70048c10aee6..6fbc44e5bf74 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -163,6 +163,28 @@ ENTRY(cpu_init_cp15)
mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register
#endif
+ mrc p15, 0, r1, c0, c0, 0 @ r1 has Read Main ID Register (MIDR)
+ mov r3, r1, lsr #20 @ get variant field
+ and r3, r3, #0xf@ r3 has CPU variant
+ and r4, r1, #0xf@ r4 has CPU revision
+ mov r2, r3, lsl #4 @ shift variant field for combined value
+ orr r2, r4, r2 @ r2 has combined CPU variant + revision
+
+#ifdef CONFIG_ARM_ERRATA_798870
+ cmp r2, #0x30 @ Applies to lower than R3p0
+ bge skip_errata_798870 @ skip if not affected rev
+ cmp r2, #0x20 @ Applies to including and above R2p0
+ blt skip_errata_798870 @ skip if not affected rev
+
+ mrc p15, 1, r0, c15, c0, 0 @ read l2 aux ctrl reg
+ orr r0, r0, #1 7 @ Enable hazard-detect timeout
+ push{r1-r4} @ Save the cpu info registers
+ b v7_arch_cp15_set_l2aux_ctrl
+ isb @ Recommended ISB after l2actlr update
+ pop {r1-r4} @ Restore the cpu info - fall through
+skip_errata_798870:
+#endif
+
mov pc, lr @ back to my caller
ENDPROC(cpu_init_cp15)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a13da23cf172..30e0cc3cf3d5 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -93,6 +93,9 @@ extern char __secure_end[];
#endif /* CONFIG_ARMV7_NONSEC || CONFIG_ARMV7_VIRT */
+void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32
[U-Boot] [PATCH V4 07/11] ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with omap_smc1
omap_smc1 is now generic enough to remove duplicate
omap3_gp_romcode_call logic that omap3 introduced.
As part of this change, move to using the generic lowlevel_init.S for
omap3 as well.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile|2 +-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S |2 ++
arch/arm/cpu/armv7/omap3/board.c |6 ++
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 11 ---
arch/arm/include/asm/arch-omap3/sys_proto.h|2 +-
5 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index b36e85d25f3f..1d5970f340d0 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -31,7 +31,7 @@ AFLAGS_lowlevel_init.o:=-Wa,-march=armv7-a$(plus_sec)
ifeq ($(CONFIG_OMAP34XX),)
obj-y += boot-common.o
-obj-y += lowlevel_init.o
endif
+obj-y += lowlevel_init.o
obj-y += mem-common.o
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 83426291b22d..23c9e197f0e8 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -16,11 +16,13 @@
#include asm/arch/spl.h
#include linux/linkage.h
+#ifndef CONFIG_OMAP34XX
ENTRY(save_boot_params)
ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
str r0, [r1]
bx lr
ENDPROC(save_boot_params)
+#endif
ENTRY(omap_smc1)
PUSH{r4-r12, lr}@ save registers - ROM code may pollute
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 90d6ae7bb5f5..51abc4b09e36 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -418,8 +418,7 @@ static void omap3_update_aux_cr_secure(u32 set_bits, u32
clear_bits)
acr |= set_bits;
if (get_device_type() == GP_DEVICE) {
- omap3_gp_romcode_call(OMAP3_GP_ROMCODE_API_WRITE_ACR,
- acr);
+ omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
} else {
struct emu_hal_params emu_romcode_params;
emu_romcode_params.num_params = 1;
@@ -459,8 +458,7 @@ static void omap3_update_aux_cr(u32 set_bits, u32
clear_bits)
static void omap3_invalidate_l2_cache_secure(void)
{
if (get_device_type() == GP_DEVICE) {
- omap3_gp_romcode_call(OMAP3_GP_ROMCODE_API_L2_INVAL,
- 0);
+ omap_smc1(OMAP3_GP_ROMCODE_API_L2_INVAL, 0);
} else {
struct emu_hal_params emu_romcode_params;
emu_romcode_params.num_params = 1;
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 78577b1d1c75..84591b8b5bab 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -27,17 +27,6 @@ ENTRY(save_boot_params)
ENDPROC(save_boot_params)
#endif
-ENTRY(omap3_gp_romcode_call)
- PUSH {r4-r12, lr} @ Save all registers from ROM code!
- MOV r12, r0 @ Copy the Service ID in R12
- MOV r0, r1 @ Copy parameter to R0
- mcr p15, 0, r0, c7, c10, 4 @ DSB
- mcr p15, 0, r0, c7, c10, 5 @ DMB
- .word 0xe1600070 @ SMC #0 to enter monitor - hand assembled
- @ because we use -march=armv5
- POP {r4-r12, pc}
-ENDPROC(omap3_gp_romcode_call)
-
/*
* Funtion for making PPA HAL API calls in secure devices
* Input:
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index bcf92fbe658b..c06605d533d3 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -73,6 +73,6 @@ void power_init_r(void);
void dieid_num_r(void);
void get_dieid(u32 *id);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
-void omap3_gp_romcode_call(u32 service_id, u32 parameter);
+void omap_smc1(u32 service, u32 val);
u32 warm_reset(void);
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 05/11] ARM: OMAP: Change set_pl310_ctrl_reg to be generic
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The only
difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add a
data barrier which is necessary as per recommendation.
While at this, switch over to smc #0 instead of handcoded assembly.
To ensure gcc compatibility, steal the strategy used by Linux kernel
for sec extension builds (NOTE: we no longer use '-march=armv5' as the
legacy comment claims).
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile|3 +++
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 17 ++---
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h|5 -
4 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 7695e16d36f5..b36e85d25f3f 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -26,6 +26,9 @@ ifeq ($(CONFIG_SYS_DCACHE_OFF),)
obj-y += omap-cache.o
endif
+plus_sec := $(call as-instr,.arch_extension sec,+sec)
+AFLAGS_lowlevel_init.o :=-Wa,-march=armv7-a$(plus_sec)
+
ifeq ($(CONFIG_OMAP34XX),)
obj-y += boot-common.o
obj-y += lowlevel_init.o
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e4217478..83426291b22d 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -22,11 +22,14 @@ ENTRY(save_boot_params)
bx lr
ENDPROC(save_boot_params)
-ENTRY(set_pl310_ctrl_reg)
- PUSH{r4-r11, lr}@ save registers - ROM code may pollute
+ENTRY(omap_smc1)
+ PUSH{r4-r12, lr}@ save registers - ROM code may pollute
@ our registers
- LDR r12, =0x102 @ Set PL310 control register - value in R0
- .word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
- @ call ROM Code API to set control register
- POP {r4-r11, pc}
-ENDPROC(set_pl310_ctrl_reg)
+ MOV r12, r0 @ Service
+ MOV r0, r1 @ Argument
+ DSB
+ DMB
+ SMC #0 @ Call the secure monitor for the service
+
+ POP {r4-r12, pc}
+ENDPROC(omap_smc1)
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c
b/arch/arm/cpu/armv7/omap4/hwinit.c
index db16548fac49..9792761d40a0 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -159,11 +159,11 @@ void init_omap_revision(void)
#ifndef CONFIG_SYS_L2CACHE_OFF
void v7_outer_cache_enable(void)
{
- set_pl310_ctrl_reg(1);
+ omap_smc1(OMAP4_SERVICE_PL310_CONTROL_REG_SET, 1);
}
void v7_outer_cache_disable(void)
{
- set_pl310_ctrl_reg(0);
+ omap_smc1(OMAP4_SERVICE_PL310_CONTROL_REG_SET, 0);
}
#endif /* !CONFIG_SYS_L2CACHE_OFF */
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index e19975efaf50..f425e3af54f5 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -37,7 +37,7 @@ void do_set_mux(u32 base, struct pad_conf_entry const *array,
int size);
void set_muxconf_regs_essential(void);
u32 wait_on_value(u32, u32, void *, u32);
void sdelay(unsigned long);
-void set_pl310_ctrl_reg(u32 val);
+void omap_smc1(u32 service, u32 val);
void setup_clocks_for_console(void);
void prcm_init(void);
void bypass_dpll(u32 const base);
@@ -57,4 +57,7 @@ int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8
reg_data);
u32 warm_reset(void);
void force_emif_self_refresh(void);
void setup_warmreset_time(void);
+
+#define OMAP4_SERVICE_PL310_CONTROL_REG_SET0x102
+
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question about board-specific Makefile actions
I have a custom board in a git workspace for U-Boot 2014.07. I've copied most of this from the .../board/ti/beagle. My board directory Makefile looks like 8--- obj-y := board.o 8--- I'd like to add a few files to this directory that are processed during make all and have any newly derived files deleted during make clean. I've experimented with various Makefile contents but I can't get the new files processed or any newly derived files deleted. U-Boot's makefile system is quite large for my experience level and it seems I don't have enough understanding. A new file might contain some hush commands that are to be executed from the U-Boot command line. I'd like to use source to process these commands. The source command requires that its argument be an image (I get this into memory via TFTP), so I'd like make all to transform the text file containing the hush commands into the image file. I'd also like make clean to delete the derived image file. So, if my hush commands are in a text file called test.txt, I'd like make all to apply mkimage so that a test.img is generated. I'd also like make clean to delete test.img. I tried various changes to my Makefile, but the most likely seeming changes are 8--- IMG = test.img obj-y := board.o board.o : $(IMG) %.img : %.txt $(srctree)/tools/mkimage -T script -n $* -C none -d $ $@ CLEAN_FILES += $(IMG) CLEAN_DIRS += . 8--- This doesn't work, nor has any other approach I've taken. mkimage is never run for make all and test.img doesn't get deleted if I create a fake one and run make clean Could someone offer a solution, either directly, or by pointing at an existing board that does something similar? Thanks Jim -- Jim Chargin AJA Video Systems j...@aja.com (530) 271-3334 http://www.aja.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARM: tegra: pinmux: Tegra210 support
I'm using this locally, so I'll apply it and push a new u-boot-tegra/next. -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, March 03, 2015 1:20 PM To: Tom Warren Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren Subject: Re: [U-Boot] [PATCH 0/9] ARM: tegra: pinmux: Tegra210 support On 02/24/2015 02:08 PM, Stephen Warren wrote: This series performs a few small cleanups to or parameterizations of the existing Tegra pinmux driver, and adds Tegra210 support. The Tegra210 code isn't actually used yet, since the balance of the Tegra210 support is not yet present. However, it should start appearing soon. I've at least compile-tested this by over-writing the Tegra124 pinmux driver and Jetson TK1 board pinmux data tables with the Tegra210 versions. TomW, note I made a couple minor tweaks since the latest version I sent internally; let's apply this version upstream. Tom, Are you waiting for anything before applying this series? --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/6] arm: spl: Allow board_init_r() to run with a larger stack
On Tue, Mar 03, 2015 at 12:04:16PM -0700, Simon Glass wrote:
Hi Tom,
On 3 March 2015 at 10:49, Tom Rini tr...@konsulko.com wrote:
On Tue, Mar 03, 2015 at 08:03:00AM -0700, Simon Glass wrote:
At present SPL uses a single stack, either CONFIG_SPL_STACK or
CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
point into SDRAM. They then set up SDRAM very early, before board_init_f(),
so that the larger stack can be used.
This is an abuse of lowlevel_init(). That function should only be used for
essential start-up code which cannot be delayed. An example of a valid use
is
when only part of the SPL code is visible/executable, and the SoC must be
set
up so that board_init_f() can be reached. It should not be used for SDRAM
init, console init, etc.
Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a
new
address before board_init_r() is called in SPL.
The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the
README.
Signed-off-by: Simon Glass s...@chromium.org
For version 1:
Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net
Reviewed-by: Stefan Roese s...@denx.de
Tested-by: Bo Shen voice.s...@atmel.com
Acked-by: Bo Shen voice.s...@atmel.com
Acked-by: Heiko Schocher h...@denx.de
Tested-by: Heiko Schocher h...@denx.de
---
Changes in v6: None
Changes in v5:
- Rebase to master
Changes in v4:
- Adjust README to mention that lowlevel_init() should have no stack
Changes in v3: None
Changes in v2:
- Move docs to top-level README file and expand them to cover U-Boot proper
- Add Kconfig settings
Kconfig | 18 ++
README | 69
+
arch/arm/lib/crt0.S | 13 +++---
common/spl/spl.c| 35 +++
4 files changed, 132 insertions(+), 3 deletions(-)
[snip]
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 22df3e5..7939ced 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -113,7 +113,14 @@ here:
/* Set up final (full) environment */
bl c_runtime_cpu_setup /* we still call old routine here */
-
+#endif
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK)
+# ifdef CONFIG_SPL_BUILD
+ /* Use a DRAM stack for the rest of SPL, if requested */
+ bl spl_relocate_stack_gd
+ cmp r0, #0
+ movne sp, r0
+# endif
ldr r0, =__bss_start/* this is auto-relocated! */
ldr r1, =__bss_end /* this is auto-relocated! */
@@ -124,9 +131,10 @@ clbss_l:cmp r0, r1 /* while not
at end of BSS */
addlo r0, r0, #4 /* move to next */
blo clbss_l
+#if ! defined(CONFIG_SPL_BUILD)
bl coloured_LED_init
bl red_led_on
-
+#endif
/* call board_init_r(gd_t *id, ulong dest_addr) */
mov r0, r9 /* gd_t */
ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
@@ -134,7 +142,6 @@ clbss_l:cmp r0, r1 /* while not
at end of BSS */
ldr pc, =board_init_r /* this is auto-relocated! */
/* we should not return here. */
-
#endif
ENDPROC(_main)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index ded0f30..cd75bbc 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -281,3 +281,38 @@ void preloader_console_init(void)
spl_display_print();
#endif
}
+
+/**
+ * spl_relocate_stack_gd() - Relocate stack ready for board_init_r()
execution
+ *
+ * Sometimes board_init_f() runs with a stack in SRAM but we want to use
SDRAM
+ * for the main board_init_r() execution. This is typically because we
need
+ * more stack space for things like the MMC sub-system.
+ *
+ * This function calculates the stack position, copies the global_data
into
+ * place and returns the new stack position. The caller is responsible for
+ * setting up the sp register.
+ *
+ * @return new stack location, or 0 to use the same stack
+ */
+ulong spl_relocate_stack_gd(void)
+{
+#ifdef CONFIG_SPL_STACK_R
+ gd_t *new_gd;
+ ulong ptr;
+
+ /* Get stack position: use 8-byte alignment for ABI compliance */
+ ptr = CONFIG_SPL_STACK_R - sizeof(gd_t);
+ ptr = ~7;
+ new_gd = (gd_t *)ptr;
+ memcpy(new_gd, (void *)gd, sizeof(gd_t));
+ gd = new_gd;
+
+ /* Clear the BSS. */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ return ptr;
+#else
+ return 0;
+#endif
+}
All of this _does_ move gd into where CONFIG_SPL_STACK_R points. It
does _not_ move the stack itself into where CONFIG_SPL_STACK_R points so
the big use case (am335x_boneblack for example where
CONFIG_SPL_ENV_SUPPORT is set) doesn't
Re: [U-Boot] [PATCH V2 2/2] ARM: tegra: import latest Jetson TK1 pinmux
I've been side-tracked with other work. Let me take another look, if it's all gravy I'll apply them to u-boot-tegra/next. -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, March 03, 2015 1:19 PM To: Tom Warren Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren Subject: Re: [U-Boot] [PATCH V2 2/2] ARM: tegra: import latest Jetson TK1 pinmux On 02/18/2015 01:27 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Syseng has revamped the Jetson TK1 pinmux spreadsheet, basing the content completely on correct configuration for the board/schematic, rather than the previous version which was based on the bare minimum changes relative to another reference board. The new spreadsheet sets TRISTATE for any input-only pins. This only works correctly if the global CLAMP bit is not set, so the Jetson TK1 board code has been adjusted accordingly. Apparently syseng have changed their mind since the previous advice that this needed to be set:-/ This content comes from Jetson_TK1_customer_pinmux.xlsm (v09) downloaded from https://developer.nvidia.com/hardware-design-and- development. Tom, do these two patches look OK? --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] ARM: tegra: import latest Jetson TK1 pinmux
On 02/18/2015 01:27 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Syseng has revamped the Jetson TK1 pinmux spreadsheet, basing the content completely on correct configuration for the board/schematic, rather than the previous version which was based on the bare minimum changes relative to another reference board. The new spreadsheet sets TRISTATE for any input-only pins. This only works correctly if the global CLAMP bit is not set, so the Jetson TK1 board code has been adjusted accordingly. Apparently syseng have changed their mind since the previous advice that this needed to be set:-/ This content comes from Jetson_TK1_customer_pinmux.xlsm (v09) downloaded from https://developer.nvidia.com/hardware-design-and-development. Tom, do these two patches look OK? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Add support for the Forfun Q88DB tablet
The Forfun Q88DB is an A13 tablet in the common Q8 format. Features are 512MB RAM, 4GB NAND, 7 Display, RTL8188 Wifi, 2 cameras. For more details see: http://linux-sunxi.org/Forfun_Q88DB Signed-off-by: Jens Lucius i...@jenslucius.com --- :100644 100644 9a287d3... cfc2764... M board/sunxi/MAINTAINERS :00 100644 000... e1b11a2... A configs/forfun_q88db_defconfig board/sunxi/MAINTAINERS| 5 + configs/forfun_q88db_defconfig | 17 + 2 files changed, 22 insertions(+) diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 9a287d3..cfc2764 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -64,6 +64,11 @@ F: include/configs/sun7i.h F: configs/Cubieboard2_defconfig F: configs/Cubietruck_defconfig +FORFUN-Q88DB TABLET +M: Jens Lucius i...@jenslucius.com +S: Maintained +F: configs/forfun_q88db_defconfig + GEMEI-G9 TABLET M: Priit Laes pl...@plaes.org S: Maintained diff --git a/configs/forfun_q88db_defconfig b/configs/forfun_q88db_defconfig new file mode 100644 index 000..e1b11a2 --- /dev/null +++ b/configs/forfun_q88db_defconfig @@ -0,0 +1,17 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER +CONFIG_FDTFILE=sun5i-a13-forfun-q88db.dtb +CONFIG_USB_MUSB_SUNXI=y +CONFIG_USB0_VBUS_PIN=PG12 +CONFIG_USB0_VBUS_DET=PG1 +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:33000,le:87,ri:40,up:31,lo:13,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=AXP0-0 +CONFIG_VIDEO_LCD_BL_EN=AXP0-1 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN5I=y ++S:CONFIG_DRAM_CLK=384 ++S:CONFIG_DRAM_ZQ=123 ++S:CONFIG_DRAM_EMR1=4 + -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARM: tegra: pinmux: Tegra210 support
On 02/24/2015 02:08 PM, Stephen Warren wrote: This series performs a few small cleanups to or parameterizations of the existing Tegra pinmux driver, and adds Tegra210 support. The Tegra210 code isn't actually used yet, since the balance of the Tegra210 support is not yet present. However, it should start appearing soon. I've at least compile-tested this by over-writing the Tegra124 pinmux driver and Jetson TK1 board pinmux data tables with the Tegra210 versions. TomW, note I made a couple minor tweaks since the latest version I sent internally; let's apply this version upstream. Tom, Are you waiting for anything before applying this series? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 06/11] ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs
This is in preperation of using generic cross OMAP code.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../arm/include/asm/arch-omap3/{omap3.h = omap.h} |0
include/configs/am3517_crane.h |2 +-
include/configs/am3517_evm.h |2 +-
include/configs/cm_t35.h |2 +-
include/configs/cm_t3517.h |2 +-
include/configs/dig297.h |2 +-
include/configs/mcx.h |2 +-
include/configs/nokia_rx51.h |2 +-
include/configs/omap3_evm.h|2 +-
include/configs/omap3_evm_quick_mmc.h |2 +-
include/configs/omap3_evm_quick_nand.h |2 +-
include/configs/omap3_logic.h |2 +-
include/configs/omap3_mvblx.h |2 +-
include/configs/omap3_pandora.h|2 +-
include/configs/omap3_sdp3430.h|2 +-
include/configs/omap3_zoom1.h |2 +-
include/configs/tam3517-common.h |2 +-
include/configs/tao3530.h |2 +-
include/configs/ti_omap3_common.h |2 +-
include/configs/tricorder.h|2 +-
20 files changed, 19 insertions(+), 19 deletions(-)
rename arch/arm/include/asm/arch-omap3/{omap3.h = omap.h} (100%)
diff --git a/arch/arm/include/asm/arch-omap3/omap3.h
b/arch/arm/include/asm/arch-omap3/omap.h
similarity index 100%
rename from arch/arm/include/asm/arch-omap3/omap3.h
rename to arch/arm/include/asm/arch-omap3/omap.h
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index 09ee10c0590b..a4128773ddb2 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -23,7 +23,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 190ef0e71bfb..94398c625eb0 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -23,7 +23,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 9767512a5cf0..56a5506f5c78 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -30,7 +30,7 @@
#define CONFIG_SDRC/* The chip has SDRC controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/cm_t3517.h b/include/configs/cm_t3517.h
index 918032bd753a..ee1b7a0cb5a7 100644
--- a/include/configs/cm_t3517.h
+++ b/include/configs/cm_t3517.h
@@ -30,7 +30,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index c8739ed29490..8791199fc61d 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -36,7 +36,7 @@
#define CONFIG_SDRC/* The chip has SDRC controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/mcx.h b/include/configs/mcx.h
index 26eb2203540f..2cf66c40d6fe 100644
--- a/include/configs/mcx.h
+++ b/include/configs/mcx.h
@@ -26,7 +26,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
#define CONFIG_OF_LIBFDT
#define CONFIG_FIT
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 46fc91e5e197..442e16ae686b 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -42,7 +42,7 @@
#define CONFIG_SDRC/* The chip has SDRC controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
#include asm/arch/mem.h
#include linux/stringify.h
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 8bdc08f5864c..4e587e10ffd3 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -18,7 +18,7 @@
#define __OMAP3EVM_CONFIG_H
#include asm/arch/cpu.h
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
[U-Boot] [PATCH V4 10/11] ARM: OMAP3: Enable workaround for ARM errata 454179, 430973, 621766
Enable the OMAP3 specific errata code for 454179, 430973, 621766
and while at it, remove legacy non-revision checked errata logic.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap3/board.c | 31 ++-
include/configs/am3517_crane.h |4
include/configs/am3517_evm.h |4
include/configs/cm_t35.h |4
include/configs/cm_t3517.h |4
include/configs/dig297.h |4
include/configs/mcx.h |4
include/configs/omap3_evm_common.h |4
include/configs/omap3_logic.h |4
include/configs/omap3_mvblx.h |4
include/configs/omap3_pandora.h|4
include/configs/omap3_sdp3430.h|4
include/configs/tam3517-common.h |4
include/configs/tao3530.h |4
include/configs/ti_omap3_common.h |5 +
include/configs/tricorder.h|4
16 files changed, 71 insertions(+), 21 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 51abc4b09e36..5587a10cdafd 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -35,7 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
/* Declarations */
extern omap3_sysinfo sysinfo;
-static void omap3_setup_aux_cr(void);
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_invalidate_l2_cache_secure(void);
#endif
@@ -246,9 +245,6 @@ void s_init(void)
try_unlock_memory();
- /* Errata workarounds */
- omap3_setup_aux_cr();
-
#ifndef CONFIG_SYS_L2CACHE_OFF
/* Invalidate L2-cache from secure mode */
omap3_invalidate_l2_cache_secure();
@@ -408,15 +404,9 @@ static void omap3_emu_romcode_call(u32 service_id, u32
*parameters)
do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
}
-static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
+void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+ u32 cpu_variant, u32 cpu_rev)
{
- u32 acr;
-
- /* Read ACR */
- asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
- acr = ~clear_bits;
- acr |= set_bits;
-
if (get_device_type() == GP_DEVICE) {
omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
} else {
@@ -428,16 +418,15 @@ static void omap3_update_aux_cr_secure(u32 set_bits, u32
clear_bits)
}
}
-static void omap3_setup_aux_cr(void)
+static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
{
- /* Workaround for Cortex-A8 errata: #454179 #430973
-* Set IBE bit
-* Set Disable Branch Size Mispredicts bit
-* Workaround for erratum #621766
-* Enable L1NEON bit
-* ACR |= (IBE | DBSM | L1NEON) = ACR |= 0xE0
-*/
- omap3_update_aux_cr_secure(0xE0, 0);
+ u32 acr;
+
+ /* Read ACR */
+ asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
+ acr = ~clear_bits;
+ acr |= set_bits;
+ v7_arch_cp15_set_acr(acr, 0, 0, 0, 0);
}
#ifndef CONFIG_SYS_L2CACHE_OFF
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index a4128773ddb2..39e121d9bc99 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -19,6 +19,10 @@
#define CONFIG_OMAP1 /* in a TI OMAP core */
#define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */
#define CONFIG_OMAP_COMMON
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_454179
+#define CONFIG_ARM_ERRATA_430973
+#define CONFIG_ARM_ERRATA_621766
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 94398c625eb0..930d7af31f18 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -19,6 +19,10 @@
#define CONFIG_OMAP1 /* in a TI OMAP core */
#define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */
#define CONFIG_OMAP_COMMON
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_454179
+#define CONFIG_ARM_ERRATA_430973
+#define CONFIG_ARM_ERRATA_621766
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 56a5506f5c78..451cb5e2fb4f 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -26,6 +26,10 @@
#define CONFIG_CM_T3X /* working with CM-T35 and CM-T3730 */
#define CONFIG_OMAP_COMMON
#define CONFIG_SYS_GENERIC_BOARD
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_454179
+#define CONFIG_ARM_ERRATA_430973
+#define CONFIG_ARM_ERRATA_621766
#define CONFIG_SDRC/* The chip has SDRC controller */
diff --git a/include/configs/cm_t3517.h b/include/configs/cm_t3517.h
index ee1b7a0cb5a7..8c6313832250 100644
--- a/include/configs/cm_t3517.h
+++ b/include/configs/cm_t3517.h
@@ -17,6 +17,10 @@
#define
[U-Boot] [PATCH] arm: rmobile: alt: Add ethernet function B support
From: Mitsuhiro Kimura mitsuhiro.kimura...@renesas.com Ethernet function of Alt board can select normal and B by DIP switch on board. But user need to set not only DIP switch but also pin function. This adds pin function of Ethernet function B. This can select from Kconfig. Signed-off-by: Mitsuhiro Kimura mitsuhiro.kimura...@renesas.com Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com --- board/renesas/alt/Kconfig | 9 + board/renesas/alt/alt.c | 17 - 2 files changed, 25 insertions(+), 1 deletion(-) diff --git a/board/renesas/alt/Kconfig b/board/renesas/alt/Kconfig index 957962d..39d53c1 100644 --- a/board/renesas/alt/Kconfig +++ b/board/renesas/alt/Kconfig @@ -9,4 +9,13 @@ config SYS_VENDOR config SYS_CONFIG_NAME default alt +config R8A7794_ETHERNET_B + bool Use ethernet B function + depends on TARGET_ALT + default n + help + ALT board can use default ethernet and etnernet B function. + This config set pin function of ethenet B. You also needt to change + DIP switch of board in order to use this function. + endif diff --git a/board/renesas/alt/alt.c b/board/renesas/alt/alt.c index f0010db..3501a17 100644 --- a/board/renesas/alt/alt.c +++ b/board/renesas/alt/alt.c @@ -1,7 +1,7 @@ /* * board/renesas/alt/alt.c * - * Copyright (C) 2014 Renesas Electronics Corporation + * Copyright (C) 2014, 2015 Renesas Electronics Corporation * * SPDX-License-Identifier: GPL-2.0 */ @@ -94,6 +94,20 @@ int board_init(void) r8a7794_pinmux_init(); /* Ether Enable */ +#if defined(CONFIG_R8A7794_ETHERNET_B) + gpio_request(GPIO_FN_ETH_CRS_DV_B, NULL); + gpio_request(GPIO_FN_ETH_RX_ER_B, NULL); + gpio_request(GPIO_FN_ETH_RXD0_B, NULL); + gpio_request(GPIO_FN_ETH_RXD1_B, NULL); + gpio_request(GPIO_FN_ETH_LINK_B, NULL); + gpio_request(GPIO_FN_ETH_REFCLK_B, NULL); + gpio_request(GPIO_FN_ETH_MDIO_B, NULL); + gpio_request(GPIO_FN_ETH_TXD1_B, NULL); + gpio_request(GPIO_FN_ETH_TX_EN_B, NULL); + gpio_request(GPIO_FN_ETH_MAGIC_B, NULL); + gpio_request(GPIO_FN_ETH_TXD0_B, NULL); + gpio_request(GPIO_FN_ETH_MDC_B, NULL); +#else gpio_request(GPIO_FN_ETH_CRS_DV, NULL); gpio_request(GPIO_FN_ETH_RX_ER, NULL); gpio_request(GPIO_FN_ETH_RXD0, NULL); @@ -106,6 +120,7 @@ int board_init(void) gpio_request(GPIO_FN_ETH_MAGIC, NULL); gpio_request(GPIO_FN_ETH_TXD0, NULL); gpio_request(GPIO_FN_ETH_MDC, NULL); +#endif gpio_request(GPIO_FN_IRQ8, NULL); /* PHY reset */ -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx, spl, siemens: enable debug uart output again
Hello Tom, Am 02.03.2015 14:59, schrieb Tom Rini: On Mon, Mar 02, 2015 at 07:56:41AM +0100, Heiko Schocher wrote: Hello Simon, Am 24.02.2015 14:31, schrieb Simon Glass: Hi Heiko, On 23 February 2015 at 23:18, Heiko Schocher h...@denx.de wrote: a6b541b090: TI ARMv7: Don't use GD before crt0.S has set it moves the init of the debug uart at the very end of SPL code. Enable it for the siemens board earlier, as they print ddr settings ... all debug output before board_init_r() is here currently useless. Maybe we must rework this globally? Assuming we are talking about U-Boot proper, the DDR init should happen in board_init_f(), specifically dram_init(). so I think this code should be updated. If it is SPL, then DDR init should happen in SPL's board_init_f(). It is in SPL... sdram_init() is called from: ./arch/arm/cpu/armv7/am33xx/board.c from s_init() ... I sent a series a few weeks ago (available at u-boot-dm branch spl-working) related to this topic: http://patchwork.ozlabs.org/patch/438581/ Ah ... Hmm... so ./arch/arm/cpu/armv7/am33xx/board.c needs a rework, right? Is a simple rename s_init() - board_init_f() correct? Right so, no, we can't just rename s_init to board_init_f. This is what I was talking about in the thread about the function Hans wants to add to enable some bits in CP15 on sunxi, iirc. In short, armv7 has a different set of abstraction hooks than the previous ARM cores (armv8 followed what we have for v7) and I'm not convinced in the end that it really won us anything. See http://lists.denx.de/pipermail/u-boot/2015-January/202350.html For today you need to rework the Siemens code to print out the DDR values (when desired) in spl_board_init() as we do not, or will not shortly, have gd prior to board_init_f running. Hmm... first I thought, ok, no problem, move the output from the RAM parameters to spl_board_init() ... but thats only the half of the story ... They read the RAM parameters from an i2c eeprom, and if there are errors, they print this errors ... currently this does not work, and thats I think the more important case ... and I could not move this error printfs to somewhere, because if RAM is not working ... there is no later ... So I have to enable the console early ... maybe I missed something, but this worked fine in the past (and I think we should not break this, as this is an essential feature). If I look into arch/arm/cpu/armv7/am33xx/board.c s_init() there gets the console also in the case: #if defined(CONFIG_NOR_BOOT) || defined(CONFIG_QSPI_BOOT) very early enabled ... is this buggy? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 04/11] ARM: Introduce erratum workaround for 621766
621766: Under a specific set of conditions, executing a sequence of
NEON or vfp load instructions can cause processor deadlock
Impacts: Every Cortex-A8 processors with revision lower than r2p1
Work around: Set L1NEON to 1
Based on ARM errata Document revision 20.0 (13 Nov 2010)
Signed-off-by: Nishanth Menon n...@ti.com
---
README |1 +
arch/arm/cpu/armv7/start.S | 13 +
2 files changed, 14 insertions(+)
diff --git a/README b/README
index 484ae9ee39a8..5ee789aea627 100644
--- a/README
+++ b/README
@@ -626,6 +626,7 @@ The following options need to be configured:
specific checks, but expect no product checks.
CONFIG_ARM_ERRATA_430973
CONFIG_ARM_ERRATA_454179
+ CONFIG_ARM_ERRATA_621766
CONFIG_ARM_ERRATA_798870
- Driver Model
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 99220ce76a25..2b1e312f9129 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -211,6 +211,19 @@ skip_errata_454179:
skip_errata_430973:
#endif
+#ifdef CONFIG_ARM_ERRATA_621766
+ cmp r2, #0x21 @ Only on r2p1
+ bge skip_errata_621766
+
+ mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+ orr r0, r0, #(0x1 5) @ Set L1NEON bit
+ push{r1-r4} @ Save the cpu info registers
+ b v7_arch_cp15_set_acr
+ pop {r1-r4} @ Restore the cpu info - fall through
+
+skip_errata_621766:
+#endif
+
mov pc, lr @ back to my caller
ENDPROC(cpu_init_cp15)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 09/11] ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended configuration
Update to existing recommendation for L2ACTLR configuration to prevent
system instability and optimize performance.
These apply to both OMAP5 and DRA7.
Reported-by: Vivek Chengalvala vchengalv...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index f8060555b680..8d6b59eeb044 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -304,6 +304,21 @@ void config_data_eye_leveling_samples(u32 emif_base)
(*ctrl)-control_emif2_sdram_config_ext);
}
+void init_cpu_configuration(void)
+{
+ u32 l2actlr;
+
+ asm volatile(mrc p15, 1, %0, c15, c0, 0 : =r(l2actlr));
+ /*
+* L2ACTLR: Ensure to enable the following:
+* 3: Disable clean/evict push to external
+* 4: Disable WriteUnique and WriteLineUnique transactions from master
+* 8: Disable DVM/CMO message broadcast
+*/
+ l2actlr |= 0x118;
+ omap_smc1(OMAP5_SERVICE_L2ACTLR_SET, l2actlr);
+}
+
void init_omap_revision(void)
{
/*
@@ -342,6 +357,7 @@ void init_omap_revision(void)
default:
*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
}
+ init_cpu_configuration();
}
void reset_cpu(ulong ignored)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 00/11] ARM: OMAP3-DRA7: CP15 erratum workarounds and improvements
The fourth incarnation of this series to address review comments on V3
With all the usual disclaimers and request to see V1 of the series for a
detailed blurb.. As usual additional testing preferred.. Sorry, I dont have
access to all possible variants atm..
changes since v3:
- few corrections - i have tried to do a push-pop of register params.
hopefully, they should do the job
- smc with a makefile handling of secure-ext enablement.. (stolen from
kernel).
V3: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/213207/focus=213307
V2: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/213060
V1: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/212174
Testing: with http://paste.ubuntu.org.cn/2522971 (4.0-rc1 patch)
BeagleBoard-X15: http://pastebin.ubuntu.com/10518934/
Before: CPUID=0x412fc0f2 L2CTLR=0x01800083 L2ACLR=0x
L2PFR=0x09b0 ACTLR=0x0040
After: CPUID=0x412fc0f2 L2CTLR=0x01800083 L2ACLR=0x0198
L2PFR=0x09b0 ACTLR=0x0040
OMAP5uEVM: http://pastebin.ubuntu.com/10518958/
Before: CPUID=0x412fc0f2 L2CTLR=0x01800083 L2ACLR=0x
L2PFR=0x09b0 ACTLR=0x0040
After: CPUID=0x412fc0f2 L2CTLR=0x01800083 L2ACLR=0x0198
L2PFR=0x09b0 ACTLR=0x0040
Beagle-XM: http://pastebin.ubuntu.com/10519417/ (this is a r2p3 device)
Before: CPUID=0x413fc082 ACR=0x00e2 L2AUXCR=0x0042
After: CPUID=0x413fc082 ACR=0x0042 L2AUXCR=0x0042
I dont have access to other omap3 platforms to give a better coverage
Sanity check:
OMAP4Panda-ES: http://pastebin.ubuntu.com/10518971/
Nishanth Menon (10):
ARM: Introduce erratum workaround for 798870
ARM: Introduce erratum workaround for 454179
ARM: Introduce erratum workaround for 430973
ARM: Introduce erratum workaround for 621766
ARM: OMAP: Change set_pl310_ctrl_reg to be generic
ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs
ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with
omap_smc1
ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended
configuration
ARM: OMAP3: Enable workaround for ARM errata 454179, 430973, 621766
ARM: OMAP3: rx51: Enable workaround for ARM errata 454179, 430973,
621766
Praveen Rao (1):
ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870
README |8 +++
arch/arm/cpu/armv7/Makefile|2 +-
arch/arm/cpu/armv7/cp15.c | 29 ++
arch/arm/cpu/armv7/omap-common/Makefile|5 +-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 19 +++---
arch/arm/cpu/armv7/omap3/board.c | 60 +++
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 11
arch/arm/cpu/armv7/omap4/hwinit.c |4 +-
arch/arm/cpu/armv7/omap5/hwinit.c | 23
arch/arm/cpu/armv7/start.S | 61
.../arm/include/asm/arch-omap3/{omap3.h = omap.h} |0
arch/arm/include/asm/arch-omap3/sys_proto.h|3 +-
arch/arm/include/asm/arch-omap4/sys_proto.h|5 +-
arch/arm/include/asm/arch-omap5/sys_proto.h|4 ++
arch/arm/include/asm/armv7.h |5 ++
board/nokia/rx51/rx51.c| 19 +++---
include/configs/am3517_crane.h |6 +-
include/configs/am3517_evm.h |6 +-
include/configs/cm_t35.h |6 +-
include/configs/cm_t3517.h |6 +-
include/configs/dig297.h |6 +-
include/configs/mcx.h |6 +-
include/configs/nokia_rx51.h |6 +-
include/configs/omap3_evm.h|2 +-
include/configs/omap3_evm_common.h |4 ++
include/configs/omap3_evm_quick_mmc.h |2 +-
include/configs/omap3_evm_quick_nand.h |2 +-
include/configs/omap3_logic.h |6 +-
include/configs/omap3_mvblx.h |6 +-
include/configs/omap3_pandora.h|6 +-
include/configs/omap3_sdp3430.h|6 +-
include/configs/omap3_zoom1.h |2 +-
include/configs/tam3517-common.h |6 +-
include/configs/tao3530.h |6 +-
include/configs/ti_omap3_common.h |7 ++-
include/configs/ti_omap5_common.h |3 +
include/configs/tricorder.h|6 +-
37 files changed, 275 insertions(+), 89 deletions(-)
create mode 100644 arch/arm/cpu/armv7/cp15.c
rename arch/arm/include/asm/arch-omap3/{omap3.h = omap.h} (100%)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [RFC PATCH v4 0/23] Add Driver Model support to network stack
On Sun, Mar 1, 2015 at 10:13 AM, Simon Glass s...@chromium.org wrote: [snip] - I think the recv() method should change before long. The NetReceive() call should be made from the uclass since it is common to all drivers. Then the recv() method can return a packet if it finds one, but not submit it for processing I looked into doing this and I think it may be more of a step backward. Currently devices can directly hand their DMA buffers to the network stack. With this change, most drivers would be forced to memcpy each packet into the supplied buffer. I do plan to rename the function, though. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v4 0/23] Add Driver Model support to network stack
Hi Simon, On Tue, Mar 3, 2015 at 5:14 PM, Simon Glass s...@chromium.org wrote: Hi Joe, On 3 March 2015 at 15:29, Joe Hershberger joe.hershber...@gmail.com wrote: On Sun, Mar 1, 2015 at 10:13 AM, Simon Glass s...@chromium.org wrote: [snip] - I think the recv() method should change before long. The NetReceive() call should be made from the uclass since it is common to all drivers. Then the recv() method can return a packet if it finds one, but not submit it for processing I looked into doing this and I think it may be more of a step backward. Currently devices can directly hand their DMA buffers to the network stack. With this change, most drivers would be forced to memcpy each packet into the supplied buffer. I don't see why. The uclass can request the address and length of the buffer. int (*recv)(char **buffp, int **lenp); That works... I think I'll return the length though. I don't see much value in having a pointer to the length. int (*recv)(uchar **packetp); -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad colors on BMP display on LCD
Hi Component order Michael On 26 Feb 2015 17:53, Guillaume Gardet guillaume.gar...@free.fr wrote: Hi, I am trying to display a BMP image on a Samsung Chromebook (snow), but I get wrong colors. The image is displayed but colors are bad. I used my own image and images provided in tools/logos/ folder, thay are all ok on the Sabrelite board (HDMI output) but displayed in bad colors on the samsung chromebook (LCD screen). What could be wrong? What am I missing? Guillaume ___ 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] Bad colors on BMP display on LCD
On 2015-03-03 15:55, Guillaume Gardet wrote: Hi, Hi Guillaume, Le 26/02/2015 18:10, Hannes Petermaier a écrit : Hi Guillaume, which imageformat (bpp) do you have? It depends on images tested. Most of them are: PC bitmap, Windows 3.x format, XXX x YY x 8. Just see tools/logos/*.bmp in U-Boot sources. I also created my own BMP image using convert tool with the following option : -depth 8 -colors 256 -compress none -alpha off. On my boards i use 24bpp BMPs maybe you try that. I will try display some logos out of tools/logos/*.bmp on my boards this evening. which u-boot framebuffer driver is used ? On snow config, this should be the exynos framebuffer driver. Guillaume best regards, Hannes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fdtdec: Improve fdtdec_get_pci_bdf() documentation
Add the description that how the compatible property is involved in the fdtdec_get_pci_bdf() documentation. Signed-off-by: Bin Meng bmeng...@gmail.com --- include/fdtdec.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/fdtdec.h b/include/fdtdec.h index 1bc70db..eef78a7 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -346,7 +346,10 @@ int fdtdec_get_pci_vendev(const void *blob, int node, /** * Look at the pci address of a device node that represents a PCI device - * and parse the bus, device and function number from it. + * and parse the bus, device and function number from it. For some cases + * like the bus number encoded in reg property is not correct after pci + * enumeration, this function looks through the node's compatible strings + * to get these numbers extracted instead. * * @param blob FDT blob * @param node node to examine -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Ask for help: Compulab CM-510 U-boot version: Load Kernel from SD-Card
Hi Gabriel, Try fixing CM-A510 related code: mvBoardEnvSpec.h ... ... /* CM-A510 */ #define CM_A510_MPP0_7 0x0033 #define CM_A510_MPP8_150x00445050 #define CM_A510_MPP16_23 0x4040 #define CM_A510_MPP24_31 0x #define CM_A510_MPP32_39 0x #define CM_A510_MPP40_47 0x #define CM_A510_MPP48_55 0x #define CM_A510_MPP56_63 0x0011 ... board/marvell/mv_dove/dove_family/boardEnv/mvBoardEnvSpec.c ... ... MV_BOARD_MPP_INFO cm_a510InfoBoardMppConfigValue[] ... Regards, Dmitry On 03/03/2015 05:55 PM, Gabriel Dobato wrote: Hello, I am trying to boot the kernel image from SD-CARD (mmc0) in the CM-510 SoM(provided by Compulab) using the u-boot image provided by Compulab: http://www.compulab.co.il/products/computer-on-modules/cm-a510/#devres By default, it seems SD-Card is not enabled, so I think I have to configure right the MPP option. I have searched over and over in the code sources, I have change some arrays defined in some files that are related to the MPP (pinmux) but nothing happens: ./board/marvell/mv_dove/dove_family/boardEnv/mvBoardEnvSpec.h: * DB-88F6781-BP B0 */ #define DB_88AP510BP_B_MPP0_70x #define DB_88AP510BP_B_MPP8_150x00442000 #define DB_88AP510BP_B_MPP16_230x32334043 --- #define DB_88AP510BP_B_MPP24_310x #define DB_88AP510BP_B_MPP32_390x #define DB_88AP510BP_B_MPP40_470x --- #define DB_88AP510BP_B_MPP48_550x #define DB_88AP510BP_B_MPP56_630x0011 #define DB_88AP510BP_B_OE_LOW (~((BIT1)|(BIT2)|(BIT5)|(BIT7)|(BIT8)|(BIT10)|(BIT11)|(BIT14)|(BIT15)|(BIT16)|(BIT18)|(BIT19))) #define DB_88AP510BP_B_OE_HIGH0x0FFF #define DB_88AP510BP_B_OE_VAL_LOW ((BIT1)|(BIT2)|(BIT5)|(BIT7)|(BIT8)|(BIT10)|(BIT11)|(BIT16)|(BIT18)|(BIT19)) #define DB_88AP510BP_B_OE_VAL_HIGH0x0 ./board/marvell/mv_dove/dove_family/boardEnv/mvBoardEnvSpec.c: MV_BOARD_MPP_INFOdb88f6781bpbInfoBoardMppConfigValue[] = DB_88AP510BP_B_MPP0_7, DB_88AP510BP_B_MPP8_15, DB_88AP510BP_B_MPP16_23, DB_88AP510BP_B_MPP40_47--- ; Anyone has faced this problem before? I really appreciate some kind of help. Best regards, Gabriel ___ 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] [RFC PATCH 05/13] dts: sunxi: Bring in Ethernet device tree bindings
Hi Ian, On 3 March 2015 at 01:36, Ian Campbell ijc+ub...@hellion.org.uk wrote: On Sun, 2015-03-01 at 09:33 -0700, Simon Glass wrote: Since we will use these bindings on sunxi, bring them in from Linux 4.0-rc1. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Ian Campbell i...@hellion.org.uk Although I do wonder if rather than importing all these bindings whether we shouldn't just be referencing https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/ ? Is Linux going to drop these bindings? 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/9] sf: Update flash params for supported read commands and sector size
On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote: +Tom Hi Jagan, On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On 12 January 2015 at 09:12, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On 17 December 2014 at 13:32, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On 15 December 2014 at 19:21, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Bin, On 11 December 2014 at 08:34, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Bin, On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote: This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K. Changes in v3: - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params Thanks for the updates - have you verified these changes? I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST. Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon. Let me know your inputs? I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support. Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4. I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd. You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong. Yes - about testing. Ping? What about your test results about this patch series? Some were pending - Will comment, pls- wait. thanks! -- I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series? Could you respond this? I wonder if this series could be merged in before MW is closed. I feel that you did not work on this. Can you please respond with any comments? Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 13/13] dm: sunxi: Use driver model for Ethernet on Linksprite pcDuino3
Hi Ian, On 3 March 2015 at 01:41, Ian Campbell ijc+ub...@hellion.org.uk wrote: On Sun, 2015-03-01 at 09:33 -0700, Simon Glass wrote: Switch this board over to use driver model for Ethernet Cover-letter RFC: dm: net: Conversion patches for sunxi driver model Ethernet This series is for Joe Hershberger. It is based on his RFC driver model Ethernet implementation, and enables it for the pcDuino3. END Did you intend to put this somewhere else? Yes that's an error. Signed-off-by: Simon Glass s...@chromium.org --- configs/Linksprite_pcDuino3_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/Linksprite_pcDuino3_defconfig b/configs/Linksprite_pcDuino3_defconfig index b5ff120..776588d 100644 --- a/configs/Linksprite_pcDuino3_defconfig +++ b/configs/Linksprite_pcDuino3_defconfig @@ -19,3 +19,4 @@ CONFIG_SYS_MALLOC_F_LEN=0x400 CONFIG_ETH_DESIGNWARE=y CONFIG_NETDEVICES=y CONFIG_NET=y +CONFIG_DM_ETH=y Also remove SUNXI_GMAC from CONFIG_SYS_EXTRA_OPTIONS? Do you mean move it to Kconfig? I did not do that, no. We can't just remove it since we need the gmac for everything to work. But maybe I am misunderstanding something. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v4 0/23] Add Driver Model support to network stack
Hi Joe, On 3 March 2015 at 16:32, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Tue, Mar 3, 2015 at 5:14 PM, Simon Glass s...@chromium.org wrote: Hi Joe, On 3 March 2015 at 15:29, Joe Hershberger joe.hershber...@gmail.com wrote: On Sun, Mar 1, 2015 at 10:13 AM, Simon Glass s...@chromium.org wrote: [snip] - I think the recv() method should change before long. The NetReceive() call should be made from the uclass since it is common to all drivers. Then the recv() method can return a packet if it finds one, but not submit it for processing I looked into doing this and I think it may be more of a step backward. Currently devices can directly hand their DMA buffers to the network stack. With this change, most drivers would be forced to memcpy each packet into the supplied buffer. I don't see why. The uclass can request the address and length of the buffer. int (*recv)(char **buffp, int **lenp); That works... I think I'll return the length though. I don't see much value in having a pointer to the length. int (*recv)(uchar **packetp); LGTM. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 12/13] dm: sunxi: Support driver model for Ethernet
Hi Ian, On 3 March 2015 at 01:40, Ian Campbell ijc+ub...@hellion.org.uk wrote: On Sun, 2015-03-01 at 09:33 -0700, Simon Glass wrote: Adjust the Ethernet initialisation code to support driver model. It is no-longer necessary to call designware_initialize(). The device will be probed when it is used. The PHY type and GMAC base will come from the device tree. I wonder if for this sort of thing designware_initialize couldn't become a nop so we can avoid some level of ifdefs? I would rather not, since the intent is to delete the whole function. Once all sunxi uses driver model for Ethernet we can drop the call in gmac.c. Anyway, that's just minor, of larger concern is all the CONFIG_RGMII and CONFIG_GMII stuff which is just above the context here. Doesn't that need to become DM driven for this to be useful? Yes In fact, doesn't the pinmux generally need to become DM driven? Yes Or is this just a partial stepping stone to DM Ethernet support and not a complete transition? (I wonder if I am confusing Device Model with Device Tree here and this is all about the former, albeit the former is often driven from the latter...) Yes this is Ethernet only. If we create a pinctl or funcmux framework we could implement this, but it is in fact a separate issue from Ethernet. Signed-off-by: Simon Glass s...@chromium.org --- board/sunxi/gmac.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c index 8849132..ce7831d 100644 --- a/board/sunxi/gmac.c +++ b/board/sunxi/gmac.c @@ -80,11 +80,16 @@ int sunxi_gmac_initialize(bd_t *bis) sunxi_gpio_set_cfgpin(pin, SUN6I_GPA0_GMAC); #endif -#ifdef CONFIG_RGMII +#ifdef CONFIG_DM_ETH + printf(eth init\n); + return 0; +#else +# ifdef CONFIG_RGMII return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_RGMII); -#elif defined CONFIG_GMII +# elif defined CONFIG_GMII return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_GMII); -#else +# else return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_MII); +# endif #endif } Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot for Snow problem
Hi Michal, On 2 March 2015 at 04:25, Michal Suchanek hramr...@gmail.com wrote: Hello, On 18 February 2015 at 06:24, Michal Suchanek hramr...@gmail.com wrote: On 18 February 2015 at 03:27, Simon Glass s...@chromium.org wrote: Hi Michal, On 16 February 2015 at 04:41, Michal Suchanek hramr...@gmail.com wrote: On 13 February 2015 at 05:51, Simon Glass s...@chromium.org wrote: Hi Michal, On 11 February 2015 at 10:16, Michal Suchanek hramr...@gmail.com wrote: Hello, I changed the SYS_START to work around the bug in the manufacturer firmware, applied snow_defconfig, built u-boot.bin, packed it into kernel uimage, signed it, copied it to a kernel partition, bumped priority of the partition, and rebooted. Do you mean u-boot-dtb.bin? If not you won't get a device tree and it won't work. No, u-boot.bin. With u-boot-dtb.bin I get a snow # prompt on the built-in LCD, and working keyboard. OK sounds like it is working, good! I wonder if we should have a page on elinux.org? It is working to some extent. I managed to load kernel from the emmc which works fine but the kernel cannot read the emmc after it boots because it does not properly parse the partitioning scheme. This should be trivially fixable in the kernel and might actually work if I updated my sources but rebasing the extra patches required for Snow is not automatically handled. On the other hand, the linux kernel has no problem with the SDXC card in the SD slot and can read it just fine. Unfortunately, u-boot complains about EFI partition errors and won't load anything from the card. I tried two different GPT partitioning tools on the card and both say that the partition layout is fine and that I have the default 128 entries. How can I tell why u-boot does not like my GPT label? You could debug it in U-Boot and see what is going wrong. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 11/11] ARM: OMAP3: rx51: Enable workaround for ARM errata 454179, 430973, 621766
RX51 has a secure logic which uses different parameters compared to
traditional implementation. So, make the generic secure acr write
over-ride-able by board file and refactor rx51 code to use this.
While at it, enable the OMAP3 specific errata code for 454179, 430973,
621766.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap3/board.c| 45 ---
arch/arm/include/asm/arch-omap3/sys_proto.h |1 +
board/nokia/rx51/rx51.c | 19 ++-
include/configs/nokia_rx51.h|4 +++
4 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 5587a10cdafd..bfbc197bf99c 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -404,31 +404,30 @@ static void omap3_emu_romcode_call(u32 service_id, u32
*parameters)
do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
}
-void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
- u32 cpu_variant, u32 cpu_rev)
+void __weak omap3_set_aux_cr_secure(u32 acr)
{
- if (get_device_type() == GP_DEVICE) {
- omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
- } else {
- struct emu_hal_params emu_romcode_params;
- emu_romcode_params.num_params = 1;
- emu_romcode_params.param1 = acr;
- omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
- (u32 *)emu_romcode_params);
- }
+ struct emu_hal_params emu_romcode_params;
+
+ emu_romcode_params.num_params = 1;
+ emu_romcode_params.param1 = acr;
+ omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
+ (u32 *)emu_romcode_params);
}
-static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
+void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+ u32 cpu_variant, u32 cpu_rev)
{
- u32 acr;
+ /* Write ACR - affects secure banked bits */
+ if (get_device_type() == GP_DEVICE)
+ omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
+ else
+ omap3_set_aux_cr_secure(acr);
- /* Read ACR */
- asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
- acr = ~clear_bits;
- acr |= set_bits;
- v7_arch_cp15_set_acr(acr, 0, 0, 0, 0);
+ /* Write ACR - affects non-secure banked bits - some erratas need it */
+ asm volatile (mcr p15, 0, %0, c1, c0, 1 : : r (acr));
}
+
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_update_aux_cr(u32 set_bits, u32 clear_bits)
{
@@ -438,9 +437,8 @@ static void omap3_update_aux_cr(u32 set_bits, u32
clear_bits)
asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
acr = ~clear_bits;
acr |= set_bits;
+ v7_arch_cp15_set_acr(acr, 0, 0, 0, 0);
- /* Write ACR - affects non-secure banked bits */
- asm volatile (mcr p15, 0, %0, c1, c0, 1 : : r (acr));
}
/* Invalidate the entire L2 cache from secure mode */
@@ -459,10 +457,9 @@ static void omap3_invalidate_l2_cache_secure(void)
void v7_outer_cache_enable(void)
{
- /* Set L2EN */
- omap3_update_aux_cr_secure(0x2, 0);
/*
+* Set L2EN
* On some revisions L2EN bit is banked on some revisions it's not
* No harm in setting both banked bits(in fact this is required
* by an erratum)
@@ -472,10 +469,8 @@ void v7_outer_cache_enable(void)
void omap3_outer_cache_disable(void)
{
- /* Clear L2EN */
- omap3_update_aux_cr_secure(0, 0x2);
-
/*
+* Clear L2EN
* On some revisions L2EN bit is banked on some revisions it's not
* No harm in clearing both banked bits(in fact this is required
* by an erratum)
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index c06605d533d3..ff1bf736cf06 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -74,5 +74,6 @@ void dieid_num_r(void);
void get_dieid(u32 *id);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
void omap_smc1(u32 service, u32 val);
+void omap3_set_aux_cr_secure(u32 acr);
u32 warm_reset(void);
#endif
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 08fcaf21b3c6..3d019b01428b 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -341,6 +341,17 @@ static void omap3_emu_romcode_call(u32 service_id, u32
*parameters)
do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
}
+void omap3_set_aux_cr_secure(u32 acr)
+{
+ struct emu_hal_params_rx51 emu_romcode_params = { 0, };
+
+ emu_romcode_params.num_params = 2;
+ emu_romcode_params.param1 = acr;
+
+ omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
+
