Re: [U-Boot] Microblaze and Sparc boards are broken because of common timer func
On 11/12/2013 03:12 AM, Masahiro Yamada wrote: > Hello, Rob, Tom, Michal, Daniel. > > Commit 8dfafdde88eb (Introduce common timer functions) > broke Microblaze and Sparc boards. > > $ git checkout 8dfafdde88eb > $ CROSS_COMPILE=microblaze-unknown-linux-gnu- ./MAKEALL -a microblaze > > lib/time.c:45: undefined reference to `timer_read_counter' > lib/libgeneric.o: In function `__udelay': > lib/time.c:86: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO > against symbol `get_ticks' defined in .text section in > arch/microblaze/cpu/libmicroblaze.o > lib/time.c:88: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO > against symbol `get_ticks' defined in .text section in > arch/microblaze/cpu/libmicroblaze.o > lib/libgeneric.o: In function `udelay': > lib/time.c:101: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO > against symbol `__udelay' defined in .text section in > arch/microblaze/cpu/libmicroblaze.o > lib/libgeneric.o: In function `timer_get_us': > lib/time.c:70: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO > against symbol `get_ticks' defined in .text section in > arch/microblaze/cpu/libmicroblaze.o > lib/libgeneric.o: In function `get_timer': > lib/time.c:65: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO > against symbol `get_ticks' defined in .text section in > arch/microblaze/cpu/libmicroblaze.o > > > > $ CROSS_COMPILE=sparc-elf- ./MAKEALL grsim_leon2 > Configuring for grsim_leon2 board... > sparc-elf-size: './u-boot': No such file > lib/libgeneric.o: In function `tick_to_time': > /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:56: undefined reference > to `get_tbclk' > lib/libgeneric.o: In function `get_ticks': > /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:45: undefined reference > to `timer_read_counter' > lib/libgeneric.o: In function `usec_to_tick': > /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:74: undefined reference > to `get_tbclk' > /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:75: undefined reference > to `get_tbclk' > > > > (I can notice broken boards because I quite often build all boards > for the test of Kbuild porting.) This should be fixed by this patch - at least for microblaze. commit 65ba7add0d609bbd035b8d42fafdaf428ac24751 Author: Rob Herring Date: Fri Nov 8 08:40:43 2013 -0600 time: add weak annotation to timer_read_counter declaration A weak annotation is needed in order to prevent link errors when get_ticks is overridden. This fixes sandbox build. Signed-off-by: Rob Herring Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
On 11/11/2013 09:33 PM, Tom Rini wrote: > On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: > >> Altera Cyclone 5 board is very different board (big, rectangular, >> expensive) than EBV Socrates (small, circular, cheap) board. Different >> parts are used there, too, but same configuration of u-boot works on >> both. Nevertheless, printing wrong name confuses users. >> >> Therefore this splits the configuration so that u-boot knows they are >> different. So far it is only used for correcting the puts, but there >> may be other uses in future. >> >> Signed-off-by: Pavel Machek > > Is there any way at run time to tell which board we are on? Why do you care about board name in general? Just write that it is socfpga and that's it. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] video: bcm2835: respect the pitch value
Hi Andre, On Sat, 9 Nov 2013 13:25:58 +0100 Andre Heider wrote: ... > I just tested these on my rpi, and confirm that it still works. Thanks for testing! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: allow overriding lcd_get_size()
On Sat, 9 Nov 2013 11:00:09 +0100 Anatolij Gustschin wrote: > Remove the redundant lcd_line_length initialisation which > sneaked in when an earlier version of the patch of commit > 6d330719 has been rebased. > > Some lcd drivers need to setup lcd_line_length not from the > panel_info parameters but by different means. Make the > lcd_get_size() weak to allow setting lcd_line_length in > a driver specific way. > > Signed-off-by: Anatolij Gustschin > Cc: Stephen Warren > --- > common/lcd.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] video: bcm2835: respect the pitch value
On Sat, 9 Nov 2013 11:07:53 +0100 Anatolij Gustschin wrote: > From: Andre Heider > > Depending on the firmware's video options [1] the active SDTV or > HDTV mode can yield a framebuffer with noncontiguous horizontal lines, > giving a messed up display, for both, u-boot and the loaded kernel. > > Fix this by setting lcd_line_length to the pitch value of the configured > framebuffer. > > [1] http://elinux.org/RPiconfig#Video_mode_options > > Signed-off-by: Andre Heider > Cc: Stephen Warren > Signed-off-by: Anatolij Gustschin > --- > Changes in v3: > - set lcd_line_length by driver specific lcd_get_size() since >setting it in lcd_enable() is not correct. This patch version >depends on patch http://patchwork.ozlabs.org/patch/289957 >Please test these both patches on rpi_b, thanks! > > drivers/video/bcm2835.c | 11 +++ > 1 file changed, 11 insertions(+) applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263)
Hello Andreas,
Am 11.11.2013 12:03, schrieb Andreas Bießmann:
Dear Mateusz Kulikowski,
On 11/02/2013 12:19 AM, Mateusz Kulikowski wrote:
Add support for USB-A9263 board manufactured by Calao Systems
(http://www.calao-systems.com/).
Code is based on old U-Boot sources (2010.09) released by Calao and
existing AT92SAM9263-EK code.
Signed-off-by: Mateusz Kulikowski
---
board/calao/usb_a9263/Makefile| 34
board/calao/usb_a9263/usb_a9263.c | 167 +
boards.cfg| 1 +
include/configs/usb_a9263.h | 168 ++
4 files changed, 370 insertions(+)
create mode 100644 board/calao/usb_a9263/Makefile
create mode 100644 board/calao/usb_a9263/usb_a9263.c
create mode 100644 include/configs/usb_a9263.h
[...]
diff --git a/board/calao/usb_a9263/usb_a9263.c
b/board/calao/usb_a9263/usb_a9263.c
new file mode 100644
index 000..bbc1e25
--- /dev/null
+++ b/board/calao/usb_a9263/usb_a9263.c
@@ -0,0 +1,167 @@
[...]
+#ifdef CONFIG_MACB
+static void usb_a9263_macb_hw_init(void)
+{
+ unsigned long erstl;
+ at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
+ at91_rstc_t *rstc = (at91_rstc_t *)ATMEL_BASE_RSTC;
+
+ /* Enable clock */
+ writel(1<< ATMEL_ID_EMAC,&pmc->pcer);
+
+ /*
+* Disable pull-up on:
+* RXDV (PC25) => PHY normal mode (not Test mode)
+* ERX0 (PE25) => PHY ADDR0
+* ERX1 (PE26) => PHY ADDR1 => PHYADDR = 0x0
+*
+* PHY has internal pull-down
+*/
+ at91_set_pio_pullup(AT91_PIO_PORTC, 25, 0);
+ at91_set_pio_pullup(AT91_PIO_PORTE, 25, 0);
+ at91_set_pio_pullup(AT91_PIO_PORTE, 26, 0);
+
+ erstl = readl(&rstc->mr)& AT91_RSTC_MR_ERSTL_MASK;
+
+ /* Need to reset PHY -> 500ms reset */
+ writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(0x0D) |
+ AT91_RSTC_MR_URSTEN,&rstc->mr);
+
+ writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST,&rstc->cr);
+
+ /* Wait for end hardware reset */
+ while (!(readl(&rstc->sr)& AT91_RSTC_SR_NRSTL))
+ ;
+
+ /* Restore NRST value */
+ writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN,&rstc->mr);
+
+ /* Re-enable pull-up */
+ at91_set_pio_pullup(AT91_PIO_PORTC, 25, 1);
+ at91_set_pio_pullup(AT91_PIO_PORTE, 25, 1);
+ at91_set_pio_pullup(AT91_PIO_PORTE, 26, 1);
+
+ at91_macb_hw_init();
Heiko proposed a solution for unifying macb reset sequence.
@Heiko will you send another patch?
I thought I wait for your GPIO update patches, and rebase my patch-
serie for the siemens boards on them ...
Ok, based on the spl patches from bo shen, see
http://lists.denx.de/pipermail/u-boot/2013-November/166272.html
I can sent soon the "phy_reset" patch, if the patch passes a
"MAKEALL" ;-)
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
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] trats: enable dfu and thor protocol for Tizen download
Trats2 config is updated to support DFU mode.
Malloc pool must be increased for DFU buffer allocation.
Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
CC: Minkyu Kang
---
This patch is based on
http://patchwork.ozlabs.org/patch/289378/
include/configs/trats2.h | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index 66b1c95..52bb5e5 100644
--- a/include/configs/trats2.h
+++ b/include/configs/trats2.h
@@ -65,10 +65,9 @@
#define CONFIG_DISPLAY_CPUINFO
-/*
- * Size of malloc() pool
- */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (2 << 20))
+#include
+/* Size of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 * SZ_1M))
/* select serial console configuration */
#define CONFIG_SERIAL2
@@ -100,6 +99,7 @@
#define CONFIG_CMD_CACHE
#define CONFIG_CMD_I2C
#define CONFIG_CMD_MMC
+#define CONFIG_CMD_DFU
#define CONFIG_CMD_GPT
#define CONFIG_CMD_PMIC
@@ -115,12 +115,19 @@
/* USB Composite download gadget - g_dnl */
#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M
#define CONFIG_DFU_FUNCTION
#define CONFIG_DFU_MMC
+/* TIZEN THOR downloader support */
+#define CONFIG_CMD_THOR_DOWNLOAD
+#define CONFIG_THOR_FUNCTION
+
/* USB Samsung's IDs */
#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM
+#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D
#define CONFIG_G_DNL_MANUFACTURER "Samsung"
/* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
@@ -165,6 +172,12 @@
"name="PARTS_CSC",size=150MiB,uuid=${uuid_gpt_"PARTS_CSC"};" \
"name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
+#define CONFIG_DFU_ALT \
+ "u-boot mmc 80 400;" \
+ "uImage ext4 0 2;" \
+ "exynos4412-trats2.dtb ext4 0 2;" \
+ ""PARTS_ROOT" part 0 5\0"
+
#define CONFIG_EXTRA_ENV_SETTINGS \
"bootk=" \
"run loaddtb; run loaduimage; bootm 0x40007FC0 - ${fdtaddr}\0" \
@@ -197,6 +210,7 @@
"mmcrootpart=5\0" \
"opts=always_resume=1\0" \
"partitions=" PARTS_DEFAULT \
+ "dfu_alt_info=" CONFIG_DFU_ALT \
"uartpath=ap\0" \
"usbpath=ap\0" \
"consoleon=set console console=ttySAC2,115200n8; save; reset\0" \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Microblaze and Sparc boards are broken because of common timer func
Hello Michal > This should be fixed by this patch - at least for microblaze. > > commit 65ba7add0d609bbd035b8d42fafdaf428ac24751 > Author: Rob Herring > Date: Fri Nov 8 08:40:43 2013 -0600 > > time: add weak annotation to timer_read_counter declaration > > A weak annotation is needed in order to prevent link errors when > get_ticks is overridden. This fixes sandbox build. > > Signed-off-by: Rob Herring No. I tried both the current u-boot/master and commit 65ba7add0d, but Microblaze board failed with the same error message. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/6] spi: omap3: remove semicolon from #define
On Wed, 16 Oct 2013 17:23:24 +0300 Nikita Kiryanov wrote: > Remove unnecessary semicolon from #define SPI_WAIT_TIMEOUT > > Cc: Tom Rini > Cc: Jagannadha Sutradharudu Teki > Cc: Igor Grinberg > Cc: Gerhard Sittig > Signed-off-by: Nikita Kiryanov > --- > NOTE: New patch in series (Gerhard Sittig, Igor Grinberg) > > drivers/spi/omap3_spi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/6] spi: omap3: add support for more word lengths
On Wed, 16 Oct 2013 17:23:25 +0300 Nikita Kiryanov wrote: > Current implementation only supports 8 bit word lengths, even though > omap3 can handle anything between 4 and 32. > > Update the spi interface to support changing the SPI word length, > and implement it in omap3_spi driver to support the full range of > possible word lengths. > This implementation is backwards compatible by defaulting to the old > behavior of 8 bit word lengths. > Also, it required a change to the omap3_spi non static I/O functions, > but since they are not used anywhere else, no collateral changes are required. > > Cc: Tom Rini > Cc: Jagannadha Sutradharudu Teki > Cc: Igor Grinberg > Signed-off-by: Nikita Kiryanov > --- > Changes in V2: > - Removed semicolon from #define SPI_DEFAULT_WORDLEN (Gerhard Sittig, > Igor Grinberg) > - Moved wordlen to generic spi_slave struct, and added generic > implementation for spi_set_wordlen which only updates the struct without > touching the hardware (Igor Grinberg) > - Update wordlen in hardware just before doing SPI transactions, not > when changing wordlen (Igor Grinberg) > - OMAP3 specific check of wordlen value from old implementation of > spi_set_wordlen moved to xfer. It refines the more general check done > in the new spi_set_wordlen. > - Fixed comment style in spi.h following a rebase on top of latest > U-Boot > > drivers/spi/omap3_spi.c | 69 > +++-- > drivers/spi/omap3_spi.h | 8 +++--- > drivers/spi/spi.c | 13 ++ > include/spi.h | 16 > 4 files changed, 82 insertions(+), 24 deletions(-) applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/6] spi: define SPI_XFER_ONCE
On Wed, 16 Oct 2013 17:23:26 +0300 Nikita Kiryanov wrote: > The flag combination "SPI_XFER_BEGIN | SPI_XFER_END" is a common use > case of spi_xfer, and it can easily cause an already long line (spi_xfer > takes 5 parameters) to go over the 80 character limit. > > define SPI_XFER_ONCE to be a shorter version of the above flag combination. > > Cc: Tom Rini > Cc: Jagannadha Sutradharudu Teki > Cc: Igor Grinberg > Signed-off-by: Nikita Kiryanov > --- > NOTE: This is a new patch. Its contents were originally part of "lcd: add > DataImage SCF0403x LCD panel support". Split because it is unrelated to > the patch it was originally in. (Igor Grinberg) > > include/spi.h | 1 + > 1 file changed, 1 insertion(+) applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 4/6] lcd: add DataImage SCF0403x LCD panel support
On Wed, 16 Oct 2013 17:23:27 +0300 Nikita Kiryanov wrote: > Add SPI-based driver for DataImage SCF0403852GGU04 and SCF0403526GGU20 > LCD panels. > > Cc: Tom Rini > Cc: Anatolij Gustschin > Cc: Igor Grinberg > Signed-off-by: Nikita Kiryanov > --- > Changes in V2: > - Added SPDX-License-Identifier to all new files (Anatolij Gustschin) > - s/printf/puts for not formatted strings (Anatolij Gustschin) > - Do not fail init if an invalid reset_gpio is given (Igor Grinberg) > - Move definition of SPI_XFER_ONCE to a separate patch (Igor Grinberg) > > drivers/video/Makefile | 1 + > drivers/video/scf0403_lcd.c | 296 > > include/scf0403_lcd.h | 11 ++ > 3 files changed, 308 insertions(+) > create mode 100644 drivers/video/scf0403_lcd.c > create mode 100644 include/scf0403_lcd.h applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 5/6] omap3_dss: define DSS_ONOFF
On Wed, 16 Oct 2013 17:23:28 +0300 Nikita Kiryanov wrote: > Add DSS_ONOFF to polarity defines > > Cc: Tom Rini > Cc: Anatolij Gustschin > Cc: Igor Grinberg > Signed-off-by: Nikita Kiryanov > Acked-by: Igor Grinberg > --- > NOTE: This is a new patch. Its contents were originally part of "cm_t35: use > scf0403 driver". Split because it is unrelated to the patch it was > originally in. > > arch/arm/include/asm/arch-omap3/dss.h | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] trats: enable dfu and thor protocol for Tizen download
Hi Piotr,
I think good that used the "trats2:xxx" instead of "trats: xxx" at subject.
On 11/12/2013 05:58 PM, Piotr Wilczek wrote:
> Trats2 config is updated to support DFU mode.
> Malloc pool must be increased for DFU buffer allocation.
>
> Signed-off-by: Piotr Wilczek
> Signed-off-by: Kyungmin Park
> CC: Minkyu Kang
> ---
> This patch is based on
> http://patchwork.ozlabs.org/patch/289378/
>
> include/configs/trats2.h | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/include/configs/trats2.h b/include/configs/trats2.h
> index 66b1c95..52bb5e5 100644
> --- a/include/configs/trats2.h
> +++ b/include/configs/trats2.h
> @@ -65,10 +65,9 @@
>
> #define CONFIG_DISPLAY_CPUINFO
>
> -/*
> - * Size of malloc() pool
> - */
> -#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (2 << 20))
> +#include
> +/* Size of malloc() pool */
> +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (80 * SZ_1M))
>
> /* select serial console configuration */
> #define CONFIG_SERIAL2
> @@ -100,6 +99,7 @@
> #define CONFIG_CMD_CACHE
> #define CONFIG_CMD_I2C
> #define CONFIG_CMD_MMC
> +#define CONFIG_CMD_DFU
> #define CONFIG_CMD_GPT
> #define CONFIG_CMD_PMIC
>
> @@ -115,12 +115,19 @@
>
> /* USB Composite download gadget - g_dnl */
> #define CONFIG_USBDOWNLOAD_GADGET
> +#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M
> #define CONFIG_DFU_FUNCTION
> #define CONFIG_DFU_MMC
>
> +/* TIZEN THOR downloader support */
> +#define CONFIG_CMD_THOR_DOWNLOAD
> +#define CONFIG_THOR_FUNCTION
> +
> /* USB Samsung's IDs */
> #define CONFIG_G_DNL_VENDOR_NUM 0x04E8
> #define CONFIG_G_DNL_PRODUCT_NUM 0x6601
> +#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM
> +#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D
> #define CONFIG_G_DNL_MANUFACTURER "Samsung"
>
> /* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
> @@ -165,6 +172,12 @@
> "name="PARTS_CSC",size=150MiB,uuid=${uuid_gpt_"PARTS_CSC"};" \
> "name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
>
> +#define CONFIG_DFU_ALT \
> + "u-boot mmc 80 400;" \
I recommend the "u-boot mmc 80 800"
Best Regards,
Jaehoon Chung
> + "uImage ext4 0 2;" \
> + "exynos4412-trats2.dtb ext4 0 2;" \
> + ""PARTS_ROOT" part 0 5\0"
> +
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "bootk=" \
> "run loaddtb; run loaduimage; bootm 0x40007FC0 - ${fdtaddr}\0" \
> @@ -197,6 +210,7 @@
> "mmcrootpart=5\0" \
> "opts=always_resume=1\0" \
> "partitions=" PARTS_DEFAULT \
> + "dfu_alt_info=" CONFIG_DFU_ALT \
> "uartpath=ap\0" \
> "usbpath=ap\0" \
> "consoleon=set console console=ttySAC2,115200n8; save; reset\0" \
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 6/6] cm_t35: use scf0403 driver
On Wed, 16 Oct 2013 17:23:29 +0300 Nikita Kiryanov wrote: > Use scf0403 driver to add scf0403x LCD support for cm-t35 and cm-t3730 > boards. > > Signed-off-by: Nikita Kiryanov > Acked-by: Igor Grinberg > --- > NOTE: This patch depends on http://patchwork.ozlabs.org/patch/275283/ > > Changes in V2: > - Changes to arch/arm/include/asm/arch-omap3/dss.h were split off to > another patch. > > board/compulab/cm_t35/cm_t35.c| 12 + > board/compulab/common/omap3_display.c | 46 > +-- > include/configs/cm_t35.h | 3 +++ > 3 files changed, 59 insertions(+), 2 deletions(-) applied to u-boot-video/master, thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] trats: enable dfu and thor protocol for Tizen download
Hi Jaehoon,
> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Tuesday, November 12, 2013 10:23 AM
> To: Piotr Wilczek; u-boot@lists.denx.de
> Cc: Kyungmin Park
> Subject: Re: [U-Boot] [PATCH] trats: enable dfu and thor protocol for
> Tizen download
>
> Hi Piotr,
>
> I think good that used the "trats2:xxx" instead of "trats: xxx" at
> subject.
Yes, I overlook that, will fix.
>
> On 11/12/2013 05:58 PM, Piotr Wilczek wrote:
> > Trats2 config is updated to support DFU mode.
> > Malloc pool must be increased for DFU buffer allocation.
> >
> > Signed-off-by: Piotr Wilczek
> > Signed-off-by: Kyungmin Park
> > CC: Minkyu Kang
> > ---
> > This patch is based on
> > http://patchwork.ozlabs.org/patch/289378/
> >
> > include/configs/trats2.h | 22 ++
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/configs/trats2.h b/include/configs/trats2.h
> index
> > 66b1c95..52bb5e5 100644
> > --- a/include/configs/trats2.h
> > +++ b/include/configs/trats2.h
> > @@ -65,10 +65,9 @@
> >
> > #define CONFIG_DISPLAY_CPUINFO
> >
> > -/*
> > - * Size of malloc() pool
> > - */
> > -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (2 <<
20))
> > +#include
> > +/* Size of malloc() pool */
> > +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 *
> SZ_1M))
> >
> > /* select serial console configuration */ #define CONFIG_SERIAL2 @@
> > -100,6 +99,7 @@ #define CONFIG_CMD_CACHE #define CONFIG_CMD_I2C
> > #define CONFIG_CMD_MMC
> > +#define CONFIG_CMD_DFU
> > #define CONFIG_CMD_GPT
> > #define CONFIG_CMD_PMIC
> >
> > @@ -115,12 +115,19 @@
> >
> > /* USB Composite download gadget - g_dnl */ #define
> > CONFIG_USBDOWNLOAD_GADGET
> > +#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M
> > #define CONFIG_DFU_FUNCTION
> > #define CONFIG_DFU_MMC
> >
> > +/* TIZEN THOR downloader support */
> > +#define CONFIG_CMD_THOR_DOWNLOAD
> > +#define CONFIG_THOR_FUNCTION
> > +
> > /* USB Samsung's IDs */
> > #define CONFIG_G_DNL_VENDOR_NUM 0x04E8 #define
> > CONFIG_G_DNL_PRODUCT_NUM 0x6601
> > +#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM #define
> > +CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D
> > #define CONFIG_G_DNL_MANUFACTURER "Samsung"
> >
> > /* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
> > @@ -165,6 +172,12 @@
> > "name="PARTS_CSC",size=150MiB,uuid=${uuid_gpt_"PARTS_CSC"};" \
> > "name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
> >
> > +#define CONFIG_DFU_ALT \
> > + "u-boot mmc 80 400;" \
> I recommend the "u-boot mmc 80 800"
Ok
>
> Best Regards,
> Jaehoon Chung
> > + "uImage ext4 0 2;" \
> > + "exynos4412-trats2.dtb ext4 0 2;" \
> > + ""PARTS_ROOT" part 0 5\0"
> > +
> > #define CONFIG_EXTRA_ENV_SETTINGS \
> > "bootk=" \
> > "run loaddtb; run loaduimage; bootm 0x40007FC0 -
> ${fdtaddr}\0" \ @@
> > -197,6 +210,7 @@
> > "mmcrootpart=5\0" \
> > "opts=always_resume=1\0" \
> > "partitions=" PARTS_DEFAULT \
> > + "dfu_alt_info=" CONFIG_DFU_ALT \
> > "uartpath=ap\0" \
> > "usbpath=ap\0" \
> > "consoleon=set console console=ttySAC2,115200n8; save; reset\0" \
> >
Best regards,
Piotr Wilczek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/6] SMDK5420: Add S2MPS11 pmic support to SMDK5420
This patchset adds support for S2MPS11 pmic on SMDK5420 This patchset has dependency on Rajeshwari's base patchset: [PATCH 00/10 V6] EXYNOS5420: Add SMDK5420 board support http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/172653 Also, for testing we need Naveen's i2c patchset as well: i2c: improve s3c24x0 with High-speed and new SYS_I2C framework support http://www.mail-archive.com/u-boot@lists.denx.de/msg122679.html Changes since V2: - Rebased on V6 version patchset sent by Rajeshwari http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/172653 Changes since V1: - In patch "exynos: Use common pmic_reg_update() definition" moved pmic_reg_update() from drivers/power/power_i2c.c to power_core.c suggested by Lukasz Majewski - Changed the License details to GPL 2.0+ license for below pathces SMDK5420: S2MPS11: Adds the register settings for S2MPS11 exynos: Add a common DT based PMIC driver initialization - corrected the typo error in "config: SMDK5420: Enable S2MPS11 pmic" patch header Leela Krishna Amudala (6): exynos: Use common pmic_reg_update() definition power: Explicitly select pmic device's bus FDT: Exynos5420: Add compatible srings for PMIC SMDK5420: S2MPS11: Adds the register settings for S2MPS11 exynos: Add a common DT based PMIC driver initialization config: SMDK5420: Enable S2MPS11 pmic board/samsung/common/board.c | 39 ++- drivers/power/pmic/Makefile |1 + drivers/power/pmic/pmic_common.c | 97 ++ drivers/power/power_core.c | 33 + drivers/power/power_i2c.c| 62 +++-- include/configs/smdk5420.h |4 ++ include/fdtdec.h |1 + include/power/pmic.h | 35 ++ include/power/s2mps11_pmic.h | 141 ++ lib/fdtdec.c |1 + 10 files changed, 391 insertions(+), 23 deletions(-) create mode 100644 drivers/power/pmic/pmic_common.c create mode 100644 include/power/s2mps11_pmic.h -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/6] exynos: Use common pmic_reg_update() definition
This function is used by different Exynos platforms, put it in the
common file.
Signed-off-by: Vadim Bendebury
Signed-off-by: Leela Krishna Amudala
Reviewed-by: Doug Anderson
Reviewed-by: Lukasz Majewski
Acked-by: Simon Glass
---
board/samsung/common/board.c | 19 ---
drivers/power/power_core.c | 19 +++
include/power/pmic.h |1 +
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 2512a59..1959c4e 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -156,25 +156,6 @@ static int board_init_cros_ec_devices(const void *blob)
#if defined(CONFIG_POWER)
#ifdef CONFIG_POWER_MAX77686
-static int pmic_reg_update(struct pmic *p, int reg, uint regval)
-{
- u32 val;
- int ret = 0;
-
- ret = pmic_reg_read(p, reg, &val);
- if (ret) {
- debug("%s: PMIC %d register read failed\n", __func__, reg);
- return -1;
- }
- val |= regval;
- ret = pmic_reg_write(p, reg, val);
- if (ret) {
- debug("%s: PMIC %d register write failed\n", __func__, reg);
- return -1;
- }
- return 0;
-}
-
static int max77686_init(void)
{
struct pmic *p;
diff --git a/drivers/power/power_core.c b/drivers/power/power_core.c
index 29ccc83..e715435 100644
--- a/drivers/power/power_core.c
+++ b/drivers/power/power_core.c
@@ -208,6 +208,25 @@ int do_pmic(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
return CMD_RET_SUCCESS;
}
+int pmic_reg_update(struct pmic *p, int reg, uint regval)
+{
+ u32 val;
+ int ret = 0;
+
+ ret = pmic_reg_read(p, reg, &val);
+ if (ret) {
+ debug("%s: PMIC %d register read failed\n", __func__, reg);
+ return -1;
+ }
+ val |= regval;
+ ret = pmic_reg_write(p, reg, val);
+ if (ret) {
+ debug("%s: PMIC %d register write failed\n", __func__, reg);
+ return -1;
+ }
+ return 0;
+}
+
U_BOOT_CMD(
pmic, CONFIG_SYS_MAXARGS, 1, do_pmic,
"PMIC",
diff --git a/include/power/pmic.h b/include/power/pmic.h
index 0e7aa31..d17dbdc 100644
--- a/include/power/pmic.h
+++ b/include/power/pmic.h
@@ -83,6 +83,7 @@ int pmic_probe(struct pmic *p);
int pmic_reg_read(struct pmic *p, u32 reg, u32 *val);
int pmic_reg_write(struct pmic *p, u32 reg, u32 val);
int pmic_set_output(struct pmic *p, u32 reg, int ldo, int on);
+int pmic_reg_update(struct pmic *p, int reg, uint regval);
#define pmic_i2c_addr (p->hw.i2c.addr)
#define pmic_i2c_tx_num (p->hw.i2c.tx_num)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/6] FDT: Exynos5420: Add compatible srings for PMIC
Add required compatible strings for PMIC S2MPS11
Signed-off-by: Leela Krishna Amudala
Acked-by: Simon Glass
---
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6bf83bf..6290078 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -85,6 +85,7 @@ enum fdt_compat_id {
COMPAT_INFINEON_SLB9635_TPM,/* Infineon SLB9635 TPM */
COMPAT_INFINEON_SLB9645_TPM,/* Infineon SLB9645 TPM */
COMPAT_SAMSUNG_EXYNOS5_I2C, /* Exynos5 High Speed I2C Controller */
+ COMPAT_SAMSUNG_S2MPS11_PMIC,/* S2MPS11 PMIC */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index dc35856..0ea1c08 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -58,6 +58,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(INFINEON_SLB9635_TPM, "infineon,slb9635-tpm"),
COMPAT(INFINEON_SLB9645_TPM, "infineon,slb9645-tpm"),
COMPAT(SAMSUNG_EXYNOS5_I2C, "samsung,exynos5-hsi2c"),
+ COMPAT(SAMSUNG_S2MPS11_PMIC, "samsung,s2mps11-pmic"),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 5/6] exynos: Add a common DT based PMIC driver initialization
Most of i2c PMIC drivers follow the same initialization sequence,
let's generalize it in a common file.
The initialization function finds the PMIC in the device tree, and if
found - registers it in the list of known PMICs and initializes it,
iterating through the table of settings supplied by the caller.
Signed-off-by: Vadim Bendebury
Signed-off-by: Leela Krishna Amudala
Reviewed-by: Doug Anderson
Acked-by: Simon Glass
---
board/samsung/common/board.c | 22 +
drivers/power/pmic/Makefile |1 +
drivers/power/pmic/pmic_common.c | 97 ++
drivers/power/power_core.c | 14 ++
include/power/pmic.h | 34 +
5 files changed, 168 insertions(+)
create mode 100644 drivers/power/pmic/pmic_common.c
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 1959c4e..cc83724 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -154,6 +155,25 @@ static int board_init_cros_ec_devices(const void *blob)
}
#endif
+#ifdef CONFIG_POWER_S2MPS11
+int board_init_s2mps11(void)
+{
+ const struct pmic_init_ops pmic_ops[] = {
+ {PMIC_REG_WRITE, S2MPS11_BUCK1_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK2_CTRL2,
+ S2MPS11_BUCK_CTRL2_1_2625V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK3_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK4_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK6_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_UPDATE, S2MPS11_REG_RTC_CTRL,
+ S2MPS11_RTC_CTRL_32KHZ_CP_EN | S2MPS11_RTC_CTRL_JIT},
+ {PMIC_REG_BAIL}
+ };
+
+ return pmic_common_init(COMPAT_SAMSUNG_S2MPS11_PMIC, pmic_ops);
+}
+#endif
+
#if defined(CONFIG_POWER)
#ifdef CONFIG_POWER_MAX77686
static int max77686_init(void)
@@ -259,6 +279,8 @@ int power_init_board(void)
#ifdef CONFIG_POWER_MAX77686
ret = max77686_init();
+#elif defined(CONFIG_POWER_S2MPS11)
+ ret = board_init_s2mps11();
#endif
return ret;
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 11b3d03..ec0a992 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -15,6 +15,7 @@ COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
COBJS-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
+COBJS-$(CONFIG_POWER) += pmic_common.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/power/pmic/pmic_common.c b/drivers/power/pmic/pmic_common.c
new file mode 100644
index 000..3117ae2
--- /dev/null
+++ b/drivers/power/pmic/pmic_common.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static unsigned pmic_number_of_regs(enum fdt_compat_id pmic_compat)
+{
+ switch (pmic_compat) {
+ case COMPAT_SAMSUNG_S2MPS11_PMIC:
+ return S2MPS11_NUM_OF_REGS;
+ default:
+ break;
+ }
+ return 0;
+}
+
+int pmic_common_init(enum fdt_compat_id pmic_compat,
+const struct pmic_init_ops *pmic_ops)
+{
+ const void *blob = gd->fdt_blob;
+ struct pmic *p;
+ int node, parent, ret;
+ unsigned number_of_regs = pmic_number_of_regs(pmic_compat);
+ const char *pmic_name, *comma;
+
+ if (!number_of_regs) {
+ printf("%s: %s - not a supported PMIC\n",
+ __func__, fdtdec_get_compatible(pmic_compat));
+ return -1;
+ }
+
+ node = fdtdec_next_compatible(blob, 0, pmic_compat);
+ if (node < 0) {
+ debug("PMIC: Error %s. No node for %s in device tree\n",
+ fdt_strerror(node), fdtdec_get_compatible(pmic_compat));
+ return node;
+ }
+
+ pmic_name = fdtdec_get_compatible(pmic_compat);
+ comma = strchr(pmic_name, ',');
+ if (comma)
+ pmic_name = comma + 1;
+
+ p = pmic_alloc();
+
+ if (!p) {
+ printf("%s: POWER allocation error!\n", __func__);
+ return -ENOMEM;
+ }
+ parent = fdt_parent_offset(blob, node);
+ if (parent < 0) {
+ debug("%s: Cannot find node parent\n", __func__);
+ return -1;
+ }
+
+ p->bus = i2c_get_bus_num_fdt(parent);
+ if (p->bus < 0) {
+ debug("%s: Cannot find I2C bus\n", __func__);
+ return -1;
+ }
+ p->hw.i2c.addr = fdtdec_get_int(blob, node, "reg", 9);
+
+ p->name = pmic_name;
+ p->interface = PMIC_I2C;
+
[U-Boot] [PATCH V3 4/6] SMDK5420: S2MPS11: Adds the register settings for S2MPS11
Adds the register settings, addresses and voltages associated with S2MPS11
Signed-off-by: Alim Akhtar
Signed-off-by: Leela Krishna Amudala
Reviewed-by: Vadim Bendebury
Reviewed-by: Lukasz Majewski
Acked-by: Simon Glass
---
include/power/s2mps11_pmic.h | 141 ++
1 file changed, 141 insertions(+)
create mode 100644 include/power/s2mps11_pmic.h
diff --git a/include/power/s2mps11_pmic.h b/include/power/s2mps11_pmic.h
new file mode 100644
index 000..20c781d
--- /dev/null
+++ b/include/power/s2mps11_pmic.h
@@ -0,0 +1,141 @@
+/*
+ * s2mps11_pmic.h
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ */
+#ifndef __S2MPS11_H
+#define __S2MPS11_H
+
+/* S2MPS11 registers */
+enum s2mps11_reg {
+ S2MPS11_REG_ID,
+ S2MPS11_REG_INT1,
+ S2MPS11_REG_INT2,
+ S2MPS11_REG_INT3,
+ S2MPS11_REG_INT1M,
+ S2MPS11_REG_INT2M,
+ S2MPS11_REG_INT3M,
+ S2MPS11_REG_ST1,
+ S2MPS11_REG_ST2,
+ S2MPS11_REG_OFFSRC,
+ S2MPS11_REG_PWRONSRC,
+ S2MPS11_REG_RTC_CTRL,
+ S2MPS11_REG_CTRL1,
+ S2MPS11_REG_ETC_TEST,
+ S2MPS11_REG_RSVD3,
+ S2MPS11_REG_BU_CHG,
+ S2MPS11_REG_RAMP,
+ S2MPS11_REG_RAMP_BUCK,
+ S2MPS11_REG_LDO1_8,
+ S2MPS11_REG_LDO9_16,
+ S2MPS11_REG_LDO17_24,
+ S2MPS11_REG_LDO25_32,
+ S2MPS11_REG_LDO33_38,
+ S2MPS11_REG_LDO1_8_1,
+ S2MPS11_REG_LDO9_16_1,
+ S2MPS11_REG_LDO17_24_1,
+ S2MPS11_REG_LDO25_32_1,
+ S2MPS11_REG_LDO33_38_1,
+ S2MPS11_REG_OTP_ADRL,
+ S2MPS11_REG_OTP_ADRH,
+ S2MPS11_REG_OTP_DATA,
+ S2MPS11_REG_MON1SEL,
+ S2MPS11_REG_MON2SEL,
+ S2MPS11_REG_LEE,
+ S2MPS11_REG_RSVD_NO,
+ S2MPS11_REG_UVLO,
+ S2MPS11_REG_LEE_NO,
+ S2MPS11_REG_B1CTRL1,
+ S2MPS11_REG_B1CTRL2,
+ S2MPS11_REG_B2CTRL1,
+ S2MPS11_REG_B2CTRL2,
+ S2MPS11_REG_B3CTRL1,
+ S2MPS11_REG_B3CTRL2,
+ S2MPS11_REG_B4CTRL1,
+ S2MPS11_REG_B4CTRL2,
+ S2MPS11_REG_B5CTRL1,
+ S2MPS11_REG_BUCK5_SW,
+ S2MPS11_REG_B5CTRL2,
+ S2MPS11_REG_B5CTRL3,
+ S2MPS11_REG_B5CTRL4,
+ S2MPS11_REG_B5CTRL5,
+ S2MPS11_REG_B6CTRL1,
+ S2MPS11_REG_B6CTRL2,
+ S2MPS11_REG_B7CTRL1,
+ S2MPS11_REG_B7CTRL2,
+ S2MPS11_REG_B8CTRL1,
+ S2MPS11_REG_B8CTRL2,
+ S2MPS11_REG_B9CTRL1,
+ S2MPS11_REG_B9CTRL2,
+ S2MPS11_REG_B10CTRL1,
+ S2MPS11_REG_B10CTRL2,
+ S2MPS11_REG_L1CTRL,
+ S2MPS11_REG_L2CTRL,
+ S2MPS11_REG_L3CTRL,
+ S2MPS11_REG_L4CTRL,
+ S2MPS11_REG_L5CTRL,
+ S2MPS11_REG_L6CTRL,
+ S2MPS11_REG_L7CTRL,
+ S2MPS11_REG_L8CTRL,
+ S2MPS11_REG_L9CTRL,
+ S2MPS11_REG_L10CTRL,
+ S2MPS11_REG_L11CTRL,
+ S2MPS11_REG_L12CTRL,
+ S2MPS11_REG_L13CTRL,
+ S2MPS11_REG_L14CTRL,
+ S2MPS11_REG_L15CTRL,
+ S2MPS11_REG_L16CTRL,
+ S2MPS11_REG_L17CTRL,
+ S2MPS11_REG_L18CTRL,
+ S2MPS11_REG_L19CTRL,
+ S2MPS11_REG_L20CTRL,
+ S2MPS11_REG_L21CTRL,
+ S2MPS11_REG_L22CTRL,
+ S2MPS11_REG_L23CTRL,
+ S2MPS11_REG_L24CTRL,
+ S2MPS11_REG_L25CTRL,
+ S2MPS11_REG_L26CTRL,
+ S2MPS11_REG_L27CTRL,
+ S2MPS11_REG_L28CTRL,
+ S2MPS11_REG_L29CTRL,
+ S2MPS11_REG_L30CTRL,
+ S2MPS11_REG_L31CTRL,
+ S2MPS11_REG_L32CTRL,
+ S2MPS11_REG_L33CTRL,
+ S2MPS11_REG_L34CTRL,
+ S2MPS11_REG_L35CTRL,
+ S2MPS11_REG_L36CTRL,
+ S2MPS11_REG_L37CTRL,
+ S2MPS11_REG_L38CTRL,
+
+ S2MPS11_NUM_OF_REGS,
+};
+
+/* I2C device address for pmic S2MPS11 */
+#define S2MPS11_I2C_ADDR (0xCC >> 1)
+#define S2MPS11_BUS_NUM4
+
+/* Value to set voltage as 1V */
+#define S2MPS11_BUCK_CTRL2_1V 0x40
+/* Value to set voltage as 1.2V */
+#define S2MPS11_BUCK_CTRL2_1_2V0x60
+/* Value to set voltage as 1.2625V */
+#define S2MPS11_BUCK_CTRL2_1_2625V 0x6A
+
+/* Buck register addresses */
+#define S2MPS11_BUCK1_CTRL20x26
+#define S2MPS11_BUCK2_CTRL20x28
+#define S2MPS11_BUCK3_CTRL20x2a
+#define S2MPS11_BUCK4_CTRL20x2c
+#define S2MPS11_BUCK6_CTRL20x34
+#define S2MPS11_LDO22_CTRL 0x52
+
+#define S2MPS11_DEVICE_NAME "S2MPS11_PMIC"
+
+#define S2MPS11_RTC_CTRL_32KHZ_CP_EN (1 << 1)
+#define S2MPS11_RTC_CTRL_JIT (1 << 4)
+#endif /* __LINUX_MFD_S2MPS11_H */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/6] power: Explicitly select pmic device's bus
The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.
Signed-off-by: Aaron Durbin
Signed-off-by: Simon Glass
Signed-off-by: Leela Krishna Amudala
Reviewed-by: Doug Anderson
Acked-by: Simon Glass
---
drivers/power/power_i2c.c | 62 +
1 file changed, 57 insertions(+), 5 deletions(-)
diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index ac76870..3cafa4d 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -16,9 +16,45 @@
#include
#include
+static int pmic_select(struct pmic *p)
+{
+ int ret, old_bus;
+
+ old_bus = i2c_get_bus_num();
+ if (old_bus != p->bus) {
+ debug("%s: Select bus %d\n", __func__, p->bus);
+ ret = i2c_set_bus_num(p->bus);
+ if (ret) {
+ debug("%s: Cannot select pmic %s, err %d\n",
+ __func__, p->name, ret);
+ return -1;
+ }
+ }
+
+ return old_bus;
+}
+
+static int pmic_deselect(int old_bus)
+{
+ int ret;
+
+ if (old_bus != i2c_get_bus_num()) {
+ ret = i2c_set_bus_num(old_bus);
+ debug("%s: Select bus %d\n", __func__, old_bus);
+ if (ret) {
+ debug("%s: Cannot restore i2c bus, err %d\n",
+ __func__, ret);
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
{
unsigned char buf[4] = { 0 };
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
@@ -52,23 +88,33 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
return -1;
}
- if (i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus < 0)
return -1;
- return 0;
+ ret = i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
+ pmic_deselect(old_bus);
+ return ret;
}
int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
{
unsigned char buf[4] = { 0 };
u32 ret_val = 0;
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
- if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus < 0)
return -1;
+ ret = i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
+ pmic_deselect(old_bus);
+ if (ret)
+ return ret;
+
switch (pmic_i2c_tx_num) {
case 3:
if (p->sensor_byte_order == PMIC_SENSOR_BYTE_ORDER_BIG)
@@ -98,9 +144,15 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
int pmic_probe(struct pmic *p)
{
- i2c_set_bus_num(p->bus);
+ int ret, old_bus;
+
+ old_bus = pmic_select(p);
+ if (old_bus < 0)
+ return -1;
debug("Bus: %d PMIC:%s probed!\n", p->bus, p->name);
- if (i2c_probe(pmic_i2c_addr)) {
+ ret = i2c_probe(pmic_i2c_addr);
+ pmic_deselect(old_bus);
+ if (ret) {
printf("Can't find PMIC:%s\n", p->name);
return -1;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 6/6] config: SMDK5420: Enable S2MPS11 pmic
configure S2MPS11 pmic on SMDK5420 Signed-off-by: Leela Krishna Amudala Acked-by: Simon Glass --- include/configs/smdk5420.h |4 1 file changed, 4 insertions(+) diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index 447f8e5..46aeec0 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -53,4 +53,8 @@ #define CONFIG_MAX_I2C_NUM 11 +#define CONFIG_POWER +#define CONFIG_POWER_I2C +#define CONFIG_POWER_S2MPS11 + #endif /* __CONFIG_5420_H */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-video/master
Hi Tom, here are LCD panel support patches for cm_t35 board and a fix for Raspberry Pi LCD driver. Please pull. Thanks! Anatolij The following changes since commit 649acfe149e8a534a17eab54004a51d69b5556ed: MPC824x: remove obsolete "PN62" board (2013-11-11 14:46:24 -0500) are available in the git repository at: git://git.denx.de/u-boot-video.git master for you to fetch changes up to 63c4f17b2f8017d22241522a48c765073b8791b0: cm_t35: use scf0403 driver (2013-11-12 10:12:07 +0100) Anatolij Gustschin (1): lcd: allow overriding lcd_get_size() Andre Heider (2): ARM: bcm2835: add missing mbox overscan response field video: bcm2835: respect the pitch value Nikita Kiryanov (6): spi: omap3: remove semicolon from #define spi: omap3: add support for more word lengths spi: define SPI_XFER_ONCE lcd: add DataImage SCF0403x LCD panel support omap3_dss: define DSS_ONOFF cm_t35: use scf0403 driver arch/arm/include/asm/arch-bcm2835/mbox.h |1 + arch/arm/include/asm/arch-omap3/dss.h|9 +- board/compulab/cm_t35/cm_t35.c | 12 ++ board/compulab/common/omap3_display.c| 46 - common/lcd.c | 10 +- drivers/spi/omap3_spi.c | 71 --- drivers/spi/omap3_spi.h |8 +- drivers/spi/spi.c| 13 ++ drivers/video/Makefile |1 + drivers/video/bcm2835.c | 11 ++ drivers/video/scf0403_lcd.c | 296 ++ include/configs/cm_t35.h |3 + include/scf0403_lcd.h| 11 ++ include/spi.h| 17 ++ 14 files changed, 475 insertions(+), 34 deletions(-) create mode 100644 drivers/video/scf0403_lcd.c create mode 100644 include/scf0403_lcd.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] udoo: Add SATA support on uDoo Board.
Hi Ottavio, On Mon, 2013-11-11 at 16:00 -0200, Otavio Salvador wrote: > Hello Giuseppe, > > On Mon, Nov 11, 2013 at 3:11 PM, Giuseppe Pagano > wrote: > > Adds SATA support on uDoo Board. > > Moves sata_setup function definition from nitrogen6x.c and udoo.c to >> arch/arm/imx-common/sata.c to avoid code duplication. > > > > Signed-off-by: Giuseppe Pagano > > Your patches should have the long description split in 80 cols; please > do the nitrogen code move in a separated patch so it is clear what you > did to include support for uDoo board. Ok I will split. Thanks Giuseppe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
Hi Tom, > On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: > >> Altera Cyclone 5 board is very different board (big, rectangular, >> expensive) than EBV Socrates (small, circular, cheap) board. Different >> parts are used there, too, but same configuration of u-boot works on >> both. Nevertheless, printing wrong name confuses users. >> >> Therefore this splits the configuration so that u-boot knows they are >> different. So far it is only used for correcting the puts, but there >> may be other uses in future. >> >> Signed-off-by: Pavel Machek > > Is there any way at run time to tell which board we are on? I'll try to find out, but currently I don't know of any way. Best wishes Detlev -- Man gelangt nicht dazu, gluecklich zu sein, aber man macht Feststellungen ueber die Gruende, die uns daran hindern es zu sein. -- Marcel Proust -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mx6: add structs for mmdc and ddr iomux registers
On Fri, 2013-11-08 at 16:42 -0700, Eric Nelson wrote:
> Hi Edward,
>
> On 11/08/2013 02:35 AM, Edward Lin wrote:
> > Signed-off-by: Edward Lin
> > ---
> > arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h | 167
> > +++
> > 1 file changed, 167 insertions(+)
> > create mode 100644 arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
> >
> > diff --git a/arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
> > b/arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
> > new file mode 100644
> > index 000..dd5e892
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
> > @@ -0,0 +1,167 @@
> > +/*
> > + * Copyright (C) 2013 TechNexion Inc.
> > + *
> > + * Author: Edward Lin
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +#ifndef __ASM_ARCH_MX6_DDR_REGS_H__
> > +#define __ASM_ARCH_MX6_DDR_REGS_H__
> > +
> > +#define MX6_MMDC_P0_BASE 0x021b
> > +#define MX6_MMDC_P1_BASE 0x021b4000
> > +
>
> These are already declared in
> arch/arm/include/asm/arch-mx6/imx-regs.h
>
Thanks for pointing that out, I agree.
> > +/* MMDC P0/P1 Registers */
> > +struct mmdc_p_regs {
> > + u32 mdctl;
> > + u32 mdpdc;
> > + u32 mdotc;
> > + u32 mdcfg0;
> > + u32 mdcfg1;
> > + u32 mdcfg2;
> > + u32 mdmisc;
> > + u32 mdscr;
> > + u32 mdref;
> > + u32 res1[2];
> > + u32 mdrwd;
> > + u32 mdor;
>
> Up to this point, this appears to be a mirror of
> struct esd_mmdc_regs from arch/arm/imx-common/cpu.c
>
The struct defined in cpu.c is for all imx cpus, including
imx5 and imx6. For this reason I would like to keep them
separate. Our struct is for imx6 only.
> > + u32 res2[3];
> > + u32 mdasp;
> > + u32 res3[240];
> > + u32 mapsr;
> > + u32 res4[254];
> > + u32 mpzqhwctrl;
> > + u32 res5[2];
> > + u32 mpwldectrl0;
> > + u32 mpwldectrl1;
> > + u32 res6;
> > + u32 mpodtctrl;
> > + u32 mprddqby0dl;
> > + u32 mprddqby1dl;
> > + u32 mprddqby2dl;
> > + u32 mprddqby3dl;
> > + u32 res7[4];
> > + u32 mpdgctrl0;
> > + u32 mpdgctrl1;
> > + u32 res8;
> > + u32 mprddlctl;
> > + u32 res9;
> > + u32 mpwrdlctl;
> > + u32 res10[25];
> > + u32 mpmur0;
> > +}__attribute__((packed, aligned(4)));
> > +
>
> I'm not sure where you're headed with these...
>
> It seems arbitrary to treat these as structures,
> and I'm guessing that you're going to want tables
> of values as is currently done in the DCD and
> declared in mx6q-ddr.h/mx6dl-ddr.h.
>
We been told by Stefano that use of structures is a strict rule.
> > +#define MX6Q_IOM_DDR_BASE 0x020e0500
> > +struct mx6q_iomux_ddr_regs {
> > + u32 res1[3];
> > + u32 dram_sdqs5;
> > + u32 dram_dqm5;
> > + u32 dram_dqm4;
> > + u32 dram_sdqs4;
> > + u32 dram_sdqs3;
> > + u32 dram_dqm3;
> > + u32 dram_sdqs2;
> > + u32 dram_dqm2;
> > + u32 res2[16];
> > + u32 dram_cas;
>
> ...
>
> Regards,
>
>
> Eric
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
Hi Michal, > On 11/11/2013 09:33 PM, Tom Rini wrote: >> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: >> >>> Altera Cyclone 5 board is very different board (big, rectangular, >>> expensive) than EBV Socrates (small, circular, cheap) board. Different >>> parts are used there, too, but same configuration of u-boot works on >>> both. Nevertheless, printing wrong name confuses users. >>> >>> Therefore this splits the configuration so that u-boot knows they are >>> different. So far it is only used for correcting the puts, but there >>> may be other uses in future. >>> >>> Signed-off-by: Pavel Machek >> >> Is there any way at run time to tell which board we are on? > > Why do you care about board name in general? We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names? Cheers Detlev -- A language that doesn't affect the way you think about programming, is not worth knowing. -- Alan Perlis, Epigrams on Programming -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] patman: add Commit-notes tag and section
Sometimes a commit should have notes enclosed with it rather
than withing the cover letter -- possibly even because there
is no cover letter. Add a 'Commit-notes' tag, similar to the
'Series-notes' one; lines between this tag and the next END
line are inserted in the patch right after the '---' commit
delimiter.
Signed-off-by: Albert ARIBAUD
---
Yes, I am writing this note through the very feature that
this patch intends to add. If you can read it just below the
commit delimiter line ('---') then the feature works.
Well, at least, it works in this very case. :)
Changes in v2:
- changed tag name from 'Series-commit-notes' to 'Commit-notes'
tools/patman/README | 2 +-
tools/patman/commit.py | 2 ++
tools/patman/patchstream.py | 43 ---
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/tools/patman/README b/tools/patman/README
index e6d3070..626dc86 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -227,7 +227,7 @@ TEST=...
Change-Id:
Review URL:
Reviewed-on:
-
+Commit-: (except Commit-notes)
Exercise for the reader: Try adding some tags to one of your current
patch series and see how the patches turn out.
diff --git a/tools/patman/commit.py b/tools/patman/commit.py
index 900cfb3..89cce7f 100644
--- a/tools/patman/commit.py
+++ b/tools/patman/commit.py
@@ -21,6 +21,7 @@ class Commit:
changes: Dict containing a list of changes (single line strings).
The dict is indexed by change version (an integer)
cc_list: List of people to aliases/emails to cc on this commit
+notes: List of lines in the commit (not series) notes
"""
def __init__(self, hash):
self.hash = hash
@@ -28,6 +29,7 @@ class Commit:
self.tags = []
self.changes = {}
self.cc_list = []
+self.notes = []
def AddChange(self, version, info):
"""Add a new change line to the change list for a version.
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index c204523..684204c 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -30,7 +30,10 @@ re_cover = re.compile('^Cover-letter:')
re_cover_cc = re.compile('^Cover-letter-cc: *(.*)')
# Patch series tag
-re_series = re.compile('^Series-([a-z-]*): *(.*)')
+re_series_tag = re.compile('^Series-([a-z-]*): *(.*)')
+
+# Commit series tag
+re_commit_tag = re.compile('^Commit-([a-z-]*): *(.*)')
# Commit tags that we want to collect and keep
re_tag = re.compile('^(Tested-by|Acked-by|Reviewed-by|Cc): (.*)')
@@ -90,6 +93,20 @@ class PatchStream:
if self.is_log:
self.series.AddTag(self.commit, line, name, value)
+def AddToCommit(self, line, name, value):
+"""Add a new Commit-xxx tag.
+
+When a Commit-xxx tag is detected, we come here to record it.
+
+Args:
+line: Source line containing tag (useful for debug/error messages)
+name: Tag name (part after 'Commit-')
+value: Tag value (part after 'Commit-xxx: ')
+"""
+if name == 'notes':
+self.in_section = 'commit-' + name
+self.skip_blank = False
+
def CloseCommit(self):
"""Save the current commit into our commit list, and reset our state"""
if self.commit and self.is_log:
@@ -138,7 +155,8 @@ class PatchStream:
line = line[4:]
# Handle state transition and skipping blank lines
-series_match = re_series.match(line)
+series_tag_match = re_series_tag.match(line)
+commit_tag_match = re_commit_tag.match(line)
commit_match = re_commit.match(line) if self.is_log else None
cover_cc_match = re_cover_cc.match(line)
tag_match = None
@@ -165,6 +183,9 @@ class PatchStream:
elif self.in_section == 'notes':
if self.is_log:
self.series.notes += self.section
+elif self.in_section == 'commit-notes':
+if self.is_log:
+self.commit.notes += self.section
else:
self.warn.append("Unknown section '%s'" % self.in_section)
self.in_section = None
@@ -178,7 +199,7 @@ class PatchStream:
self.commit.subject = line
# Detect the tags we want to remove, and skip blank lines
-elif re_remove.match(line):
+elif re_remove.match(line) and not commit_tag_match:
self.skip_blank = True
# TEST= should be the last thing in the commit, so remove
@@ -211,9 +232,9 @@ class PatchStream:
self.skip_blank = False
# Detect Series-xxx tags
-elif series_match:
-name = series_match.group(1)
-value = series_match.group(2)
+elif series_tag_match:
+name = series_tag_match.group(1)
+value = series_tag_match.group(2)
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
On 11/12/2013 10:56 AM, Detlev Zundel wrote: > Hi Michal, > >> On 11/11/2013 09:33 PM, Tom Rini wrote: >>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: >>> Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users. Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future. Signed-off-by: Pavel Machek >>> >>> Is there any way at run time to tell which board we are on? >> >> Why do you care about board name in general? > > We care for board names for a very long time in U-Boot and I'd like to > keep this. I actually expect a sensible board name on any platform that > I touch. The board name is an important extra information additional to > the SoC name. So the question is the other way round - since when do we > _not_ care about board names? There could be i2c memory on board where you can find out this information but that's problematic if it is empty or you want to use this i2c for something else. For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design (if user is smart enough board name is the part of hw design name). For zynq/socfpga sensible solution is probably to load this name for DTS. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] arm926ejs, at91: add common phy_reset function
add common phy reset code into a common function.
Signed-off-by: Heiko Schocher
Cc: Andreas Bießmann
Cc: Bo Shen
Cc: Jens Scharsig
Cc: Sergey Lapin
Cc: Stelian Pop
Cc: Albin Tonnerre
Cc: Eric Benard
Cc: Markus Hubig
---
Patch based on the spl patchset from Bo Shen (as I want to
collect this function in at91-common directory), see:
http://lists.denx.de/pipermail/u-boot/2013-November/166272.html
(reworked this against newest Kconfig Makefile changes ...
@Bo: Do you plan an update for this patchset for the Kconfig changes?
Maybe my change in arch/arm/cpu/at91-common/Makefile
could be done better... Do we have a common define for
all this variants?
---
arch/arm/cpu/Makefile | 1 +
arch/arm/cpu/at91-common/Makefile | 5 +++
arch/arm/cpu/at91-common/phy.c | 48 +
arch/arm/include/asm/arch-at91/at91_common.h| 1 +
board/BuS/vl_ma2sc/vl_ma2sc.c | 18 ++
board/afeb9260/afeb9260.c | 18 +-
board/atmel/at91sam9260ek/at91sam9260ek.c | 19 +-
board/atmel/at91sam9263ek/at91sam9263ek.c | 19 ++
board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 19 +-
board/bluewater/snapper9260/snapper9260.c | 16 +
board/calao/sbc35_a9g20/sbc35_a9g20.c | 19 +-
board/eukrea/cpu9260/cpu9260.c | 18 +-
board/taskit/stamp9g20/stamp9g20.c | 31 +---
spl/Makefile| 4 ---
14 files changed, 66 insertions(+), 170 deletions(-)
create mode 100644 arch/arm/cpu/at91-common/phy.c
diff --git a/arch/arm/cpu/Makefile b/arch/arm/cpu/Makefile
index fd0da53..886347d 100644
--- a/arch/arm/cpu/Makefile
+++ b/arch/arm/cpu/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_TEGRA) += $(SOC)-common/
obj-$(CONFIG_TEGRA) += tegra-common/
+obj-$(CONFIG_AT91FAMILY) += at91-common/
diff --git a/arch/arm/cpu/at91-common/Makefile
b/arch/arm/cpu/at91-common/Makefile
index 040b956..255c7b9 100644
--- a/arch/arm/cpu/at91-common/Makefile
+++ b/arch/arm/cpu/at91-common/Makefile
@@ -8,5 +8,10 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj-$(CONFIG_AT91SAM9260) += phy.o
+obj-$(CONFIG_AT91SAM9G20) += phy.o
+obj-$(CONFIG_AT91SAM9263) += phy.o
+obj-$(CONFIG_AT91SAM9XE) += phy.o
+obj-$(CONFIG_AT91SAM9M10G45) += phy.o
obj-$(CONFIG_SPL_BUILD) += mpddrc.o
obj-$(CONFIG_SPL_BUILD) += spl.o
diff --git a/arch/arm/cpu/at91-common/phy.c b/arch/arm/cpu/at91-common/phy.c
new file mode 100644
index 000..4706635
--- /dev/null
+++ b/arch/arm/cpu/at91-common/phy.c
@@ -0,0 +1,48 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop
+ * Lead Tech Design
+ *
+ * Copyright (C) 2013 DENX Software Engineering, h...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+void at91_phy_reset(void)
+{
+ unsigned long erstl;
+ unsigned long start = get_timer(0);
+ unsigned long timeout = 1000; /* 1000ms */
+ at91_rstc_t *rstc = (at91_rstc_t *)ATMEL_BASE_RSTC;
+
+ erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK;
+
+ /* Need to reset PHY -> 500ms reset */
+ writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(0x0D) |
+ AT91_RSTC_MR_URSTEN, &rstc->mr);
+
+ writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr);
+
+ /* Wait for end of hardware reset */
+ while (!(readl(&rstc->sr) & AT91_RSTC_SR_NRSTL)) {
+ /* avoid shutdown by watchdog */
+ WATCHDOG_RESET();
+ mdelay(10);
+
+ /* timeout for not getting stuck in an endless loop */
+ if (get_timer(start) >= timeout) {
+ puts("*** ERROR: Timeout waiting for PHY reset!\n");
+ break;
+ }
+ };
+
+ /* Restore NRST value */
+ writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN, &rstc->mr);
+}
diff --git a/arch/arm/include/asm/arch-at91/at91_common.h
b/arch/arm/include/asm/arch-at91/at91_common.h
index 3ca4d5b..59e2f43 100644
--- a/arch/arm/include/asm/arch-at91/at91_common.h
+++ b/arch/arm/include/asm/arch-at91/at91_common.h
@@ -26,5 +26,6 @@ void at91_plla_init(u32 pllar);
void at91_mck_init(u32 mckr);
void at91_pmc_init(void);
void mem_init(void);
+void at91_phy_reset(void);
#endif /* AT91_COMMON_H */
diff --git a/board/BuS/vl_ma2sc/vl_ma2sc.c b/board/BuS/vl_ma2sc/vl_ma2sc.c
index e2ae6fd..412ff3b 100644
--- a/board/BuS/vl_ma2sc/vl_ma2sc.c
+++ b/board/BuS/vl_ma2sc/vl_ma2sc.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -76,25 +75,12 @@ static void vl_ma2sc_nand_hw_init(void)
#ifdef CONFIG_MACB
static void vl_ma2sc_macb_hw_init(void)
{
- unsigned long erstl;
at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
- at91_rstc_t *rstc = (at91_rstc_t *) ATMEL_BASE_RSTC;
+
/* Ena
Re: [U-Boot] u-boot gerrit server
Hi Vadim, On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) wrote: > For the purposes of this demo the patches submitted for review were > generated by a script I wrote. The script scrapes > http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches > from there and tries applying them. Not all patches apply cleanly (as > some of them are for branches). How do we intend to handle this? Will we move to a single repository, with each patch getting reviewers assigned based on which parts of the code it touches? Or move from repos to branches, one per current custodian repo? Or something else yet? > If the patch applies cleanly, the script adds two stanzas to the patch > > - Change-Id: generated by git > - Patch-At: a reference to the patchwork page where the patch was > downloaded from 'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'? > and uploads the patch for review as the user named 'Gerrit Tester'. > Each upload creates a new git branch just for review purposes. (I'm skipping the gerrit workflow description here as I have used gerrit extensively in my, ahem, previous job) I'm fine with using gerrit and yes, it can be a useful tool, not only regarding review, but also for learning the whys and hows of code changes through the comments from both reviewers and submitters (and I am in strong favor of a policy that every reviewer comment must be addressed by a supmitter reply, even the default will-do one. One drawback though: I cannot seem to be able to use my U-Boot mail address, even though it is a secondary address of my G+ account; gerrit only wants to see my gmail address. I sure hope that I am not required to use a gmail address to identify myself as the author of my own patches within the U-Boot project. > --vb Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
Thank you Eric,
this is a comment to your comments. See inline.
< long snip >
> >> +The header files mx6q_pins.h and mx6dls_pins consolidate
> >> +the settings through a macro providing a common name
> >> +of SD3_DAT2__USDHC3_DAT2:
> >> +
> >> + MX6_PAD_DECL(SD3_DAT2__USDHC3_DAT2,...)
> >> +
> >> +By using the MX6_PAD_DECL macro, this can be expanded
> >> +in one of three ways, depending on the declarations of
> >> +CONFIG_MX6x by a board file. Valid options are:
> >> +
> >> + MX6Q- single architecture for i.MX6DQ
> >> + MX6DL - single architecture for i.MX6DL/S
> >> + MX6QDL - multi-architecture
> >> +
> >> +In the first two cases, the MX6_PAD_DECL macro will
> >> +be expanded into a declararation with the MX6_PAD_
> >> +prefix:
> >> + MX6_PAD_name = IOMUX_PAD(...)
> >> +
> >> +In the last case, the MX6_PAD_DECL macro will be
> >> +expanded into two sets of declarations, with the
> >> +prefix MX6Q_PAD_ for the i.MX6DQ pads and the
> >> +prefix MX6DL_PAD_ for the i.MX6DLS pads.
> >> +
> >> +This is accomplished by the header file mx6-pins.h:
> >> +
> >> + #ifdef CONFIG_MX6QDL
> >> + enum {
> >> + #define MX6_PAD_DECL ...
> >> + #include "mx6q_pins.h"
> >> +
> >> + #define MX6_PAD_DECL ...
> >> + #include "mx6dl_pins.h"
> >> + };
> >> + #elif defined(CONFIG_MX6Q)
> >> + enum {
> >> + #define MX6_PAD_DECL ...
> >> + #include "mx6q_pins.h"
> >> + };
> >> + #elif defined(CONFIG_MX6DL)
> >> + enum {
> >> + #define MX6_PAD_DECL ...
> >> + #include "mx6dl_pins.h"
> >> + };
> >> + #endif
> >> +
Actually, it occurred to me yesterday that this kludge maybe solves the
drawback
of our method. Having this we can use our way to setup the pinmuxing without
having duplicate MX6Q/MX6DL defines at all!
More about that below.
> >
> > Opinion: This is a terrible macro kludge to begin with. However, I'm afraid
> > there
> > is no solutions completely free macro hacks, but maybe we can have less of
> > them?
> >
> Agreed, but I don't see a way around it.
>
> If we want to declare each pad once, we either need to always name them
> differently (i.e. MX6Q_PAD_padname and MX6DL_PAD_padname) or use a macro
> to translate the names.
>
> I think we're all in agreement that each use of a pad reference should
> be in a generic form (i.e. shouldn't specify MX6Q_ or MX6DL_) when the
> pad is independent of the model.
>
> We have this (single-name for a pad setting regardless of CPU variant)
> now for single-model builds (with no macro-fu) precisely because we
> named the pad declarations the same (without the Q or DL suffix).
>
And we have the same, precisely because we named them with suffices :-)
> If we try to switch to separate names (MX6Q_PAD/MX6DL_PAD), we have an
> immediate need to refactor all board files to replace the simple
> macro names to something else.
>
> The ~20 lines of code above provide a means of backward-compatibility.
>
> As I side benefit, I like being able to use word-selection to grab the
> entire generic pad reference such as SD2_DAT1__USHDC2_DAT1
> from this declaration:
>
> MX6_PAD_DECL(SD2_DAT1__USDHC2_DAT1,...)
>
> and paste it into the spot where it's used:
> MX6_PAD_DEF(SD2_DAT1__USDHC2_DAT1)
>
> (As opposed to having to hand-edit to remove the MX6Q_PAD_ prefix
> from one of the declarations)
>
> > Technical point: Could you clarify how this approach scales? There are still
> > new imx6 models to be released (imx6-next).
> >
>
> It's always tough to tell until we hash through the reference manuals.
>
Maybe you misunderstood me. We both know there are many more iMX6 CPUs
coming next year (and they are under NDA; but the public Freescale roadmap
confirms a imx6-next line, so we can safely say that stuff is coming).
My point was that the approach we take to make multi-variant code now
should be scalable to add additional variants in the future. Assuming the
new variants are compatible enough, but maybe requiring their own padconfs.
So we have families of cpus like (just an example): { iMX6Q, iMX6D },
{ iMX6S, iMX6DL }, { iMX6SL }, { iMX6x1, iMX6x2 }, { iMX6x3, iMX6x4 }, ...
We should be able to support multi-variant over as many families of cpus
as possible, without having another macro-fu nightmare when we need to
support another new CPU group.
My worry was that your approach could grow in complexity when a hypothetical
iMX6X cpu is to be supported.
> > Short sighted thinking caused the need for this mess to begin with, just
> > trying
> > to not do the same mistake again.
> >
< snip >
> >
> >> +4. IOMUX usage in board files
> >> +-
> >> +
< snip >
> >
> > We have suggested an alternative solution, but somehow nobody seem
> > to notice. We avoid almost all the preprocessor messing, and have the
> > definitions only once. And it would scale for even more cpu types.
> > Admittedly, the drawback is duplicate padconf macro definitio
Re: [U-Boot] u-boot gerrit server
Hello Vadim, On Tue, Nov 12, 2013 at 3:21 AM, Vadim Bendebury (вб) wrote: > Gentlemen, I have not forgotten our discussion regarding setting up a > sample gerrit server for u-boot during the ELCE mini-summit. Sorry > for this long and not very clear email, if there is any interest I > will be glad to answer questions and address concerns to the best of > my ability, and I am sure Simon (sjg@) will pitch in. I support the idea about using Gerrit. I've been using it a lot for O.S. Systems products and it works very well. Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there? I think just doing auto-assignment of patches would work quite well. -- 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] Question re HYP mode and IRQ/FIQ stack setting
(Cc:ing Andre and Christoffer as they have discussed HYP on the ML.) Hello, I am working on changing the way IRQ/FIQ stacks are set up, from "on-the-fly in a hurry while in the handler" to "during init, so that when entering the handler, the stack is already correct". Setting the stack then requires switching from the current mode (in most cases, SVC32, 0x13) to IRQ (0x11) or FIQ (0x12) mode, in order to set the right banked SP, then back into the original mode. However, in the first lines of reset in arch/arm/cpu/armv7/start.S, the possibility of U-Boot being started in HYP mode (0x1A) is considered and, if in HYP mode, no switch to SVC32 is performed. I understand that the problem here is, if we drop from HYP to SVC32, then we cannot go back to HYP, and we want to be able to remain in HYP. Does this also apply to dropping from HYP to IRQ or FIQ mode, i.e., if we do such a drop, are we prevented from rising back from IRQ or FIQ mode to HYP? I seem to remember such an issue, but I am no specialist in HYP, so any help is welcome. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/7] exynos_fb: Remove usage of static defines
Previously, we used to statically assign values for vl_col, vl_row and
vl_bpix using #defines like LCD_XRES, LCD_YRES and LCD_COLOR16.
Introducing the function exynos_lcd_early_init() would take care of this
assignment on the fly by parsing FIMD DT properties, thereby allowing us
to remove LCD_XRES and LCD_YRES from the main config file.
Signed-off-by: Ajay Kumar
---
arch/arm/include/asm/arch-exynos/system.h | 1 +
board/samsung/common/board.c | 15 +++
drivers/video/exynos_fb.c | 20 ++--
include/configs/exynos5250-dt.h | 2 --
4 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/system.h
b/arch/arm/include/asm/arch-exynos/system.h
index 7e2057c..4968d3d 100644
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -39,5 +39,6 @@ struct exynos5_sysreg {
void set_usbhost_mode(unsigned int mode);
void set_system_display_ctrl(void);
+int exynos_lcd_early_init(const void *blob);
#endif /* _EXYNOS4_SYSTEM_H */
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index cc83724..2536457 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -135,6 +136,20 @@ int board_early_init_f(void)
#ifdef CONFIG_SYS_I2C_INIT_BOARD
board_i2c_init(gd->fdt_blob);
#endif
+
+#if defined(CONFIG_OF_CONTROL) && defined(CONFIG_EXYNOS_FB)
+/*
+ * board_init_f(arch/arm/lib/board.c) calls lcd_setmem() which needs
+ * panel_info.vl_col, panel_info.vl_row and panel_info.vl_bpix, to reserve
+ * FB memory at a very early stage. So, we need to fill panel_info.vl_col,
+ * panel_info.vl_row and panel_info.vl_bpix before lcd_setmem() is called.
+ */
+ err = exynos_lcd_early_init(gd->fdt_blob);
+ if (err) {
+ debug("LCD early init failed\n");
+ return err;
+ }
+#endif
return err;
}
#endif
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 7d4c6e0..69899a1 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -27,17 +27,12 @@ DECLARE_GLOBAL_DATA_PTR;
static unsigned int panel_width, panel_height;
-/*
- * board_init_f(arch/arm/lib/board.c) calls lcd_setmem() which needs
- * panel_info.vl_col, panel_info.vl_row and panel_info.vl_bpix to reserve
- * FB memory at a very early stage, i.e even before exynos_fimd_parse_dt()
- * is called. So, we are forced to statically assign it.
- */
#ifdef CONFIG_OF_CONTROL
vidinfo_t panel_info = {
- .vl_col = LCD_XRES,
- .vl_row = LCD_YRES,
- .vl_bpix = LCD_COLOR16,
+ /* Insert a value here so that we don't end up in the BSS
+* Reference: drivers/video/tegra.c
+*/
+ .vl_col = -1,
};
#endif
@@ -159,7 +154,7 @@ static void lcd_panel_on(vidinfo_t *vid)
}
#ifdef CONFIG_OF_CONTROL
-int exynos_fimd_parse_dt(const void *blob)
+int exynos_lcd_early_init(const void *blob)
{
unsigned int node;
node = fdtdec_next_compatible(blob, 0, COMPAT_SAMSUNG_EXYNOS_FIMD);
@@ -303,10 +298,7 @@ void lcd_ctrl_init(void *lcdbase)
set_system_display_ctrl();
set_lcd_clk();
-#ifdef CONFIG_OF_CONTROL
- if (exynos_fimd_parse_dt(gd->fdt_blob))
- debug("Can't get proper panel info\n");
-#else
+#ifndef CONFIG_OF_CONTROL
/* initialize parameters which is specific to panel. */
init_panel_info(&panel_info);
#endif
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 689919d..508962c 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -50,8 +50,6 @@
#ifdef CONFIG_LCD
#define CONFIG_EXYNOS_FB
#define CONFIG_EXYNOS_DP
-#define LCD_XRES 2560
-#define LCD_YRES 1600
#define LCD_BPPLCD_COLOR16
#endif
#endif /* __CONFIG_5250_H */
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/7] arm: exynos: Add RPLL for Exynos5420
RPLL is needed to drive the LCD panel on Exynos5420 based boards.
Signed-off-by: Ajay Kumar
---
arch/arm/cpu/armv7/exynos/clock_init.h | 3 +++
arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 +
2 files changed, 16 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/clock_init.h
b/arch/arm/cpu/armv7/exynos/clock_init.h
index a875d0b..fce502f 100644
--- a/arch/arm/cpu/armv7/exynos/clock_init.h
+++ b/arch/arm/cpu/armv7/exynos/clock_init.h
@@ -75,6 +75,9 @@ struct mem_timings {
unsigned spll_mdiv;
unsigned spll_pdiv;
unsigned spll_sdiv;
+ unsigned rpll_mdiv;
+ unsigned rpll_pdiv;
+ unsigned rpll_sdiv;
unsigned pclk_cdrex_ratio;
unsigned direct_cmd_msr[MEM_TIMINGS_MSR_COUNT];
diff --git a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
index e7f1496..c91c4a1 100644
--- a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
+++ b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
@@ -179,6 +179,10 @@ struct mem_timings mem_timings[] = {
.spll_mdiv = 0xc8,
.spll_pdiv = 0x3,
.spll_sdiv = 0x2,
+ /* RPLL @266MHz */
+ .rpll_mdiv = 0x10A,
+ .rpll_pdiv = 0x3,
+ .rpll_sdiv = 0x3,
.direct_cmd_msr = {
0x00020018, 0x0003, 0x00010046, 0x0d70,
@@ -800,6 +804,7 @@ static void exynos5420_system_clock_init(void)
writel(mem->ipll_pdiv * PLL_LOCK_FACTOR, &clk->ipll_lock);
writel(mem->spll_pdiv * PLL_LOCK_FACTOR, &clk->spll_lock);
writel(mem->kpll_pdiv * PLL_LOCK_FACTOR, &clk->kpll_lock);
+ writel(mem->rpll_pdiv * PLL_X_LOCK_FACTOR, &clk->rpll_lock);
setbits_le32(&clk->src_cpu, MUX_HPM_SEL_MASK);
@@ -898,6 +903,14 @@ static void exynos5420_system_clock_init(void)
while ((readl(&clk->spll_con0) & PLL_LOCKED) == 0)
;
+ /* Set RPLL */
+ writel(RPLL_CON2_VAL, &clk->rpll_con2);
+ writel(RPLL_CON1_VAL, &clk->rpll_con1);
+ val = set_pll(mem->rpll_mdiv, mem->rpll_pdiv, mem->rpll_sdiv);
+ writel(val, &clk->rpll_con0);
+ while ((readl(&clk->rpll_con0) & PLL_LOCKED) == 0)
+ ;
+
writel(CLK_DIV_CDREX0_VAL, &clk->div_cdrex0);
writel(CLK_DIV_CDREX1_VAL, &clk->div_cdrex1);
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/7] SMDK5420: Add support for FIMD and DP
This patchset adds support for FIMD and DP on SMDK5420. This patchset is rebased on Rajeshwari's latest SMDK5420 patchset: [PATCH 00/10 V6] EXYNOS5420: Add SMDK5420 board support http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/172653 For testing we need: Naveen's i2c patchset: i2c: improve s3c24x0 with High-speed and new SYS_I2C framework support http://www.mail-archive.com/u-boot@lists.denx.de/msg122679.html Leela's PMIC patchset: [PATCH V3 0/6] SMDK5420: Add S2MPS11 pmic support to SMDK5420 http://www.mail-archive.com/u-boot@lists.denx.de/msg125733.html Changes since V1: [PATCH V2 4/7] - Read FIMD sysmmu addresses from DT instead of hardcoding them. [PATCH V2 5/7] - Remove hardcoded i2c setting for enabling VDD_28IO_DP [PATCH V2 6/7] - Enable VDD_28IO_DP in standard PMIC way Ajay Kumar (7): [PATCH V2 1/7] exynos_fb: Remove usage of static defines [PATCH V2 2/7] arm: exynos: Add RPLL for Exynos5420 [PATCH V2 3/7] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 [PATCH V2 4/7] video: exynos_fimd: Add framework to disable FIMD sysmmu [PATCH V2 5/7] smdk5420: Implement callbacks needed by exynos_fb driver [PATCH V2 6/7] exynos: s2mps11_pmic: Enable LDO38 for SMDK5420 [PATCH V2 7/7] CONFIG: SMDK5420: Enable FIMD and DP arch/arm/cpu/armv7/exynos/clock.c | 74 +- arch/arm/cpu/armv7/exynos/clock_init.h | 3 + arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 arch/arm/cpu/armv7/exynos/exynos5_setup.h | 2 +- arch/arm/dts/exynos5420.dtsi | 7 ++ arch/arm/include/asm/arch-exynos/clk.h | 1 + arch/arm/include/asm/arch-exynos/system.h | 1 + board/samsung/common/board.c | 18 + board/samsung/smdk5420/smdk5420.c | 102 + doc/device-tree-bindings/video/exynos-fb.txt | 4 + drivers/video/exynos_fb.c | 20 ++--- drivers/video/exynos_fimd.c| 24 ++ include/configs/exynos5250-dt.h| 2 - include/configs/smdk5420.h | 8 ++ include/power/s2mps11_pmic.h | 3 + 15 files changed, 177 insertions(+), 105 deletions(-) -- 1.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/7] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420
Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 needed by
exynos video driver.
Also, configure ACLK_400_DISP1 as the parent for MUX_ACLK_400_DISP1_SUB_SEL.
Signed-off-by: Ajay Kumar
---
arch/arm/cpu/armv7/exynos/clock.c | 74 +--
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 2 +-
arch/arm/include/asm/arch-exynos/clk.h| 1 +
3 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index b52e61a..60ca7ea 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -82,7 +82,8 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r,
unsigned int k)
* VPLL_CON: MIDV [24:16]
* BPLL_CON: MIDV [25:16]: Exynos5
*/
- if (pllreg == APLL || pllreg == MPLL || pllreg == BPLL)
+ if (pllreg == APLL || pllreg == MPLL ||
+ pllreg == BPLL || pllreg == SPLL)
mask = 0x3ff;
else
mask = 0x1ff;
@@ -391,6 +392,9 @@ static unsigned long exynos5420_get_pll_clk(int pllreg)
r = readl(&clk->rpll_con0);
k = readl(&clk->rpll_con1);
break;
+ case SPLL:
+ r = readl(&clk->spll_con0);
+ break;
default:
printf("Unsupported PLL (%d)\n", pllreg);
return 0;
@@ -1038,6 +1042,40 @@ static unsigned long exynos5_get_lcd_clk(void)
return pclk;
}
+static unsigned long exynos5420_get_lcd_clk(void)
+{
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+ unsigned long pclk, sclk;
+ unsigned int sel;
+ unsigned int ratio;
+
+ /*
+* CLK_SRC_DISP10
+* FIMD1_SEL [4]
+* 0: SCLK_RPLL
+* 1: SCLK_SPLL
+*/
+ sel = readl(&clk->src_disp10);
+ sel &= (1 << 4);
+
+ if (sel)
+ sclk = get_pll_clk(SPLL);
+ else
+ sclk = get_pll_clk(RPLL);
+
+ /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+ ratio = readl(&clk->div_disp10);
+ ratio = ratio & 0xf;
+
+ pclk = sclk / (ratio + 1);
+
+ return pclk;
+}
+
void exynos4_set_lcd_clk(void)
{
struct exynos4_clock *clk =
@@ -1162,6 +1200,33 @@ void exynos5_set_lcd_clk(void)
writel(cfg, &clk->div_disp1_0);
}
+void exynos5420_set_lcd_clk(void)
+{
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+ unsigned int cfg;
+
+ /*
+* CLK_SRC_DISP10
+* FIMD1_SEL [4]
+* 0: SCLK_RPLL
+* 1: SCLK_SPLL
+*/
+ cfg = readl(&clk->src_disp10);
+ cfg &= ~(0x1 << 4);
+ cfg |= (0 << 4);
+ writel(cfg, &clk->src_disp10);
+
+ /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+ cfg = readl(&clk->div_disp10);
+ cfg &= ~(0xf << 0);
+ cfg |= (0 << 0);
+ writel(cfg, &clk->div_disp10);
+}
+
void exynos4_set_mipi_clk(void)
{
struct exynos4_clock *clk =
@@ -1657,14 +1722,17 @@ unsigned long get_lcd_clk(void)
{
if (cpu_is_exynos4())
return exynos4_get_lcd_clk();
- else
- return exynos5_get_lcd_clk();
+ else if (proid_is_exynos5420())
+ return exynos5420_get_lcd_clk();
+ return exynos5_get_lcd_clk();
}
void set_lcd_clk(void)
{
if (cpu_is_exynos4())
exynos4_set_lcd_clk();
+ else if (proid_is_exynos5420())
+ exynos5420_set_lcd_clk();
else
exynos5_set_lcd_clk();
}
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index 8e05a00..70b1c04 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -780,7 +780,7 @@
#define CLK_SRC_TOP2_VAL 0x11101000
#define CLK_SRC_TOP3_VAL 0x
#define CLK_SRC_TOP4_VAL 0x0111
-#define CLK_SRC_TOP5_VAL 0x1100
+#define CLK_SRC_TOP5_VAL 0x1101
#define CLK_SRC_TOP6_VAL 0x0111
#define CLK_SRC_TOP7_VAL 0x00022200
diff --git a/arch/arm/include/asm/arch-exynos/clk.h
b/arch/arm/include/asm/arch-exynos/clk.h
index cdeef32..98faae7 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -15,6 +15,7 @@
#define VPLL 4
#define BPLL 5
#define RPLL 6
+#define SPLL 7
enum pll_src_bit {
EXYNOS_SRC_MPLL = 6,
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 7/7] CONFIG: SMDK5420: Enable FIMD and DP
Enable FIMD and DP drivers on SMDK5420 so that we get to see the LCD console on eDP panel. Signed-off-by: Ajay Kumar --- include/configs/smdk5420.h | 8 1 file changed, 8 insertions(+) diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index 46aeec0..d3fa49b 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -57,4 +57,12 @@ #define CONFIG_POWER_I2C #define CONFIG_POWER_S2MPS11 +/* Display */ +#define CONFIG_LCD +#ifdef CONFIG_LCD +#define CONFIG_EXYNOS_FB +#define CONFIG_EXYNOS_DP +#define LCD_BPPLCD_COLOR16 +#endif + #endif /* __CONFIG_5420_H */ -- 1.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 4/7] video: exynos_fimd: Add framework to disable FIMD sysmmu
On Exynos5420 and newer versions, the FIMD sysmmus are in
"on state" by default.
We have to disable them in order to make FIMD DMA work.
This patch adds the required framework to exynos_fimd driver,
and disables FIMD sysmmu on Exynos5420.
Signed-off-by: Ajay Kumar
---
arch/arm/dts/exynos5420.dtsi | 7 +++
doc/device-tree-bindings/video/exynos-fb.txt | 4
drivers/video/exynos_fimd.c | 24
3 files changed, 35 insertions(+)
diff --git a/arch/arm/dts/exynos5420.dtsi b/arch/arm/dts/exynos5420.dtsi
index ca6c605..7443953 100644
--- a/arch/arm/dts/exynos5420.dtsi
+++ b/arch/arm/dts/exynos5420.dtsi
@@ -71,4 +71,11 @@
reg = <0x12E2 0x100>;
interrupts = <0 203 0>;
};
+
+ fimd@1440 {
+ /* sysmmu is not used in U-Boot */
+ samsung,disable-sysmmu;
+ samsung,sysmmu-fimdm0 = <0x1464>;
+ samsung,sysmmu-fimdm1 = <0x1468>;
+ };
};
diff --git a/doc/device-tree-bindings/video/exynos-fb.txt
b/doc/device-tree-bindings/video/exynos-fb.txt
index bb7441c..9ba2c47 100644
--- a/doc/device-tree-bindings/video/exynos-fb.txt
+++ b/doc/device-tree-bindings/video/exynos-fb.txt
@@ -55,6 +55,10 @@ Board(panel specific):
samsung,pclk-name: parent clock identifier: 1(MPLL), 2(EPLL), 3(VPLL)
samsung,sclk-div: parent_clock/source_clock ratio
samsung,dual-lcd-enabled: 1 if you support two LCD, else 0
+ samsung,disable-sysmmu: present if you want to disable the sysmmu
+ (needed for Exynos5420 and newer versions)
+ samsung,sysmmu-fimdm0: Address of sysmmufimdm0 MMU_CTRL
+ samsung,sysmmu-fimdm1: Address of sysmmufimdm1 MMU_CTRL
Example:
SOC specific part:
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index f962c4f..bffc8fa 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -257,6 +257,7 @@ void exynos_fimd_lcd_init(vidinfo_t *vid)
unsigned int offset;
#ifdef CONFIG_OF_CONTROL
unsigned int node;
+ u32 *sysmmufimdm0, *sysmmufimdm1;
node = fdtdec_next_compatible(gd->fdt_blob,
0, COMPAT_SAMSUNG_EXYNOS_FIMD);
@@ -267,6 +268,29 @@ void exynos_fimd_lcd_init(vidinfo_t *vid)
node, "reg");
if (fimd_ctrl == NULL)
debug("Can't get the FIMD base address\n");
+
+ if (fdtdec_get_bool(gd->fdt_blob, node, "samsung,disable-sysmmu")) {
+ /*
+ * The reset value for FIMD SYSMMU register MMU_CTRL is 3
+ * on Exynos5420 and newer versions.
+ * This means FIMD SYSMMU is on by default on Exynos5420
+ * and newer versions.
+ * Since in u-boot we don't use SYSMMU, we should disable
+ * those FIMD SYSMMU.
+ */
+ sysmmufimdm0 = (u32 *)fdtdec_get_int(gd->fdt_blob, node,
+ "samsung,sysmmu-fimdm0", 0);
+ if (!sysmmufimdm0)
+ debug("Can't get sysmmufimdm0");
+
+ sysmmufimdm1 = (u32 *)fdtdec_get_int(gd->fdt_blob, node,
+ "samsung,sysmmu-fimdm1", 0);
+ if (!sysmmufimdm1)
+ debug("Can't get sysmmufimdm1");
+
+ writel(0x0, sysmmufimdm0);
+ writel(0x0, sysmmufimdm1);
+ }
#else
fimd_ctrl = (struct exynos_fb *)samsung_get_base_fimd();
#endif
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 5/7] smdk5420: Implement callbacks needed by exynos_fb driver
Add callbacks to set up DP-HPD, backlight and LCD power
on SMDK5420.
Signed-off-by: Ajay Kumar
---
board/samsung/smdk5420/smdk5420.c | 102 +++---
1 file changed, 17 insertions(+), 85 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/smdk5420/smdk5420.c
index d85b953..75b22cc 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -43,98 +43,30 @@ int exynos_init(void)
}
#ifdef CONFIG_LCD
-void cfg_lcd_gpio(void)
+void exynos_cfg_lcd_gpio(void)
{
- struct exynos5_gpio_part1 *gpio1 =
- (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
-
- /* For Backlight */
- s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
- s5p_gpio_set_value(&gpio1->b2, 0, 1);
-
- /* LCD power on */
- s5p_gpio_cfg_pin(&gpio1->x1, 5, GPIO_OUTPUT);
- s5p_gpio_set_value(&gpio1->x1, 5, 1);
+ struct exynos5420_gpio_part2 *gpio2 =
+ (struct exynos5420_gpio_part2 *)samsung_get_base_gpio_part2();
/* Set Hotplug detect for DP */
- s5p_gpio_cfg_pin(&gpio1->x0, 7, GPIO_FUNC(0x3));
+ s5p_gpio_cfg_pin(&gpio2->x0, 7, GPIO_FUNC(0x3));
}
-vidinfo_t panel_info = {
- .vl_freq= 60,
- .vl_col = 2560,
- .vl_row = 1600,
- .vl_width = 2560,
- .vl_height = 1600,
- .vl_clkp= CONFIG_SYS_LOW,
- .vl_hsp = CONFIG_SYS_LOW,
- .vl_vsp = CONFIG_SYS_LOW,
- .vl_dp = CONFIG_SYS_LOW,
- .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
-
- /* wDP panel timing infomation */
- .vl_hspw= 32,
- .vl_hbpd= 80,
- .vl_hfpd= 48,
-
- .vl_vspw= 6,
- .vl_vbpd= 37,
- .vl_vfpd= 3,
- .vl_cmd_allow_len = 0xf,
-
- .win_id = 3,
- .cfg_gpio = cfg_lcd_gpio,
- .backlight_on = NULL,
- .lcd_power_on = NULL,
- .reset_lcd = NULL,
- .dual_lcd_enabled = 0,
-
- .init_delay = 0,
- .power_on_delay = 0,
- .reset_delay= 0,
- .interface_mode = FIMD_RGB_INTERFACE,
- .dp_enabled = 1,
-};
-
-static struct edp_device_info edp_info = {
- .disp_info = {
- .h_res = 2560,
- .h_sync_width = 32,
- .h_back_porch = 80,
- .h_front_porch = 48,
- .v_res = 1600,
- .v_sync_width = 6,
- .v_back_porch = 37,
- .v_front_porch = 3,
- .v_sync_rate = 60,
- },
- .lt_info = {
- .lt_status = DP_LT_NONE,
- },
- .video_info = {
- .master_mode = 0,
- .bist_mode = DP_DISABLE,
- .bist_pattern = NO_PATTERN,
- .h_sync_polarity = 0,
- .v_sync_polarity = 0,
- .interlaced = 0,
- .color_space = COLOR_RGB,
- .dynamic_range = VESA,
- .ycbcr_coeff = COLOR_YCBCR601,
- .color_depth = COLOR_8,
- },
-};
-
-static struct exynos_dp_platform_data dp_platform_data = {
- .phy_enable = set_dp_phy_ctrl,
- .edp_dev_info = &edp_info,
-};
-
-void init_panel_info(vidinfo_t *vid)
+void exynos_backlight_on(unsigned int onoff)
{
- vid->rgb_mode = MODE_RGB_P,
+ struct exynos5420_gpio_part1 *gpio1 =
+ (struct exynos5420_gpio_part1 *)samsung_get_base_gpio_part1();
+
+ struct exynos5420_gpio_part2 *gpio2 =
+ (struct exynos5420_gpio_part2 *)samsung_get_base_gpio_part2();
+
+ /* For PWM */
+ s5p_gpio_cfg_pin(&gpio1->b2, 0, GPIO_OUTPUT);
+ s5p_gpio_set_value(&gpio1->b2, 0, 1);
- exynos_set_dp_platform_data(&dp_platform_data);
+ /* BL_EN */
+ s5p_gpio_cfg_pin(&gpio2->x1, 5, GPIO_OUTPUT);
+ s5p_gpio_set_value(&gpio2->x1, 5, 1);
}
#endif
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 6/7] exynos: s2mps11_pmic: Enable LDO38 for SMDK5420
Enabling VDD_28IO_DP via LDO38 for SMDK5420.
Signed-off-by: Ajay Kumar
---
board/samsung/common/board.c | 3 +++
include/power/s2mps11_pmic.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 2536457..224f83d 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -180,6 +180,9 @@ int board_init_s2mps11(void)
{PMIC_REG_WRITE, S2MPS11_BUCK3_CTRL2, S2MPS11_BUCK_CTRL2_1V},
{PMIC_REG_WRITE, S2MPS11_BUCK4_CTRL2, S2MPS11_BUCK_CTRL2_1V},
{PMIC_REG_WRITE, S2MPS11_BUCK6_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+#ifdef CONFIG_SMDK5420
+ {PMIC_REG_WRITE, S2MPS11_LDO38_CTRL, S2MPS11_LDO_CTRL_2_8V},
+#endif
{PMIC_REG_UPDATE, S2MPS11_REG_RTC_CTRL,
S2MPS11_RTC_CTRL_32KHZ_CP_EN | S2MPS11_RTC_CTRL_JIT},
{PMIC_REG_BAIL}
diff --git a/include/power/s2mps11_pmic.h b/include/power/s2mps11_pmic.h
index 20c781d..8c6bf4b 100644
--- a/include/power/s2mps11_pmic.h
+++ b/include/power/s2mps11_pmic.h
@@ -125,6 +125,8 @@ enum s2mps11_reg {
#define S2MPS11_BUCK_CTRL2_1_2V0x60
/* Value to set voltage as 1.2625V */
#define S2MPS11_BUCK_CTRL2_1_2625V 0x6A
+/* Value to set voltage as 2.8V */
+#define S2MPS11_LDO_CTRL_2_8V 0x78
/* Buck register addresses */
#define S2MPS11_BUCK1_CTRL20x26
@@ -133,6 +135,7 @@ enum s2mps11_reg {
#define S2MPS11_BUCK4_CTRL20x2c
#define S2MPS11_BUCK6_CTRL20x34
#define S2MPS11_LDO22_CTRL 0x52
+#define S2MPS11_LDO38_CTRL 0x62
#define S2MPS11_DEVICE_NAME "S2MPS11_PMIC"
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] arm, omap3: Add support for TechNexion modules
From: Tapani Utriainen
Add support for TechNexion TAO3530 SoM
This patch has been posted quite a long time ago. I ported it to
the latest mainline U-Boot version. With some additional cleanup
and enhancements.
Signed-off-by: Tapani Utriainen
CC: Sandeep Paulraj
Signed-off-by: Stefan Roese
Cc: Thorsten Eisbein
Cc: Tom Rini
---
arch/arm/include/asm/mach-types.h | 1 +
board/technexion/tao3530/Makefile | 5 +
board/technexion/tao3530/tao3530.c | 170 +
board/technexion/tao3530/tao3530.h | 364 +
boards.cfg | 1 +
include/configs/tao3530.h | 310 +++
6 files changed, 851 insertions(+)
create mode 100644 board/technexion/tao3530/Makefile
create mode 100644 board/technexion/tao3530/tao3530.c
create mode 100644 board/technexion/tao3530/tao3530.h
create mode 100644 include/configs/tao3530.h
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 440b041..cb7604a 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -470,6 +470,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_EUKREA_CPUIMX35SD2821
#define MACH_TYPE_EUKREA_CPUIMX51SD2822
#define MACH_TYPE_EUKREA_CPUIMX51 2823
+#define MACH_TYPE_OMAP3_TAO35302836
#define MACH_TYPE_SMDKC210 2838
#define MACH_TYPE_OMAP3_BRAILLO2839
#define MACH_TYPE_SPYPLUG 2840
diff --git a/board/technexion/tao3530/Makefile
b/board/technexion/tao3530/Makefile
new file mode 100644
index 000..2aff383
--- /dev/null
+++ b/board/technexion/tao3530/Makefile
@@ -0,0 +1,5 @@
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := tao3530.o
diff --git a/board/technexion/tao3530/tao3530.c
b/board/technexion/tao3530/tao3530.c
new file mode 100644
index 000..9482f35
--- /dev/null
+++ b/board/technexion/tao3530/tao3530.c
@@ -0,0 +1,170 @@
+/*
+ * Maintainer :
+ * Tapani Utriainen
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "tao3530.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int tao3530_revision(void)
+{
+ int ret = 0;
+
+ /* char *label argument is unused in gpio_request() */
+ ret = gpio_request(65, "");
+ if (ret) {
+ printf("Error? GPIO 65 not available\n");
+ goto out;
+ }
+ MUX_VAL(CP(GPMC_WAIT3), (IEN | PTU | EN | M4));
+
+ ret = gpio_request(1, "");
+ if (ret) {
+ printf("Error? GPIO 1 not available\n");
+ goto out2;
+ }
+ MUX_VAL(CP(SYS_CLKREQ), (IEN | PTU | EN | M4));
+
+ ret = gpio_direction_input(65);
+ if (ret) {
+ printf("Error? GPIO 65 not available for input\n");
+ goto out3;
+ }
+
+ ret = gpio_direction_input(1);
+ if (ret) {
+ printf("Error? GPIO 1 not available for input\n");
+ goto out3;
+ }
+
+ ret = gpio_get_value(65) << 1 | gpio_get_value(1);
+
+out3:
+ MUX_VAL(CP(SYS_CLKREQ), (IEN | PTU | EN | M0));
+ gpio_free(1);
+out2:
+ MUX_VAL(CP(GPMC_WAIT3), (IEN | PTU | EN | M0));
+ gpio_free(65);
+out:
+
+ return ret;
+}
+
+/*
+ * Routine: board_init
+ * Description: Early hardware init.
+ */
+int board_init(void)
+{
+ gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
+ /* board id for Linux */
+ gd->bd->bi_arch_number = MACH_TYPE_OMAP3_TAO3530;
+ /* boot param addr */
+ gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+
+ return 0;
+}
+
+/*
+ * Routine: misc_init_r
+ * Description: Configure board specific parts
+ */
+int misc_init_r(void)
+{
+ struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
+ struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
+
+ twl4030_power_init();
+ twl4030_led_init(TWL4030_LED_LEDEN_LEDAON | TWL4030_LED_LEDEN_LEDBON);
+
+ /* Configure GPIOs to output */
+ /* GPIO23 */
+ writel(~(GPIO10 | GPIO8 | GPIO2 | GPIO1), &gpio6_base->oe);
+ writel(~(GPIO31 | GPIO30 | GPIO22 | GPIO21 |
+GPIO15 | GPIO14 | GPIO13 | GPIO12), &gpio5_base->oe);
+
+ /* Set GPIOs */
+ writel(GPIO10 | GPIO8 | GPIO2 | GPIO1,
+ &gpio6_base->setdataout);
+ writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
+ GPIO15 | GPIO14 | GPIO13 | GPIO12, &gpio5_base->setdataout);
+
+ dieid_num_r();
+
+ /* Set memory size environment variable, depending on revision */
+ switch (tao3530_revision()) {
+ case 0x2: /* Rev C1 -- 256MB */
+setenv("mem_size", "mem=256M");
+break;
+ case 0x3: /* Rev A2/B2 -- 128MB */
+setenv("mem_size", "mem=128M");
+bre
[U-Boot] [PATCH 2/5] arm: omap3: Add SPL support to tao3530
Add SPL support for the Technexion TAO3530 SOM to replace
x-loader. Tested with the Thunder baseboard. Currently this is
only tested with the TAO3530 SOM revision (Ax/Bx).
Tested by booting via MMC and NAND.
Signed-off-by: Stefan Roese
Cc: Tapani Utriainen
Cc: Thorsten Eisbein
Cc: Tom Rini
---
board/technexion/tao3530/tao3530.c | 27 +++-
include/configs/tao3530.h | 64 ++
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/board/technexion/tao3530/tao3530.c
b/board/technexion/tao3530/tao3530.c
index 9482f35..7cf5aa6 100644
--- a/board/technexion/tao3530/tao3530.c
+++ b/board/technexion/tao3530/tao3530.c
@@ -67,6 +67,31 @@ out:
return ret;
}
+#ifdef CONFIG_SPL_BUILD
+/*
+ * Routine: get_board_mem_timings
+ * Description: If we use SPL then there is no x-loader nor config header
+ * so we have to setup the DDR timings ourself on both banks.
+ */
+void get_board_mem_timings(struct board_sdrc_timings *timings)
+{
+ if (tao3530_revision() < 3) {
+ /* 256MB / Bank */
+ timings->mcfg = MCFG(256 << 20, 14);/* RAS-width 14 */
+ timings->ctrla = HYNIX_V_ACTIMA_165;
+ timings->ctrlb = HYNIX_V_ACTIMB_165;
+ } else {
+ /* 128MB / Bank */
+ timings->mcfg = MCFG(128 << 20, 13);/* RAS-width 13 */
+ timings->ctrla = MICRON_V_ACTIMA_165;
+ timings->ctrlb = MICRON_V_ACTIMB_165;
+ }
+
+ timings->mr = MICRON_V_MR_165;
+ timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
+}
+#endif
+
/*
* Routine: board_init
* Description: Early hardware init.
@@ -134,7 +159,7 @@ void set_muxconf_regs(void)
MUX_TAO3530();
}
-#ifdef CONFIG_GENERIC_MMC
+#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
int board_mmc_init(bd_t *bis)
{
omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/include/configs/tao3530.h b/include/configs/tao3530.h
index 6327161..03eb85e 100644
--- a/include/configs/tao3530.h
+++ b/include/configs/tao3530.h
@@ -5,6 +5,8 @@
* Edward Lin
* Tapani Utriainen
*
+ * Copyright (C) 2013 Stefan Roese
+ *
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -307,4 +309,66 @@
#define CONFIG_USB_STORAGE
#define CONGIG_CMD_STORAGE
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SPL_FRAMEWORK
+#define CONFIG_SPL_NAND_SIMPLE
+
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0x300 /* address
0x6 */
+#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */
+#define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1
+#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img"
+
+#define CONFIG_SPL_BOARD_INIT
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBDISK_SUPPORT
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_NAND_BASE
+#define CONFIG_SPL_NAND_DRIVERS
+#define CONFIG_SPL_NAND_ECC
+#define CONFIG_SPL_GPIO_SUPPORT
+#define CONFIG_SPL_POWER_SUPPORT
+#define CONFIG_SPL_OMAP3_ID_NAND
+#define CONFIG_SPL_LDSCRIPT"$(CPUDIR)/omap-common/u-boot-spl.lds"
+
+/* NAND boot config */
+#define CONFIG_SYS_NAND_5_ADDR_CYCLE
+#define CONFIG_SYS_NAND_PAGE_COUNT 64
+#define CONFIG_SYS_NAND_PAGE_SIZE 2048
+#define CONFIG_SYS_NAND_OOBSIZE64
+#define CONFIG_SYS_NAND_BLOCK_SIZE (128 * 1024)
+#define CONFIG_SYS_NAND_BAD_BLOCK_POS NAND_LARGE_BADBLOCK_POS
+/*
+ * Use the ECC/OOB layout from omap_gpmc.h that matches your chip:
+ * SP vs LP, 8bit vs 16bit: GPMC_NAND_HW_ECC_LAYOUT
+ */
+#define CONFIG_SYS_NAND_ECCPOS { 2, 3, 4, 5, 6, 7, 8, 9, \
+10, 11, 12, 13 }
+#define CONFIG_SYS_NAND_ECCSIZE512
+#define CONFIG_SYS_NAND_ECCBYTES 3
+
+#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_NAND_U_BOOT_OFFS0x8
+
+#define CONFIG_SPL_TEXT_BASE 0x40200800
+#define CONFIG_SPL_MAX_SIZE(54 * 1024) /* 8 KB for stack */
+#define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
+
+/*
+ * Use 0x80008000 as TEXT_BASE here for compatibility reasons with the
+ * older x-loader implementations. And move the BSS area so that it
+ * doesn't overlap with TEXT_BASE.
+ */
+#define CONFIG_SYS_TEXT_BASE 0x80008000
+#define CONFIG_SPL_BSS_START_ADDR 0x8010
+#define CONFIG_SPL_BSS_MAX_SIZE0x8 /* 512 KB */
+
+#define CONFIG_SYS_SPL_MALLOC_START0x80208000
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10
+
#endif /* __CONFIG_H */
--
1.8.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] arm: omap3: Add board revision output to tao3530
Signed-off-by: Stefan Roese
Cc: Tapani Utriainen
Cc: Thorsten Eisbein
Cc: Tom Rini
---
board/technexion/tao3530/tao3530.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/board/technexion/tao3530/tao3530.c
b/board/technexion/tao3530/tao3530.c
index f9ea131..2f3f929 100644
--- a/board/technexion/tao3530/tao3530.c
+++ b/board/technexion/tao3530/tao3530.c
@@ -131,6 +131,23 @@ int misc_init_r(void)
writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
GPIO15 | GPIO14 | GPIO13 | GPIO12, &gpio5_base->setdataout);
+ switch (tao3530_revision()) {
+ case 0:
+ printf("TAO-3530 REV Reserve 1\n");
+ break;
+ case 1:
+ printf("TAO-3530 REV Reserve 2\n");
+ break;
+ case 2:
+ printf("TAO-3530 REV Cx\n");
+ break;
+ case 3:
+ printf("TAO-3530 REV Ax/Bx\n");
+ break;
+ default:
+ printf("Unknown board revision\n");
+ }
+
dieid_num_r();
return 0;
--
1.8.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] arm: omap3: Add HEAD acoustics (HA) board variant omap3_ha to tao3530
The Head acoustics (HA) baseboard used the Technexion TAO3530 SOM
and has only some minor differences to the Technexion Thunder baseboard.
This patch adds support for this HA baseboard / TAO3530 as the "omap3_ha"
build target.
Signed-off-by: Stefan Roese
Cc: Tapani Utriainen
Cc: Thorsten Eisbein
Cc: Tom Rini
---
board/technexion/tao3530/tao3530.c | 15 +++
board/technexion/tao3530/tao3530.h | 7 +++
boards.cfg | 1 +
3 files changed, 23 insertions(+)
diff --git a/board/technexion/tao3530/tao3530.c
b/board/technexion/tao3530/tao3530.c
index 2f3f929..e829d6f 100644
--- a/board/technexion/tao3530/tao3530.c
+++ b/board/technexion/tao3530/tao3530.c
@@ -75,6 +75,18 @@ out:
*/
void get_board_mem_timings(struct board_sdrc_timings *timings)
{
+#if defined(CONFIG_SYS_BOARD_OMAP3_HA)
+ /*
+* Switch baseboard LED to red upon power-on
+*/
+ MUX_OMAP3_HA();
+
+ /* Request a gpio before using it */
+ gpio_request(111, "");
+ /* Sets the gpio as output and its value to 1, switch LED to red */
+ gpio_direction_output(111, 1);
+#endif
+
if (tao3530_revision() < 3) {
/* 256MB / Bank */
timings->mcfg = MCFG(256 << 20, 14);/* RAS-width 14 */
@@ -162,6 +174,9 @@ int misc_init_r(void)
void set_muxconf_regs(void)
{
MUX_TAO3530();
+#if defined(CONFIG_SYS_BOARD_OMAP3_HA)
+ MUX_OMAP3_HA();
+#endif
}
#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
diff --git a/board/technexion/tao3530/tao3530.h
b/board/technexion/tao3530/tao3530.h
index 1ea767d..5c0330c 100644
--- a/board/technexion/tao3530/tao3530.h
+++ b/board/technexion/tao3530/tao3530.h
@@ -9,7 +9,11 @@
const omap3_sysinfo sysinfo = {
DDR_STACKED,
+#if defined(CONFIG_SYS_BOARD_OMAP3_HA)
+ "HEAD acoustics OMAP3-HA\n",
+#else
"OMAP3 TAO-3530 board",
+#endif
"NAND",
};
@@ -361,4 +365,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(SDRC_CKE0), (IDIS | PTU | EN | M0)) \
MUX_VAL(CP(SDRC_CKE1), (IDIS | PTU | EN | M0))
+#define MUX_OMAP3_HA() \
+ MUX_VAL(CP(CAM_XCLKB), (IDIS | PTD | DIS | M4)) /* GPIO_111 */
+
#endif
diff --git a/boards.cfg b/boards.cfg
index d72be99..90923db 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -325,6 +325,7 @@ Active arm armv7 omap3 logicpd
zoom1
Active arm armv7 omap3 logicpd zoom2
omap3_zoom2 -
Tom Rix
Active arm armv7 omap3 matrix_vision mvblx
omap3_mvblx -
Michael Jones
Active arm armv7 omap3 nokia rx51
nokia_rx51 -
Pali Rohár
+Active arm armv7 omap3 technexion tao3530
omap3_ha tao3530:SYS_BOARD_OMAP3_HA
Stefan Roese
Active arm armv7 omap3 technexion tao3530
tao3530 -
Tapani Utriainen
Active arm armv7 omap3 technexion twister
twister -
Stefano Babic
Active arm armv7 omap3 teejet mt_ventoux
mt_ventoux -
Stefano Babic
--
1.8.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] arm: omap3: Remove bootargs mem_size handling
The memory size is autodetected and is passed to the Linux kernel
either via ATAGs or device-tree (dtb). So there is no need to
pass it via the bootargs.
Signed-off-by: Stefan Roese
Cc: Tapani Utriainen
Cc: Thorsten Eisbein
Cc: Tom Rini
---
board/technexion/tao3530/tao3530.c | 12
include/configs/tao3530.h | 3 ---
2 files changed, 15 deletions(-)
diff --git a/board/technexion/tao3530/tao3530.c
b/board/technexion/tao3530/tao3530.c
index 7cf5aa6..f9ea131 100644
--- a/board/technexion/tao3530/tao3530.c
+++ b/board/technexion/tao3530/tao3530.c
@@ -133,18 +133,6 @@ int misc_init_r(void)
dieid_num_r();
- /* Set memory size environment variable, depending on revision */
- switch (tao3530_revision()) {
- case 0x2: /* Rev C1 -- 256MB */
-setenv("mem_size", "mem=256M");
-break;
- case 0x3: /* Rev A2/B2 -- 128MB */
-setenv("mem_size", "mem=128M");
-break;
- default:
-printf("Warning: Unknown TAO3530 rev, setting mem=128M\n");
- }
-
return 0;
}
diff --git a/include/configs/tao3530.h b/include/configs/tao3530.h
index 03eb85e..9c8e8cf 100644
--- a/include/configs/tao3530.h
+++ b/include/configs/tao3530.h
@@ -150,21 +150,18 @@
"video_mode=omapdss.def_disp=lcd vram=6M omapfb.vram=0:2M,1:2M,2:2M\0" \
"lcd_mode=omapfb.mode=lcd:800x480@60 \0" \
"extra_options= \0" \
- "mem_size=mem=128M \0" \
"mmcdev=0\0" \
"mmcroot=/dev/mmcblk0p2 rw\0" \
"mmcrootfstype=ext3 rootwait\0" \
"nandroot=ubi0:rootfs ubi.mtd=4\0" \
"nandrootfstype=ubifs\0" \
"mmcargs=setenv bootargs console=${console} " \
- "${mem_size} " \
"mpurate=${mpurate} " \
"${video_mode} " \
"root=${mmcroot} " \
"rootfstype=${mmcrootfstype} " \
"${extra_options}\0" \
"nandargs=setenv bootargs console=${console} " \
- "${mem_size} " \
"mpurate=${mpurate} " \
"${video_mode} " \
"${network_setting} " \
--
1.8.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Microblaze and Sparc boards are broken because of common timer func
Hi Masahiro, On 11/12/2013 10:04 AM, Masahiro Yamada wrote: > Hello Michal > > >> This should be fixed by this patch - at least for microblaze. >> >> commit 65ba7add0d609bbd035b8d42fafdaf428ac24751 >> Author: Rob Herring >> Date: Fri Nov 8 08:40:43 2013 -0600 >> >> time: add weak annotation to timer_read_counter declaration >> >> A weak annotation is needed in order to prevent link errors when >> get_ticks is overridden. This fixes sandbox build. >> >> Signed-off-by: Rob Herring > > No. > I tried both the current u-boot/master and commit 65ba7add0d, > but Microblaze board failed with the same error message. > Look at this log - uboot section. http://www.monstr.eu/wiki/doku.php?id=log:2013-11-12_13_29_22 Which toolchain do you use? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs, at91: add common phy_reset function
Hello Heiko,
On 11/12/2013 11:21 AM, Heiko Schocher wrote:
> add common phy reset code into a common function.
>
> Signed-off-by: Heiko Schocher
> Cc: Andreas Bießmann
> Cc: Bo Shen
> Cc: Jens Scharsig
> Cc: Sergey Lapin
> Cc: Stelian Pop
> Cc: Albin Tonnerre
> Cc: Eric Benard
> Cc: Markus Hubig
>
> ---
> Patch based on the spl patchset from Bo Shen (as I want to
> collect this function in at91-common directory), see:
> http://lists.denx.de/pipermail/u-boot/2013-November/166272.html
> (reworked this against newest Kconfig Makefile changes ...
> @Bo: Do you plan an update for this patchset for the Kconfig changes?
@Bo: I'll review the patches also these days.
>
> Maybe my change in arch/arm/cpu/at91-common/Makefile
> could be done better... Do we have a common define for
> all this variants?
I think not, but how about defining a new one?
>
> ---
> arch/arm/cpu/Makefile | 1 +
> arch/arm/cpu/at91-common/Makefile | 5 +++
> arch/arm/cpu/at91-common/phy.c | 48
> +
> arch/arm/include/asm/arch-at91/at91_common.h| 1 +
> board/BuS/vl_ma2sc/vl_ma2sc.c | 18 ++
> board/afeb9260/afeb9260.c | 18 +-
> board/atmel/at91sam9260ek/at91sam9260ek.c | 19 +-
> board/atmel/at91sam9263ek/at91sam9263ek.c | 19 ++
> board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 19 +-
> board/bluewater/snapper9260/snapper9260.c | 16 +
> board/calao/sbc35_a9g20/sbc35_a9g20.c | 19 +-
> board/eukrea/cpu9260/cpu9260.c | 18 +-
> board/taskit/stamp9g20/stamp9g20.c | 31 +---
> spl/Makefile| 4 ---
> 14 files changed, 66 insertions(+), 170 deletions(-)
> create mode 100644 arch/arm/cpu/at91-common/phy.c
>
> diff --git a/arch/arm/cpu/Makefile b/arch/arm/cpu/Makefile
> index fd0da53..886347d 100644
> --- a/arch/arm/cpu/Makefile
> +++ b/arch/arm/cpu/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_TEGRA) += $(SOC)-common/
> obj-$(CONFIG_TEGRA) += tegra-common/
> +obj-$(CONFIG_AT91FAMILY) += at91-common/
> diff --git a/arch/arm/cpu/at91-common/Makefile
> b/arch/arm/cpu/at91-common/Makefile
> index 040b956..255c7b9 100644
> --- a/arch/arm/cpu/at91-common/Makefile
> +++ b/arch/arm/cpu/at91-common/Makefile
> @@ -8,5 +8,10 @@
> # SPDX-License-Identifier: GPL-2.0+
> #
>
> +obj-$(CONFIG_AT91SAM9260) += phy.o
> +obj-$(CONFIG_AT91SAM9G20) += phy.o
> +obj-$(CONFIG_AT91SAM9263) += phy.o
> +obj-$(CONFIG_AT91SAM9XE) += phy.o
> +obj-$(CONFIG_AT91SAM9M10G45) += phy.o
How about defining some CONFIG_AT91_WANTS_PHY_RESET or
CONFIG_AT91_WANTS_COMMON_PHY?
> obj-$(CONFIG_SPL_BUILD) += mpddrc.o
> obj-$(CONFIG_SPL_BUILD) += spl.o
> diff --git a/arch/arm/cpu/at91-common/phy.c b/arch/arm/cpu/at91-common/phy.c
> new file mode 100644
> index 000..4706635
> --- /dev/null
> +++ b/arch/arm/cpu/at91-common/phy.c
> @@ -0,0 +1,48 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop
> + * Lead Tech Design
> + *
> + * Copyright (C) 2013 DENX Software Engineering, h...@denx.de
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +void at91_phy_reset(void)
> +{
> + unsigned long erstl;
> + unsigned long start = get_timer(0);
> + unsigned long timeout = 1000; /* 1000ms */
I'd constify timeout, it could give a hint to the compiler and it
doesn't hurt here.
> + at91_rstc_t *rstc = (at91_rstc_t *)ATMEL_BASE_RSTC;
> +
> + erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK;
> +
> + /* Need to reset PHY -> 500ms reset */
As there where discussion about this trick here could you please add
some comments:
---8<---
Reset PHY by pulling the NRST line for 500ms to low. To do so disable
user reset for low level on NRST pin and poll the NRST level in reset
status register.
--->8---
> + writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(0x0D) |
> + AT91_RSTC_MR_URSTEN, &rstc->mr);
> +
> + writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr);
> +
> + /* Wait for end of hardware reset */
> + while (!(readl(&rstc->sr) & AT91_RSTC_SR_NRSTL)) {
> + /* avoid shutdown by watchdog */
> + WATCHDOG_RESET();
> + mdelay(10);
> +
> + /* timeout for not getting stuck in an endless loop */
> + if (get_timer(start) >= timeout) {
> + puts("*** ERROR: Timeout waiting for PHY reset!\n");
> + break;
> + }
> + };
> +
> + /* Restore NRST value */
> + writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN, &rstc->mr);
> +}
> diff --git a/arch/arm/include/asm/arch-at91/at91_common.h
> b/arch/arm/include/asm/arch-at91/at91_common.h
> index 3ca4d5b..59e2f43 100644
> --- a/arch/arm/include/asm/arch-at91/at91_common.h
> +++ b/arch/arm/inc
[U-Boot] Microblaze and Sparc boards are broken because of common timer func
Hello, Rob, Tom, Michal, Daniel. Commit 8dfafdde88eb (Introduce common timer functions) broke Microblaze and Sparc boards. $ git checkout 8dfafdde88eb $ CROSS_COMPILE=microblaze-unknown-linux-gnu- ./MAKEALL -a microblaze lib/time.c:45: undefined reference to `timer_read_counter' lib/libgeneric.o: In function `__udelay': lib/time.c:86: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO against symbol `get_ticks' defined in .text section in arch/microblaze/cpu/libmicroblaze.o lib/time.c:88: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO against symbol `get_ticks' defined in .text section in arch/microblaze/cpu/libmicroblaze.o lib/libgeneric.o: In function `udelay': lib/time.c:101: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO against symbol `__udelay' defined in .text section in arch/microblaze/cpu/libmicroblaze.o lib/libgeneric.o: In function `timer_get_us': lib/time.c:70: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO against symbol `get_ticks' defined in .text section in arch/microblaze/cpu/libmicroblaze.o lib/libgeneric.o: In function `get_timer': lib/time.c:65: relocation truncated to fit: R_MICROBLAZE_32_PCREL_LO against symbol `get_ticks' defined in .text section in arch/microblaze/cpu/libmicroblaze.o $ CROSS_COMPILE=sparc-elf- ./MAKEALL grsim_leon2 Configuring for grsim_leon2 board... sparc-elf-size: './u-boot': No such file lib/libgeneric.o: In function `tick_to_time': /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:56: undefined reference to `get_tbclk' lib/libgeneric.o: In function `get_ticks': /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:45: undefined reference to `timer_read_counter' lib/libgeneric.o: In function `usec_to_tick': /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:74: undefined reference to `get_tbclk' /home/yamada/workspace/arm-linux-pf/u-boot/lib/time.c:75: undefined reference to `get_tbclk' (I can notice broken boards because I quite often build all boards for the test of Kbuild porting.) Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs, at91: add common phy_reset function
Hello Andreas,
Am 12.11.2013 13:56, schrieb Andreas Bießmann:
Hello Heiko,
On 11/12/2013 11:21 AM, Heiko Schocher wrote:
add common phy reset code into a common function.
Signed-off-by: Heiko Schocher
Cc: Andreas Bießmann
Cc: Bo Shen
Cc: Jens Scharsig
Cc: Sergey Lapin
Cc: Stelian Pop
Cc: Albin Tonnerre
Cc: Eric Benard
Cc: Markus Hubig
---
Patch based on the spl patchset from Bo Shen (as I want to
collect this function in at91-common directory), see:
http://lists.denx.de/pipermail/u-boot/2013-November/166272.html
(reworked this against newest Kconfig Makefile changes ...
@Bo: Do you plan an update for this patchset for the Kconfig changes?
@Bo: I'll review the patches also these days.
Perfect!
Maybe my change in arch/arm/cpu/at91-common/Makefile
could be done better... Do we have a common define for
all this variants?
I think not, but how about defining a new one?
I am fine with this too...
---
arch/arm/cpu/Makefile | 1 +
arch/arm/cpu/at91-common/Makefile | 5 +++
arch/arm/cpu/at91-common/phy.c | 48 +
arch/arm/include/asm/arch-at91/at91_common.h| 1 +
board/BuS/vl_ma2sc/vl_ma2sc.c | 18 ++
board/afeb9260/afeb9260.c | 18 +-
board/atmel/at91sam9260ek/at91sam9260ek.c | 19 +-
board/atmel/at91sam9263ek/at91sam9263ek.c | 19 ++
board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 19 +-
board/bluewater/snapper9260/snapper9260.c | 16 +
board/calao/sbc35_a9g20/sbc35_a9g20.c | 19 +-
board/eukrea/cpu9260/cpu9260.c | 18 +-
board/taskit/stamp9g20/stamp9g20.c | 31 +---
spl/Makefile| 4 ---
14 files changed, 66 insertions(+), 170 deletions(-)
create mode 100644 arch/arm/cpu/at91-common/phy.c
diff --git a/arch/arm/cpu/Makefile b/arch/arm/cpu/Makefile
index fd0da53..886347d 100644
--- a/arch/arm/cpu/Makefile
+++ b/arch/arm/cpu/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_TEGRA) += $(SOC)-common/
obj-$(CONFIG_TEGRA) += tegra-common/
+obj-$(CONFIG_AT91FAMILY) += at91-common/
diff --git a/arch/arm/cpu/at91-common/Makefile
b/arch/arm/cpu/at91-common/Makefile
index 040b956..255c7b9 100644
--- a/arch/arm/cpu/at91-common/Makefile
+++ b/arch/arm/cpu/at91-common/Makefile
@@ -8,5 +8,10 @@
# SPDX-License-Identifier:GPL-2.0+
#
+obj-$(CONFIG_AT91SAM9260) += phy.o
+obj-$(CONFIG_AT91SAM9G20) += phy.o
+obj-$(CONFIG_AT91SAM9263) += phy.o
+obj-$(CONFIG_AT91SAM9XE) += phy.o
+obj-$(CONFIG_AT91SAM9M10G45) += phy.o
How about defining some CONFIG_AT91_WANTS_PHY_RESET or
CONFIG_AT91_WANTS_COMMON_PHY?
I vote for CONFIG_AT91_WANTS_COMMON_PHY
obj-$(CONFIG_SPL_BUILD) += mpddrc.o
obj-$(CONFIG_SPL_BUILD) += spl.o
diff --git a/arch/arm/cpu/at91-common/phy.c b/arch/arm/cpu/at91-common/phy.c
new file mode 100644
index 000..4706635
--- /dev/null
+++ b/arch/arm/cpu/at91-common/phy.c
@@ -0,0 +1,48 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop
+ * Lead Tech Design
+ *
+ * Copyright (C) 2013 DENX Software Engineering, h...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+void at91_phy_reset(void)
+{
+ unsigned long erstl;
+ unsigned long start = get_timer(0);
+ unsigned long timeout = 1000; /* 1000ms */
I'd constify timeout, it could give a hint to the compiler and it
doesn't hurt here.
Ok.
+ at91_rstc_t *rstc = (at91_rstc_t *)ATMEL_BASE_RSTC;
+
+ erstl = readl(&rstc->mr)& AT91_RSTC_MR_ERSTL_MASK;
+
+ /* Need to reset PHY -> 500ms reset */
As there where discussion about this trick here could you please add
some comments:
Ok.
---8<---
Reset PHY by pulling the NRST line for 500ms to low. To do so disable
user reset for low level on NRST pin and poll the NRST level in reset
status register.
--->8---
+ writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(0x0D) |
+ AT91_RSTC_MR_URSTEN,&rstc->mr);
+
+ writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST,&rstc->cr);
+
+ /* Wait for end of hardware reset */
+ while (!(readl(&rstc->sr)& AT91_RSTC_SR_NRSTL)) {
+ /* avoid shutdown by watchdog */
+ WATCHDOG_RESET();
+ mdelay(10);
+
+ /* timeout for not getting stuck in an endless loop */
+ if (get_timer(start)>= timeout) {
+ puts("*** ERROR: Timeout waiting for PHY reset!\n");
+ break;
+ }
+ };
+
+ /* Restore NRST value */
+ writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN,&rstc->mr);
+}
diff --git a/arch/arm/include/asm/arch-at91/at91_common.h
b/arch/arm/include/asm/arch-at91/at91_common.h
index 3ca4d5b..59e2f43 100644
--- a/arch/arm/include/asm/arch-at91/at91_common.h
+++ b/arch/arm/include/asm/arch-at91/at91_common.h
Re: [U-Boot] Microblaze and Sparc boards are broken because of common timer func
On 11/12/2013 06:32 AM, Michal Simek wrote:
> Hi Masahiro,
>
> On 11/12/2013 10:04 AM, Masahiro Yamada wrote:
>> Hello Michal
>>
>>
>>> This should be fixed by this patch - at least for microblaze.
>>>
>>> commit 65ba7add0d609bbd035b8d42fafdaf428ac24751 Author: Rob
>>> Herring Date: Fri Nov 8 08:40:43
>>> 2013 -0600
>>>
>>> time: add weak annotation to timer_read_counter declaration
>>>
>>> A weak annotation is needed in order to prevent link errors
>>> when get_ticks is overridden. This fixes sandbox build.
>>>
>>> Signed-off-by: Rob Herring
>>
>> No. I tried both the current u-boot/master and commit
>> 65ba7add0d, but Microblaze board failed with the same error
>> message.
>>
>
> Look at this log - uboot section.
> http://www.monstr.eu/wiki/doku.php?id=log:2013-11-12_13_29_22
>
> Which toolchain do you use?
It builds for me with 4.8.0 from kernel.org, but I had to disable
systemace driver otherwise I get this error:
/opt/gcc-4.8.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc -g
-Os -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x2900
-I/home/rob/proj/git/u-boot-arm/include -fno-builtin -ffreestanding
-nostdinc -isystem
/opt/gcc-4.8.0-nolibc/microblaze-linux/bin/../lib/gcc/microblaze-linux/4.8.0/include
-pipe -ffixed-r31 -D__microblaze__ -mno-xl-soft-mul -mno-xl-soft-div
-mxl-barrel-shift -Wall -Wstrict-prototypes -fno-stack-protector
-Wno-format-nonliteral -Wno-format-security -fstack-usage -o
systemace.o systemace.c -c
systemace.c: In function 'ace_readw':
systemace.c:70:1: warning: stack usage computation not supported for
this target [enabled by default]
}
^
{standard input}: Assembler messages:
{standard input}:2499: Error: operation combines symbols in different
segments
{standard input}:2500: Error: operation combines symbols in different
segments
{standard input}:2503: Error: operation combines symbols in different
segments
{standard input}:2504: Error: operation combines symbols in different
segments
{standard input}:2509: Error: operation combines symbols in different
segments
{standard input}:2510: Error: operation combines symbols in different
segments
{standard input}:2519: Error: operation combines symbols in different
segments
{standard input}:2520: Error: operation combines symbols in different
segments
{standard input}:2523: Error: operation combines symbols in different
segments
{standard input}:2524: Error: operation combines symbols in different
segments
{standard input}:2533: Error: operation combines symbols in different
segments
{standard input}:2534: Error: operation combines symbols in different
segments
{standard input}:2537: Error: operation combines symbols in different
segments
{standard input}:2538: Error: operation combines symbols in different
segments
{standard input}:2543: Error: operation combines symbols in different
segments
{standard input}:2544: Error: operation combines symbols in different
segments
{standard input}:2553: Error: operation combines symbols in different
segments
{standard input}:2554: Error: operation combines symbols in different
segments
make[3]: *** [systemace.o] Error 1
Rob
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/4] udoo: Move and optimize platform register setting.
Hi Giuseppe, On Mon, Nov 11, 2013 at 3:11 PM, Giuseppe Pagano wrote: > Previous uDoo configuration adopts register settings for DDR3, clock, muxing, > etc. taken from Nitrogen6x. uDoo schematics is rather different from that > board, and it needs customized setting for most of the registers. > All this changes can be considered atomical since it is part of initial > support of the board. > > Patch changes uDoo configuration files path to a specific one, and adopt > optimized value for every configured register. > > Signed-off-by: Giuseppe Pagano > CC: Stefano Babic > CC: Fabio Estevam Tested-by: Fabio Estevam Thanks. Only one minor nit below: > --- > board/udoo/1066mhz_4x256mx16.cfg | 56 > board/udoo/clocks.cfg| 32 ++ > board/udoo/ddr-setup.cfg | 87 > ++ > board/udoo/udoo.cfg | 29 + > boards.cfg |2 +- > 5 files changed, 205 insertions(+), 1 deletion(-) > create mode 100644 board/udoo/1066mhz_4x256mx16.cfg > create mode 100644 board/udoo/clocks.cfg > create mode 100644 board/udoo/ddr-setup.cfg > create mode 100644 board/udoo/udoo.cfg > > diff --git a/board/udoo/1066mhz_4x256mx16.cfg > b/board/udoo/1066mhz_4x256mx16.cfg > new file mode 100644 > index 000..539e3f6 > --- /dev/null > +++ b/board/udoo/1066mhz_4x256mx16.cfg > @@ -0,0 +1,56 @@ > +/* > + * Copyright (C) 2013 Boundary Devices > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > + No need to add two lines here. One line is enough. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] udoo: Add ethernet support (FEC + Micrel KSZ9031).
On Mon, Nov 11, 2013 at 3:11 PM, Giuseppe Pagano wrote: > Add Ethernet and networking support on uDoo board (FEC + phy Micrel KSZ9031). > > Signed-off-by: Giuseppe Pagano > CC: Stefano Babic > CC: Fabio Estevam TFTP transfer worked fine here, so: Tested-by: Fabio Estevam Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH,v1,4/4] udoo: Fix watchdog during kernel boot.
On Mon, Nov 11, 2013 at 3:11 PM, Giuseppe Pagano wrote: > uDoo uses APX823-31W5 watchdog chip. Timeout is about 1.2 seconds. > To disabled watchdog during kernel boot, WDI pin of that chip needs to be in > "high impedance" state. > I.mx6 gpio configuration does not contemplate tristate, so pin is set as > input in high impedance. > > Signed-off-by: Giuseppe Pagano > CC: Stefano Babic > CC: Fabio Estevam > --- > board/udoo/udoo.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/board/udoo/udoo.c b/board/udoo/udoo.c > index b53f70c..af8004e 100644 > --- a/board/udoo/udoo.c > +++ b/board/udoo/udoo.c > @@ -169,6 +169,7 @@ static void setup_iomux_wdog(void) > imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads)); > gpio_direction_output(WDT_TRG, 0); > gpio_direction_output(WDT_EN, 1); > + gpio_direction_input(WDT_TRG); Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mx28: disable DCDC-converter and use internal linear regulators
Hello, I'm having a problem with the internal DCDC-converter on a custom board. I'm now looking for a way to disable the internal DCDC-converter and use the internal regulators to power the CPU and memories. If I understand it correctly the pmu is configured in arch/arm/cpu/arm926ejs/mxs/spl_power_init.c. How do I disable the internal DCDC-converter and use internal linear regulator instead? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] trats2: enable dfu and thor protocol for Tizen download
Trats2 config is updated to support DFU mode.
Malloc pool must be increased for DFU buffer allocation.
Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
CC: Minkyu Kang
---
Changes for v2:
- modified subject to reflect that the patch is for Trats2;
- changed u-boot write size to 0x800 in dfu alts;
This patch is based on
http://patchwork.ozlabs.org/patch/289378/
include/configs/trats2.h | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index 66b1c95..bf49dd5 100644
--- a/include/configs/trats2.h
+++ b/include/configs/trats2.h
@@ -65,10 +65,9 @@
#define CONFIG_DISPLAY_CPUINFO
-/*
- * Size of malloc() pool
- */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (2 << 20))
+#include
+/* Size of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 * SZ_1M))
/* select serial console configuration */
#define CONFIG_SERIAL2
@@ -100,6 +99,7 @@
#define CONFIG_CMD_CACHE
#define CONFIG_CMD_I2C
#define CONFIG_CMD_MMC
+#define CONFIG_CMD_DFU
#define CONFIG_CMD_GPT
#define CONFIG_CMD_PMIC
@@ -115,12 +115,19 @@
/* USB Composite download gadget - g_dnl */
#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M
#define CONFIG_DFU_FUNCTION
#define CONFIG_DFU_MMC
+/* TIZEN THOR downloader support */
+#define CONFIG_CMD_THOR_DOWNLOAD
+#define CONFIG_THOR_FUNCTION
+
/* USB Samsung's IDs */
#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM
+#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D
#define CONFIG_G_DNL_MANUFACTURER "Samsung"
/* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
@@ -165,6 +172,12 @@
"name="PARTS_CSC",size=150MiB,uuid=${uuid_gpt_"PARTS_CSC"};" \
"name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
+#define CONFIG_DFU_ALT \
+ "u-boot mmc 80 800;" \
+ "uImage ext4 0 2;" \
+ "exynos4412-trats2.dtb ext4 0 2;" \
+ ""PARTS_ROOT" part 0 5\0"
+
#define CONFIG_EXTRA_ENV_SETTINGS \
"bootk=" \
"run loaddtb; run loaduimage; bootm 0x40007FC0 - ${fdtaddr}\0" \
@@ -197,6 +210,7 @@
"mmcrootpart=5\0" \
"opts=always_resume=1\0" \
"partitions=" PARTS_DEFAULT \
+ "dfu_alt_info=" CONFIG_DFU_ALT \
"uartpath=ap\0" \
"usbpath=ap\0" \
"consoleon=set console console=ttySAC2,115200n8; save; reset\0" \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
Hi Tapani,
On 11/12/2013 04:05 AM, Tapani wrote:
Thank you Eric,
< snip >
and paste it into the spot where it's used:
MX6_PAD_DEF(SD2_DAT1__USDHC2_DAT1)
(As opposed to having to hand-edit to remove the MX6Q_PAD_ prefix
from one of the declarations)
Technical point: Could you clarify how this approach scales? There are still
new imx6 models to be released (imx6-next).
It's always tough to tell until we hash through the reference manuals.
Maybe you misunderstood me. We both know there are many more iMX6 CPUs
coming next year (and they are under NDA; but the public Freescale roadmap
confirms a imx6-next line, so we can safely say that stuff is coming).
My point was that the approach we take to make multi-variant code now
should be scalable to add additional variants in the future. Assuming the
new variants are compatible enough, but maybe requiring their own padconfs.
So we have families of cpus like (just an example): { iMX6Q, iMX6D },
{ iMX6S, iMX6DL }, { iMX6SL }, { iMX6x1, iMX6x2 }, { iMX6x3, iMX6x4 }, ...
We should be able to support multi-variant over as many families of cpus
as possible, without having another macro-fu nightmare when we need to
support another new CPU group.
My worry was that your approach could grow in complexity when a hypothetical
iMX6X cpu is to be supported.
I think this scales linearly with the number of CPU variants.
I'm also not sure that any of the new processors will be pin-compatible,
which is really the only time this effort helps.
< snip >
We have suggested an alternative solution, but somehow nobody seem
to notice. We avoid almost all the preprocessor messing, and have the
definitions only once. And it would scale for even more cpu types.t
Admittedly, the drawback is duplicate padconf macro definitions
(or having to convert the existing boards padconfigs).
Somehow I missed it. What I recall involved duplicating code and data.
Can you explain?
Ok, for the third time :-) But this time combined with some of your suggestions.
In mx6_pins.h we can do the 20 lines of macro-fu you suggested, to create
the enums for MX6Q_PAD_x + MX6DL_PAD_x or MX6_PAD_x, depending on CPUs to
support. Or use separate includes with duplicate padconf definitions.
Anyway assume MX6Q_PAD_x and MX6DL_PAD_x definitions are in scope.
Now somewhere (board file? mx6_pins.h?) we need one helper macro:
#define IMX6_SET_PAD(p) \
if ( is_mx6q ) \
mxc_iomux_v3_setup_pad(MX6Q_##p); \
else \
mxc_iomux_v3_setup_pad(MX6DL_##p)
Using this macro a pad can be set in code, and no need for tables!
(The compiler will do a good job on that, don't worry about the resulting code)
For instance, a board file can now initialize UART1 with:
static __init void edm_cf_imx6_init_uart(void) {
IMX6_SET_PAD( PAD_CSI0_DAT10__UART1_TXD );
IMX6_SET_PAD( PAD_CSI0_DAT11__UART1_RXD );
IMX6_SET_PAD( PAD_EIM_D19__UART1_CTS );
IMX6_SET_PAD( PAD_EIM_D20__UART1_RTS );
imx6_add_uart(0, NULL);
}
I didn't catch that you were using a global (local) variable
for is_mx6q so the compiler can optimize this, but I would still
prefer an array and a single call to imx_iomux_v3_setup_multiple_pads().
I would also suggest re-visiting the pad setting in each block
(uart, SD, i2c, etc) and consider a single block of pad setup,
regardless of whether it's done with a table or individual calls.
An example of this architecture is in our kernel board file:
https://github.com/TechNexion/linux/blob/imx-3.0.35-4.1.0/arch/arm/mach-mx6/board-edm_cf_imx6.c
Using this method the boardfile part contains less macro hacks, is clearer,
no tables, and results in shorter C code than your suggestion. (Ok, the
clearer part could be an opinion.)
Actually, I am not sure this is mutually exclusive with your suggestion.
(Since we suspect you like your board file as much as we like ours, maybe
it is better to not mandate how board files should do their pinmuxing?).
I actually don't like our board file so much, but don't want to thrash
it without a clear(er) direction.
Anyway, let's work together on this, so we can avoid the maintenance mess the
iMX6 products otherwise could become.
Sounds good.
I'm hoping to get some feedback from at least Fabio and Stefano on this.
They've been notably silent, but I'm sure it's because they're busy...
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-video/master
On Tue, Nov 12, 2013 at 10:49:39AM +0100, Anatolij Gustschin wrote: > Hi Tom, > > here are LCD panel support patches for cm_t35 board and a fix for > Raspberry Pi LCD driver. > > Please pull. Thanks! > > Anatolij > > The following changes since commit 649acfe149e8a534a17eab54004a51d69b5556ed: > > MPC824x: remove obsolete "PN62" board (2013-11-11 14:46:24 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-video.git master > > for you to fetch changes up to 63c4f17b2f8017d22241522a48c765073b8791b0: > > cm_t35: use scf0403 driver (2013-11-12 10:12:07 +0100) > > > Anatolij Gustschin (1): > lcd: allow overriding lcd_get_size() > > Andre Heider (2): > ARM: bcm2835: add missing mbox overscan response field > video: bcm2835: respect the pitch value > > Nikita Kiryanov (6): > spi: omap3: remove semicolon from #define > spi: omap3: add support for more word lengths > spi: define SPI_XFER_ONCE > lcd: add DataImage SCF0403x LCD panel support > omap3_dss: define DSS_ONOFF > cm_t35: use scf0403 driver > > arch/arm/include/asm/arch-bcm2835/mbox.h |1 + > arch/arm/include/asm/arch-omap3/dss.h|9 +- > board/compulab/cm_t35/cm_t35.c | 12 ++ > board/compulab/common/omap3_display.c| 46 - > common/lcd.c | 10 +- > drivers/spi/omap3_spi.c | 71 --- > drivers/spi/omap3_spi.h |8 +- > drivers/spi/spi.c| 13 ++ > drivers/video/Makefile |1 + > drivers/video/bcm2835.c | 11 ++ > drivers/video/scf0403_lcd.c | 296 > ++ > include/configs/cm_t35.h |3 + > include/scf0403_lcd.h| 11 ++ > include/spi.h| 17 ++ > 14 files changed, 475 insertions(+), 34 deletions(-) > create mode 100644 drivers/video/scf0403_lcd.c > create mode 100644 include/scf0403_lcd.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
Hi all, On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote: > On 11/12/2013 10:56 AM, Detlev Zundel wrote: > > Hi Michal, > > > >> On 11/11/2013 09:33 PM, Tom Rini wrote: > >>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: > >>> > Altera Cyclone 5 board is very different board (big, rectangular, > expensive) than EBV Socrates (small, circular, cheap) board. Different > parts are used there, too, but same configuration of u-boot works on > both. Nevertheless, printing wrong name confuses users. > > Therefore this splits the configuration so that u-boot knows they are > different. So far it is only used for correcting the puts, but there > may be other uses in future. > > Signed-off-by: Pavel Machek > >>> > >>> Is there any way at run time to tell which board we are on? > >> > >> Why do you care about board name in general? > > > > We care for board names for a very long time in U-Boot and I'd like to > > keep this. I actually expect a sensible board name on any platform that > > I touch. The board name is an important extra information additional to > > the SoC name. So the question is the other way round - since when do we > > _not_ care about board names? > > There could be i2c memory on board where you can find out this information > but that's > problematic if it is empty or you want to use this i2c for something else. > For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design > (if user is smart enough board name is the part of hw design name). > For zynq/socfpga sensible solution is probably to load this name for DTS. > Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks Chin Liang > Thanks, > Michal > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hey, The following changes since commit 85b8c5c4bf80025de4632ae6c9a8a606e51508a4: Merge branch 'iu-boot/master' into 'u-boot-arm/master' (2013-11-09 22:59:47 +0100) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 79c5c08d7c560aef2d5706501557b7907c2829bb: omap730p2: Remove board (2013-11-11 12:17:48 -0500) Andrew Bradford (1): am335x_evm: Fix CONS_INDEX numbering Heiko Schocher (2): bootcount: store bootcount var in environment arm, am33x: make RTC32K OSC enable configurable Igor Grinberg (1): cm-t35: use gpio_led driver for status led Matt Porter (1): boards.cfg: update email address for ti814x_evm maintainer Tom Rini (2): am33xx: Make SoC bootcount driver have its own symbol omap730p2: Remove board README| 19 ++ arch/arm/cpu/armv7/am33xx/board.c |4 + board/compulab/cm_t35/Makefile|2 +- board/compulab/cm_t35/leds.c | 33 --- board/ti/omap730p2/Makefile |9 - board/ti/omap730p2/README.omap730p2 | 91 --- board/ti/omap730p2/config.mk | 25 -- board/ti/omap730p2/flash.c| 463 - board/ti/omap730p2/lowlevel_init.S| 379 --- board/ti/omap730p2/omap730p2.c| 255 -- boards.cfg| 15 +- doc/README.scrapyard |5 +- drivers/bootcount/Makefile|3 +- drivers/bootcount/bootcount_davinci.c |4 + drivers/bootcount/bootcount_env.c | 29 +++ include/configs/am335x_evm.h |4 + include/configs/cm_t35.h |9 +- include/configs/h2_p2_dbg_board.h | 120 - include/configs/omap730.h | 246 -- include/configs/omap730p2.h | 173 include/configs/ti_am335x_common.h|5 +- 21 files changed, 80 insertions(+), 1813 deletions(-) delete mode 100644 board/compulab/cm_t35/leds.c delete mode 100644 board/ti/omap730p2/Makefile delete mode 100644 board/ti/omap730p2/README.omap730p2 delete mode 100644 board/ti/omap730p2/config.mk delete mode 100644 board/ti/omap730p2/flash.c delete mode 100644 board/ti/omap730p2/lowlevel_init.S delete mode 100644 board/ti/omap730p2/omap730p2.c create mode 100644 drivers/bootcount/bootcount_env.c delete mode 100644 include/configs/h2_p2_dbg_board.h delete mode 100644 include/configs/omap730.h delete mode 100644 include/configs/omap730p2.h -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] udoo: Add ethernet support (FEC + Micrel KSZ9031).
Hi Giuseppe,
On Mon, Nov 11, 2013 at 3:11 PM, Giuseppe Pagano
wrote:
> +static iomux_v3_cfg_t const enet_pads1[] = {
> + MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_RGMII_TXC__ENET_RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_RGMII_TD0__ENET_RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_RGMII_TD1__ENET_RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_RGMII_TD2__ENET_RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_RGMII_TD3__ENET_RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_RGMII_RXC__ENET_RGMII_RXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + /* RGMII reset */
> + MX6_PAD_EIM_D23__GPIO_3_23 | MUX_PAD_CTRL(NO_PAD_CTRL),
> + /* alimentazione ethernet*/
Actually this is pin is Ethernet PHY reset, so the comment in Italian
is not correct :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boards.cfg: update email address for ti814x_evm maintainer
On Mon, Nov 04, 2013 at 03:31:15PM -0500, Matt Porter wrote: > Update my email address as ti814x_evm maintainer to save > people some frustrating bounces and non-response. > > Signed-off-by: Matt Porter > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/5] arm, am33x: make RTC32K OSC enable configurable
On Mon, Nov 04, 2013 at 02:05:00PM +0100, Heiko Schocher wrote: > As > http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#2_Keep_it_Fast > states: > "Initialize devices only when they are needed within U-Boot" > > enable the RTC32K OSC only, if CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC is > enabled. Enable this in ti_am335x_common.h, so all boards in mainline > should work as before. > > Signed-off-by: Heiko Schocher > Cc: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am335x_evm: Fix CONS_INDEX numbering
On Mon, Nov 04, 2013 at 03:42:52PM -0500, Andrew Bradford wrote: > From: Andrew Bradford > > Commit f6d1f6e4a58edae4776937647381a43fea5e83a5 broke selection of UARTs > other than UART0 for am335x_evm configurations by setting CONS_INDEX to > 1 for all configurations. Revert the CONS_INDEX changes. > > Signed-off-by: Andrew Bradford Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Make SoC bootcount driver have its own symbol
On Fri, Nov 08, 2013 at 01:54:32PM -0500, Tom Rini wrote: > Some am33xx boards may not use the RTC block for bootcount (as it may > not be wired up for the board) and use some other facility. So add > another symbol for the bootcount driver for the IP block. > > Cc: Heiko Schocher > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cm-t35: use gpio_led driver for status led
On Wed, Nov 06, 2013 at 04:39:47PM +0200, Igor Grinberg wrote: > Switch to using the generic gpio_led driver instead of the private to > cm_t35 board led implementation. > > Signed-off-by: Igor Grinberg > Tested-by: Nikita Kiryanov Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap730p2: Remove board
On Mon, Nov 11, 2013 at 12:09:40PM -0500, Tom Rini wrote: > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: use CONFIG_SYS_TEXT_BASE in relocation calculations
2013.11.11. 23:36 keltezéssel, Daniel Schwierzeck írta: <...> >>> to be consistent with all other architectures, we should keep >>> CONFIG_SYS_MONITOR_BASE. I think it is neither valid nor intentional >>> to use a value different from CONFIG_SYS_TEXT_BASE. >> >> If it is neither valid nor intentional, the CONFIG_SYS_MONITOR_BASE constant >> should not exist at all and CONFIG_SYS_TEXT_BASE should be used everywhere >> instead IMHO. > > By now it is redundant. Once CONFIG_SYS_TEXT_BASE was only a make > variable named TEXT_BASE and defined in board-specific config.mk. This > has been converted with commit > 14d0a02a168b36e87665b8d7f42fa3e88263d26d. > > BTW the README states: > > - CONFIG_SYS_MONITOR_BASE: > Physical start address of boot monitor code (set by > make config files to be same as the text base address > (CONFIG_SYS_TEXT_BASE) used when linking) - same as > CONFIG_SYS_FLASH_BASE when booting from flash. I see. Thank you for the explanation. >> >> Additionally, we have this check in arch/mips/lib/board.c: >> >>> #if CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE >>> bd->bi_flashoffset = monitor_flash_len; /* reserved area for U-Boot */ >>> #else >>> bd->bi_flashoffset = 0; >>> #endif >> >> If it is not allowed to use different values for the two constants, >> the condition and the #else branch should be removed. > > no that is still needed if a board has NOR flash but boots from NAND > or SPI flash or other media (e.g. SoC evaluation boards). In that case > CONFIG_SYS_TEXT_BASE points usually to an SRAM address. Ok. > >> >>> Instead we should change include/configs/malta.h: >>> >>> -#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE >>> +#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE >>> >>> >>> Comments? >> >> I have tried this already. It is working as well, however with this change >> the >> flash sectors containing the bootloader are not protected correctly: >> >>> malta # flinfo >>> >>> Bank # 1: CFI conformant flash (32 x 32) Size: 4 MB in 64 Sectors >>> Intel Extended command set, Manufacturer ID: 0x00, Device ID: 0x00 >>> Erase timeout: 16384 ms, write timeout: 3 ms >>> Buffer write timeout: 3 ms, buffer size: 2048 bytes >>> >>> Sector Start Addresses: >>> BE00BE01BE02BE03BE04 >>> BE05BE06BE07BE08BE09 >>> BE0ABE0BBE0CBE0DBE0E >>> BE0FBE10BE11BE12BE13 >>> BE14BE15BE16BE17BE18 >>> BE19BE1ABE1BBE1CBE1D >>> BE1EBE1FBE20BE21BE22 >>> BE23BE24BE25BE26BE27 >>> BE28BE29BE2ABE2BBE2C >>> BE2DBE2EBE2FBE30BE31 >>> BE32BE33BE34BE35BE36 >>> BE37BE38BE39BE3ABE3B >>> BE3CBE3DBE3E RO BE3F RO >>> malta # >> >> For reference, this is the output of flinfo with my change: >> >>> malta # flinfo >>> >>> Bank # 1: CFI conformant flash (32 x 32) Size: 4 MB in 64 Sectors >>> Intel Extended command set, Manufacturer ID: 0x00, Device ID: 0x00 >>> Erase timeout: 16384 ms, write timeout: 3 ms >>> Buffer write timeout: 3 ms, buffer size: 2048 bytes >>> >>> Sector Start Addresses: >>> BE00 RO BE01 RO BE02 RO BE03BE04 >>> BE05BE06BE07BE08BE09 >>> BE0ABE0BBE0CBE0DBE0E >>> BE0FBE10BE11BE12BE13 >>> BE14BE15BE16BE17BE18 >>> BE19BE1ABE1BBE1CBE1D >>> BE1EBE1FBE20BE21BE22 >>> BE23BE24BE25BE26BE27 >>> BE28BE29BE2ABE2BBE2C >>> BE2DBE2EBE2FBE30BE31 >>> BE32BE33BE34BE35BE36 >>> BE37BE38BE39BE3ABE3B >>> BE3CBE3DBE3E RO BE3F RO >>> malta # >> >> Any idea how can we resolve this properly? >> >> -Gabor > > following seems to work (in both variants with -bios and -pflash) > > #define CONFIG_SYS_TEXT_BASE 0xbe00 > #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE Yeah, this definitely looks better than my solut
Re: [U-Boot] [U-Boot, v3, 1/5] bootcount: store bootcount var in environment
On Mon, Nov 04, 2013 at 02:04:59PM +0100, Heiko Schocher wrote: > If no softreset save registers are found on the hardware > "bootcount" is stored in the environment. To prevent a > saveenv on all reboots, the environment variable > "upgrade_available" is introduced. If "upgrade_available" is > 0, "bootcount" is always 0 therefore no need to save the > environment on u-boot boot, if "upgrade_available" is 1 "bootcount" > is incremented in the environment and environment gets written > on u-boot start. > So the Userspace Applikation must set the "upgrade_available" > and "bootcount" variable to 0 (for example with fw_setenv), > if a boot was successfully. > > Signed-off-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] udoo: Add ethernet support (FEC + Micrel KSZ9031).
On Tue, Nov 12, 2013 at 12:51 PM, Fabio Estevam wrote:
> Hi Giuseppe,
>
> On Mon, Nov 11, 2013 at 3:11 PM, Giuseppe Pagano
> wrote:
>
>> +static iomux_v3_cfg_t const enet_pads1[] = {
>> + MX6_PAD_ENET_MDIO__ENET_MDIO|
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_ENET_MDC__ENET_MDC |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_RGMII_TXC__ENET_RGMII_TXC |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_RGMII_TD0__ENET_RGMII_TD0 |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_RGMII_TD1__ENET_RGMII_TD1 |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_RGMII_TD2__ENET_RGMII_TD2 |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_RGMII_TD3__ENET_RGMII_TD3 |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_ENET_REF_CLK__ENET_TX_CLK |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + MX6_PAD_RGMII_RXC__ENET_RGMII_RXC |
>> MUX_PAD_CTRL(ENET_PAD_CTRL),
>> + /* RGMII reset */
>> + MX6_PAD_EIM_D23__GPIO_3_23 | MUX_PAD_CTRL(NO_PAD_CTRL),
>> + /* alimentazione ethernet*/
>
> Actually this is pin is Ethernet PHY reset, so the comment in Italian
> is not correct :-)
Sorry, I looked at the wrong line. Anyway, please change the comment
to "Ethernet power supply".
Thanks,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Tue, Nov 12, 2013 at 09:50:43AM -0500, Tom Rini wrote: > Hey, > > The following changes since commit 85b8c5c4bf80025de4632ae6c9a8a606e51508a4: > > Merge branch 'iu-boot/master' into 'u-boot-arm/master' (2013-11-09 22:59:47 > +0100) > > are available in the git repository at: > > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to 79c5c08d7c560aef2d5706501557b7907c2829bb: > > omap730p2: Remove board (2013-11-11 12:17:48 -0500) > > > Andrew Bradford (1): > am335x_evm: Fix CONS_INDEX numbering > > Heiko Schocher (2): > bootcount: store bootcount var in environment > arm, am33x: make RTC32K OSC enable configurable > > Igor Grinberg (1): > cm-t35: use gpio_led driver for status led > > Matt Porter (1): > boards.cfg: update email address for ti814x_evm maintainer > > Tom Rini (2): > am33xx: Make SoC bootcount driver have its own symbol > omap730p2: Remove board Oops, since u-boot-arm was updated, I have 2 more patches, new PR in a second.. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master, v2
Hey, The following changes since commit 85b8c5c4bf80025de4632ae6c9a8a606e51508a4: Merge branch 'iu-boot/master' into 'u-boot-arm/master' (2013-11-09 22:59:47 +0100) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 56eb3da43fab5990a4b7bc118b76c7cae2ceb140: arm, am335x: update for the siemens boards (2013-11-12 09:53:59 -0500) Andrew Bradford (1): am335x_evm: Fix CONS_INDEX numbering Heiko Schocher (3): bootcount: store bootcount var in environment arm, am33x: make RTC32K OSC enable configurable usb, g_dnl: make bcdDevice value configurable Igor Grinberg (1): cm-t35: use gpio_led driver for status led Matt Porter (1): boards.cfg: update email address for ti814x_evm maintainer Samuel Egli (1): arm, am335x: update for the siemens boards Tom Rini (2): am33xx: Make SoC bootcount driver have its own symbol omap730p2: Remove board README | 19 ++ arch/arm/cpu/armv7/am33xx/board.c |4 + board/compulab/cm_t35/Makefile |2 +- board/compulab/cm_t35/leds.c | 33 --- board/siemens/common/factoryset.c | 24 +- board/siemens/common/factoryset.h |2 + board/siemens/dxr2/board.c | 11 +- board/siemens/dxr2/board.h |9 +- board/siemens/dxr2/mux.c | 158 +++ board/siemens/pxm2/board.c |3 +- board/siemens/rut/board.c | 51 +++- board/ti/omap730p2/Makefile|9 - board/ti/omap730p2/README.omap730p2| 91 --- board/ti/omap730p2/config.mk | 25 -- board/ti/omap730p2/flash.c | 463 board/ti/omap730p2/lowlevel_init.S | 379 -- board/ti/omap730p2/omap730p2.c | 255 -- boards.cfg | 15 +- doc/README.scrapyard |5 +- drivers/bootcount/Makefile |3 +- drivers/bootcount/bootcount_davinci.c |4 + drivers/bootcount/bootcount_env.c | 29 ++ drivers/usb/gadget/g_dnl.c | 23 +- include/configs/am335x_evm.h |4 + include/configs/cm_t35.h |9 +- include/configs/dxr2.h | 13 +- include/configs/h2_p2_dbg_board.h | 120 - include/configs/omap730.h | 246 - include/configs/omap730p2.h| 173 include/configs/pxm2.h |7 +- include/configs/rut.h | 10 +- include/configs/siemens-am33x-common.h | 69 +++-- include/configs/ti_am335x_common.h |5 +- 33 files changed, 404 insertions(+), 1869 deletions(-) delete mode 100644 board/compulab/cm_t35/leds.c delete mode 100644 board/ti/omap730p2/Makefile delete mode 100644 board/ti/omap730p2/README.omap730p2 delete mode 100644 board/ti/omap730p2/config.mk delete mode 100644 board/ti/omap730p2/flash.c delete mode 100644 board/ti/omap730p2/lowlevel_init.S delete mode 100644 board/ti/omap730p2/omap730p2.c create mode 100644 drivers/bootcount/bootcount_env.c delete mode 100644 include/configs/h2_p2_dbg_board.h delete mode 100644 include/configs/omap730.h delete mode 100644 include/configs/omap730p2.h -- 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] [U-Boot, v3, 4/5] usb, g_dnl: make bcdDevice value configurable
On Mon, Nov 04, 2013 at 02:05:02PM +0100, Heiko Schocher wrote: > add the possibility to set the bcdDevice number board specific. > Therefore the weak function g_dnl_get_board_bcd_device_number() > is introduced. Used on the siemens boards. > > Signed-off-by: Heiko Schocher > Acked-by: Lukasz Majewski > Cc: Marek Vasut > Cc: Kyungmin Park Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/5] arm, am335x: update for the siemens boards
On Mon, Nov 04, 2013 at 02:05:03PM +0100, Heiko Schocher wrote: > From: Samuel Egli > > - dxr2: define unused pins as input > - do not enable RTC32K OSC on dxr2 board > - update default environment > - add splashpos=m,m to default environment, so splash screen is always > centered. > - adapt environment for bootcount feature > - add altbootcmd to default environment > - rut: SPL add early reset pulse for eth-phy, maXTouch and display > - rut: display timing aenderungen > - siemens boards: adapt for background color = white > - add boutcount feature for the siemens boards > store the bootcount in the environment, as we have no softreset > save registers on this hardware. Use therefore the CONFIG_BOOTCOUNT_ENV > bootcount driver. > - change spi mode from 3 to 0 for the lcd init > - add gpio pin for lcd reset with state 0 and add mdelay > - siemens boards: use own USB id's > - add dfu serial and device number for siemens boards > Add for the siemens boards the possibility to define in dfu mode, > the iSerialNumber and the bcdDevice fields in the USB Device > descriptor. > - fix upgrade mechanism based on bootcount > Correct location of saveenv and remove not active variable. > > Add CONFIG_BOOT_RETRY_TIME and CONFIG_RESET_TO_RETRY to > reboot board in case of empty kernel partition. Without > these defines an empty kernel partition leads to an > abort of boot process and one remains in u-boot prompt. > > - general cleanup of dxr2, pxm2 and rut boards > all: >* Remove net boot from bootcmd > Ping can cause a crash on boards without ethernet phy. > net_nfs command is used only for development > >* Add reset at the end of bootcmd > In order to have an immediate reset of the boot when bootcmd > fails, add reset at the end of bootcmd. > > rut: >* add nand_img_size > > dxr2: >* update nand_img_size > >* ddr3 timings updated with iocontrol property that can be > modified via eeprom. New default parameters from software > leveling with draco ES2. > > Signed-off-by: Samuel Egli > Signed-off-by: Pascal Bach > Signed-off-by: Roger Meier > Signed-off-by: Heiko Schocher > Cc: Matthias Michel > Cc: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] udoo: Add ethernet support (FEC + Micrel KSZ9031).
Hi Fabio, On Tue, 2013-11-12 at 13:00 -0200, Fabio Estevam wrote: > >> + /* alimentazione ethernet*/ > > > > Actually this is pin is Ethernet PHY reset, so the comment in Italian > > is not correct :-) > > Sorry, I looked at the wrong line. Anyway, please change the comment > to "Ethernet power supply". Sure, I'll do in the next v2 version. > Thanks, > Fabio Estevam Bye Giuseppe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mx6: add structs for mmdc and ddr iomux registers
Hi Edward,
On 08/11/2013 10:35, Edward Lin wrote:
> Signed-off-by: Edward Lin
> ---
> arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h | 167
> +++
> 1 file changed, 167 insertions(+)
> create mode 100644 arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
>
> diff --git a/arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
> b/arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
> new file mode 100644
> index 000..dd5e892
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-mx6/mx6_ddr_regs.h
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright (C) 2013 TechNexion Inc.
> + *
> + * Author: Edward Lin
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +#ifndef __ASM_ARCH_MX6_DDR_REGS_H__
> +#define __ASM_ARCH_MX6_DDR_REGS_H__
> +
> +#define MX6_MMDC_P0_BASE 0x021b
> +#define MX6_MMDC_P1_BASE 0x021b4000
> +
> +/* MMDC P0/P1 Registers */
> +struct mmdc_p_regs {
> + u32 mdctl;
> + u32 mdpdc;
> + u32 mdotc;
> + u32 mdcfg0;
> + u32 mdcfg1;
> + u32 mdcfg2;
> + u32 mdmisc;
Ok - if these structure is to make it available for other components, it
should replace the structure esd_mmdc_regs in cpu.c. We cannot have both.
> + u32 res10[25];
> + u32 mpmur0;
> +}__attribute__((packed, aligned(4)));
> +
I am missing why the packed is needed.
> +#define MX6Q_IOM_DDR_BASE 0x020e0500
> +struct mx6q_iomux_ddr_regs {
> + u32 res1[3];
> + u32 dram_sdqs5;
> + u32 dram_dqm5;
> + u32 dram_dqm4;
> + u32 dram_sdqs4;
> + u32 dram_sdqs3;
> + u32 dram_dqm3;
> + u32 dram_sdqs2;
> + u32 dram_dqm2;
> + u32 res2[16];
> + u32 dram_cas;
> + u32 res3[2];
> + u32 dram_ras;
> + u32 dram_reset;
> + u32 res4[2];
> + u32 dram_sdclk_0;
> + u32 dram_sdba2;
> + u32 dram_sdcke0;
> + u32 dram_sdclk_1;
> + u32 dram_sdcke1;
> + u32 dram_sdodt0;
> + u32 dram_sdodt1;
> + u32 res5;
> + u32 dram_sdqs0;
> + u32 dram_dqm0;
> + u32 dram_sdqs1;
> + u32 dram_dqm1;
> + u32 dram_sdqs6;
> + u32 dram_dqm6;
> + u32 dram_sdqs7;
> + u32 dram_dqm7;
> +}__attribute__((packed, aligned(4)));
> +
> +#define MX6Q_IOM_GRP_BASE 0x020e0700
> +struct mx6q_iomux_grp_regs {
> + u32 res1[18];
> + u32 grp_b7ds;
> + u32 grp_addds;
> + u32 grp_ddrmode_ctl;
> + u32 res2;
> + u32 grp_ddrpke;
> + u32 res3[6];
> + u32 grp_ddrmode;
> + u32 res4[3];
> + u32 grp_b0ds;
> + u32 grp_b1ds;
> + u32 grp_ctlds;
> + u32 res5;
> + u32 grp_b2ds;
> + u32 grp_ddr_type;
> + u32 grp_b3ds;
> + u32 grp_b4ds;
> + u32 grp_b5ds;
> + u32 grp_b6ds;
> +}__attribute__((packed, aligned(4)));
> +
> +#define MX6DL_IOM_DDR_BASE 0x020e0400
> +struct mx6dl_iomux_ddr_regs {
> + u32 res1[25];
> + u32 dram_cas;
> + u32 res2[2];
> + u32 dram_dqm0;
> + u32 dram_dqm1;
> + u32 dram_dqm2;
> + u32 dram_dqm3;
> + u32 dram_dqm4;
> + u32 dram_dqm5;
> + u32 dram_dqm6;
> + u32 dram_dqm7;
> + u32 dram_ras;
> + u32 dram_reset;
> + u32 res3[2];
> + u32 dram_sdba2;
> + u32 dram_sdcke0;
> + u32 dram_sdcke1;
> + u32 dram_sdclk_0;
> + u32 dram_sdclk_1;
> + u32 dram_sdodt0;
> + u32 dram_sdodt1;
> + u32 dram_sdqs0;
> + u32 dram_sdqs1;
> + u32 dram_sdqs2;
> + u32 dram_sdqs3;
> + u32 dram_sdqs4;
> + u32 dram_sdqs5;
> + u32 dram_sdqs6;
> + u32 dram_sdqs7;
> +}__attribute__((packed, aligned(4)));
> +
> +#define MX6DL_IOM_GRP_BASE 0x020e0700
> +struct mx6dl_iomux_grp_regs {
> + u32 res1[18];
> + u32 grp_b7ds;
> + u32 grp_addds;
> + u32 grp_ddrmode_ctl;
> + u32 grp_ddrpke;
> + u32 res2[2];
> + u32 grp_ddrmode;
> + u32 grp_b0ds;
> + u32 res3;
> + u32 grp_ctlds;
> + u32 grp_b1ds;
> + u32 grp_ddr_type;
> + u32 grp_b2ds;
> + u32 grp_b3ds;
> + u32 grp_b4ds;
> + u32 grp_b5ds;
> + u32 res4;
> + u32 grp_b6ds;
> +}__attribute__((packed, aligned(4)));
> +
> +#endif
>
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
On 11/12/2013 03:46 PM, Chin Liang See wrote: > Hi all, > > On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote: >> On 11/12/2013 10:56 AM, Detlev Zundel wrote: >>> Hi Michal, >>> On 11/11/2013 09:33 PM, Tom Rini wrote: > On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: > >> Altera Cyclone 5 board is very different board (big, rectangular, >> expensive) than EBV Socrates (small, circular, cheap) board. Different >> parts are used there, too, but same configuration of u-boot works on >> both. Nevertheless, printing wrong name confuses users. >> >> Therefore this splits the configuration so that u-boot knows they are >> different. So far it is only used for correcting the puts, but there >> may be other uses in future. >> >> Signed-off-by: Pavel Machek > > Is there any way at run time to tell which board we are on? Why do you care about board name in general? >>> >>> We care for board names for a very long time in U-Boot and I'd like to >>> keep this. I actually expect a sensible board name on any platform that >>> I touch. The board name is an important extra information additional to >>> the SoC name. So the question is the other way round - since when do we >>> _not_ care about board names? >> >> There could be i2c memory on board where you can find out this information >> but that's >> problematic if it is empty or you want to use this i2c for something else. >> For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design >> (if user is smart enough board name is the part of hw design name). >> For zynq/socfpga sensible solution is probably to load this name for DTS. >> > > Currently, the SOCFPGA SPL is customized through a set of handoff files > which located at board folders. These handoff files are generated by > tools based on board and user design in FPGA. With that, not much > decision being made during run time based on the board. With this > handoff and tools approach, it will shield off the complexity of > hardware configuration and errors (if user change it manually without > tools help). Thanks Which nice copy of our approach. :-) But anyway I believe that you are also generating one macro which define name of this configuration based on hw design/board you are using. And then you can use this macro for showing board/design name in u-boot. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
On Tue, Nov 12, 2013 at 10:56:29AM +0100, Detlev Zundel wrote: > Hi Michal, > > > On 11/11/2013 09:33 PM, Tom Rini wrote: > >> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: > >> > >>> Altera Cyclone 5 board is very different board (big, rectangular, > >>> expensive) than EBV Socrates (small, circular, cheap) board. Different > >>> parts are used there, too, but same configuration of u-boot works on > >>> both. Nevertheless, printing wrong name confuses users. > >>> > >>> Therefore this splits the configuration so that u-boot knows they are > >>> different. So far it is only used for correcting the puts, but there > >>> may be other uses in future. > >>> > >>> Signed-off-by: Pavel Machek > >> > >> Is there any way at run time to tell which board we are on? > > > > Why do you care about board name in general? > > We care for board names for a very long time in U-Boot and I'd like to > keep this. I actually expect a sensible board name on any platform that > I touch. The board name is an important extra information additional to > the SoC name. So the question is the other way round - since when do we > _not_ care about board names? We have a few different and somewhat conflicting concerns right now, and this particular platform is an example of a few of them: 1) It's not only possible, but desirable (seemingly, in this case) to support N boards with a single binary. The space-cost is outweighed by the usability-gain. We're seeing this in Freescale and TI parts, and I bet if I looked a tiny bit harder, other vendors too. 2) We want to know what particular board we're on, and perhaps even as part of deployment build something more trimmed down to just what we're running on. -- 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] Microblaze and Sparc boards are broken because of common timer func
On 11/12/2013 02:46 PM, Rob Herring wrote: > On 11/12/2013 06:32 AM, Michal Simek wrote: >> Hi Masahiro, >> >> On 11/12/2013 10:04 AM, Masahiro Yamada wrote: >>> Hello Michal >>> >>> This should be fixed by this patch - at least for microblaze. commit 65ba7add0d609bbd035b8d42fafdaf428ac24751 Author: Rob Herring Date: Fri Nov 8 08:40:43 2013 -0600 time: add weak annotation to timer_read_counter declaration A weak annotation is needed in order to prevent link errors when get_ticks is overridden. This fixes sandbox build. Signed-off-by: Rob Herring >>> >>> No. I tried both the current u-boot/master and commit >>> 65ba7add0d, but Microblaze board failed with the same error >>> message. >>> >> >> Look at this log - uboot section. >> http://www.monstr.eu/wiki/doku.php?id=log:2013-11-12_13_29_22 >> >> Which toolchain do you use? > > It builds for me with 4.8.0 from kernel.org, but I had to disable > systemace driver otherwise I get this error: yes. That's my behaviour too when I use this toolchain. I have to ping toolchain people to find out status of stack support in mainline gcc. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: use CONFIG_SYS_TEXT_BASE in relocation calculations
2013/11/12 Gabor Juhos : > 2013.11.11. 23:36 keltezéssel, Daniel Schwierzeck írta: > ... >>> >>> Any idea how can we resolve this properly? >>> >>> -Gabor >> >> following seems to work (in both variants with -bios and -pflash) >> >> #define CONFIG_SYS_TEXT_BASE 0xbe00 >> #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE > > Yeah, this definitely looks better than my solution. :) > > Do you want me to incorporate this into the 'malta: use unmapped flash base > address' patch, yes, one patch is sufficiently > or do you want to apply this separately? > -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: use CONFIG_SYS_TEXT_BASE in relocation calculations
2013.11.12. 16:40 keltezéssel, Daniel Schwierzeck írta: > 2013/11/12 Gabor Juhos : >> 2013.11.11. 23:36 keltezéssel, Daniel Schwierzeck írta: >> > ... Any idea how can we resolve this properly? -Gabor >>> >>> following seems to work (in both variants with -bios and -pflash) >>> >>> #define CONFIG_SYS_TEXT_BASE 0xbe00 >>> #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE >> >> Yeah, this definitely looks better than my solution. :) >> >> Do you want me to incorporate this into the 'malta: use unmapped flash base >> address' patch, > > yes, one patch is sufficiently Ok. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] malta: use unmapped flash base address
The physical base address of the NOR flash is 0x1e00
on the Malta boards. The hardware also maps the first 4MiB
of the flash into the 0x1fc0-0x1fff range.
Currently, U-Boot uses the mapped address to access the
flash, which does not work in recent qemu versions.
Since commit a427338b222b43197c2776cbc996936df0302f51
(mips_malta: correct reading MIPS revision at 0x1fc00010)
writing to the mapped address space causes a CPU exception.
Due to the exception, U-Boot hangs during boot when it tries
to detect the CFI flash chip.
Use the correct physical address for the MALTA_FLASH_BASE
constant to fix the problem. In order to avoid relocation
problems, also update the CONFIG_SYS_{TEXT,MONITOR}_BASE
constants.
The change makes it possible to start U-Boot on a Malta
board emulated with Qemu 1.6.1 and 1.7.0-rc0. It also
works on older versions (tested with 1.1.1, 1.2.2, 1.4.2,
1.5.3).
Signed-off-by: Gabor Juhos
Signed-off-by: Daniel Schwierzeck
Cc: Paul Burton
---
Changes since v1:
- update CONFIG_SYS_{TEXT,MONITOR}_BASE constants
- update commit message
---
arch/mips/include/asm/malta.h |2 +-
include/configs/malta.h |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h
index 9b1100b..bd9043d 100644
--- a/arch/mips/include/asm/malta.h
+++ b/arch/mips/include/asm/malta.h
@@ -44,7 +44,7 @@
#define MALTA_RESET_BASE 0x1f000500
#define GORESET0x42
-#define MALTA_FLASH_BASE 0x1fc0
+#define MALTA_FLASH_BASE 0x1e00
#define MALTA_REVISION 0x1fc00010
#define MALTA_REVISION_CORID_SHF 10
diff --git a/include/configs/malta.h b/include/configs/malta.h
index 4098e72..458c33a 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -40,8 +40,8 @@
/*
* Memory map
*/
-#define CONFIG_SYS_TEXT_BASE 0xbfc0 /* Rom version */
-#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE
+#define CONFIG_SYS_TEXT_BASE 0xbe00 /* Rom version */
+#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE
#define CONFIG_SYS_SDRAM_BASE 0x8000 /* Cached addr */
#define CONFIG_SYS_MEM_SIZE(256 * 1024 * 1024)
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master, v2
Hi Tom, On Tue, 12 Nov 2013 10:03:51 -0500, Tom Rini wrote: > Hey, > > The following changes since commit 85b8c5c4bf80025de4632ae6c9a8a606e51508a4: > > Merge branch 'iu-boot/master' into 'u-boot-arm/master' (2013-11-09 22:59:47 > +0100) > > are available in the git repository at: > > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to 56eb3da43fab5990a4b7bc118b76c7cae2ceb140: > > arm, am335x: update for the siemens boards (2013-11-12 09:53:59 -0500) > > > Andrew Bradford (1): > am335x_evm: Fix CONS_INDEX numbering > > Heiko Schocher (3): > bootcount: store bootcount var in environment > arm, am33x: make RTC32K OSC enable configurable > usb, g_dnl: make bcdDevice value configurable > > Igor Grinberg (1): > cm-t35: use gpio_led driver for status led > > Matt Porter (1): > boards.cfg: update email address for ti814x_evm maintainer > > Samuel Egli (1): > arm, am335x: update for the siemens boards > > Tom Rini (2): > am33xx: Make SoC bootcount driver have its own symbol > omap730p2: Remove board > > README | 19 ++ > arch/arm/cpu/armv7/am33xx/board.c |4 + > board/compulab/cm_t35/Makefile |2 +- > board/compulab/cm_t35/leds.c | 33 --- > board/siemens/common/factoryset.c | 24 +- > board/siemens/common/factoryset.h |2 + > board/siemens/dxr2/board.c | 11 +- > board/siemens/dxr2/board.h |9 +- > board/siemens/dxr2/mux.c | 158 +++ > board/siemens/pxm2/board.c |3 +- > board/siemens/rut/board.c | 51 +++- > board/ti/omap730p2/Makefile|9 - > board/ti/omap730p2/README.omap730p2| 91 --- > board/ti/omap730p2/config.mk | 25 -- > board/ti/omap730p2/flash.c | 463 > > board/ti/omap730p2/lowlevel_init.S | 379 -- > board/ti/omap730p2/omap730p2.c | 255 -- > boards.cfg | 15 +- > doc/README.scrapyard |5 +- > drivers/bootcount/Makefile |3 +- > drivers/bootcount/bootcount_davinci.c |4 + > drivers/bootcount/bootcount_env.c | 29 ++ > drivers/usb/gadget/g_dnl.c | 23 +- > include/configs/am335x_evm.h |4 + > include/configs/cm_t35.h |9 +- > include/configs/dxr2.h | 13 +- > include/configs/h2_p2_dbg_board.h | 120 - > include/configs/omap730.h | 246 - > include/configs/omap730p2.h| 173 > include/configs/pxm2.h |7 +- > include/configs/rut.h | 10 +- > include/configs/siemens-am33x-common.h | 69 +++-- > include/configs/ti_am335x_common.h |5 +- > 33 files changed, 404 insertions(+), 1869 deletions(-) > delete mode 100644 board/compulab/cm_t35/leds.c > delete mode 100644 board/ti/omap730p2/Makefile > delete mode 100644 board/ti/omap730p2/README.omap730p2 > delete mode 100644 board/ti/omap730p2/config.mk > delete mode 100644 board/ti/omap730p2/flash.c > delete mode 100644 board/ti/omap730p2/lowlevel_init.S > delete mode 100644 board/ti/omap730p2/omap730p2.c > create mode 100644 drivers/bootcount/bootcount_env.c > delete mode 100644 include/configs/h2_p2_dbg_board.h > delete mode 100644 include/configs/omap730.h > delete mode 100644 include/configs/omap730p2.h > Applied to u-boot-arm/master, thanks! Note: number of boards failing due to CONFIG_SYS_HZ down from 11 to 8, namely: scb9328 palmtc balloon3 mini2440 zipitz2 palmld omap3_zoom2 mx1ads. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question re HYP mode and IRQ/FIQ stack setting
On 12 November 2013 03:41, Albert ARIBAUD wrote: > (Cc:ing Andre and Christoffer as they have discussed HYP on the ML.) > > Hello, > > I am working on changing the way IRQ/FIQ stacks are set up, from > "on-the-fly in a hurry while in the handler" to "during init, so that > when entering the handler, the stack is already correct". > > Setting the stack then requires switching from the current mode (in > most cases, SVC32, 0x13) to IRQ (0x11) or FIQ (0x12) mode, in order to > set the right banked SP, then back into the original mode. > > However, in the first lines of reset in arch/arm/cpu/armv7/start.S, the > possibility of U-Boot being started in HYP mode (0x1A) is considered > and, if in HYP mode, no switch to SVC32 is performed. > > I understand that the problem here is, if we drop from HYP to SVC32, > then we cannot go back to HYP, and we want to be able to remain in HYP. correct (not without setting up a trap handler in Hyp mode and trapping to Hyp mode) > > Does this also apply to dropping from HYP to IRQ or FIQ mode, i.e., if > we do such a drop, are we prevented from rising back from IRQ or FIQ > mode to HYP? I seem to remember such an issue, but I am no specialist > in HYP, so any help is welcome. Yes, it also applies. Hyp is strictly more privileged (PL2) than all the PL1 modes (SVC, SYS, IRQ, FIQ, ABT, UND) and therefore requires a trap to go from PL1 to PL2 (basically this is how hardware protection works - just like with syscalls from user mode to PL1). You can use MSR and MRS instructions to access the IRQ and FIQ registers directly from Hyp mode though. -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador wrote: > Hello Vadim, > > On Tue, Nov 12, 2013 at 3:21 AM, Vadim Bendebury (вб) > wrote: >> Gentlemen, I have not forgotten our discussion regarding setting up a >> sample gerrit server for u-boot during the ELCE mini-summit. Sorry >> for this long and not very clear email, if there is any interest I >> will be glad to answer questions and address concerns to the best of >> my ability, and I am sure Simon (sjg@) will pitch in. > Hello Ottavio, > I support the idea about using Gerrit. I've been using it a lot for > O.S. Systems products and it works very well. > exactly, it certainly is very different from what's in use now, but offers many advantages and results in highly improved productivity. > Once I saw this announcement I thought the same thing as Albert: how > custodians will have their trees there? > It is easy to create multiple projects, one per custodian. --vb > I think just doing auto-assignment of patches would work quite well. > > -- > 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] u-boot gerrit server
On Tue, Nov 12, 2013 at 2:42 AM, Albert ARIBAUD wrote: > Hi Vadim, > > On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) > wrote: > > >> For the purposes of this demo the patches submitted for review were >> generated by a script I wrote. The script scrapes >> http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches >> from there and tries applying them. Not all patches apply cleanly (as >> some of them are for branches). > > How do we intend to handle this? Will we move to a single > repository, with each patch getting reviewers assigned based on > which parts of the code it touches? Or move from repos to branches, > one per current custodian repo? Or something else yet? > Hi Albert, I *think* the way to go is to create multiple projects, one per custodian, such that the upload URLs are different. >> If the patch applies cleanly, the script adds two stanzas to the patch > >> >> - Change-Id: generated by git >> - Patch-At: a reference to the patchwork page where the patch was >> downloaded from > > 'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'? It should not be there at all, scraping the patchwork is just a means of seeding the server with patches to show how this looks. In the proper use case each user will puth their patches to the server, so there is no need in the cross reference to patchwork. > >> and uploads the patch for review as the user named 'Gerrit Tester'. >> Each upload creates a new git branch just for review purposes. > > (I'm skipping the gerrit workflow description here as I have > used gerrit extensively in my, ahem, previous job) > > I'm fine with using gerrit and yes, it can be a useful tool, not only > regarding review, but also for learning the whys and hows of code > changes through the comments from both reviewers and submitters > (and I am in strong favor of a policy that every reviewer comment > must be addressed by a supmitter reply, even the default will-do one. > exactly, this is the main advantage IMO also, keeping track of changes and comments becomes so much more robust. Also, gerrit allows to see diffs between patches, this is what email based review system can not easily deliver. > One drawback though: I cannot seem to be able to use my U-Boot mail > address, even though it is a secondary address of my G+ account; > gerrit only wants to see my gmail address. I sure hope that I am not > required to use a gmail address to identify myself as the author > of my own patches within the U-Boot project. > This should not be the case, but there are some kinks with multiple accounts. Can you try opening an 'incognito' window and sign up through it? --vb >> --vb > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) wrote: > On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador > wrote: >> Once I saw this announcement I thought the same thing as Albert: how >> custodians will have their trees there? >> > > It is easy to create multiple projects, one per custodian. Yes but than Tom would need to send another branch for review or directly push into master? Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge... -- 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] u-boot gerrit server
On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador wrote: > On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) > wrote: >> On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador >> wrote: >>> Once I saw this announcement I thought the same thing as Albert: how >>> custodians will have their trees there? >>> >> >> It is easy to create multiple projects, one per custodian. > > Yes but than Tom would need to send another branch for review or > directly push into master? > I am not sure what would be the best way of doing it, but the bottom line is that there still would be multiple git repos with chunks of code going upstream once accepted by custodians. > Besides, how people will 'transfer' one patch from one tree to > another? This will happen quite often as someone mistakenly sending a > patch for the wrong tree or custodians wanting the set to go together > in a single merge... > How is it handled today? Gerrit is after all just a means of keeping track of patches in a more efficient way, the rest could be similar to what is in use now, or enhanced using gerrit's features. --vb > -- > 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] Question re HYP mode and IRQ/FIQ stack setting
On 11/12/2013 05:28 PM, Christoffer Dall wrote:
On 12 November 2013 03:41, Albert ARIBAUD wrote:
(Cc:ing Andre and Christoffer as they have discussed HYP on the ML.)
Hello,
I am working on changing the way IRQ/FIQ stacks are set up, from
"on-the-fly in a hurry while in the handler" to "during init, so that
when entering the handler, the stack is already correct".
Setting the stack then requires switching from the current mode (in
most cases, SVC32, 0x13) to IRQ (0x11) or FIQ (0x12) mode, in order to
set the right banked SP, then back into the original mode.
However, in the first lines of reset in arch/arm/cpu/armv7/start.S, the
possibility of U-Boot being started in HYP mode (0x1A) is considered
and, if in HYP mode, no switch to SVC32 is performed.
I understand that the problem here is, if we drop from HYP to SVC32,
then we cannot go back to HYP, and we want to be able to remain in HYP.
Right, that is to keep the HYP mode in case the firmware already enabled
it. This is for instance the case on the new Calxeda Midway. Actually
this approach will become more widespread, since it is required to
provide proper PSCI support (which needs to run in secure state, so
requires an even higher privilege level than HYP: EL3 in the new ARM speak).
correct (not without setting up a trap handler in Hyp mode and
trapping to Hyp mode)
Does this also apply to dropping from HYP to IRQ or FIQ mode, i.e., if
we do such a drop, are we prevented from rising back from IRQ or FIQ
mode to HYP? I seem to remember such an issue, but I am no specialist
in HYP, so any help is welcome.
Yes, it also applies. Hyp is strictly more privileged (PL2) than all
the PL1 modes (SVC, SYS, IRQ, FIQ, ABT, UND) and therefore requires a
trap to go from PL1 to PL2 (basically this is how hardware protection
works - just like with syscalls from user mode to PL1).
Thanks Christoffer for clarifying this, I wasn't sure about FIQ, but of
course your explanation (EL1 vs. EL2) makes totally sense.
But I wonder what happens when we enter FIQ or IRQ due to an actual
interrupt. Will the CPU return into HYP mode when the handler returns?
That is subject to some HYP mode register configuration, right?
You can use MSR and MRS instructions to access the IRQ and FIQ
registers directly from Hyp mode though.
Albert,
so does "msr sp_{fiq,irq}, r" fix your problem? Or do you still need
to actually go into one of these modes for further setup?
Regards,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) wrote: > On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador > wrote: >> On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) >> wrote: >>> On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador >>> wrote: Once I saw this announcement I thought the same thing as Albert: how custodians will have their trees there? >>> >>> It is easy to create multiple projects, one per custodian. >> >> Yes but than Tom would need to send another branch for review or >> directly push into master? >> > > I am not sure what would be the best way of doing it, but the bottom > line is that there still would be multiple git repos with chunks of > code going upstream once accepted by custodians. > >> Besides, how people will 'transfer' one patch from one tree to >> another? This will happen quite often as someone mistakenly sending a >> patch for the wrong tree or custodians wanting the set to go together >> in a single merge... >> > > How is it handled today? Gerrit is after all just a means of keeping > track of patches in a more efficient way, the rest could be similar to > what is in use now, or enhanced using gerrit's features. Currently it is just reassigned in Patchwork; using multiple trees will complicate this. Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the problems/issues we need to find solutions to be able to use/try it. -- 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] u-boot gerrit server
On Tue, Nov 12, 2013 at 9:00 AM, Otavio Salvador wrote: > On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) > wrote: >> On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador >> wrote: >>> On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) >>> wrote: On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador wrote: > Once I saw this announcement I thought the same thing as Albert: how > custodians will have their trees there? > It is easy to create multiple projects, one per custodian. >>> >>> Yes but than Tom would need to send another branch for review or >>> directly push into master? >>> >> >> I am not sure what would be the best way of doing it, but the bottom >> line is that there still would be multiple git repos with chunks of >> code going upstream once accepted by custodians. >> >>> Besides, how people will 'transfer' one patch from one tree to >>> another? This will happen quite often as someone mistakenly sending a >>> patch for the wrong tree or custodians wanting the set to go together >>> in a single merge... >>> >> >> How is it handled today? Gerrit is after all just a means of keeping >> track of patches in a more efficient way, the rest could be similar to >> what is in use now, or enhanced using gerrit's features. > > Currently it is just reassigned in Patchwork; using multiple trees > will complicate this. > > Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the > problems/issues we need to find solutions to be able to use/try it. > Ottavio, these all are certainly very good questions to ask. Admittedly, I am not very much involved in the u-boot review process, so I am sure there are details to figure out. It is just a question of buying into a web/GUI based review system, once that decision is made the details could be sorted out in more ways than one. --v > -- > 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] Question re HYP mode and IRQ/FIQ stack setting
On 12 November 2013 08:53, Andre Przywara wrote:
> On 11/12/2013 05:28 PM, Christoffer Dall wrote:
>>
>> On 12 November 2013 03:41, Albert ARIBAUD
>> wrote:
>>>
>>> (Cc:ing Andre and Christoffer as they have discussed HYP on the ML.)
>>>
>>> Hello,
>>>
>>> I am working on changing the way IRQ/FIQ stacks are set up, from
>>> "on-the-fly in a hurry while in the handler" to "during init, so that
>>> when entering the handler, the stack is already correct".
>>>
>>> Setting the stack then requires switching from the current mode (in
>>> most cases, SVC32, 0x13) to IRQ (0x11) or FIQ (0x12) mode, in order to
>>> set the right banked SP, then back into the original mode.
>>>
>>> However, in the first lines of reset in arch/arm/cpu/armv7/start.S, the
>>> possibility of U-Boot being started in HYP mode (0x1A) is considered
>>> and, if in HYP mode, no switch to SVC32 is performed.
>>>
>>> I understand that the problem here is, if we drop from HYP to SVC32,
>>> then we cannot go back to HYP, and we want to be able to remain in HYP.
>
>
> Right, that is to keep the HYP mode in case the firmware already enabled it.
> This is for instance the case on the new Calxeda Midway. Actually this
> approach will become more widespread, since it is required to provide proper
> PSCI support (which needs to run in secure state, so requires an even higher
> privilege level than HYP: EL3 in the new ARM speak).
>
What Andre is referring to here is that the PSCI specs mandates the
CPUs that a are turned on using PSCI go through the highest privilege
level implemented in the non-secure state. I couldn't actually find
the place in the PSCI specs where this is also true for the boot CPU,
but granted, anything else will be quite strange.
So to stay in 32-bit ARMv7 terminology here, a likely case for systems
with PSCI support in the firmware is that all cores will enter U-Boot
in non-secure PL2 (hyp) mode and power management is done by calling
SMC calls to the firmware that sits in the secure monitor.
>
>> correct (not without setting up a trap handler in Hyp mode and
>> trapping to Hyp mode)
>>
>>>
>>> Does this also apply to dropping from HYP to IRQ or FIQ mode, i.e., if
>>> we do such a drop, are we prevented from rising back from IRQ or FIQ
>>> mode to HYP? I seem to remember such an issue, but I am no specialist
>>> in HYP, so any help is welcome.
>>
>>
>> Yes, it also applies. Hyp is strictly more privileged (PL2) than all
>> the PL1 modes (SVC, SYS, IRQ, FIQ, ABT, UND) and therefore requires a
>> trap to go from PL1 to PL2 (basically this is how hardware protection
>> works - just like with syscalls from user mode to PL1).
>
>
> Thanks Christoffer for clarifying this, I wasn't sure about FIQ, but of
> course your explanation (EL1 vs. EL2) makes totally sense.
>
> But I wonder what happens when we enter FIQ or IRQ due to an actual
> interrupt. Will the CPU return into HYP mode when the handler returns?
> That is subject to some HYP mode register configuration, right?
>
Not quite, interrupts in Hyp mode will always be taken to Hyp mode
(unless it's secure interrupts, which are taken to monitor mode). In
fact, when you have the virtualization extensions, you also have the
security extensions, and I think all FIQs go to the secure mode here,
so you can't ever see an FIQ in Hyp mode. I may be mistaken here,
someone should look it up and verify.
Now, you can configure Hyp mode to trap interrupts raised while in any
PL1 or PL0 mode to Hyp mode.
I suspect that if you are in Hyp mode, you should not worry about
FIQ/IRQ mode, but just make sure to configure Hyp mode properly to
handle interrupts. (it's a separate entry in the exception vector and
you probably need to look at the HSR register whn you've taken an
interrupt). So, as Andre suggests below, it depends on your use case.
>
>> You can use MSR and MRS instructions to access the IRQ and FIQ
>> registers directly from Hyp mode though.
>
>
> Albert,
> so does "msr sp_{fiq,irq}, r" fix your problem? Or do you still need to
> actually go into one of these modes for further setup?
>
> Regards,
> Andre.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
Hi Vadim, On Tue, 12 Nov 2013 08:33:46 -0800, Vadim Bendebury (вб) wrote: > On Tue, Nov 12, 2013 at 2:42 AM, Albert ARIBAUD > wrote: > > Hi Vadim, > > > > On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) > > wrote: > > > > > >> For the purposes of this demo the patches submitted for review were > >> generated by a script I wrote. The script scrapes > >> http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches > >> from there and tries applying them. Not all patches apply cleanly (as > >> some of them are for branches). > > > > How do we intend to handle this? Will we move to a single > > repository, with each patch getting reviewers assigned based on > > which parts of the code it touches? Or move from repos to branches, > > one per current custodian repo? Or something else yet? > > > > Hi Albert, > > I *think* the way to go is to create multiple projects, one per > custodian, such that the upload URLs are different. > > >> If the patch applies cleanly, the script adds two stanzas to the patch > > > >> > >> - Change-Id: generated by git > >> - Patch-At: a reference to the patchwork page where the patch was > >> downloaded from > > > > 'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'? > > It should not be there at all, scraping the patchwork is just a means > of seeding the server with patches to show how this looks. > > In the proper use case each user will puth their patches to the > server, so there is no need in the cross reference to patchwork. > > > >> and uploads the patch for review as the user named 'Gerrit Tester'. > >> Each upload creates a new git branch just for review purposes. > > > > (I'm skipping the gerrit workflow description here as I have > > used gerrit extensively in my, ahem, previous job) > > > > I'm fine with using gerrit and yes, it can be a useful tool, not only > > regarding review, but also for learning the whys and hows of code > > changes through the comments from both reviewers and submitters > > (and I am in strong favor of a policy that every reviewer comment > > must be addressed by a supmitter reply, even the default will-do one. > > > > exactly, this is the main advantage IMO also, keeping track of changes > and comments becomes so much more robust. > > Also, gerrit allows to see diffs between patches, this is what email > based review system can not easily deliver. > > > One drawback though: I cannot seem to be able to use my U-Boot mail > > address, even though it is a secondary address of my G+ account; > > gerrit only wants to see my gmail address. I sure hope that I am not > > required to use a gmail address to identify myself as the author > > of my own patches within the U-Boot project. > > > > This should not be the case, but there are some kinks with multiple > accounts. Can you try opening an 'incognito' window and sign up > through it? I did try anyway, but it did nothing, and that was quite predictable, and here's why: I didn't mean gerrit got mixed up between two of my Google+ accounts, as I only have one account, and can thus only log in with this one. But This account's main address i a gmail one, and my so-to-speak "U-Boot e-mail address", which I use for the ML, and in 'Copyright' lines in the U-Boot code base, and on Patchwork) is a secondary address of my Google+ account. And gerrit does not know of my secondary addresses, which make it unable to recognize me, once logged in, as the submitter of patches posted under my "U-Boot" address. > --vb Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
Hi Otavio, On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador wrote: > On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) > wrote: > > On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador > > wrote: > >> On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) > >> wrote: > >>> On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador > >>> wrote: > Once I saw this announcement I thought the same thing as Albert: how > custodians will have their trees there? > > >>> > >>> It is easy to create multiple projects, one per custodian. > >> > >> Yes but than Tom would need to send another branch for review or > >> directly push into master? > >> > > > > I am not sure what would be the best way of doing it, but the bottom > > line is that there still would be multiple git repos with chunks of > > code going upstream once accepted by custodians. > > > >> Besides, how people will 'transfer' one patch from one tree to > >> another? This will happen quite often as someone mistakenly sending a > >> patch for the wrong tree or custodians wanting the set to go together > >> in a single merge... > >> > > > > How is it handled today? Gerrit is after all just a means of keeping > > track of patches in a more efficient way, the rest could be similar to > > what is in use now, or enhanced using gerrit's features. > > Currently it is just reassigned in Patchwork; using multiple trees > will complicate this. How about one branch per custodian? At my previous job we had a couple branches, one per distinct "product". > Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the > problems/issues we need to find solutions to be able to use/try it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
On Tue, Nov 12, 2013 at 3:07 PM, Vadim Bendebury (вб) wrote: > On Tue, Nov 12, 2013 at 9:00 AM, Otavio Salvador > wrote: >> On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) >> wrote: >>> On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador >>> wrote: On Tue, Nov 12, 2013 at 2:36 PM, Vadim Bendebury (вб) wrote: > On Tue, Nov 12, 2013 at 3:07 AM, Otavio Salvador > wrote: >> Once I saw this announcement I thought the same thing as Albert: how >> custodians will have their trees there? >> > > It is easy to create multiple projects, one per custodian. Yes but than Tom would need to send another branch for review or directly push into master? >>> >>> I am not sure what would be the best way of doing it, but the bottom >>> line is that there still would be multiple git repos with chunks of >>> code going upstream once accepted by custodians. >>> Besides, how people will 'transfer' one patch from one tree to another? This will happen quite often as someone mistakenly sending a patch for the wrong tree or custodians wanting the set to go together in a single merge... >>> >>> How is it handled today? Gerrit is after all just a means of keeping >>> track of patches in a more efficient way, the rest could be similar to >>> what is in use now, or enhanced using gerrit's features. >> >> Currently it is just reassigned in Patchwork; using multiple trees >> will complicate this. >> >> Don't get me wrong, I enjoy Gerrit, I am just trying to bring up the >> problems/issues we need to find solutions to be able to use/try it. >> > > Ottavio, these all are certainly very good questions to ask. > Admittedly, I am not very much involved in the u-boot review process, > so I am sure there are details to figure out. > > It is just a question of buying into a web/GUI based review system, > once that decision is made the details could be sorted out in more > ways than one. Sorry but this is not that simple. Personally I dislike the idea of multiple U-Boot trees (when it comes to Gerrit workflow). What I think it'd be possible to get working would be: Custodians would have Submit rights Custodians would have +2 review rights "Normal" people would have +1 review rights CI system could have the +1 for verified Single tree So essentially custodians could be assigned using some keyword, file matching and other clever heuristics, but it'd give freedom for them to 'drop' their review need or add someone else. Once they submit a change it goes straight to 'master' branch. This easy the merging of stuff but this ends with the sub-trees. -- 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] u-boot gerrit server
Hello Albert, On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD wrote: > On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador > wrote: > >> On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) >> wrote: >> > On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador >> > wrote: >> >> Besides, how people will 'transfer' one patch from one tree to >> >> another? This will happen quite often as someone mistakenly sending a >> >> patch for the wrong tree or custodians wanting the set to go together >> >> in a single merge... >> >> >> > >> > How is it handled today? Gerrit is after all just a means of keeping >> > track of patches in a more efficient way, the rest could be similar to >> > what is in use now, or enhanced using gerrit's features. >> >> Currently it is just reassigned in Patchwork; using multiple trees >> will complicate this. > > How about one branch per custodian? At my previous job we had a couple > branches, one per distinct "product". I am not aware of a way to 'transfer' a patch from one branch to another. -- 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] u-boot gerrit server
Hi Otavio, On Tue, 12 Nov 2013 15:16:15 -0200, Otavio Salvador wrote: > Hello Albert, > > On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD > wrote: > > On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador > > wrote: > > > >> On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (вб) > >> wrote: > >> > On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador > >> > wrote: > >> >> Besides, how people will 'transfer' one patch from one tree to > >> >> another? This will happen quite often as someone mistakenly sending a > >> >> patch for the wrong tree or custodians wanting the set to go together > >> >> in a single merge... > >> >> > >> > > >> > How is it handled today? Gerrit is after all just a means of keeping > >> > track of patches in a more efficient way, the rest could be similar to > >> > what is in use now, or enhanced using gerrit's features. > >> > >> Currently it is just reassigned in Patchwork; using multiple trees > >> will complicate this. > > > > How about one branch per custodian? At my previous job we had a couple > > branches, one per distinct "product". > > I am not aware of a way to 'transfer' a patch from one branch to another. There would not be such transfers -- we don't do this right now with our trees. We do merge requests, which means pulling two custodian repos into the same working repo, doing a merge between what are now two custodian branches, and pushing the result back onto one of the custodian trees. So here, if there is one branch per custodian, what we would need is the ability to merge one custodian branch into another. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
On Tue, Nov 12, 2013 at 9:11 AM, Albert ARIBAUD wrote: > Hi Vadim, > > On Tue, 12 Nov 2013 08:33:46 -0800, Vadim Bendebury (вб) > wrote: > >> On Tue, Nov 12, 2013 at 2:42 AM, Albert ARIBAUD >> wrote: >> > Hi Vadim, >> > >> > On Mon, 11 Nov 2013 21:21:27 -0800, Vadim Bendebury (вб) >> > wrote: >> > >> > >> >> For the purposes of this demo the patches submitted for review were >> >> generated by a script I wrote. The script scrapes >> >> http://patchwork.ozlabs.org/project/uboot/list/, downloads the patches >> >> from there and tries applying them. Not all patches apply cleanly (as >> >> some of them are for branches). >> > >> > How do we intend to handle this? Will we move to a single >> > repository, with each patch getting reviewers assigned based on >> > which parts of the code it touches? Or move from repos to branches, >> > one per current custodian repo? Or something else yet? >> > >> >> Hi Albert, >> >> I *think* the way to go is to create multiple projects, one per >> custodian, such that the upload URLs are different. >> >> >> If the patch applies cleanly, the script adds two stanzas to the patch >> > >> >> >> >> - Change-Id: generated by git >> >> - Patch-At: a reference to the patchwork page where the patch was >> >> downloaded from >> > >> > 'Patch-At' seem ininformative to me. Why not 'Patchwork-URL'? >> >> It should not be there at all, scraping the patchwork is just a means >> of seeding the server with patches to show how this looks. >> >> In the proper use case each user will puth their patches to the >> server, so there is no need in the cross reference to patchwork. >> > >> >> and uploads the patch for review as the user named 'Gerrit Tester'. >> >> Each upload creates a new git branch just for review purposes. >> > >> > (I'm skipping the gerrit workflow description here as I have >> > used gerrit extensively in my, ahem, previous job) >> > >> > I'm fine with using gerrit and yes, it can be a useful tool, not only >> > regarding review, but also for learning the whys and hows of code >> > changes through the comments from both reviewers and submitters >> > (and I am in strong favor of a policy that every reviewer comment >> > must be addressed by a supmitter reply, even the default will-do one. >> > >> >> exactly, this is the main advantage IMO also, keeping track of changes >> and comments becomes so much more robust. >> >> Also, gerrit allows to see diffs between patches, this is what email >> based review system can not easily deliver. >> >> > One drawback though: I cannot seem to be able to use my U-Boot mail >> > address, even though it is a secondary address of my G+ account; >> > gerrit only wants to see my gmail address. I sure hope that I am not >> > required to use a gmail address to identify myself as the author >> > of my own patches within the U-Boot project. >> > >> >> This should not be the case, but there are some kinks with multiple >> accounts. Can you try opening an 'incognito' window and sign up >> through it? > > I did try anyway, but it did nothing, and that was quite predictable, > and here's why: I didn't mean gerrit got mixed up between two of my > Google+ accounts, as I only have one account, and can thus only log in > with this one. But This account's main address i a gmail one, and my > so-to-speak "U-Boot e-mail address", which I use for the ML, and in > 'Copyright' lines in the U-Boot code base, and on Patchwork) is a > secondary address of my Google+ account. And gerrit does not know of my > secondary addresses, which make it unable to recognize me, once logged > in, as the submitter of patches posted under my "U-Boot" address. > Moving everybody to bcc so that we could sort this out without disturbing the rest. Have you tried creating a new account from the incognito window? You should be able to create an account with any arbitrary email. --v >> --vb > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
