Re: [U-Boot] [PATCH v2 2/2] arm: ls1021aqds: Enable driver model lpuart serial driver
On Tue, Feb 23, 2016 at 3:01 AM, York Sun wrote: > Convert ls1021aqds_nor_lpuart and ls1021aqds_ddr4_nor_lpuart to driver > model suport. Enable lpuart port driver. > > Signed-off-by: York Sun > CC: Alison Wang > CC: Bin Meng > > --- > > Changes in v2: > Fix default device tree name for > ls1021aqds_ddr4_nor_lpuart_defconfig > > arch/arm/dts/Makefile|1 + > arch/arm/dts/ls1021a-qds-lpuart.dts | 16 > configs/ls1021aqds_ddr4_nor_lpuart_defconfig |4 > configs/ls1021aqds_nor_lpuart_defconfig |4 > 4 files changed, 25 insertions(+) > create mode 100644 arch/arm/dts/ls1021a-qds-lpuart.dts > > Reviewed-by: Alison Wang Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd: mem: Show 64bit addresses which are tested
Fix print message to show full 64bit addresses.
Signed-off-by: Michal Simek
---
cmd/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/mem.c b/cmd/mem.c
index efa39296ef7a..a690957d0ff9 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -1038,7 +1038,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int
argc,
return -1;
}
- printf("Testing %08x ... %08x:\n", (uint)start, (uint)end);
+ printf("Testing %08lx ... %08lx:\n", start, end);
debug("%s:%d: start %#08lx end %#08lx\n", __func__, __LINE__,
start, end);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: serial: Move a carriage return before a line feed
Hi, Bin,
> On Wed, Feb 24, 2016 at 11:56 AM, Alison Wang
> wrote:
> > In general, a carriage return needs to execute before a line feed.
> > The patch is to change serial DM driver based on this rule.
> >
> > Signed-off-by: Alison Wang
> > ---
> > drivers/serial/serial-uclass.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/serial/serial-uclass.c
> > b/drivers/serial/serial-uclass.c index 1c447ff..f154eb1 100644
> > --- a/drivers/serial/serial-uclass.c
> > +++ b/drivers/serial/serial-uclass.c
> > @@ -123,11 +123,12 @@ static void _serial_putc(struct udevice *dev,
> char ch)
> > struct dm_serial_ops *ops = serial_get_ops(dev);
> > int err;
> >
> > + if (ch == '\n')
> > + _serial_putc(dev, '\r');
> > +
> > do {
> > err = ops->putc(dev, ch);
> > } while (err == -EAGAIN);
> > - if (ch == '\n')
> > - _serial_putc(dev, '\r');
> > }
> >
>
> We should also clean up all DM serial driver to remove this handling in
> their driver. eg: serial_lpuart.c/serial_mxc.c
>
[Alison Wang] Thanks for your advice. Yes, I agree. This handling in
particular driver is redundant.
It seems only serial_lpuart.c and serial_arc.c has this handling. For
serial_mxc.c, this handling is only in the non-DM .putc function,
but not in the DM .putc function. Do you think it is necessary to change
the non-DM .putc function?
Best Regards,
Alison Wang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: Remove ARM dcc from the list
Remove ARM Debug communication channel driver from the list of not converted drivers to DM. Signed-off-by: Michal Simek --- doc/driver-model/serial-howto.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/driver-model/serial-howto.txt b/doc/driver-model/serial-howto.txt index 61f2da323e7f..cddfb9fc0021 100644 --- a/doc/driver-model/serial-howto.txt +++ b/doc/driver-model/serial-howto.txt @@ -4,7 +4,6 @@ How to port a serial driver to driver model Almost all of the serial drivers have been converted as at January 2016. These ones remain: - arm_dcc.c mcfuart.c serial_bfin.c serial_pxa.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] patman: fix series-notes handling for buildman
On 2 February 2016 at 02:24, Albert ARIBAUD wrote:
> A patman series with a 'Series-notes' section causes
> buildman to crash with:
>
> self.series.notes += self.section
> TypeError: cannot concatenate 'str' and 'list' objects
>
> Fix by initializing series.notes as a one-element array
> rather than a scalar.
>
> Signed-off-by: Albert ARIBAUD
> ---
>
> Changes in v2:
> - fix typo in commit message ("rathen" -> "rather")
> - actually limit array initialization to series.notes
>
> tools/patman/series.py | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Simon Glass
Tested-by: Simon Glass
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dts: keep clock-names and clocks in SPL DTB if SPL_CLK is enabled
On 3 February 2016 at 04:51, Masahiro Yamada wrote: > These two properties are necessary for SPL to get clocks from DT. > > Note: > For now, only clock look-up by index is supported (clk_get_by_index() > function), so "clock-names" is never parsed in U-Boot. However, we > may want to support something like clk_get_by_name() in the future, > so let's keep "clock-names" as well as "clocks". > > Signed-off-by: Masahiro Yamada > --- > > dts/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] net: Move CONFIG_RTL8139 to Kconfig
Introduce CONFIG_RTL8139 in Kconfig and move over boards' defconfig to use that. Signed-off-by: Bin Meng --- configs/MPC8544DS_defconfig | 1 + drivers/net/Kconfig | 6 ++ include/configs/MPC8536DS.h | 1 - include/configs/MPC8544DS.h | 1 - include/configs/MPC8572DS.h | 1 - include/configs/MPC8641HPCN.h | 1 - include/configs/r2dplus.h | 1 - 7 files changed, 7 insertions(+), 5 deletions(-) diff --git a/configs/MPC8544DS_defconfig b/configs/MPC8544DS_defconfig index e4e2f9c..22ad4bb 100644 --- a/configs/MPC8544DS_defconfig +++ b/configs/MPC8544DS_defconfig @@ -3,4 +3,5 @@ CONFIG_MPC85xx=y CONFIG_TARGET_MPC8544DS=y CONFIG_NETDEVICES=y CONFIG_E1000=y +CONFIG_RTL8139=y CONFIG_SYS_NS16550=y diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index bc2f51d..3ac6b66 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -102,6 +102,12 @@ config PCH_GBE This MAC is present in Intel Platform Controller Hub EG20T. It supports 10/100/1000 Mbps operation. +config RTL8139 + bool "Realtek 8139 series Ethernet controller driver" + help + This driver supports Realtek 8139 series fast ethernet family of + PCI chipsets/adapters. + config XILINX_AXIEMAC depends on DM_ETH && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP) select PHYLIB diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h index 294be3b..22d204b 100644 --- a/include/configs/MPC8536DS.h +++ b/include/configs/MPC8536DS.h @@ -534,7 +534,6 @@ #undef CONFIG_EEPRO100 #undef CONFIG_TULIP -#undef CONFIG_RTL8139 #ifndef CONFIG_PCI_PNP #define PCI_ENET0_IOADDRCONFIG_SYS_PCI1_IO_BUS diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h index 0fa5fd3..2cfae77 100644 --- a/include/configs/MPC8544DS.h +++ b/include/configs/MPC8544DS.h @@ -303,7 +303,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #undef CONFIG_EEPRO100 #undef CONFIG_TULIP -#define CONFIG_RTL8139 #ifndef CONFIG_PCI_PNP #define PCI_ENET0_IOADDRCONFIG_SYS_PCI1_IO_BUS diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index b34a033..2a7ccda 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -501,7 +501,6 @@ #undef CONFIG_EEPRO100 #undef CONFIG_TULIP -#undef CONFIG_RTL8139 #ifndef CONFIG_PCI_PNP #define PCI_ENET0_IOADDRCONFIG_SYS_PCIE3_IO_BUS diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index a84db51..987e614 100644 --- a/include/configs/MPC8641HPCN.h +++ b/include/configs/MPC8641HPCN.h @@ -369,7 +369,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_PCI_PNP /* do pci plug-and-play */ -#define CONFIG_RTL8139 #undef CONFIG_EEPRO100 #undef CONFIG_TULIP diff --git a/include/configs/r2dplus.h b/include/configs/r2dplus.h index 2d1e56a..3610a2e 100644 --- a/include/configs/r2dplus.h +++ b/include/configs/r2dplus.h @@ -113,6 +113,5 @@ /* * Network device (RTL8139) support */ -#define CONFIG_RTL8139 #endif /* __CONFIG_H */ -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] net: Move CONFIG_RTL8169 to Kconfig
Introduce CONFIG_RTL8169 in Kconfig and move over boards' defconfig to use that. Signed-off-by: Bin Meng --- configs/beaver_defconfig| 1 + configs/cardhu_defconfig| 1 + configs/chromebox_panther_defconfig | 1 + configs/jetson-tk1_defconfig| 1 + configs/minnowmax_defconfig | 1 + configs/p2371-2180_defconfig| 1 + configs/trimslice_defconfig | 1 + drivers/net/Kconfig | 6 ++ include/configs/beaver.h| 1 - include/configs/cardhu.h| 1 - include/configs/chromebox_panther.h | 1 - include/configs/jetson-tk1.h| 1 - include/configs/minnowmax.h | 1 - include/configs/p2371-2180.h| 1 - include/configs/r7780mp.h | 1 - include/configs/sh7785lcr.h | 1 - include/configs/trimslice.h | 1 - 17 files changed, 13 insertions(+), 9 deletions(-) diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig index 8add08d..3804d4d 100644 --- a/configs/beaver_defconfig +++ b/configs/beaver_defconfig @@ -14,6 +14,7 @@ CONFIG_CMD_GPIO=y # CONFIG_CMD_NFS is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_RTL8169=y CONFIG_PCI_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_TEGRA20_SLINK=y diff --git a/configs/cardhu_defconfig b/configs/cardhu_defconfig index c9f565a..ac37326 100644 --- a/configs/cardhu_defconfig +++ b/configs/cardhu_defconfig @@ -14,6 +14,7 @@ CONFIG_CMD_GPIO=y # CONFIG_CMD_NFS is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_RTL8169=y CONFIG_PCI_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_TEGRA20_SLINK=y diff --git a/configs/chromebox_panther_defconfig b/configs/chromebox_panther_defconfig index 86014c5..37448eb 100644 --- a/configs/chromebox_panther_defconfig +++ b/configs/chromebox_panther_defconfig @@ -26,6 +26,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_DM_ETH=y +CONFIG_RTL8169=y CONFIG_DM_PCI=y CONFIG_DM_RTC=y CONFIG_SYS_NS16550=y diff --git a/configs/jetson-tk1_defconfig b/configs/jetson-tk1_defconfig index efc4aee..b2ae53f 100644 --- a/configs/jetson-tk1_defconfig +++ b/configs/jetson-tk1_defconfig @@ -14,6 +14,7 @@ CONFIG_CMD_GPIO=y # CONFIG_CMD_NFS is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_RTL8169=y CONFIG_PCI_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_TEGRA114_SPI=y diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig index 5d5579a..ff9e44c 100644 --- a/configs/minnowmax_defconfig +++ b/configs/minnowmax_defconfig @@ -25,6 +25,7 @@ CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_DM_ETH=y +CONFIG_RTL8169=y CONFIG_DM_PCI=y CONFIG_DM_RTC=y CONFIG_DEBUG_UART=y diff --git a/configs/p2371-2180_defconfig b/configs/p2371-2180_defconfig index 5e5139b..ddd7320 100644 --- a/configs/p2371-2180_defconfig +++ b/configs/p2371-2180_defconfig @@ -13,6 +13,7 @@ CONFIG_CMD_GPIO=y # CONFIG_CMD_NFS is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_RTL8169=y CONFIG_PCI_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_TEGRA114_SPI=y diff --git a/configs/trimslice_defconfig b/configs/trimslice_defconfig index e34faa3..c6a10f0 100644 --- a/configs/trimslice_defconfig +++ b/configs/trimslice_defconfig @@ -14,6 +14,7 @@ CONFIG_CMD_GPIO=y # CONFIG_CMD_NFS is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_RTL8169=y CONFIG_PCI_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_TEGRA20_SFLASH=y diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 3ac6b66..2a229b8 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -108,6 +108,12 @@ config RTL8139 This driver supports Realtek 8139 series fast ethernet family of PCI chipsets/adapters. +config RTL8169 + bool "Realtek 8169 series Ethernet controller driver" + help + This driver supports Realtek 8169 series gigabit ethernet family of + PCI/PCIe chipsets/adapters. + config XILINX_AXIEMAC depends on DM_ETH && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP) select PHYLIB diff --git a/include/configs/beaver.h b/include/configs/beaver.h index c672a8e..21ee954 100644 --- a/include/configs/beaver.h +++ b/include/configs/beaver.h @@ -64,7 +64,6 @@ #define CONFIG_CMD_PCI /* PCI networking support */ -#define CONFIG_RTL8169 /* General networking support */ #define CONFIG_CMD_DHCP diff --git a/include/configs/cardhu.h b/include/configs/cardhu.h index fc2dc5a..12cc394 100644 --- a/include/configs/cardhu.h +++ b/include/configs/cardhu.h @@ -67,7 +67,6 @@ #define CONFIG_CMD_PCI /* PCI networking support */ -#define CONFIG_RTL8169 /* General networking support */ #define CONFIG_CMD_DHCP diff --git a/include/configs/chromebox_panther.h b/include/configs/chromebox_panther.h index d5b3390..46bbe4c 100644 --- a/include/configs/chromebox_panther.h +++ b/include/configs/chromebox_panther.h @@ -10,6 +10,5 @@ #include #include -#define CONFIG_RTL8169 #endif /* __CONF
Re: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic
Hi Stephen, On 23 February 2016 at 13:33, Stephen Warren wrote: > On 02/23/2016 01:00 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 23 February 2016 at 10:40, Stephen Warren >> wrote: >>> >>> On 02/23/2016 10:30 AM, Simon Glass wrote: Hi Stephen, On 23 February 2016 at 10:21, Stephen Warren wrote: > > > On 02/23/2016 06:17 AM, Simon Glass wrote: >> >> >> >> Hi Alex, >> >> On 21 February 2016 at 18:57, Alexander Graf wrote: >>> >>> >>> >>> The idea to generate our pages tables from an array of memory ranges >>> is very sound. However, instead of hard coding the code to create up >>> to 2 levels of 64k granule page tables, we really should just create >>> normal 4k page tables that allow us to set caching attributes on 2M >>> or 4k level later on. >>> >>> So this patch moves the full_va mapping code to 4k page size and >>> makes it fully flexible to dynamically create as many levels as >>> necessary for a map (including dynamic 1G/2M pages). It also adds >>> support to dynamically split a large map into smaller ones when >>> some code wants to set dcache attributes. >>> >>> With all this in place, there is very little reason to create your >>> own page tables in board specific files. > > > > >>> static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP; >> >> >> >> >> I am not ken on the idea of using a big #define table on these boards. >> Is there not a device-tree binding for this that we can use? It is >> just a data table, We are moving to Kconfig and eventually want to >> drop the config files. > > > > > I would strongly object to making the MMU setup depend on device tree > parsing. This is low-level system code that should be handled purely by > simple standalone C code. Because...? >>> >>> >>> >>> There is literally zero benefit from putting the exact same content into >>> DT, >>> and hence having to run significantly more code to parse DT and get back >>> exactly the same hard-coded table. >> >> >> We do this so that board-specific variations can be described in one >> place. In the board-specific case, there are benefits. > > > I'd like to see an explicit enumeration of the benefits; I'm not aware of > any (either benefits, or such an enumeration). Board-specific data can just > as easily (actually, more easily due to lack of need for parsing code) be > stored in C data structures vs. stored in DT. > > Or put another way, the simple fact that some data is board-specific does > not in-and-of-itself mean there's a benefit to putting it into DT. To move > something into DT, we should be able to enumerate some other benefit, such > as: > - Speeds up boot time. > - Allows code to be simpler. > - Simplifies editing the data. > > (Note that I don't believe any of those example potential benefits are > actually true, but in fact are the opposite of the truth). Didn't this get discussed to death in the Linux mailing list with the result that platform data was abolished in favour of device tree? From my perspective: - the relevant configuration is mostly in one place - we can share it with Linux - it is easier to maintain a few text files than dispersed platform data - it permits easy run-time configuration, avoiding the need for multiple builds for trivial differences - it converts to platform data fairly easily at run-time, so most of the code can still deal with that - it is easy to have base SoC data that is expanded/overridden by board data - the configuration can be listed and queried easily, by U-Boot at run-time, or by build systems - device tree is a well-understood format with robust tools I suspect others have done a much more thoughtful and persuasive analysis. If you want to pick up on these points I suggest starting a new thread! > >>> DT is not a goal in-and-of-itself. In some cases there are benefits to >>> placing configuration data outside a binary, and in those cases DT is an >>> acceptable mechanism to do that. However, any benefit from doing so >>> derives >>> from arguments for separating the data out of the code, not because "use >>> DT" >>> is itself a benefit. >> >> >> That's fine as far as it goes. >> >> The config file is not an acceptable means of providing per-board or >> per-arch configuration. If it is arch-specific and/or SoC-specific, >> but NOT board-specific then we can have it in a C table in a source >> file (not the config header) that is built into the binary. If it is >> board-specific, it must use the device tree. >> >> What category are we talking about here? Unfortunately it's not >> entirely clear from the patches and I lack the knowledge/background to >> figure it out. > > > I expect this data is SoC-specific. At least for Tegra in the codebase, > that's certainly true. I believe it's true for other SoCs in the current
Re: [U-Boot] [PATCH] dm: serial: Move a carriage return before a line feed
Hi Alison,
On Wed, Feb 24, 2016 at 11:56 AM, Alison Wang wrote:
> In general, a carriage return needs to execute before a line feed.
> The patch is to change serial DM driver based on this rule.
>
> Signed-off-by: Alison Wang
> ---
> drivers/serial/serial-uclass.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index 1c447ff..f154eb1 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -123,11 +123,12 @@ static void _serial_putc(struct udevice *dev, char ch)
> struct dm_serial_ops *ops = serial_get_ops(dev);
> int err;
>
> + if (ch == '\n')
> + _serial_putc(dev, '\r');
> +
> do {
> err = ops->putc(dev, ch);
> } while (err == -EAGAIN);
> - if (ch == '\n')
> - _serial_putc(dev, '\r');
> }
>
We should also clean up all DM serial driver to remove this handling
in their driver. eg: serial_lpuart.c/serial_mxc.c
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: serial: Move a carriage return before a line feed
In general, a carriage return needs to execute before a line feed.
The patch is to change serial DM driver based on this rule.
Signed-off-by: Alison Wang
---
drivers/serial/serial-uclass.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 1c447ff..f154eb1 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -123,11 +123,12 @@ static void _serial_putc(struct udevice *dev, char ch)
struct dm_serial_ops *ops = serial_get_ops(dev);
int err;
+ if (ch == '\n')
+ _serial_putc(dev, '\r');
+
do {
err = ops->putc(dev, ch);
} while (err == -EAGAIN);
- if (ch == '\n')
- _serial_putc(dev, '\r');
}
static void _serial_puts(struct udevice *dev, const char *str)
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: serial: Move a carriage return before a line feed
On 23 February 2016 at 20:56, Alison Wang wrote: > In general, a carriage return needs to execute before a line feed. > The patch is to change serial DM driver based on this rule. > > Signed-off-by: Alison Wang > --- > drivers/serial/serial-uclass.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: Disable "DISCARD" for secure section if CONFIG_ARMV7_SECURE_BASE isn't defined
Thanks, Albert. Regards, -Dongsheng > -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Saturday, January 30, 2016 12:21 AM > To: Tom Rini > Cc: Dongsheng Wang ; > alison.w...@freescale.com; jan.kis...@siemens.com; o...@buserror.net; u- > b...@lists.denx.de; twar...@nvidia.com; i...@hellion.org.uk; > york...@freescale.com > Subject: Re: [U-Boot] [PATCH v2] ARM: Disable "DISCARD" for secure section if > CONFIG_ARMV7_SECURE_BASE isn't defined > > Hello Tom, > > On Tue, 19 Jan 2016 10:57:11 -0500, Tom Rini wrote: > > On Mon, Jan 18, 2016 at 11:02:40AM +0800, Dongsheng Wang wrote: > > > > > From: Wang Dongsheng > > > > > > "DISCARD" will remove ._secure.text relocate, but PSCI framework has > > > already used some absolute address those need to relocate. > > > > > > Use readelf -t -r u-boot show us: > > > .__secure_start addr: 601408e4 > > > .__secure_end addr: 60141460 > > > > > > 60141140 0017 R_ARM_RELATIVE > > > 46_secure_monitor: > > > 47#ifdef CONFIG_ARMV7_PSCI > > > 48 ldr r5, =_psci_vectors > > > > > > 60141194 0017 R_ARM_RELATIVE > > > 6014119c 0017 R_ARM_RELATIVE > > > 601411a4 0017 R_ARM_RELATIVE > > > 601411ac 0017 R_ARM_RELATIVE > > > 64_psci_table: > > > 66.word psci_cpu_suspend > > > ... > > > 72.word psci_migrate > > > > > > 60141344 0017 R_ARM_RELATIVE > > > 6014145c 0017 R_ARM_RELATIVE > > > 202 ldr r5, =psci_text_end > > > > > > Solutions: > > > 1. Change absolute address to RelAdr. > > >Based on LDR (immediate, ARM), we only have 4K offset to jump. > > > Now PSCI code size is close to 4K size that is LDR limit jump size, > > > so even if the LDR is based on the current instruction address, > > > there is also have a risk for RelAdr. If we use two jump steps I > > > think we can fix this issue, but looks too hack, so give up this way. > > > > > > 2. Enable "DISCARD" only for CONFIG_ARMV7_SECURE_BASE has defined. > > >If CONFIG_ARMV7_SECURE_BASE is defined in platform, all of secure > > > will in the BASE address that is absolute. > > > > > > Signed-off-by: Wang Dongsheng > > > > > > diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds index > > > d48a905..e148ab7 100644 > > > > Reviewed-by: Tom Rini > > > > -- > > Tom > > Applied to u-boot-arm/master, thanks! > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] armv8: layerscape: Add support of u-boot device tree fix-up
> -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Tuesday, February 23, 2016 12:14 PM > To: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Cc: york sun ; Priyanka Jain > Subject: Re: [RFC] armv8: layerscape: Add support of u-boot device tree fix- > up > > On Tue, 2016-02-23 at 04:09 +, Prabhakar Kushwaha wrote: > > > -Original Message- > > > From: Scott Wood [mailto:o...@buserror.net] > > > Sent: Tuesday, February 23, 2016 6:52 AM > > > To: Prabhakar Kushwaha ; u- > > > b...@lists.denx.de > > > Cc: york sun ; Priyanka Jain > > > > > > Subject: Re: [RFC] armv8: layerscape: Add support of u-boot device > > > tree > > > fix- > > > up > > > > > > On Mon, 2016-02-22 at 16:05 +0530, Prabhakar Kushwaha wrote: > > > > There is a requirement of u-boot dts fix-up before it is being > > > > consumed by u-boot. > > > > > > You might want to explain the reason *why* we have this requirement > > > -- that the board takes a socketed SoC, and we don't want to have to > > > reflash the board if one SoC is unplugged and another plugged in. > > > > > > > > > > > NXP's SoC LS2085A, LS2080A and LS2088A are almost same except > > > > variation in ARM core where LS2085A/LS2080A has A57 and LS2088A > > > > has > > > A72. > > > > These SoCs will be placed on common LS2085ARDB platform. > > > > > > > > So instead of maintaining defferent device tree per SoC, fix-up > > > > dts before being used by u-boot. > > > > > > > > Signed-off-by: Prabhakar Kushwaha > > > > > > And what happens when the next socketed board can support chips with > > > device trees that are significantly more different? > > > > Usually next revision of board should not have major change in terms > > of interface. > > If it is **different** new device tree, defconfig, _config.h > > needs to be used. > > This has nothing to do with different revisions of a board. It has to do with > the set of chips that can be plugged into the *same* board. > > > > There should be a mechanism for having multiple device trees > > > present, and choosing one based on platform code. > > > That would also avoid any problems of trying to modify a device > > > tree before relocation. > > > > > > > I agree. But it may have following problems > > - Increasing bootloader size (u-boot + dtb(s)). > > Not by much. If some boot sources are so close to the limit that this > presents > a problem, then we can deal with it, but this should not be a problem with > NOR flash at least. > I agree. But we may not be looking to increase u-boot size too much. > > - Need to maintain different dts per combination like LS2080 + LS2085ARDB > , > >LS2088 + LS2085ARDB, LS2085A + LS2085ARDB > > So? Includes make it easy to maintain variants. I agree. It will provide better dts understanding. Same can be achieved by "fdt print" to get u-boot fixed dts. > > > Here board is common and SoC getting change > > > > Assumption: SoC does not have major change. > > I don't think that's a good assumption -- and what constitutes a major > change? > A different core could be considered a major change. In any case, you need > specialized fixup code for every type of difference between the SoCs. > Ideally dts fix-up approach should only be applied to new Revision of SoCs. And one should be very careful of using this approach for new SoC. > Choosing from multiple device trees is a cleaner solution that does not place > limits on the type of change from SoC to SoC, and does not consume OCRAM > (among other benefits, this makes the mechanism transferable to other > types of devices that may not have enough pre-relocation RAM to hold a > device tree). Choosing from multiple device tree is cleaner approach. I agree with you. But same should be applied for Linux also. We should not have different approach for u-boot dts and Linux dts. I will suggest to have botha) dts fix-up b) multiple dts SoC with small change can follow "a" SoC with major change can follow "b" assuming same approach has been accepted in Linux. > > > > > diff --git a/include/configs/ls2080a_common.h > > > > b/include/configs/ls2080a_common.h > > > > index def0a6f..aa5ace9 100644 > > > > --- a/include/configs/ls2080a_common.h > > > > +++ b/include/configs/ls2080a_common.h > > > > @@ -24,6 +24,7 @@ > > > > > > > > /* Link Definitions */ > > > > #define CONFIG_SYS_INIT_SP_ADDR > > > (CONFIG_SYS_FSL_OCRAM_BASE + > > > > 0xfff0) > > > > +#define CONFIG_SYS_DTS_ADDR > > > (CONFIG_SYS_FSL_OCRAM_BASE + > > > > 0xfff0) > > > > > > Why 0xfff0, and not, say, 0x1 (or rather, why is INIT_SP_ADDR > > > 0xfff0 and not 0x1 if there is no need to reserve some space > > > above the initial SP addr (e.g. to indicate the end of a > > > traceback))? > > > > I used the 0xfff0 thinking STACK moving from 0xfff0 to 0x. > > So better put dts starting from 0xfff0 to high address. > > My point is that there is likely a reason that the stack ends at
Re: [U-Boot] [RFC PATCH v4 2/3] common: Convert ulong to phys_addr_t for image addresses
Hi York,
On 23 February 2016 at 13:36, york sun wrote:
> On 02/16/2016 08:01 AM, Simon Glass wrote:
>> Hi York,
>>
>> On 12 February 2016 at 13:59, York Sun wrote:
>>> When dealing with image addresses, ulong has been used. Some files
>>> are used by both host and target. It is OK for the target, but not
>>> always enough for host tools including mkimage. This patch replaces
>>> "ulong" with "phys_addr_t" to make sure addresses are correct for
>>> both the target and the host.
>>>
>>> This issue was found on 32-bit host when compiling for 64-bit target
>>> to support images with address higher than 32-bit space.
>>>
>>> Signed-off-by: York Sun
>>>
>>> ---
>>>
>>> Changes in v4:
>>> New patch, separated from fixing FIT image.
>>>
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>> arch/powerpc/lib/bootm.c |4 ++--
>>> cmd/ximg.c |9 +
>>> common/bootm.c | 21 +++--
>>> common/bootm_os.c| 14 --
>>> common/image-android.c |6 +++---
>>> common/image-fdt.c | 16
>>> common/image-fit.c | 27 ++-
>>> common/image.c | 17 ++---
>>> include/bootm.h |6 +++---
>>> include/image.h | 30 ++
>>> tools/default_image.c|2 +-
>>> 11 files changed, 83 insertions(+), 69 deletions(-)
>>>
>>> diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
>>> index ef15e7a..794382a 100644
>>> --- a/arch/powerpc/lib/bootm.c
>>> +++ b/arch/powerpc/lib/bootm.c
>>> @@ -47,7 +47,7 @@ static void boot_jump_linux(bootm_headers_t *images)
>>> #endif
>>>
>>> kernel = (void (*)(bd_t *, ulong, ulong, ulong,
>>> - ulong, ulong, ulong))images->ep;
>>> + ulong, ulong, ulong))(uintptr_t)images->ep;
>>> debug ("## Transferring control to Linux (at address %08lx) ...\n",
>>> (ulong)kernel);
>>>
>>> @@ -335,7 +335,7 @@ void boot_jump_vxworks(bootm_headers_t *images)
>>> WATCHDOG_RESET();
>>>
>>> ((void (*)(void *, ulong, ulong, ulong,
>>> - ulong, ulong, ulong))images->ep)(images->ft_addr,
>>> + ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,
>>> 0, 0, EPAPR_MAGIC, getenv_bootm_mapsize(), 0, 0);
>>> }
>>> #endif
>>> diff --git a/cmd/ximg.c b/cmd/ximg.c
>>> index d033c15..70d6d14 100644
>>> --- a/cmd/ximg.c
>>> +++ b/cmd/ximg.c
>>> @@ -33,7 +33,8 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char
>>> * const argv[])
>>> {
>>> ulong addr = load_addr;
>>> ulong dest = 0;
>>> - ulong data, len;
>>> + phys_addr_t data;
>>> + ulong len;
>>> int verify;
>>> int part = 0;
>>> #if defined(CONFIG_IMAGE_FORMAT_LEGACY)
>>> @@ -173,7 +174,7 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc,
>>> char * const argv[])
>>> return 1;
>>> }
>>>
>>> - data = (ulong)fit_data;
>>> + data = (phys_addr_t)(uintptr_t)fit_data;
>>> len = (ulong)fit_len;
>>> break;
>>> #endif
>>> @@ -205,14 +206,14 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc,
>>> char * const argv[])
>>> }
>>> #else /* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */
>>> printf(" Loading part %d ... ", part);
>>> - memmove((char *) dest, (char *)data, len);
>>> + memmove((char *)dest, (char *)(uintptr_t)data, len);
>>> #endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */
>>> break;
>>> #ifdef CONFIG_GZIP
>>> case IH_COMP_GZIP:
>>> printf(" Uncompressing part %d ... ", part);
>>> if (gunzip((void *) dest, unc_len,
>>> - (uchar *) data, &len) != 0) {
>>> + (uchar *)(uintptr_t)data, &len) != 0) {
>>
>> The uintptr_t cast presumably defeats the warning. Is the intention to
>> convert a 64-bit value to 32-bit?
>
> Yes. Before this patch, all these addresses are ulong. It is enough to hold
> the
> addresses _used_ for images on 32- and 64-bit targets. Please note, the key
> here
> is the address used. On system with 36 or more bits for physical addresses,
> the
> phys_addr_t is "unsigned long long". If the core is in 32-bit, the images are
> actually put in 32-bit space. So it is safe to case the 64-bit phys_addr_t to
> a
> 32-bit pointer.
>
> The idea behind this change is to make the host tool (such as mkimge) to
> support
> 64-bit address, even on a 32-bit host. My solution is to always use 64-bit
> variable on host. I didn't find a better way to deal with this issue.
>
>>
>> Is it true that sizeof(phys_addr_t) is always si
Re: [U-Boot] [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered PCI devices
> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Tuesday, February 23, 2016 9:19 AM
> To: Stuart Yoder ; Minghuan Lian
> ; u-
> b...@lists.denx.de
> Cc: york sun ; Prabhakar Kushwaha
> ;
> Mingkai Hu ; Yang-Leo Li
> Subject: Re: [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered
> PCI devices
>
> On 23/02/16 15:01, Stuart Yoder wrote:
> >
> >
> >> -Original Message-
> >> From: Minghuan Lian
> >> Sent: Tuesday, February 23, 2016 3:57 AM
> >> To: Stuart Yoder ; u-boot@lists.denx.de
> >> Cc: york sun ; Prabhakar Kushwaha
> >> ;
> >> Mingkai Hu ; Yang-Leo Li ;
> marc.zyng...@arm.com;
> >> Stuart Yoder
> >> Subject: RE: [PATCH 7/7] pci/layerscape: set LUT and msi-map for
> >> discovered PCI
> devices
> >>
> >> Hi Stuart,
> >>
> >>
> >>> -Original Message-
> >>> From: Stuart Yoder [mailto:stuart.yo...@nxp.com]
> >>> Sent: Monday, February 22, 2016 11:26 PM
> >>> To: u-boot@lists.denx.de
> >>> Cc: york sun ; Prabhakar Kushwaha
> >>> ; Mingkai Hu ;
> >>> Minghuan Lian ; Yang-Leo Li ;
> >>> marc.zyng...@arm.com; Stuart Yoder
> >>> Subject: [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered
> >>> PCI
> >>> devices
> >>>
> >>> From: Stuart Yoder
> >>>
> >>> for all PCI devices discovered in a system:
> >>> -allocate a LUT (look-up-table) entry in that PCI controller
> >>> -allocate a stream ID for the device
> >>> -program and enable a LUT entry (maps PCI requester id to stream ID)
> >>> -set the msi-map property on the controller reflecting the
> >>>LUT mapping
> >>>
> >>> basic bus scanning loop/logic was taken from drivers/pci/pci.c
> >>> pci_hose_scan_bus().
> >>>
> >>> Signed-off-by: Stuart Yoder
> >>> ---
> >>> drivers/pci/pcie_layerscape.c | 68
> >>> +
> >>> 1 file changed, 68 insertions(+)
> >>>
> >>> diff --git a/drivers/pci/pcie_layerscape.c
> >>> b/drivers/pci/pcie_layerscape.c index
> >>> dfafaf2..eaac9e1 100644
> >>> --- a/drivers/pci/pcie_layerscape.c
> >>> +++ b/drivers/pci/pcie_layerscape.c
> >>> @@ -569,6 +569,70 @@ static void fdt_pcie_set_msi_map_entry(void *blob,
> >>> struct ls_pcie *pcie,
> >>> fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1); }
> >>>
> >>> +static void fdt_fixup_pcie(void *blob)
> >>> +{
> >>> + unsigned int found_multi = 0;
> >>> + unsigned char header_type;
> >>> + int index;
> >>> + u32 streamid;
> >>> + pci_dev_t dev;
> >>> + int bus;
> >>> + unsigned short id;
> >>> + struct pci_controller *hose;
> >>> + struct ls_pcie *pcie;
> >>> + int i;
> >>> +
> >>> + for (i = 0, hose = pci_get_hose_head(); hose; hose = hose->next, i++) {
> >>> + pcie = hose->priv_data;
> >>> + for (bus = hose->first_busno; bus <= hose->last_busno; bus++) {
> >>> +
> >>> + for (dev = PCI_BDF(bus, 0, 0);
> >>> + dev < PCI_BDF(bus, PCI_MAX_PCI_DEVICES - 1,
> >>> + PCI_MAX_PCI_FUNCTIONS - 1);
> >>> + dev += PCI_BDF(0, 0, 1)) {
> >>> +
> >>> + /* skip the host bridge */
> >>> + if (dev == PCI_BDF(0, 0, 0))
> >>> + continue;
> >> [Lian Minghuan-B31939] PCIe controller also needs a stream ID. It may
> >> request a MSI
> for
> >> AER PME hotplug service.
> >
> > Is this a theoretical problem, or does the ls2080a actually support
> > hotplug and assert an MSI? Mingkai said that a hotplug interrupt
> > could be an INTx interrupt. The fdt_fixup_pcie() in this patch
> > is specifically for Layerscape SoCs and I think it makes sense
> > to implement what hardware actually supports.
>
> For sure, the ls2085 reports such a capability, and the kernel assigns a
> pair of MSIs to it.
>
> 97: 0 0 0 0 0 0
> 0 0 ITS-MSI 0 Edge PCIe PME
> 98: 0 0 0 0 0 0
> 0 0 ITS-MSI 1 Edge aerdrv
>
> I haven't tried to exercise it though.
Ok, I will respin and remove the "skip the host bridge"
check, which will allow the host bridge to get a LUT
entry created for it.
Stuart
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered PCI devices
On 23/02/16 15:01, Stuart Yoder wrote:
>
>
>> -Original Message-
>> From: Minghuan Lian
>> Sent: Tuesday, February 23, 2016 3:57 AM
>> To: Stuart Yoder ; u-boot@lists.denx.de
>> Cc: york sun ; Prabhakar Kushwaha
>> ;
>> Mingkai Hu ; Yang-Leo Li ;
>> marc.zyng...@arm.com;
>> Stuart Yoder
>> Subject: RE: [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered
>> PCI devices
>>
>> Hi Stuart,
>>
>>
>>> -Original Message-
>>> From: Stuart Yoder [mailto:stuart.yo...@nxp.com]
>>> Sent: Monday, February 22, 2016 11:26 PM
>>> To: u-boot@lists.denx.de
>>> Cc: york sun ; Prabhakar Kushwaha
>>> ; Mingkai Hu ;
>>> Minghuan Lian ; Yang-Leo Li ;
>>> marc.zyng...@arm.com; Stuart Yoder
>>> Subject: [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered PCI
>>> devices
>>>
>>> From: Stuart Yoder
>>>
>>> for all PCI devices discovered in a system:
>>> -allocate a LUT (look-up-table) entry in that PCI controller
>>> -allocate a stream ID for the device
>>> -program and enable a LUT entry (maps PCI requester id to stream ID)
>>> -set the msi-map property on the controller reflecting the
>>>LUT mapping
>>>
>>> basic bus scanning loop/logic was taken from drivers/pci/pci.c
>>> pci_hose_scan_bus().
>>>
>>> Signed-off-by: Stuart Yoder
>>> ---
>>> drivers/pci/pcie_layerscape.c | 68
>>> +
>>> 1 file changed, 68 insertions(+)
>>>
>>> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
>>> index
>>> dfafaf2..eaac9e1 100644
>>> --- a/drivers/pci/pcie_layerscape.c
>>> +++ b/drivers/pci/pcie_layerscape.c
>>> @@ -569,6 +569,70 @@ static void fdt_pcie_set_msi_map_entry(void *blob,
>>> struct ls_pcie *pcie,
>>> fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1); }
>>>
>>> +static void fdt_fixup_pcie(void *blob)
>>> +{
>>> + unsigned int found_multi = 0;
>>> + unsigned char header_type;
>>> + int index;
>>> + u32 streamid;
>>> + pci_dev_t dev;
>>> + int bus;
>>> + unsigned short id;
>>> + struct pci_controller *hose;
>>> + struct ls_pcie *pcie;
>>> + int i;
>>> +
>>> + for (i = 0, hose = pci_get_hose_head(); hose; hose = hose->next, i++) {
>>> + pcie = hose->priv_data;
>>> + for (bus = hose->first_busno; bus <= hose->last_busno; bus++) {
>>> +
>>> + for (dev = PCI_BDF(bus, 0, 0);
>>> +dev < PCI_BDF(bus, PCI_MAX_PCI_DEVICES - 1,
>>> + PCI_MAX_PCI_FUNCTIONS - 1);
>>> +dev += PCI_BDF(0, 0, 1)) {
>>> +
>>> + /* skip the host bridge */
>>> + if (dev == PCI_BDF(0, 0, 0))
>>> + continue;
>> [Lian Minghuan-B31939] PCIe controller also needs a stream ID. It may
>> request a MSI for
>> AER PME hotplug service.
>
> Is this a theoretical problem, or does the ls2080a actually support
> hotplug and assert an MSI? Mingkai said that a hotplug interrupt
> could be an INTx interrupt. The fdt_fixup_pcie() in this patch
> is specifically for Layerscape SoCs and I think it makes sense
> to implement what hardware actually supports.
For sure, the ls2085 reports such a capability, and the kernel assigns a
pair of MSIs to it.
97: 0 0 0 0 0 0
0 0 ITS-MSI 0 Edge PCIe PME
98: 0 0 0 0 0 0
0 0 ITS-MSI 1 Edge aerdrv
I haven't tried to exercise it though.
M.
--
Jazz is not dead. It just smells funny...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v4 2/3] common: Convert ulong to phys_addr_t for image addresses
On 02/16/2016 08:01 AM, Simon Glass wrote:
> Hi York,
>
> On 12 February 2016 at 13:59, York Sun wrote:
>> When dealing with image addresses, ulong has been used. Some files
>> are used by both host and target. It is OK for the target, but not
>> always enough for host tools including mkimage. This patch replaces
>> "ulong" with "phys_addr_t" to make sure addresses are correct for
>> both the target and the host.
>>
>> This issue was found on 32-bit host when compiling for 64-bit target
>> to support images with address higher than 32-bit space.
>>
>> Signed-off-by: York Sun
>>
>> ---
>>
>> Changes in v4:
>> New patch, separated from fixing FIT image.
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> arch/powerpc/lib/bootm.c |4 ++--
>> cmd/ximg.c |9 +
>> common/bootm.c | 21 +++--
>> common/bootm_os.c| 14 --
>> common/image-android.c |6 +++---
>> common/image-fdt.c | 16
>> common/image-fit.c | 27 ++-
>> common/image.c | 17 ++---
>> include/bootm.h |6 +++---
>> include/image.h | 30 ++
>> tools/default_image.c|2 +-
>> 11 files changed, 83 insertions(+), 69 deletions(-)
>>
>> diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
>> index ef15e7a..794382a 100644
>> --- a/arch/powerpc/lib/bootm.c
>> +++ b/arch/powerpc/lib/bootm.c
>> @@ -47,7 +47,7 @@ static void boot_jump_linux(bootm_headers_t *images)
>> #endif
>>
>> kernel = (void (*)(bd_t *, ulong, ulong, ulong,
>> - ulong, ulong, ulong))images->ep;
>> + ulong, ulong, ulong))(uintptr_t)images->ep;
>> debug ("## Transferring control to Linux (at address %08lx) ...\n",
>> (ulong)kernel);
>>
>> @@ -335,7 +335,7 @@ void boot_jump_vxworks(bootm_headers_t *images)
>> WATCHDOG_RESET();
>>
>> ((void (*)(void *, ulong, ulong, ulong,
>> - ulong, ulong, ulong))images->ep)(images->ft_addr,
>> + ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,
>> 0, 0, EPAPR_MAGIC, getenv_bootm_mapsize(), 0, 0);
>> }
>> #endif
>> diff --git a/cmd/ximg.c b/cmd/ximg.c
>> index d033c15..70d6d14 100644
>> --- a/cmd/ximg.c
>> +++ b/cmd/ximg.c
>> @@ -33,7 +33,8 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char
>> * const argv[])
>> {
>> ulong addr = load_addr;
>> ulong dest = 0;
>> - ulong data, len;
>> + phys_addr_t data;
>> + ulong len;
>> int verify;
>> int part = 0;
>> #if defined(CONFIG_IMAGE_FORMAT_LEGACY)
>> @@ -173,7 +174,7 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc,
>> char * const argv[])
>> return 1;
>> }
>>
>> - data = (ulong)fit_data;
>> + data = (phys_addr_t)(uintptr_t)fit_data;
>> len = (ulong)fit_len;
>> break;
>> #endif
>> @@ -205,14 +206,14 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc,
>> char * const argv[])
>> }
>> #else /* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */
>> printf(" Loading part %d ... ", part);
>> - memmove((char *) dest, (char *)data, len);
>> + memmove((char *)dest, (char *)(uintptr_t)data, len);
>> #endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */
>> break;
>> #ifdef CONFIG_GZIP
>> case IH_COMP_GZIP:
>> printf(" Uncompressing part %d ... ", part);
>> if (gunzip((void *) dest, unc_len,
>> - (uchar *) data, &len) != 0) {
>> + (uchar *)(uintptr_t)data, &len) != 0) {
>
> The uintptr_t cast presumably defeats the warning. Is the intention to
> convert a 64-bit value to 32-bit?
Yes. Before this patch, all these addresses are ulong. It is enough to hold the
addresses _used_ for images on 32- and 64-bit targets. Please note, the key here
is the address used. On system with 36 or more bits for physical addresses, the
phys_addr_t is "unsigned long long". If the core is in 32-bit, the images are
actually put in 32-bit space. So it is safe to case the 64-bit phys_addr_t to a
32-bit pointer.
The idea behind this change is to make the host tool (such as mkimge) to support
64-bit address, even on a 32-bit host. My solution is to always use 64-bit
variable on host. I didn't find a better way to deal with this issue.
>
> Is it true that sizeof(phys_addr_t) is always sizeof(ulong) on the target?
No. On some arch (eg arm, mips, powerpc), phys_addr_t can be either "unsigned
long long", or "unsigned long".
>
>> puts("GUNZIP ERRO
[U-Boot] [PATCH v2] sunxi: power: add support for sy8106a driver
SY8106A is a PMIC which is used on the Allwinner
H3 Orange Pi Pc and Plus board. The VOUT1_SEL register is
implemented to set the default V-CPU voltage to 1200 mV.
This driver is required to retain the SY8106A V-CPU
voltage after a software reset. On cold boot the default
SY8106A output voltage is selected by a pair of resistors
and happens to be 1.2V on the Orange Pi PC and Plus.
Signed-off-by: Jelle van der Waa
Signed-off-by: Hans de Goede
Tested-by: Siarhei Siamashka
Acked-by: Siarhei Siamashka
---
Changes in v2
- Fixed typo in commit message thea => the.
- Made config R_I2C_ENABLE depend on SY8106A_POWER.
- Removed 'default n' from config R_I2C_ENABLE
- Changed SY8106A_POWER description from "most" to "some" boards.
- Added license/copyright to include/sy8106a.h and
drivers/power/sy8106a.c.
---
board/sunxi/Kconfig| 5 -
board/sunxi/board.c| 5 +
configs/orangepi_pc_defconfig | 2 +-
drivers/power/Kconfig | 16
drivers/power/Makefile | 1 +
drivers/power/sy8106a.c| 29 +
include/configs/sunxi-common.h | 6 --
include/sy8106a.h | 11 +++
8 files changed, 71 insertions(+), 4 deletions(-)
create mode 100644 drivers/power/sy8106a.c
create mode 100644 include/sy8106a.h
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index a334aa3..5e9d3af 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -372,11 +372,14 @@ config I2C3_ENABLE
See I2C0_ENABLE help text.
endif
+if SUNXI_GEN_SUN6I
config R_I2C_ENABLE
bool "Enable the PRCM I2C/TWI controller"
- default n
+ # This is used for the pmic on H3
+ default y if SY8106A_POWER
---help---
Set this to y to enable the I2C controller which is part of the PRCM.
+endif
if MACH_SUN7I
config I2C4_ENABLE
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 420481a..15b7af6 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#if defined CONFIG_VIDEO_LCD_PANEL_I2C && !(defined CONFIG_SPL_BUILD)
/* So that we can use pin names in Kconfig and sunxi_name_to_gpio() */
@@ -436,6 +437,10 @@ void sunxi_board_init(void)
int power_failed = 0;
unsigned long ramsize;
+#ifdef CONFIG_SY8106A_POWER
+ power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
+#endif
+
#if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
defined CONFIG_AXP221_POWER || defined CONFIG_AXP818_POWER
power_failed = axp_init();
diff --git a/configs/orangepi_pc_defconfig b/configs/orangepi_pc_defconfig
index ea9ed87..29a8da6 100644
--- a/configs/orangepi_pc_defconfig
+++ b/configs/orangepi_pc_defconfig
@@ -12,4 +12,4 @@ CONFIG_SPL=y
# CONFIG_CMD_FLASH is not set
# CONFIG_CMD_FPGA is not set
CONFIG_CMD_GPIO=y
-CONFIG_R_I2C_ENABLE=y
+CONFIG_SY8106A_POWER=y
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 10683a2..adc6455 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -48,6 +48,13 @@ config AXP818_POWER
Say y here to enable support for the axp818 pmic found on
A83T dev board.
+config SY8106A_POWER
+ boolean "SY8106A pmic support"
+ depends on MACH_SUN8I_H3
+ ---help---
+ Select this to enable support for the SY8106A pmic found on some
+ H3 boards.
+
endchoice
config AXP_DCDC1_VOLT
@@ -232,4 +239,13 @@ config AXP_ELDO3_VOLT
1.2V for the SSD2828 chip (converter of parallel LCD interface
into MIPI DSI).
+config SY8106A_VOUT1_VOLT
+ int "SY8106A pmic VOUT1 voltage"
+ depends on SY8106A_POWER
+ default 1200
+ ---help---
+ Set the voltage (mV) to program the SY8106A pmic VOUT1. This
+ is typically used to power the VDD-CPU and should be 1200mV.
+ Values can range from 680mV till 1950mV.
+
endmenu
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 0fdbca3..690faa0 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_AXP221_POWER)+= axp221.o
obj-$(CONFIG_AXP818_POWER) += axp818.o
obj-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
obj-$(CONFIG_FTPMU010_POWER) += ftpmu010.o
+obj-$(CONFIG_SY8106A_POWER)+= sy8106a.o
obj-$(CONFIG_TPS6586X_POWER) += tps6586x.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030.o
obj-$(CONFIG_TWL6030_POWER)+= twl6030.o
diff --git a/drivers/power/sy8106a.c b/drivers/power/sy8106a.c
new file mode 100644
index 000..bbf116f
--- /dev/null
+++ b/drivers/power/sy8106a.c
@@ -0,0 +1,29 @@
+/*
+ * (C) Copyright 2016
+ * Jelle van der Waa
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+
+#define SY8106A_I2C_ADDR 0x65
+#define SY8106A_VOUT1_SEL 1
+#define SY8106A_VOUT1_SEL_ENABLE (1 << 7)
+
+static u8 sy8106a_mvolt_to_cfg(int mvolt, int min, int max, int div)
+{
+ if (mvolt < min)
+ mv
Re: [U-Boot] [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered PCI devices
> -Original Message-
> From: Minghuan Lian
> Sent: Tuesday, February 23, 2016 3:57 AM
> To: Stuart Yoder ; u-boot@lists.denx.de
> Cc: york sun ; Prabhakar Kushwaha
> ;
> Mingkai Hu ; Yang-Leo Li ;
> marc.zyng...@arm.com;
> Stuart Yoder
> Subject: RE: [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered
> PCI devices
>
> Hi Stuart,
>
>
> > -Original Message-
> > From: Stuart Yoder [mailto:stuart.yo...@nxp.com]
> > Sent: Monday, February 22, 2016 11:26 PM
> > To: u-boot@lists.denx.de
> > Cc: york sun ; Prabhakar Kushwaha
> > ; Mingkai Hu ;
> > Minghuan Lian ; Yang-Leo Li ;
> > marc.zyng...@arm.com; Stuart Yoder
> > Subject: [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered PCI
> > devices
> >
> > From: Stuart Yoder
> >
> > for all PCI devices discovered in a system:
> > -allocate a LUT (look-up-table) entry in that PCI controller
> > -allocate a stream ID for the device
> > -program and enable a LUT entry (maps PCI requester id to stream ID)
> > -set the msi-map property on the controller reflecting the
> >LUT mapping
> >
> > basic bus scanning loop/logic was taken from drivers/pci/pci.c
> > pci_hose_scan_bus().
> >
> > Signed-off-by: Stuart Yoder
> > ---
> > drivers/pci/pcie_layerscape.c | 68
> > +
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> > index
> > dfafaf2..eaac9e1 100644
> > --- a/drivers/pci/pcie_layerscape.c
> > +++ b/drivers/pci/pcie_layerscape.c
> > @@ -569,6 +569,70 @@ static void fdt_pcie_set_msi_map_entry(void *blob,
> > struct ls_pcie *pcie,
> > fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1); }
> >
> > +static void fdt_fixup_pcie(void *blob)
> > +{
> > + unsigned int found_multi = 0;
> > + unsigned char header_type;
> > + int index;
> > + u32 streamid;
> > + pci_dev_t dev;
> > + int bus;
> > + unsigned short id;
> > + struct pci_controller *hose;
> > + struct ls_pcie *pcie;
> > + int i;
> > +
> > + for (i = 0, hose = pci_get_hose_head(); hose; hose = hose->next, i++) {
> > + pcie = hose->priv_data;
> > + for (bus = hose->first_busno; bus <= hose->last_busno; bus++) {
> > +
> > + for (dev = PCI_BDF(bus, 0, 0);
> > +dev < PCI_BDF(bus, PCI_MAX_PCI_DEVICES - 1,
> > + PCI_MAX_PCI_FUNCTIONS - 1);
> > +dev += PCI_BDF(0, 0, 1)) {
> > +
> > + /* skip the host bridge */
> > + if (dev == PCI_BDF(0, 0, 0))
> > + continue;
> [Lian Minghuan-B31939] PCIe controller also needs a stream ID. It may request
> a MSI for
> AER PME hotplug service.
Is this a theoretical problem, or does the ls2080a actually support
hotplug and assert an MSI? Mingkai said that a hotplug interrupt
could be an INTx interrupt. The fdt_fixup_pcie() in this patch
is specifically for Layerscape SoCs and I think it makes sense
to implement what hardware actually supports.
Stuart
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
On Tue, Feb 23, 2016 at 10:03 AM, Jagan Teki wrote: > Hi Fabio, > > On 23 February 2016 at 00:22, Fabio Estevam wrote: >> On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki wrote: >> >>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor >> >> Does not even build for me (mx6qsabresd_defconfig) : > > Please try again, I think I missed some changes. mean while I ran > buildman again will update that one as well. Now it builds and basic sf commands work fine. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master
On Tue, Feb 23, 2016 at 09:29:14PM +0100, Hans de Goede wrote: > Hi Tom, > > Here is a sunxi pull-req for v2016.04, it contains > some improvements for Allwinner H3 support. > > The following changes since commit 595af9db2422fa5ae734cfe615415b17a5098f34: > > Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-02-21 > 07:56:16 -0500) > > are available in the git repository at: > > http://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to dc44fd8ae4be0a88123a90ae2b3acdec45290ecf: > > sunxi: H3: Add support for the host usb-phys (2016-02-23 20:59:10 +0100) > 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] [GIT PULL] Xilinx fixes
On Mon, Feb 22, 2016 at 04:52:26PM +0100, Michal Simek wrote: > Hi Tom, > > please pull these fixes to your tree. > Below is the log from buildman for zynq platform. > Microblaze build is broken by one commit I have just replied in > different thread. > > Thanks, > Michal > > The following changes since commit 595af9db2422fa5ae734cfe615415b17a5098f34: > > Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-02-21 > 07:56:16 -0500) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-microblaze.git master > > for you to fetch changes up to fdcdde567c1bd4f4c4b81dc1432933d8f88feef4: > > ARM: zynq: Enable EDID for zybo (2016-02-22 16:37:51 +0100) > 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] Pull request: u-boot-spi/master
On Tue, Feb 23, 2016 at 04:19:01PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this series. > > thanks! > Jagan. > > The following changes since commit 595af9db2422fa5ae734cfe615415b17a5098f34: > > Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-02-21 > 07:56:16 -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-spi.git master > > for you to fetch changes up to 674f3609aad39f099a5c3605643a6be124504b96: > > spi: spi-uclass: Set slave wordlen with SPI_DEFAULT_WORDLEN (2016-02-23 > 16:14:46 +0530) > Applied to u-boot/master, thanks! Mugunthan, can you please test QSPI boot on J6 or J6Eco? My board isn't behaving well and I couldn't walk Nishanth through doing it on his (or, there's a problem..). 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] Pull request: u-boot-video/master
On Mon, Feb 22, 2016 at 06:15:25PM +0100, Anatolij Gustschin wrote: > Hi Tom, > > The following changes since commit 595af9db2422fa5ae734cfe615415b17a5098f34: > > Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-02-21 > 07:56:16 -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-video.git master > > for you to fetch changes up to 703c751169feafecb0abfd730e287986cf4ac4e1: > > video: Add S3C24xx framebuffer support (2016-02-22 18:07:17 +0100) > 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 2/9] arm64: Make full va map code more dynamic
On 02/23/2016 01:00 PM, Simon Glass wrote: Hi Stephen, On 23 February 2016 at 10:40, Stephen Warren wrote: On 02/23/2016 10:30 AM, Simon Glass wrote: Hi Stephen, On 23 February 2016 at 10:21, Stephen Warren wrote: On 02/23/2016 06:17 AM, Simon Glass wrote: Hi Alex, On 21 February 2016 at 18:57, Alexander Graf wrote: The idea to generate our pages tables from an array of memory ranges is very sound. However, instead of hard coding the code to create up to 2 levels of 64k granule page tables, we really should just create normal 4k page tables that allow us to set caching attributes on 2M or 4k level later on. So this patch moves the full_va mapping code to 4k page size and makes it fully flexible to dynamically create as many levels as necessary for a map (including dynamic 1G/2M pages). It also adds support to dynamically split a large map into smaller ones when some code wants to set dcache attributes. With all this in place, there is very little reason to create your own page tables in board specific files. static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP; I am not ken on the idea of using a big #define table on these boards. Is there not a device-tree binding for this that we can use? It is just a data table, We are moving to Kconfig and eventually want to drop the config files. I would strongly object to making the MMU setup depend on device tree parsing. This is low-level system code that should be handled purely by simple standalone C code. Because...? There is literally zero benefit from putting the exact same content into DT, and hence having to run significantly more code to parse DT and get back exactly the same hard-coded table. We do this so that board-specific variations can be described in one place. In the board-specific case, there are benefits. I'd like to see an explicit enumeration of the benefits; I'm not aware of any (either benefits, or such an enumeration). Board-specific data can just as easily (actually, more easily due to lack of need for parsing code) be stored in C data structures vs. stored in DT. Or put another way, the simple fact that some data is board-specific does not in-and-of-itself mean there's a benefit to putting it into DT. To move something into DT, we should be able to enumerate some other benefit, such as: - Speeds up boot time. - Allows code to be simpler. - Simplifies editing the data. (Note that I don't believe any of those example potential benefits are actually true, but in fact are the opposite of the truth). DT is not a goal in-and-of-itself. In some cases there are benefits to placing configuration data outside a binary, and in those cases DT is an acceptable mechanism to do that. However, any benefit from doing so derives from arguments for separating the data out of the code, not because "use DT" is itself a benefit. That's fine as far as it goes. The config file is not an acceptable means of providing per-board or per-arch configuration. If it is arch-specific and/or SoC-specific, but NOT board-specific then we can have it in a C table in a source file (not the config header) that is built into the binary. If it is board-specific, it must use the device tree. What category are we talking about here? Unfortunately it's not entirely clear from the patches and I lack the knowledge/background to figure it out. I expect this data is SoC-specific. At least for Tegra in the codebase, that's certainly true. I believe it's true for other SoCs in the current codebase too. I don't expect this to change going forward, at the very least for Tegra. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-sunxi master
Hi Tom, Here is a sunxi pull-req for v2016.04, it contains some improvements for Allwinner H3 support. The following changes since commit 595af9db2422fa5ae734cfe615415b17a5098f34: Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-02-21 07:56:16 -0500) are available in the git repository at: http://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to dc44fd8ae4be0a88123a90ae2b3acdec45290ecf: sunxi: H3: Add support for the host usb-phys (2016-02-23 20:59:10 +0100) Jelle van der Waa (2): sunxi: power: add support for sy8106a driver sunxi: H3: Add support for the host usb-phys arch/arm/cpu/armv7/sunxi/usb_phy.c| 35 +-- arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 22 + arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 8 ++ board/sunxi/Kconfig | 5 +++- board/sunxi/board.c | 5 configs/orangepi_pc_defconfig | 3 ++- configs/orangepi_plus_defconfig | 2 ++ drivers/power/Kconfig | 16 drivers/power/Makefile| 1 + drivers/power/sy8106a.c | 29 ++ drivers/usb/host/ehci-sunxi.c | 14 +-- drivers/usb/host/ohci-sunxi.c | 18 +++--- include/configs/sun8i.h | 6 - include/configs/sunxi-common.h| 6 +++-- include/sy8106a.h | 11 + 15 files changed, 153 insertions(+), 28 deletions(-) create mode 100644 drivers/power/sy8106a.c create mode 100644 include/sy8106a.h Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic
Hi Stephen, On 23 February 2016 at 10:40, Stephen Warren wrote: > On 02/23/2016 10:30 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 23 February 2016 at 10:21, Stephen Warren >> wrote: >>> >>> On 02/23/2016 06:17 AM, Simon Glass wrote: Hi Alex, On 21 February 2016 at 18:57, Alexander Graf wrote: > > > The idea to generate our pages tables from an array of memory ranges > is very sound. However, instead of hard coding the code to create up > to 2 levels of 64k granule page tables, we really should just create > normal 4k page tables that allow us to set caching attributes on 2M > or 4k level later on. > > So this patch moves the full_va mapping code to 4k page size and > makes it fully flexible to dynamically create as many levels as > necessary for a map (including dynamic 1G/2M pages). It also adds > support to dynamically split a large map into smaller ones when > some code wants to set dcache attributes. > > With all this in place, there is very little reason to create your > own page tables in board specific files. >>> >>> >>> >static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP; I am not ken on the idea of using a big #define table on these boards. Is there not a device-tree binding for this that we can use? It is just a data table, We are moving to Kconfig and eventually want to drop the config files. >>> >>> >>> >>> I would strongly object to making the MMU setup depend on device tree >>> parsing. This is low-level system code that should be handled purely by >>> simple standalone C code. >> >> >> Because...? > > > There is literally zero benefit from putting the exact same content into DT, > and hence having to run significantly more code to parse DT and get back > exactly the same hard-coded table. We do this so that board-specific variations can be described in one place. In the board-specific case, there are benefits. > > DT is not a goal in-and-of-itself. In some cases there are benefits to > placing configuration data outside a binary, and in those cases DT is an > acceptable mechanism to do that. However, any benefit from doing so derives > from arguments for separating the data out of the code, not because "use DT" > is itself a benefit. That's fine as far as it goes. The config file is not an acceptable means of providing per-board or per-arch configuration. If it is arch-specific and/or SoC-specific, but NOT board-specific then we can have it in a C table in a source file (not the config header) that is built into the binary. If it is board-specific, it must use the device tree. What category are we talking about here? Unfortunately it's not entirely clear from the patches and I lack the knowledge/background to figure it out. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: H3: Add support for the host usb-phys
Hi,
On 02/14/2016 08:45 AM, Chen-Yu Tsai wrote:
Hi,
On Wed, Feb 10, 2016 at 5:25 PM, Hans de Goede wrote:
From: Jelle van der Waa
Add support for phy 1-3.
Signed-off-by: Jelle van der Waa
[hdego...@redhat.com: use setclrbits_le32 instead of read-modify-write]
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/usb_phy.c| 35 +--
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 22 +
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 8 ++
configs/orangepi_pc_defconfig | 1 +
configs/orangepi_plus_defconfig | 1 +
drivers/usb/host/ehci-sunxi.c | 14 +--
drivers/usb/host/ohci-sunxi.c | 18 +++---
include/configs/sun8i.h | 6 -
8 files changed, 81 insertions(+), 24 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/usb_phy.c
b/arch/arm/cpu/armv7/sunxi/usb_phy.c
index 19bb5a1..6ac96cc 100644
--- a/arch/arm/cpu/armv7/sunxi/usb_phy.c
+++ b/arch/arm/cpu/armv7/sunxi/usb_phy.c
@@ -31,6 +31,9 @@
#define SUNXI_EHCI_AHB_INCRX_ALIGN_EN (1 << 8)
#define SUNXI_EHCI_ULPI_BYPASS_EN (1 << 0)
+#define REG_PHY_UNK_H3 0x420
+#define REG_PMU_UNK_H3 0x810
+
static struct sunxi_usb_phy {
int usb_rst_mask;
int gpio_vbus;
@@ -39,19 +42,30 @@ static struct sunxi_usb_phy {
int id;
int init_count;
int power_on_count;
+ int base;
} sunxi_usb_phy[] = {
{
.usb_rst_mask = CCM_USB_CTRL_PHY0_RST | CCM_USB_CTRL_PHY0_CLK,
.id = 0,
+ .base = SUNXI_USB0_BASE,
},
{
.usb_rst_mask = CCM_USB_CTRL_PHY1_RST | CCM_USB_CTRL_PHY1_CLK,
.id = 1,
+ .base = SUNXI_USB1_BASE,
},
#if CONFIG_SUNXI_USB_PHYS >= 3
{
.usb_rst_mask = CCM_USB_CTRL_PHY2_RST | CCM_USB_CTRL_PHY2_CLK,
.id = 2,
+ .base = SUNXI_USB2_BASE,
+ },
+#endif
+#if CONFIG_SUNXI_USB_PHYS >= 4
+ {
+ .usb_rst_mask = CCM_USB_CTRL_PHY3_RST | CCM_USB_CTRL_PHY3_CLK,
+ .id = 3,
+ .base = SUNXI_USB3_BASE,
}
#endif
};
@@ -114,6 +128,15 @@ static void usb_phy_write(struct sunxi_usb_phy *phy, int
addr,
}
}
+#if defined CONFIG_MACH_SUN8I_H3
+static void sunxi_usb_phy_config(struct sunxi_usb_phy *phy)
+{
+ if (phy->id == 0)
+ clrbits_le32(SUNXI_USBPHY_BASE + REG_PHY_UNK_H3, 0x01);
+
+ clrbits_le32(phy->base + REG_PMU_UNK_H3, 0x02);
+}
+#else
static void sunxi_usb_phy_config(struct sunxi_usb_phy *phy)
{
/* The following comments are machine
@@ -136,16 +159,14 @@ static void sunxi_usb_phy_config(struct sunxi_usb_phy
*phy)
return;
}
+#endif
-static void sunxi_usb_phy_passby(int index, int enable)
+static void sunxi_usb_phy_passby(struct sunxi_usb_phy *phy, int enable)
{
unsigned long bits = 0;
void *addr;
- if (index == 1)
- addr = (void *)SUNXI_USB1_BASE + SUNXI_USB_PMU_IRQ_ENABLE;
- else
- addr = (void *)SUNXI_USB2_BASE + SUNXI_USB_PMU_IRQ_ENABLE;
+ addr = (void *)phy->base + SUNXI_USB_PMU_IRQ_ENABLE;
I'd suggest moving this into struct sunxi_usb_phy itself, i.e. have
sunxi_usb_phy
record the phy register base, instead of the whole usb controller block, kind of
like what we have for the kernel sun4i-a10-usb-phy bindings. This
would help with
moving the phy driver to device model / DT. But it would add more modifications.
It's up to you though.
I think its best to keep this as is for now.
bits = SUNXI_EHCI_AHB_ICHR8_EN |
SUNXI_EHCI_AHB_INCR4_BURST_EN |
@@ -181,7 +202,7 @@ void sunxi_usb_phy_init(int index)
sunxi_usb_phy_config(phy);
if (phy->id != 0)
- sunxi_usb_phy_passby(index, SUNXI_USB_PASSBY_EN);
+ sunxi_usb_phy_passby(phy, SUNXI_USB_PASSBY_EN);
}
void sunxi_usb_phy_exit(int index)
@@ -194,7 +215,7 @@ void sunxi_usb_phy_exit(int index)
return;
if (phy->id != 0)
- sunxi_usb_phy_passby(index, !SUNXI_USB_PASSBY_EN);
+ sunxi_usb_phy_passby(phy, !SUNXI_USB_PASSBY_EN);
clrbits_le32(&ccm->usb_clk_cfg, phy->usb_rst_mask);
}
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index 554d858..1655f10 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -229,8 +229,18 @@ struct sunxi_ccm_reg {
/* ahb_gate0 offsets */
#define AHB_GATE_OFFSET_USB_OHCI1 30
#define AHB_GATE_OFFSET_USB_OHCI0 29
+#ifdef CONFIG_MACH_SUN8I_H3
+/*
+ * These are EHCI1 - EHCI3 in the datasheet we call them 0 - 2 like they
+ * were called on older SoCs.
+ */
Maybe mention EHCI0 / OHCI0 are for USB OTG?
Re: [U-Boot] [PATCH 2/2] Add support the Avionic Design Meerkat COM and Kein Baseboard
On 23.02.16 19:03, Stephen Warren wrote:
On 02/23/2016 05:59 AM, Julian Scheel wrote:
Add support for platforms based on the Meerkat COM module. Includes
support
for the minimal reference platform called Kein Baseboard, which in
fact is
sufficient to run most existing Meerkat carriers.
diff --git a/arch/arm/dts/tegra124-meerkat.dtsi
b/arch/arm/dts/tegra124-meerkat.dtsi
+aliases {
+i2c0 = "/i2c@7000c000";
+i2c1 = "/i2c@7000c400";
+i2c2 = "/i2c@7000c500";
+i2c3 = "/i2c@7000c700";
+i2c4 = "/i2c@7000d000";
+i2c5 = "/i2c@7000d100";
/i2c@7000d000 is alias i2c0 on all other Tegra boards that have I2C
aliases.
See topic mail, I think we can change that.
diff --git a/arch/arm/mach-tegra/tegra124/Kconfig
b/arch/arm/mach-tegra/tegra124/Kconfig
+config TARGET_KBB
+bool "Avionic Design Kein Baseboard"
+select CPU_V7_HAS_NONSEC if !SPL_BUILD
+select CPU_V7_HAS_VIRT if !SPL_BUILD
+help
+ Minimal baseboard for Avionic Design Meerkat COM. Should work
with most
+ baseboard that follow the reference design.
I hope "KBB" doesn't turn out to be too generic and cause conflicts. I
might suggest TARGET_AD_KBB. However, I suppose we can just rename this
if it becomes a problem later, so perhaps it isn't worth fixing.
I think changing to TARGET_KEIN_BASEBOARD might be the best? Matches the
directory name and is unlikely to conflict with anything... Only a bit
bulky.
diff --git a/board/avionic-design/common/meerkat.c
b/board/avionic-design/common/meerkat.c
+int tegra_pcie_board_init(void)
+err = as3722_gpio_configure(pmic, 1, AS3722_GPIO_OUTPUT_VDDH |
+ AS3722_GPIO_INVERT);
+if (err < 0) {
+error("failed to configure GPIO#1 as output: %d\n", err);
+return err;
+}
+
+err = as3722_gpio_direction_output(pmic, 2, 1);
+if (err < 0) {
+error("failed to set GPIO#2 high: %d\n", err);
+return err;
+}
Those two GPIO manipulations should likely be removed; see the recent
change to similar code in jetson-tk1.c.
Ack. I think this code was shamelessly stolen from jetson-tk1.c without
rethinking, anyway.
diff --git a/board/avionic-design/common/pinmux-config-meerkat.h
b/board/avionic-design/common/pinmux-config-meerkat.h
I'd like to see the pinmux config for this board added to
https://github.com/NVIDIA/tegra-pinmux-scripts
That way, if we want to support other SW stacks and/or e.g. change the
structure of these pinmux tables, we can simply re-generate this file
with no issue.
Was this file auto-generated using a downstream version of
tegra-pinmux-scripts? There's no comment indicating it was, and the most
recent tegra-pinmux-scripts does add such a comment...
In fact this pinmux is handcrafted and we do not maintain that excel
sheet which tegra-pinmux-scripts uses.
I'll start a discussion internally if we could provide it with
reasonable effort.
diff --git a/board/avionic-design/kein-baseboard/Kconfig
b/board/avionic-design/kein-baseboard/Kconfig
+if TARGET_KBB
It'd be nice if this directory name matched the Kconfig symbol.
See above.
diff --git a/configs/kein-baseboard_defconfig
b/configs/kein-baseboard_defconfig
diff --git a/include/configs/kein-baseboard.h
b/include/configs/kein-baseboard.h
+#define CONFIG_USB_MAX_CONTROLLER_COUNT3
That define shouldn't be necessary any more, following the conversion of
Tegra to DM USB.
Ack, didn't spot that when rebasing to recent u-boot.
+#define CONFIG_CMD_PCI_ENUM
That define shouldn't be necessary any more, following the conversion of
Tegra to DM PCI.
Ack again.
Thanks for the super fast review :)
-Julian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: power: add support for sy8106a driver
Hi, On 02/23/2016 06:47 PM, Jelle van der Waa wrote: SY8106A is a PMIC which is used on the Allwinner H3 Orange Pi Pc and Plus board. The VOUT1_SEL register is implemented to set the default V-CPU voltage to 1200 mV. This driver is required to retain the SY8106A V-CPU voltage after a software reset. On cold boot the default SY8106A output voltage is selected by a pair of resistors and happens to be 1.2V on the Orange Pi PC and Plus. Signed-off-by: Jelle van der Waa Signed-off-by: Hans de Goede Tested-by: Siarhei Siamashka Acked-by: Siarhei Siamashka --- Changes in v2 - Fixed typo in commit message thea => the. - Made config R_I2C_ENABLE depend on SY8106A_POWER. - Removed 'default n' from config R_I2C_ENABLE - Changed SY8106A_POWER description from "most" to "some" boards. - Added license/copyright to include/sy8106a.h and drivers/power/sy8106a.c. Thanks, I've merged this (with a slightly improved commit msg) into my tree and it will be part of my next pull-req. Regards, Hans --- board/sunxi/Kconfig| 5 - board/sunxi/board.c| 5 + configs/orangepi_pc_defconfig | 2 +- drivers/power/Kconfig | 16 drivers/power/Makefile | 1 + drivers/power/sy8106a.c| 29 + include/configs/sunxi-common.h | 6 -- include/sy8106a.h | 11 +++ 8 files changed, 71 insertions(+), 4 deletions(-) create mode 100644 drivers/power/sy8106a.c create mode 100644 include/sy8106a.h diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index a334aa3..5e9d3af 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -372,11 +372,14 @@ config I2C3_ENABLE See I2C0_ENABLE help text. endif +if SUNXI_GEN_SUN6I config R_I2C_ENABLE bool "Enable the PRCM I2C/TWI controller" - default n + # This is used for the pmic on H3 + default y if SY8106A_POWER ---help--- Set this to y to enable the I2C controller which is part of the PRCM. +endif if MACH_SUN7I config I2C4_ENABLE diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 420481a..15b7af6 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -25,6 +25,7 @@ #include #include #include +#include #if defined CONFIG_VIDEO_LCD_PANEL_I2C && !(defined CONFIG_SPL_BUILD) /* So that we can use pin names in Kconfig and sunxi_name_to_gpio() */ @@ -436,6 +437,10 @@ void sunxi_board_init(void) int power_failed = 0; unsigned long ramsize; +#ifdef CONFIG_SY8106A_POWER + power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT); +#endif + #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \ defined CONFIG_AXP221_POWER || defined CONFIG_AXP818_POWER power_failed = axp_init(); diff --git a/configs/orangepi_pc_defconfig b/configs/orangepi_pc_defconfig index ea9ed87..29a8da6 100644 --- a/configs/orangepi_pc_defconfig +++ b/configs/orangepi_pc_defconfig @@ -12,4 +12,4 @@ CONFIG_SPL=y # CONFIG_CMD_FLASH is not set # CONFIG_CMD_FPGA is not set CONFIG_CMD_GPIO=y -CONFIG_R_I2C_ENABLE=y +CONFIG_SY8106A_POWER=y diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 10683a2..adc6455 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -48,6 +48,13 @@ config AXP818_POWER Say y here to enable support for the axp818 pmic found on A83T dev board. +config SY8106A_POWER + boolean "SY8106A pmic support" + depends on MACH_SUN8I_H3 + ---help--- + Select this to enable support for the SY8106A pmic found on some + H3 boards. + endchoice config AXP_DCDC1_VOLT @@ -232,4 +239,13 @@ config AXP_ELDO3_VOLT 1.2V for the SSD2828 chip (converter of parallel LCD interface into MIPI DSI). +config SY8106A_VOUT1_VOLT + int "SY8106A pmic VOUT1 voltage" + depends on SY8106A_POWER + default 1200 + ---help--- + Set the voltage (mV) to program the SY8106A pmic VOUT1. This + is typically used to power the VDD-CPU and should be 1200mV. + Values can range from 680mV till 1950mV. + endmenu diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 0fdbca3..690faa0 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_AXP221_POWER)+= axp221.o obj-$(CONFIG_AXP818_POWER)+= axp818.o obj-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o obj-$(CONFIG_FTPMU010_POWER) += ftpmu010.o +obj-$(CONFIG_SY8106A_POWER)+= sy8106a.o obj-$(CONFIG_TPS6586X_POWER) += tps6586x.o obj-$(CONFIG_TWL4030_POWER) += twl4030.o obj-$(CONFIG_TWL6030_POWER) += twl6030.o diff --git a/drivers/power/sy8106a.c b/drivers/power/sy8106a.c new file mode 100644 index 000..bbf116f --- /dev/null +++ b/drivers/power/sy8106a.c @@ -0,0 +1,29 @@ +/* + * (C) Copyright 2016 + * Jelle van der Waa + * + * SPDX-License-Identifier:GPL-2.0+ + */ +#include +#include +#include + +#defin
Re: [U-Boot] [PATCH 0/2] tegra124: Add support for Avionic Design platform
On 23.02.16 18:49, Stephen Warren wrote: On 02/23/2016 05:59 AM, Julian Scheel wrote: This adds support for the Avionic Design Tegra124 platform. It consists of the Meerkat SOM and a minimal baseboard Kein Baseboard. The as3722 is placed on a different bus as compared to nvidia Jetson, which makes the as3722 required. This doesn't appear to be quite true. It looks like the AS3722 is on the same physical bus, it's just that the I2C aliases in DT assign this bus a different number. Typically, all Tegra boards have the PMIC I2C bus as U-Boot I2C bus 0. Is there a good reason not to do that here? You are indeed right. I was so sure about it being a different bus that I did not check it at all... In fact I don't see a real reason not do reorder the i2c to match the other platforms. But let me discuss it with Alban before changing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: atheros: Fix problem with phy_reset() clearing BMCR
On Fri, Feb 19, 2016 at 1:52 AM, Alison Wang wrote: > In commit [net: phy: do not read configuration register on > reset], phy_reset() will clear the BMCR register. Bit 12(AUTO_NEGOTIATION) > is cleared too. It causes auto-negotiation timeout error on Atheros's > PHY AR8033. > > To fix this problem, genphy_config_aneg() and genphy_restart_aneg() > needs to be called in ar8035_config() to enable and restart > auto-negotiation. > > Signed-off-by: Alison Wang Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx53ard: Move to booting zImage
Move to booting a zImage kernel by default to align with the other
i.MX boards.
While at it, adjust the fdt_addr so that we can boot a standard
mainline kernel.
Signed-off-by: Fabio Estevam
---
include/configs/mx53ard.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
index fdb4134..25a4630 100644
--- a/include/configs/mx53ard.h
+++ b/include/configs/mx53ard.h
@@ -31,6 +31,8 @@
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_MXC_GPIO
+#define CONFIG_CMD_BOOTZ
+
#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_BASE NFC_BASE_ADDR_AXI
#define CONFIG_NAND_MXC
@@ -93,12 +95,12 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
- "uimage=uImage\0" \
+ "uimage=zImage\0" \
"console=ttymxc0\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
- "fdt_addr=0x7100\0" \
+ "fdt_addr=0x7800\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
@@ -130,16 +132,16 @@
"run mmcargs; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
"if run loadfdt; then " \
- "bootm ${loadaddr} - ${fdt_addr}; " \
+ "bootz ${loadaddr} - ${fdt_addr}; " \
"else " \
"if test ${boot_fdt} = try; then " \
- "bootm; " \
+ "bootz; " \
"else " \
"echo WARN: Cannot load the DT; " \
"fi; " \
"fi; " \
"else " \
- "bootm; " \
+ "bootz; " \
"fi;\0" \
"netargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/nfs " \
@@ -154,16 +156,16 @@
"${get_cmd} ${uimage}; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
"if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
- "bootm ${loadaddr} - ${fdt_addr}; " \
+ "bootz ${loadaddr} - ${fdt_addr}; " \
"else " \
"if test ${boot_fdt} = try; then " \
- "bootm; " \
+ "bootz; " \
"else " \
"echo WARN: Cannot load the DT; " \
"fi; " \
"fi; " \
"else " \
- "bootm; " \
+ "bootz; " \
"fi;\0"
#define CONFIG_BOOTCOMMAND \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: bootp: Add environment variable for timeout period
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of > amessier.t...@gmail.com > Sent: 1-Feb-16 5:09 PM > > From: Alexandre Messier > > There is currently one config option (CONFIG_NET_RETRY_COUNT) that > is available to tune the retries of the network stack. > Unfortunately, it is global to all protocols, and the value is > interpreted differently in all of them. > > Add a new environment variable that directly sets the retry period for > BOOTP timeouts. If this new value is not set, the period is still derived > from the default number of retries, or from CONFIG_NET_RETRY_COUNT if > defined. When both the new variable is set and CONFIG_NET_RETRY_COUNT > is defined, the variable has precedence. > > Signed-off-by: Alexandre Messier > --- > > Changes since v1: > - Now uses an environment variable instead of a config option. This is to >have a similar approach as TFTP towards how timeouts are controlled. >(e.g. https://patchwork.ozlabs.org/patch/528815/) > - Title was changed, it was previously "net: bootp: Add BOOTP specific >config for timeout value." > - Removed from patch series. v1 was in a series, but now the patch >stands alone. > > v1 can be found here: > Patchwork: https://patchwork.ozlabs.org/patch/571776/ > Mailing list: http://lists.denx.de/pipermail/u-boot/2016-January/242840.html > Hi Joe, Is there any change this patch can make it into v2016.03? Sylvain Lemieux > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hello Dennis, Am 22.02.2016 um 15:17 schrieb Bakhvalov, Denis (Nokia - PL/Wroclaw): Dear U-Boot support, I have problems while running following commands in U-Boot: Which U-Boot version? Which board? U-Boot => sf probe 0 0 0 SF: Detected S25FL512S with page size 512, total: 67108864 U-Boot => mtdparts device nor0 , # parts = 4 #: namesizeoffset mask_flags 0: boot0x0010 0x 0 1: bootenv 0x0008 0x0010 0 2: SomeInfo0x0198 0x0018 0 3: ubifspart 0x0250 0x01b0 0 U-Boot => ubi part ubifspart mtd: Giving out device 1 to mtd=3 ubi0: attaching mtd1 UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48 UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20 UBI DBG gen (pid 1): min_io_size 1 UBI DBG gen (pid 1): max_write_size 512 UBI DBG gen (pid 1): hdrs_min_io_size 1 UBI DBG gen (pid 1): ec_hdr_alsize64 UBI DBG gen (pid 1): vid_hdr_alsize 64 UBI DBG gen (pid 1): vid_hdr_offset 64 UBI DBG gen (pid 1): vid_hdr_aloffset 64 UBI DBG gen (pid 1): vid_hdr_shift0 UBI DBG gen (pid 1): leb_start128 UBI DBG gen (pid 1): max_erroneous16 UBI DBG gen (pid 1): process PEB 0 UBI DBG bld (pid 1): scan PEB 0 UBI DBG io (pid 1): read EC header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:0 ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead of 55424923 Erase counter header dump: magic 0xff554249 Where does this leading 0xff come from? There seems a problem with your spi nor flash driver? I am currently on the EW 2016 in nuernberg, I could not look deeper here... I think try to check your spi nor flash driver... bye, Heiko version35 ec 0 vid_hdr_offset 16777216 data_offset1073741824 image_seq -2142856561 hdr_crc0xe046ed erase counter header hexdump: UBI DBG bld (pid 1): bad magic number at PEB 0: ff554249 instead of 55424923 UBI DBG io (pid 1): read VID header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:64 UBI DBG bld (pid 1): no VID header found at PEB 0, only 0xFF bytes UBI DBG bld (pid 1): add to erase: PEB 0, EC -1 ... // this warning goes for all PEBs from 1 to 147 ubi0: scanning is finished UBI DBG gen (pid 1): max. sequence number: 0 ubi0 error: ubi_read_volume_table: the layout volume was not found ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22 UBI error: cannot attach mtd1 UBI error: cannot initialize UBI, error -22 UBI init error 22 UBI init error 22 For me it looks like this magic number is shifted one byte right, although I can't understand why. Here is how I create UBI partition in Linux env: Linux Env #> mtdinfo -a mtd5 Name: data Type: nor Eraseblock size:262144 bytes, 256.0 KiB Amount of eraseblocks: 148 (38797312 bytes, 37.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:10 Bad blocks are allowed: false Device is writable: true Linux Env #> ubiformat /dev/mtd5 ubiformat: mtd5 (nor), size 38797312 bytes (37.0 MiB), 148 eraseblocks of 262144 bytes (256.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 147 -- 100 % complete ubiformat: 148 eraseblocks are supposedly empty ubiformat: formatting eraseblock 147 -- 100 % complete 797312 Linux Env #> ubiattach -m 5 /dev/ubi_ctrl UBI: attaching mtd5 to ubi0 UBI: scanning is finished UBI: attached mtd5 (name "part5", size 37 MiB) to ubi0 UBI: PEB size: 262144 bytes (256 KiB), LEB size: 262016 bytes UBI: min./max. I/O unit sizes: 1/256, sub-page size 1 UBI: VID header offset: 64 (aligned 64), data offset: 128 UBI: good PEBs: 148, bad PEBs: 0, corrupted PEBs: 0 UBI: user volume: 0, internal volumes: 1, max. volumes count: 128 UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1371523162 UBI: available PEBs: 144, total reserved PEBs: 4, PEBs reserved for bad PEB handling: 0 UBI: background thread "ubi_bgt0d" started, PID 1003 Linux Env #> ubimkvol -N data -m /dev/ubi0 Linux Env #> mount -t ubifs ubi0:data /mnt Linux Env #> mount -t ubifs ubi0:data /mnt UBIFS: default file-system created UBIFS: background thread "ubifs_bgt0_0" started, PID 1010 UBIFS: mounted UBI device 0, volume 0, name "data" UBIFS: LEB size: 262016 bytes (255 KiB), min./max. I/O unit sizes: 8 bytes/256 bytes UBIFS: FS size: 35110144 bytes (33 MiB, 134 LEBs), journal size 2096129 bytes (1 MiB, 7 LEBs) UBIFS: reserved for root: 1658338 bytes (1619 KiB) UBIFS: media format: w4/r0 (latest is w4/r0), UUID 696FFD7B-1957-4ABD-9FDC-ED0EEB674D9D, small LPT model It's perfectly working from Linux env, however U-Boot don't want to attach UBI partition. Please help me identify the problem! Best regards, Denis B
Re: [U-Boot] [PATCH 2/2] Add support the Avionic Design Meerkat COM and Kein Baseboard
On 02/23/2016 05:59 AM, Julian Scheel wrote:
Add support for platforms based on the Meerkat COM module. Includes support
for the minimal reference platform called Kein Baseboard, which in fact is
sufficient to run most existing Meerkat carriers.
diff --git a/arch/arm/dts/tegra124-meerkat.dtsi
b/arch/arm/dts/tegra124-meerkat.dtsi
+ aliases {
+ i2c0 = "/i2c@7000c000";
+ i2c1 = "/i2c@7000c400";
+ i2c2 = "/i2c@7000c500";
+ i2c3 = "/i2c@7000c700";
+ i2c4 = "/i2c@7000d000";
+ i2c5 = "/i2c@7000d100";
/i2c@7000d000 is alias i2c0 on all other Tegra boards that have I2C aliases.
diff --git a/arch/arm/mach-tegra/tegra124/Kconfig
b/arch/arm/mach-tegra/tegra124/Kconfig
+config TARGET_KBB
+ bool "Avionic Design Kein Baseboard"
+ select CPU_V7_HAS_NONSEC if !SPL_BUILD
+ select CPU_V7_HAS_VIRT if !SPL_BUILD
+ help
+ Minimal baseboard for Avionic Design Meerkat COM. Should work with
most
+ baseboard that follow the reference design.
I hope "KBB" doesn't turn out to be too generic and cause conflicts. I
might suggest TARGET_AD_KBB. However, I suppose we can just rename this
if it becomes a problem later, so perhaps it isn't worth fixing.
diff --git a/board/avionic-design/common/meerkat.c
b/board/avionic-design/common/meerkat.c
+int tegra_pcie_board_init(void)
+ err = as3722_gpio_configure(pmic, 1, AS3722_GPIO_OUTPUT_VDDH |
+AS3722_GPIO_INVERT);
+ if (err < 0) {
+ error("failed to configure GPIO#1 as output: %d\n", err);
+ return err;
+ }
+
+ err = as3722_gpio_direction_output(pmic, 2, 1);
+ if (err < 0) {
+ error("failed to set GPIO#2 high: %d\n", err);
+ return err;
+ }
Those two GPIO manipulations should likely be removed; see the recent
change to similar code in jetson-tk1.c.
diff --git a/board/avionic-design/common/pinmux-config-meerkat.h
b/board/avionic-design/common/pinmux-config-meerkat.h
I'd like to see the pinmux config for this board added to
https://github.com/NVIDIA/tegra-pinmux-scripts
That way, if we want to support other SW stacks and/or e.g. change the
structure of these pinmux tables, we can simply re-generate this file
with no issue.
Was this file auto-generated using a downstream version of
tegra-pinmux-scripts? There's no comment indicating it was, and the most
recent tegra-pinmux-scripts does add such a comment...
diff --git a/board/avionic-design/kein-baseboard/Kconfig
b/board/avionic-design/kein-baseboard/Kconfig
+if TARGET_KBB
It'd be nice if this directory name matched the Kconfig symbol.
diff --git a/configs/kein-baseboard_defconfig b/configs/kein-baseboard_defconfig
diff --git a/include/configs/kein-baseboard.h b/include/configs/kein-baseboard.h
+#define CONFIG_USB_MAX_CONTROLLER_COUNT3
That define shouldn't be necessary any more, following the conversion of
Tegra to DM USB.
+#define CONFIG_CMD_PCI_ENUM
That define shouldn't be necessary any more, following the conversion of
Tegra to DM PCI.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] power: as3722: Allow using on any i2c bus with any address
On 02/23/2016 05:59 AM, Julian Scheel wrote: From: Alban Bedel The init simply hardcoded the i2c bus and address to those used on jetson. Extend the init function to take the bus number and device address as parameter. As only jetson is using this code for now just fix this single use of the function. Signed-off-by: Alban Bedel Reviewed-by: Julian Scheel Since you (Julian) are submitting this, it should be s-o-b you too. Irrespective of my comments on the cover letter, this patch seems fine, so once the s-o-b is fixed, Acked-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] tegra124: Add support for Avionic Design platform
On 02/23/2016 05:59 AM, Julian Scheel wrote: This adds support for the Avionic Design Tegra124 platform. It consists of the Meerkat SOM and a minimal baseboard Kein Baseboard. The as3722 is placed on a different bus as compared to nvidia Jetson, which makes the as3722 required. This doesn't appear to be quite true. It looks like the AS3722 is on the same physical bus, it's just that the I2C aliases in DT assign this bus a different number. Typically, all Tegra boards have the PMIC I2C bus as U-Boot I2C bus 0. Is there a good reason not to do that here? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic
On 02/23/2016 10:30 AM, Simon Glass wrote: Hi Stephen, On 23 February 2016 at 10:21, Stephen Warren wrote: On 02/23/2016 06:17 AM, Simon Glass wrote: Hi Alex, On 21 February 2016 at 18:57, Alexander Graf wrote: The idea to generate our pages tables from an array of memory ranges is very sound. However, instead of hard coding the code to create up to 2 levels of 64k granule page tables, we really should just create normal 4k page tables that allow us to set caching attributes on 2M or 4k level later on. So this patch moves the full_va mapping code to 4k page size and makes it fully flexible to dynamically create as many levels as necessary for a map (including dynamic 1G/2M pages). It also adds support to dynamically split a large map into smaller ones when some code wants to set dcache attributes. With all this in place, there is very little reason to create your own page tables in board specific files. static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP; I am not ken on the idea of using a big #define table on these boards. Is there not a device-tree binding for this that we can use? It is just a data table, We are moving to Kconfig and eventually want to drop the config files. I would strongly object to making the MMU setup depend on device tree parsing. This is low-level system code that should be handled purely by simple standalone C code. Because...? There is literally zero benefit from putting the exact same content into DT, and hence having to run significantly more code to parse DT and get back exactly the same hard-coded table. DT is not a goal in-and-of-itself. In some cases there are benefits to placing configuration data outside a binary, and in those cases DT is an acceptable mechanism to do that. However, any benefit from doing so derives from arguments for separating the data out of the code, not because "use DT" is itself a benefit. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic
Hi Stephen, On 23 February 2016 at 10:21, Stephen Warren wrote: > On 02/23/2016 06:17 AM, Simon Glass wrote: >> >> Hi Alex, >> >> On 21 February 2016 at 18:57, Alexander Graf wrote: >>> >>> The idea to generate our pages tables from an array of memory ranges >>> is very sound. However, instead of hard coding the code to create up >>> to 2 levels of 64k granule page tables, we really should just create >>> normal 4k page tables that allow us to set caching attributes on 2M >>> or 4k level later on. >>> >>> So this patch moves the full_va mapping code to 4k page size and >>> makes it fully flexible to dynamically create as many levels as >>> necessary for a map (including dynamic 1G/2M pages). It also adds >>> support to dynamically split a large map into smaller ones when >>> some code wants to set dcache attributes. >>> >>> With all this in place, there is very little reason to create your >>> own page tables in board specific files. > > >>> static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP; >> >> >> I am not ken on the idea of using a big #define table on these boards. >> Is there not a device-tree binding for this that we can use? It is >> just a data table, We are moving to Kconfig and eventually want to >> drop the config files. > > > I would strongly object to making the MMU setup depend on device tree > parsing. This is low-level system code that should be handled purely by > simple standalone C code. Because...? > > Having some CPU-/SoC-/board-specific code define the table, rather than > having it be a #define, seems fine though, if the code in the current patch > needs to change. That seems OK. Perhaps a table in board-specific code and a way to add new entries on top. Bear in mind that this happens before relocation but quite late in the pre-reloc init sequence. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] tegra: Replace home grown mmu code with generic table approach
On 02/23/2016 03:37 AM, Michal Simek wrote:
On 22.2.2016 19:28, Stephen Warren wrote:
On 02/21/2016 06:57 PM, Alexander Graf wrote:
Now that we have nice table driven page table creating code that gives
us everything we need, move to that.
diff --git a/include/configs/tegra210-common.h
b/include/configs/tegra210-common.h
+#define CONFIG_SYS_FULL_VA
+#define CONFIG_SYS_MEM_MAP {\
+{\
+.base = 0x0UL,\
+.size = 0x8000UL,\
+.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |\
+ PTE_BLOCK_NON_SHARE |\
+ PTE_BLOCK_PXN | PTE_BLOCK_UXN\
+}, {\
+.base = 0x8000UL,\
+.size = 0xff8000UL,\
+.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |\
+ PTE_BLOCK_INNER_SHARE\
+},\
+}
I'd prefer a layout that didn't align the closing } for different
nesting levels in the same column. To avoid indenting everything a lot,
it seems simplest to pull the final } back into the first column.
I believe the .size field of the second entry in the array only needs to
be 0x8000. Testing with a PCIe Ethernet card on p2371-2180 (the
driver for which sets up noncached entries in the page tables, hence
should exercise all this code) confirms that.
While recent Tegra systems do support more than 2GB of RAM, U-Boot will
itself only use the first 2GB, so that PAs over 4GB are not used. See
board_get_usable_ram_top() in arch/arm/mach-tegra/board2.c. That's
because some peripherals can only access 32-bit PAs, and the simplest
way to accommodate that is to ignore any RAM above the 32-bit limit.
Didn't you use mtest to test memory above of 2GB?
It looks like we don't have mtest enabled.
However, I was able to use itest to confirm that RAM > 4GB PA does work
with this patch. I suppose we may as well leave it enabled then.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic
On 02/23/2016 06:17 AM, Simon Glass wrote: Hi Alex, On 21 February 2016 at 18:57, Alexander Graf wrote: The idea to generate our pages tables from an array of memory ranges is very sound. However, instead of hard coding the code to create up to 2 levels of 64k granule page tables, we really should just create normal 4k page tables that allow us to set caching attributes on 2M or 4k level later on. So this patch moves the full_va mapping code to 4k page size and makes it fully flexible to dynamically create as many levels as necessary for a map (including dynamic 1G/2M pages). It also adds support to dynamically split a large map into smaller ones when some code wants to set dcache attributes. With all this in place, there is very little reason to create your own page tables in board specific files. static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP; I am not ken on the idea of using a big #define table on these boards. Is there not a device-tree binding for this that we can use? It is just a data table, We are moving to Kconfig and eventually want to drop the config files. I would strongly object to making the MMU setup depend on device tree parsing. This is low-level system code that should be handled purely by simple standalone C code. Having some CPU-/SoC-/board-specific code define the table, rather than having it be a #define, seems fine though, if the code in the current patch needs to change. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] test/py: Add option to skip SPL signature checking
On 02/23/2016 02:40 AM, Michal Simek wrote:
Provide user option to skip SPL signature verification for cases where
u-boot is build with SPL support but full U-Boot is also verified
without SPL.
If you want to support this feature please add env__spl_skipped = True
to your boardenv configuration file.
For example Xilinx Zynq is using this feature where the same U-Boot
binary is checked with SPL and without SPL(with FSBL).
Signed-off-by: Michal Simek
Tested-by: Stephen Warren
Acked-by: Stephen Warren
Actually, NAK now...
diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index d6502c6e64cb..b48d07261ff2 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -307,7 +307,9 @@ class ConsoleBase(object):
config_spl = bcfg.get('config_spl', 'n') == 'y'
config_spl_serial_support = bcfg.get('config_spl_serial_support',
'n') == 'y'
-if config_spl and config_spl_serial_support:
+config_spl_skip = self.config.env.get('env_spl_skipped',
+ False)
I was talking about renaming the Python variable config_spl_skip, not
the boardenv_*.py variable env__spl_skipped.
The boardenv_*.py variable should be env__* to match existing variables
in the Python file.
I was requesting that the Python variable be named env_... not
config_... since it contains "board environment" not "config" data.
(BTW, you probably want to Cc Tom Rini on the next patch version since I
assume he'd apply this)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v4 1/3] sandbox: Fix compiling warning on 32-bit host
On 02/16/2016 08:01 AM, Simon Glass wrote:
> +Masahiro
>
> Hi York,
>
> On 12 February 2016 at 13:59, York Sun wrote:
>> Fix the following compiling warning on 32-bit host
>>
>> disk/part_efi.c: In function 'alloc_read_gpt_entries':
>> disk/part_efi.c:894:2: warning: format '%zu' expects argument of
>> type 'size_t', but argument 5 has type 'long unsigned int'
>> [-Wformat]
>> disk/part_efi.c:907:4: warning: format '%zX' expects argument of
>> type 'size_t', but argument 3 has type 'long unsigned int'
>> [-Wformat]
>> cmd/lzmadec.c: In function 'do_lzmadec':
>> cmd/lzmadec.c:39:12: warning: passing argument 2 of
>> 'lzmaBuffToBuffDecompress' from incompatible pointer type
>> [enabled by default]
>> include/lzma/../../lib/lzma/LzmaTools.h:17:12: note: expected
>> 'SizeT *' but argument is of type 'long unsigned int *'
>> lib/hashtable.c: In function 'hexport_r':
>> lib/hashtable.c:605:2: warning: format '%zu' expects argument of
>> type 'size_t', but argument 5 has type 'long unsigned int'
>> [-Wformat]
>> lib/hashtable.c:661:5: warning: format '%zu' expects argument of
>> type 'size_t', but argument 2 has type 'long unsigned int'
>> [-Wformat]
>> lib/hashtable.c:661:5: warning: format '%zu' expects argument of
>> type 'size_t', but argument 3 has type 'long unsigned int'
>> [-Wformat]
>> lib/hashtable.c: In function 'himport_r':
>> lib/hashtable.c:793:3: warning: format '%zu' expects argument of
>> type 'size_t', but argument 2 has type 'long unsigned int'
>> [-Wformat]
>>
>> Signed-off-by: York Sun
>>
>> ---
>>
>> Changes in v4:
>> New patch to fix compiling warnings for sandbox built on 32-bit host
>> Still need to change CONFIG_SANDBOX_BITS_PER_LONG to 32 to avoid
>> these warnings
>> include/asm-generic/bitops/__fls.h:17:2: warning: left shift
>>count >= width of type [enabled by default]
>> include/asm-generic/bitops/__fls.h:19:3: warning: left shift
>>count >= width of type [enabled by default]
>> include/asm-generic/bitops/__fls.h:22:2: warning: left shift
>>count >= width of type [enabled by default]
>> include/asm-generic/bitops/__fls.h:26:2: warning: left shift
>>count >= width of type [enabled by default]
>> include/asm-generic/bitops/__fls.h:30:2: warning: left shift
>>count >= width of type [enabled by default]
>> include/asm-generic/bitops/__fls.h:34:2: warning: left shift
>>count >= width of type [enabled by default]
>> include/asm-generic/bitops/__fls.h:38:2: warning: left shift
>>count >= width of type [enabled by default]
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> arch/sandbox/cpu/cpu.c |3 ++-
>> arch/sandbox/include/asm/types.h |4 ++--
>> arch/sandbox/lib/bootm.c |3 ++-
>> arch/sandbox/lib/pci_io.c|2 +-
>> cmd/bootm.c |4 ++--
>> cmd/lzmadec.c|5 +++--
>> disk/part_efi.c |2 +-
>> include/image.h |6 ++
>> lib/hashtable.c |2 +-
>> 9 files changed, 20 insertions(+), 11 deletions(-)
>
> I think this makes sense. But one nit - the % is not included in the
> macros in inttypes,h. What do you think about doing the same with your
> macro?
Sure. I can drop the % sign in the macro.
>
>>
>> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
>> index 196f3e1..7aad876 100644
>> --- a/arch/sandbox/cpu/cpu.c
>> +++ b/arch/sandbox/cpu/cpu.c
>> @@ -62,7 +62,8 @@ void *map_physmem(phys_addr_t paddr, unsigned long len,
>> unsigned long flags)
>> map_dev = NULL;
>> if (enable_pci_map && !pci_map_physmem(paddr, &len, &map_dev, &ptr))
>> {
>> if (plen != len) {
>> - printf("%s: Warning: partial map at %x, wanted %lx,
>> got %lx\n",
>> + printf("%s: Warning: partial map at " PRIpa
>> + ", wanted %lx, got %lx\n",
>>__func__, paddr, len, plen);
>> }
>> map_len = len;
>> diff --git a/arch/sandbox/include/asm/types.h
>> b/arch/sandbox/include/asm/types.h
>> index 42c09e2..c3bb76e 100644
>> --- a/arch/sandbox/include/asm/types.h
>> +++ b/arch/sandbox/include/asm/types.h
>> @@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
>> #define BITS_PER_LONG CONFIG_SANDBOX_BITS_PER_LONG
>>
>> typedef unsigned long dma_addr_t;
>> -typedef u32 phys_addr_t;
>> -typedef u32 phys_size_t;
>> +typedef unsigned long phys_addr_t;
>> +typedef unsigned long phys_size_t;
>>
>> #endif /* __KERNEL__ */
>>
>> diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
>> index d49c927..9ca89b5 100644
>> --- a/arch/sandbox/lib/bootm.c
>> +++ b/arch/sandbox/lib/bootm.c
>> @@ -54,7 +54,8 @@ int do_bootm_linux(int flag, int argc, char *argv[],
>> bootm_headers_t *images)
>> {
>> if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
>> bootstage_mark(BOOTSTAGE_ID_RUN_OS);
>> -
Re: [U-Boot] Problem with attaching UBI partition
Hi, I found that I have problem with reading flash contents: When dumping the flash from Linux env: $ cat /dev/mtd5 > /tmp/flash.bin : 55424923 0100 0003 But when I dump the flash contents from U-Boot I see this: => sf read 0x1B00 0x01B0 0x1000 => md 0x1B00 1b00: 494255ff 0123 So, that's why I see this print: ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead of 55424923 I will investigate why data was read from flash incorrectly. Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic
Hi Alex,
On 21 February 2016 at 18:57, Alexander Graf wrote:
> The idea to generate our pages tables from an array of memory ranges
> is very sound. However, instead of hard coding the code to create up
> to 2 levels of 64k granule page tables, we really should just create
> normal 4k page tables that allow us to set caching attributes on 2M
> or 4k level later on.
>
> So this patch moves the full_va mapping code to 4k page size and
> makes it fully flexible to dynamically create as many levels as
> necessary for a map (including dynamic 1G/2M pages). It also adds
> support to dynamically split a large map into smaller ones when
> some code wants to set dcache attributes.
>
> With all this in place, there is very little reason to create your
> own page tables in board specific files.
>
> Signed-off-by: Alexander Graf
> ---
> arch/arm/cpu/armv8/cache_v8.c | 346
> +++--
> arch/arm/include/asm/armv8/mmu.h | 68
> arch/arm/include/asm/global_data.h | 4 +-
> arch/arm/include/asm/system.h | 3 +-
> include/configs/thunderx_88xx.h| 14 +-
> 5 files changed, 332 insertions(+), 103 deletions(-)
>
Should the change to the thunderx file go in a separate patch?
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 9229532..4369a83 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -2,6 +2,9 @@
> * (C) Copyright 2013
> * David Feng
> *
> + * (C) Copyright 2016
> + * Alexander Graf
> + *
> * SPDX-License-Identifier:GPL-2.0+
> */
>
> @@ -9,35 +12,40 @@
> #include
> #include
>
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -#ifndef CONFIG_SYS_DCACHE_OFF
> +/* #define DEBUG_MMU */
>
> -#ifdef CONFIG_SYS_FULL_VA
> -static void set_ptl1_entry(u64 index, u64 ptl2_entry)
> -{
> - u64 *pgd = (u64 *)gd->arch.tlb_addr;
> - u64 value;
> +#ifdef DEBUG_MMU
> +#define DPRINTF(a, ...) printf("%s:%d: " a, __func__, __LINE__, __VA_ARGS__)
> +#else
> +#define DPRINTF(a, ...) do { } while(0)
> +#endif
Can you use the normal DEBUG and debug()?
>
> - value = ptl2_entry | PTL1_TYPE_TABLE;
> - pgd[index] = value;
> -}
> +DECLARE_GLOBAL_DATA_PTR;
>
> -static void set_ptl2_block(u64 ptl1, u64 bfn, u64 address, u64 memory_attrs)
> -{
> - u64 *pmd = (u64 *)ptl1;
> - u64 value;
> +#ifndef CONFIG_SYS_DCACHE_OFF
>
> - value = address | PTL2_TYPE_BLOCK | PTL2_BLOCK_AF;
> - value |= memory_attrs;
> - pmd[bfn] = value;
> -}
> +/*
> + * With 4k page granule, a virtual address is split into 4 lookup parts
> + * spanning 9 bits each:
> + *
> + *___
> + * | | | | | | |
> + * | 0 | Lv0 | Lv1 | Lv2 | Lv3 | off |
> + * |___|___|___|___|___|___|
> + * 63-48 47-39 38-30 29-21 20-12 11-00
> + *
> + * maskpage size
> + *
> + *Lv0: FF80 --
> + *Lv1: 7FC000 1G
> + *Lv2: 3FE0 2M
> + *Lv3: 1FF000 4K
> + *off: FFF
> + */
>
> +#ifdef CONFIG_SYS_FULL_VA
> static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP;
I am not ken on the idea of using a big #define table on these boards.
Is there not a device-tree binding for this that we can use? It is
just a data table, We are moving to Kconfig and eventually want to
drop the config files.
>
> -#define PTL1_ENTRIES CONFIG_SYS_PTL1_ENTRIES
> -#define PTL2_ENTRIES CONFIG_SYS_PTL2_ENTRIES
> -
> static u64 get_tcr(int el, u64 *pips, u64 *pva_bits)
> {
> u64 max_addr = 0;
> @@ -79,8 +87,8 @@ static u64 get_tcr(int el, u64 *pips, u64 *pva_bits)
> }
>
> /* PTWs cacheable, inner/outer WBWA and inner shareable */
> - tcr |= TCR_TG0_64K | TCR_SHARED_INNER | TCR_ORGN_WBWA | TCR_IRGN_WBWA;
> - tcr |= TCR_T0SZ(VA_BITS);
> + tcr |= TCR_TG0_4K | TCR_SHARED_INNER | TCR_ORGN_WBWA | TCR_IRGN_WBWA;
> + tcr |= TCR_T0SZ(va_bits);
>
> if (pips)
> *pips = ips;
> @@ -90,39 +98,196 @@ static u64 get_tcr(int el, u64 *pips, u64 *pva_bits)
> return tcr;
> }
>
> -static void setup_pgtables(void)
> +#define MAX_PTE_ENTRIES 512
> +
> +static int pte_type(u64 *pte)
> +{
> + return *pte & PTE_TYPE_MASK;
> +}
> +
> +/* Returns the LSB number for a PTE on level */
> +static int level2shift(int level)
> {
> - int l1_e, l2_e;
> - unsigned long pmd = 0;
> - unsigned long address;
> -
> - /* Setup the PMD pointers */
> - for (l1_e = 0; l1_e < CONFIG_SYS_MEM_MAP_SIZE; l1_e++) {
> - gd->arch.pmd_addr[l1_e] = gd->arch.tlb_addr +
> - PTL1_ENTRIES * sizeof(u64);
> - gd->arch.pmd_addr[l1_e] += PTL2_ENTRIES * sizeof(u64) * l1_e;
> - gd->arch.pmd_addr[l1_e] = ALIGN(gd->arch.pmd_addr[l1_e],
> -
Re: [U-Boot] [PATCH v2 1/2] serial: dcc: Move driver to DM
On 23 February 2016 at 02:02, Michal Simek wrote:
> Enabling this driver requires some DT changes.
> Adding DCC to root or main bus:
> dcc: dcc {
> compatible = "arm,dcc";
> u-boot,dm-pre-reloc;
> };
>
> Extend alias list to link DCC:
> serial0 = &uart0;
> serial1 = &uart1;
> serial2 = &dcc;
>
> Change stdout-path to point to dcc port.
> stdout-path = "serial2:115200n8";
>
> Also add support for debug uart to help with early debug.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Extend Kconfig entry description
>
> drivers/serial/Kconfig | 11 +
> drivers/serial/arm_dcc.c | 63
> +---
> 2 files changed, 49 insertions(+), 25 deletions(-)
Reviewed-by: Simon Glass
Great Kconfig help, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] Add support the Avionic Design Meerkat COM and Kein Baseboard
Add support for platforms based on the Meerkat COM module. Includes support
for the minimal reference platform called Kein Baseboard, which in fact is
sufficient to run most existing Meerkat carriers.
Signed-off-by: Julian Scheel
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/tegra124-kein-baseboard.dts | 66
arch/arm/dts/tegra124-meerkat.dtsi | 395 +
arch/arm/mach-tegra/tegra124/Kconfig | 9 +
board/avionic-design/common/meerkat.c | 70
.../avionic-design/common/pinmux-config-meerkat.h | 233
board/avionic-design/kein-baseboard/Kconfig| 15 +
board/avionic-design/kein-baseboard/MAINTAINERS| 7 +
board/avionic-design/kein-baseboard/Makefile | 9 +
configs/kein-baseboard_defconfig | 21 ++
include/configs/kein-baseboard.h | 76
11 files changed, 902 insertions(+)
create mode 100644 arch/arm/dts/tegra124-kein-baseboard.dts
create mode 100644 arch/arm/dts/tegra124-meerkat.dtsi
create mode 100644 board/avionic-design/common/meerkat.c
create mode 100644 board/avionic-design/common/pinmux-config-meerkat.h
create mode 100644 board/avionic-design/kein-baseboard/Kconfig
create mode 100644 board/avionic-design/kein-baseboard/MAINTAINERS
create mode 100644 board/avionic-design/kein-baseboard/Makefile
create mode 100644 configs/kein-baseboard_defconfig
create mode 100644 include/configs/kein-baseboard.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b574284..5452e69 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra30-tec-ng.dtb \
tegra114-dalmore.dtb \
tegra124-jetson-tk1.dtb \
+ tegra124-kein-baseboard.dtb \
tegra124-nyan-big.dtb \
tegra124-venice2.dtb \
tegra210-e2220-1170.dtb \
diff --git a/arch/arm/dts/tegra124-kein-baseboard.dts
b/arch/arm/dts/tegra124-kein-baseboard.dts
new file mode 100644
index 000..75a0b99
--- /dev/null
+++ b/arch/arm/dts/tegra124-kein-baseboard.dts
@@ -0,0 +1,66 @@
+/dts-v1/;
+
+#include "tegra124-meerkat.dtsi"
+
+/ {
+ model = "Avionic Design Kein Baseboard";
+ compatible = "ad,kein-baseboard", "ad,meerkat", "nvidia,tegra124";
+
+ chosen {
+ stdout-path = &uartd;
+ };
+
+ serial@70006300 {
+ status = "okay";
+ };
+
+ sdhci@700b0400 {
+ status = "okay";
+ };
+
+ usb@7d00 {
+ status = "okay";
+ };
+
+ usb@7d004000 {
+ status = "okay";
+ };
+
+ usb@7d008000 {
+ status = "okay";
+ };
+
+ pcie-controller@01003000 {
+ status = "okay";
+
+ pci@1,0 {
+ status = "okay";
+ };
+
+ pci@2,0 {
+ status = "okay";
+ };
+ };
+
+ regulators {
+ vdd_5v0: regulator@100 {
+ compatible = "regulator-fixed";
+ reg = <100>;
+ regulator-name = "+VDD_5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_3v3: regulator@101 {
+ compatible = "regulator-fixed";
+ reg = <101>;
+ regulator-name = "+VDD_3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+};
diff --git a/arch/arm/dts/tegra124-meerkat.dtsi
b/arch/arm/dts/tegra124-meerkat.dtsi
new file mode 100644
index 000..88a7c86
--- /dev/null
+++ b/arch/arm/dts/tegra124-meerkat.dtsi
@@ -0,0 +1,395 @@
+
+#include "tegra124.dtsi"
+
+/ {
+ model = "Avionic-Design Meerkat";
+ compatible = "ad,meerkat", "nvidia,tegra124";
+
+ aliases {
+ i2c0 = "/i2c@7000c000";
+ i2c1 = "/i2c@7000c400";
+ i2c2 = "/i2c@7000c500";
+ i2c3 = "/i2c@7000c700";
+ i2c4 = "/i2c@7000d000";
+ i2c5 = "/i2c@7000d100";
+
+ sdhci0 = "/sdhci@700b0600";
+ sdhci1 = "/sdhci@700b0400";
+
+ usb0 = "/usb@7d00";
+ usb1 = "/usb@7d008000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x8000>;
+ };
+
+ pcie-controller@01003000 {
+ avddio-pex-supply = <&vdd_1v05_run>;
+ dvddio-pex-supply = <&vdd_1v05_run>;
+ avdd-pex-pll-supply = <&vdd_1v05_run>;
+
[U-Boot] [PATCH 0/2] tegra124: Add support for Avionic Design platform
This adds support for the Avionic Design Tegra124 platform. It consists of the Meerkat SOM and a minimal baseboard Kein Baseboard. The as3722 is placed on a different bus as compared to nvidia Jetson, which makes the as3722 required. Alban Bedel (1): power: as3722: Allow using on any i2c bus with any address Julian Scheel (1): Add support the Avionic Design Meerkat COM and Kein Baseboard arch/arm/dts/Makefile | 1 + arch/arm/dts/tegra124-kein-baseboard.dts | 66 arch/arm/dts/tegra124-meerkat.dtsi | 395 + arch/arm/mach-tegra/board2.c | 2 +- arch/arm/mach-tegra/tegra124/Kconfig | 9 + board/avionic-design/common/meerkat.c | 70 .../avionic-design/common/pinmux-config-meerkat.h | 233 board/avionic-design/kein-baseboard/Kconfig| 15 + board/avionic-design/kein-baseboard/MAINTAINERS| 7 + board/avionic-design/kein-baseboard/Makefile | 9 + board/nvidia/jetson-tk1/jetson-tk1.c | 2 +- configs/kein-baseboard_defconfig | 21 ++ drivers/power/as3722.c | 4 +- include/configs/kein-baseboard.h | 76 include/power/as3722.h | 2 +- 15 files changed, 906 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/tegra124-kein-baseboard.dts create mode 100644 arch/arm/dts/tegra124-meerkat.dtsi create mode 100644 board/avionic-design/common/meerkat.c create mode 100644 board/avionic-design/common/pinmux-config-meerkat.h create mode 100644 board/avionic-design/kein-baseboard/Kconfig create mode 100644 board/avionic-design/kein-baseboard/MAINTAINERS create mode 100644 board/avionic-design/kein-baseboard/Makefile create mode 100644 configs/kein-baseboard_defconfig create mode 100644 include/configs/kein-baseboard.h -- 2.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] power: as3722: Allow using on any i2c bus with any address
From: Alban Bedel
The init simply hardcoded the i2c bus and address to those used on
jetson. Extend the init function to take the bus number and device
address as parameter. As only jetson is using this code for now just
fix this single use of the function.
Signed-off-by: Alban Bedel
Reviewed-by: Julian Scheel
---
arch/arm/mach-tegra/board2.c | 2 +-
board/nvidia/jetson-tk1/jetson-tk1.c | 2 +-
drivers/power/as3722.c | 4 +---
include/power/as3722.h | 2 +-
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index ac274e1..55c50df 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -148,7 +148,7 @@ int board_init(void)
# endif
# endif /* CONFIG_TEGRA_PMU */
#ifdef CONFIG_AS3722_POWER
- err = as3722_init(NULL);
+ err = as3722_init(NULL, 0, 0x40);
if (err && err != -ENODEV)
return err;
#endif
diff --git a/board/nvidia/jetson-tk1/jetson-tk1.c
b/board/nvidia/jetson-tk1/jetson-tk1.c
index 14f0ce5..7f16a4a 100644
--- a/board/nvidia/jetson-tk1/jetson-tk1.c
+++ b/board/nvidia/jetson-tk1/jetson-tk1.c
@@ -39,7 +39,7 @@ int tegra_pcie_board_init(void)
struct udevice *pmic;
int err;
- err = as3722_init(&pmic);
+ err = as3722_init(&pmic, 0, 0x40);
if (err) {
error("failed to initialize AS3722 PMIC: %d\n", err);
return err;
diff --git a/drivers/power/as3722.c b/drivers/power/as3722.c
index c09e1de..321d65d 100644
--- a/drivers/power/as3722.c
+++ b/drivers/power/as3722.c
@@ -243,12 +243,10 @@ int as3722_get(struct udevice **devp)
return i2c_get_chip_for_busnum(bus, address, 1, devp);
}
-int as3722_init(struct udevice **devp)
+int as3722_init(struct udevice **devp, unsigned int bus, unsigned int address)
{
struct udevice *pmic;
u8 id, revision;
- const unsigned int bus = 0;
- const unsigned int address = 0x40;
int err;
err = i2c_get_chip_for_busnum(bus, address, 1, &pmic);
diff --git a/include/power/as3722.h b/include/power/as3722.h
index 0f22482..c37b43a 100644
--- a/include/power/as3722.h
+++ b/include/power/as3722.h
@@ -14,7 +14,7 @@
struct udevice;
-int as3722_init(struct udevice **devp);
+int as3722_init(struct udevice **devp, unsigned int bus, unsigned int address);
int as3722_sd_enable(struct udevice *pmic, unsigned int sd);
int as3722_sd_set_voltage(struct udevice *pmic, unsigned int sd, u8 value);
int as3722_ldo_enable(struct udevice *pmic, unsigned int ldo);
--
2.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] zymqmp: Replace home grown mmu code with generic table approach
Hi,
before I comment the rest. You need to also fix gem driver because it is
using 1MB mapping.
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index b3821c31a91d..cf1376ce1bd7 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -150,10 +150,10 @@ struct emac_bd {
};
#define RX_BUF 32
-/* Page table entries are set to 1MB, or multiples of 1MB
- * (not < 1MB). driver uses less bd's so use 1MB bdspace.
+/* Page table entries are set to 2MB, or multiples of 2MB
+ * (not < 2MB). driver uses less bd's so use 2MB bdspace.
*/
-#define BD_SPACE 0x10
+#define BD_SPACE 0x20
/* BD separation space */
#define BD_SEPRN_SPACE (RX_BUF * sizeof(struct emac_bd))
On 23.2.2016 12:33, Alexander Graf wrote:
>
>
> On 23.02.16 12:04, Michal Simek wrote:
>> On 22.2.2016 02:57, Alexander Graf wrote:
>>> Now that we have nice table driven page table creating code that gives
>>> us everything we need, move to that.
>>>
>>> Signed-off-by: Alexander Graf
>>> ---
>>> arch/arm/cpu/armv8/zynqmp/cpu.c | 169
>>>
>>> include/configs/xilinx_zynqmp.h | 44 +++
>>> 2 files changed, 44 insertions(+), 169 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c
>>> b/arch/arm/cpu/armv8/zynqmp/cpu.c
>>> index c71f291..3f661a9 100644
>>> --- a/arch/arm/cpu/armv8/zynqmp/cpu.c
>>> +++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
>>> @@ -44,172 +44,3 @@ unsigned int zynqmp_get_silicon_version(void)
>>>
>>> return ZYNQMP_CSU_VERSION_SILICON;
>>> }
>>> -
>>> -#ifndef CONFIG_SYS_DCACHE_OFF
>>> -#include
>>> -
>>> -#define SECTION_SHIFT_L1 30UL
>>> -#define SECTION_SHIFT_L2 21UL
>>> -#define BLOCK_SIZE_L0 0x80UL
>>> -#define BLOCK_SIZE_L1 (1 << SECTION_SHIFT_L1)
>>> -#define BLOCK_SIZE_L2 (1 << SECTION_SHIFT_L2)
>>> -
>>> -#define TCR_TG1_4K (1 << 31)
>>> -#define TCR_EPD1_DISABLE (1 << 23)
>>> -#define ZYNQMO_VA_BITS 40
>>> -#define ZYNQMP_TCR TCR_TG1_4K | \
>>> - TCR_EPD1_DISABLE | \
>>> - TCR_SHARED_OUTER | \
>>> - TCR_SHARED_INNER | \
>>> - TCR_IRGN_WBWA | \
>>> - TCR_ORGN_WBWA | \
>>> - TCR_T0SZ(ZYNQMO_VA_BITS)
>>> -
>>> -#define MEMORY_ATTRPMD_SECT_AF | PMD_SECT_INNER_SHARE |\
>>> - PMD_ATTRINDX(MT_NORMAL) | \
>>> - PMD_TYPE_SECT
>>> -#define DEVICE_ATTRPMD_SECT_AF | PMD_SECT_PXN |\
>>> - PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_NGNRNE) | \
>>> - PMD_TYPE_SECT
>>> -
>>> -/* 4K size is required to place 512 entries in each level */
>>> -#define TLB_TABLE_SIZE 0x1000
>>> -
>>> -struct attr_tbl {
>>> - u32 num;
>>> - u64 attr;
>>> -};
>>> -
>>> -static struct attr_tbl attr_tbll1t0[4] = { {16, 0x0},
>>> - {8, DEVICE_ATTR},
>>> - {32, MEMORY_ATTR},
>>> - {456, DEVICE_ATTR}
>>> -};
>>> -static struct attr_tbl attr_tbll2t3[4] = { {0x180, DEVICE_ATTR},
>>> - {0x40, 0x0},
>>> - {0x3F, DEVICE_ATTR},
>>> - {0x1, MEMORY_ATTR}
>>> -};
>>> -
>>> -/*
>>> - * This mmu table looks as below
>>> - * Level 0 table contains two entries to 512GB sizes. One is Level1 Table 0
>>> - * and other Level1 Table1.
>>> - * Level1 Table0 contains entries for each 1GB from 0 to 511GB.
>>> - * Level1 Table1 contains entries for each 1GB from 512GB to 1TB.
>>> - * Level2 Table0, Level2 Table1, Level2 Table2 and Level2 Table3 contains
>>> - * entries for each 2MB starting from 0GB, 1GB, 2GB and 3GB respectively.
>>> - */
>>> -static void zynqmp_mmu_setup(void)
>>> -{
>>> - int el;
>>> - u32 index_attr;
>>> - u64 i, section_l1t0, section_l1t1;
>>> - u64 section_l2t0, section_l2t1, section_l2t2, section_l2t3;
>>> - u64 *level0_table = (u64 *)gd->arch.tlb_addr;
>>> - u64 *level1_table_0 = (u64 *)(gd->arch.tlb_addr + TLB_TABLE_SIZE);
>>> - u64 *level1_table_1 = (u64 *)(gd->arch.tlb_addr + (2 * TLB_TABLE_SIZE));
>>> - u64 *level2_table_0 = (u64 *)(gd->arch.tlb_addr + (3 * TLB_TABLE_SIZE));
>>> - u64 *level2_table_1 = (u64 *)(gd->arch.tlb_addr + (4 * TLB_TABLE_SIZE));
>>> - u64 *level2_table_2 = (u64 *)(gd->arch.tlb_addr + (5 * TLB_TABLE_SIZE));
>>> - u64 *level2_table_3 = (u64 *)(gd->arch.tlb_addr + (6 * TLB_TABLE_SIZE));
>>> -
>>> - level0_table[0] =
>>> - (u64)level1_table_0 | PMD_TYPE_TABLE;
>>> - level0_table[1] =
>>> - (u64)level1_table_1 | PMD_TYPE_TABLE;
>>> -
>>> - /*
>>> -* set level 1 table 0, covering 0 to 512GB
>>> -* set level 1 table 1, covering 512GB to 1TB
>>> -*/
>
Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
Hi Fabio, On 23 February 2016 at 00:22, Fabio Estevam wrote: > On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki wrote: > >> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor > > Does not even build for me (mx6qsabresd_defconfig) : Please try again, I think I missed some changes. mean while I ran buildman again will update that one as well. -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered PCI devices
Hi Stuart,
> -Original Message-
> From: Stuart Yoder [mailto:stuart.yo...@nxp.com]
> Sent: Monday, February 22, 2016 11:26 PM
> To: u-boot@lists.denx.de
> Cc: york sun ; Prabhakar Kushwaha
> ; Mingkai Hu ;
> Minghuan Lian ; Yang-Leo Li ;
> marc.zyng...@arm.com; Stuart Yoder
> Subject: [PATCH 7/7] pci/layerscape: set LUT and msi-map for discovered PCI
> devices
>
> From: Stuart Yoder
>
> for all PCI devices discovered in a system:
> -allocate a LUT (look-up-table) entry in that PCI controller
> -allocate a stream ID for the device
> -program and enable a LUT entry (maps PCI requester id to stream ID)
> -set the msi-map property on the controller reflecting the
>LUT mapping
>
> basic bus scanning loop/logic was taken from drivers/pci/pci.c
> pci_hose_scan_bus().
>
> Signed-off-by: Stuart Yoder
> ---
> drivers/pci/pcie_layerscape.c | 68
> +
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index
> dfafaf2..eaac9e1 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -569,6 +569,70 @@ static void fdt_pcie_set_msi_map_entry(void *blob,
> struct ls_pcie *pcie,
> fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1); }
>
> +static void fdt_fixup_pcie(void *blob)
> +{
> + unsigned int found_multi = 0;
> + unsigned char header_type;
> + int index;
> + u32 streamid;
> + pci_dev_t dev;
> + int bus;
> + unsigned short id;
> + struct pci_controller *hose;
> + struct ls_pcie *pcie;
> + int i;
> +
> + for (i = 0, hose = pci_get_hose_head(); hose; hose = hose->next, i++) {
> + pcie = hose->priv_data;
> + for (bus = hose->first_busno; bus <= hose->last_busno; bus++) {
> +
> + for (dev = PCI_BDF(bus, 0, 0);
> + dev < PCI_BDF(bus, PCI_MAX_PCI_DEVICES - 1,
> + PCI_MAX_PCI_FUNCTIONS - 1);
> + dev += PCI_BDF(0, 0, 1)) {
> +
> + /* skip the host bridge */
> + if (dev == PCI_BDF(0, 0, 0))
> + continue;
[Lian Minghuan-B31939] PCIe controller also needs a stream ID. It may request a
MSI for AER PME hotplug service.
> +
> + if (PCI_FUNC(dev) && !found_multi)
> + continue;
> +
> + pci_read_config_word(dev, PCI_VENDOR_ID, &id);
> +
> + pci_read_config_byte(dev, PCI_HEADER_TYPE,
> + &header_type);
> +
> + if ((id == 0x) || (id == 0x))
> + continue;
> +
> + if (!PCI_FUNC(dev))
> + found_multi = header_type & 0x80;
> +
> + streamid = ls_pcie_next_streamid();
> + if (streamid < 0) {
> + printf("ERROR: no stream ids free\n");
> + continue;
> + }
> +
> + index = ls_pcie_next_lut_index(pcie);
> + if (index < 0) {
> + printf("ERROR: no LUT indexes free\n");
> + continue;
> + }
> +
> + /* map PCI b.d.f to streamID in LUT */
> + ls_pcie_lut_set_mapping(pcie, index, dev >> 8,
> + streamid);
> +
> + /* update msi-map in device tree */
> + fdt_pcie_set_msi_map_entry(blob, pcie, dev >> 8,
> +streamid);
> + }
> + }
> + }
> +}
> +
> int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info
> *info)
> {
> struct ls_pcie *pcie;
> @@ -745,6 +809,10 @@ void ft_pci_setup(void *blob, bd_t *bd)
> #ifdef CONFIG_PCIE4
> ft_pcie_ls_setup(blob, FSL_PCIE_COMPAT, CONFIG_SYS_PCIE4_ADDR,
> PCIE4);
> #endif
> +
> + #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> + fdt_fixup_pcie(blob);
> + #endif
> }
>
> #else
> --
> 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 v2 00/25] exynos: video: Convert exynos LCD driver to use driver model
Dear Simon Glass, On 23/02/16 15:42, Simon Glass wrote: > Hi Minkyu, > > On 21 February 2016 at 21:08, Simon Glass wrote: >> >> This series converts the exynos LCD driver to work with driver model. Only >> the eDP display is converted - the MIPI display is left mostly alone as I >> do not have a device to test with. >> >> The conversion involves some refactoring to simplify the code, reduce the >> amount of global/static data and allow boards to be built without LCD >> support. >> >> The series is tested with snow, spring, pit and pi. It disables LCD on other >> exynos boards so that they will still build with these changes. Further work >> will be needed (by someone with a board) to convert the others. I am not >> sure when this series can be applied. >> >> The series also brings in device tree features from Linux v4.4. It would be >> useful to do a full sync with the kernel on these files, but this is really >> a job for the Samsung maintainer :-) >> >> The series is available at u-boot-dm/rkg-working. >> >> Changes in v2: >> - Rebase to master >> - Rebase to master >> > > What do you think we should do about applying this series? > Although we have to do remaining work, I think applying is possible without next work. Board maintainers, what do you think? Remaining Work: - MIPI display driver - s5pc210_universal - smdk5420 - smdk5250 - trats - trats2 Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
Le 22/02/2016 08:03, Schrempf Frieder a écrit : > On 18.02.2016 18:14, Fabio Estevam wrote: >> On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut wrote: >> Also one of our customers tested a few non-working sticks with this change and reported, that it fixed it for him. Here's a list of those devices, but I guess there are a lot more: 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive, VID: 0x090c, PID: 0x1000 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 3. Newron, VID: 0x8644, PID: 0x800e 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 >>> Maybe we need a quirk table then ? >> It seems the list of affected devices is unknown. >> >> What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767? >> >> Would this impact the USB transfer rate? Frieder, do you know? > I don't really know. While testing I had the feeling, that the transfer > is slightly slower, but I can't tell for sure. > Hello, I was hit by the same problem, where my USB SD card reader would timeout in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK to 32767 fixed the problem but I investigated a little more. I was curious to see what the Linux kernel used, because it had no problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to max_sector in the scsiglue, which is set to 240 blocks per transfer by default, and is tunable via sysfs. There is also a list of unusual devices which needs no higher than 64 blocks per transfer. The linux USB FAQ has a very interesting entry about this which explains the rationale for this value: http://www.linux-usb.org/FAQ.html#i5 FWIW: my USB card reader is 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) I've benchmarked in U-boot the time impact of this change. For reading my 16764395 bytes file: USB_MAX_XFER_BLKRead duration (as reported by U-boot): 64 3578 ms 128 2221 ms 240 1673 ms 32767 1020 ms 65535 974 ms So there is definitely a strong impact for lower values. -- Maxime Jayat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] zymqmp: Replace home grown mmu code with generic table approach
On 23.02.16 12:04, Michal Simek wrote:
> On 22.2.2016 02:57, Alexander Graf wrote:
>> Now that we have nice table driven page table creating code that gives
>> us everything we need, move to that.
>>
>> Signed-off-by: Alexander Graf
>> ---
>> arch/arm/cpu/armv8/zynqmp/cpu.c | 169
>>
>> include/configs/xilinx_zynqmp.h | 44 +++
>> 2 files changed, 44 insertions(+), 169 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c
>> b/arch/arm/cpu/armv8/zynqmp/cpu.c
>> index c71f291..3f661a9 100644
>> --- a/arch/arm/cpu/armv8/zynqmp/cpu.c
>> +++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
>> @@ -44,172 +44,3 @@ unsigned int zynqmp_get_silicon_version(void)
>>
>> return ZYNQMP_CSU_VERSION_SILICON;
>> }
>> -
>> -#ifndef CONFIG_SYS_DCACHE_OFF
>> -#include
>> -
>> -#define SECTION_SHIFT_L130UL
>> -#define SECTION_SHIFT_L221UL
>> -#define BLOCK_SIZE_L0 0x80UL
>> -#define BLOCK_SIZE_L1 (1 << SECTION_SHIFT_L1)
>> -#define BLOCK_SIZE_L2 (1 << SECTION_SHIFT_L2)
>> -
>> -#define TCR_TG1_4K (1 << 31)
>> -#define TCR_EPD1_DISABLE(1 << 23)
>> -#define ZYNQMO_VA_BITS 40
>> -#define ZYNQMP_TCR TCR_TG1_4K | \
>> -TCR_EPD1_DISABLE | \
>> -TCR_SHARED_OUTER | \
>> -TCR_SHARED_INNER | \
>> -TCR_IRGN_WBWA | \
>> -TCR_ORGN_WBWA | \
>> -TCR_T0SZ(ZYNQMO_VA_BITS)
>> -
>> -#define MEMORY_ATTR PMD_SECT_AF | PMD_SECT_INNER_SHARE |\
>> -PMD_ATTRINDX(MT_NORMAL) | \
>> -PMD_TYPE_SECT
>> -#define DEVICE_ATTR PMD_SECT_AF | PMD_SECT_PXN |\
>> -PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_NGNRNE) | \
>> -PMD_TYPE_SECT
>> -
>> -/* 4K size is required to place 512 entries in each level */
>> -#define TLB_TABLE_SIZE 0x1000
>> -
>> -struct attr_tbl {
>> -u32 num;
>> -u64 attr;
>> -};
>> -
>> -static struct attr_tbl attr_tbll1t0[4] = { {16, 0x0},
>> - {8, DEVICE_ATTR},
>> - {32, MEMORY_ATTR},
>> - {456, DEVICE_ATTR}
>> - };
>> -static struct attr_tbl attr_tbll2t3[4] = { {0x180, DEVICE_ATTR},
>> - {0x40, 0x0},
>> - {0x3F, DEVICE_ATTR},
>> - {0x1, MEMORY_ATTR}
>> - };
>> -
>> -/*
>> - * This mmu table looks as below
>> - * Level 0 table contains two entries to 512GB sizes. One is Level1 Table 0
>> - * and other Level1 Table1.
>> - * Level1 Table0 contains entries for each 1GB from 0 to 511GB.
>> - * Level1 Table1 contains entries for each 1GB from 512GB to 1TB.
>> - * Level2 Table0, Level2 Table1, Level2 Table2 and Level2 Table3 contains
>> - * entries for each 2MB starting from 0GB, 1GB, 2GB and 3GB respectively.
>> - */
>> -static void zynqmp_mmu_setup(void)
>> -{
>> -int el;
>> -u32 index_attr;
>> -u64 i, section_l1t0, section_l1t1;
>> -u64 section_l2t0, section_l2t1, section_l2t2, section_l2t3;
>> -u64 *level0_table = (u64 *)gd->arch.tlb_addr;
>> -u64 *level1_table_0 = (u64 *)(gd->arch.tlb_addr + TLB_TABLE_SIZE);
>> -u64 *level1_table_1 = (u64 *)(gd->arch.tlb_addr + (2 * TLB_TABLE_SIZE));
>> -u64 *level2_table_0 = (u64 *)(gd->arch.tlb_addr + (3 * TLB_TABLE_SIZE));
>> -u64 *level2_table_1 = (u64 *)(gd->arch.tlb_addr + (4 * TLB_TABLE_SIZE));
>> -u64 *level2_table_2 = (u64 *)(gd->arch.tlb_addr + (5 * TLB_TABLE_SIZE));
>> -u64 *level2_table_3 = (u64 *)(gd->arch.tlb_addr + (6 * TLB_TABLE_SIZE));
>> -
>> -level0_table[0] =
>> -(u64)level1_table_0 | PMD_TYPE_TABLE;
>> -level0_table[1] =
>> -(u64)level1_table_1 | PMD_TYPE_TABLE;
>> -
>> -/*
>> - * set level 1 table 0, covering 0 to 512GB
>> - * set level 1 table 1, covering 512GB to 1TB
>> - */
>> -section_l1t0 = 0;
>> -section_l1t1 = BLOCK_SIZE_L0;
>> -
>> -index_attr = 0;
>> -for (i = 0; i < 512; i++) {
>> -level1_table_0[i] = section_l1t0;
>> -level1_table_0[i] |= attr_tbll1t0[index_attr].attr;
>> -attr_tbll1t0[index_attr].num--;
>> -if (attr_tbll1t0[index_attr].num == 0)
>> -index_attr++;
>> -level1_table_1[i] = section_l1t1;
>> -level1_table_1[i] |= DEVICE_ATTR;
>> -section_l1t0 += BLOCK_SIZE_L1;
>> -section_l1t1 += BLOCK_SIZE_L1;
>> -}
>> -
>> -level1_table_0[0] =
>> -(u64)level2_table_0 | PMD_TYPE_TABLE;
>> -level1_table_0[1] =
>> -(u64)level2_table_1 | PMD_TYPE_TABLE;
>> -level1_table_0[2] =
>> -(u64)level2_table_2 | P
Re: [U-Boot] [PATCH 3/9] zymqmp: Replace home grown mmu code with generic table approach
On 22.2.2016 02:57, Alexander Graf wrote:
> Now that we have nice table driven page table creating code that gives
> us everything we need, move to that.
>
> Signed-off-by: Alexander Graf
> ---
> arch/arm/cpu/armv8/zynqmp/cpu.c | 169
>
> include/configs/xilinx_zynqmp.h | 44 +++
> 2 files changed, 44 insertions(+), 169 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
> index c71f291..3f661a9 100644
> --- a/arch/arm/cpu/armv8/zynqmp/cpu.c
> +++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
> @@ -44,172 +44,3 @@ unsigned int zynqmp_get_silicon_version(void)
>
> return ZYNQMP_CSU_VERSION_SILICON;
> }
> -
> -#ifndef CONFIG_SYS_DCACHE_OFF
> -#include
> -
> -#define SECTION_SHIFT_L1 30UL
> -#define SECTION_SHIFT_L2 21UL
> -#define BLOCK_SIZE_L00x80UL
> -#define BLOCK_SIZE_L1(1 << SECTION_SHIFT_L1)
> -#define BLOCK_SIZE_L2(1 << SECTION_SHIFT_L2)
> -
> -#define TCR_TG1_4K (1 << 31)
> -#define TCR_EPD1_DISABLE (1 << 23)
> -#define ZYNQMO_VA_BITS 40
> -#define ZYNQMP_TCR TCR_TG1_4K | \
> - TCR_EPD1_DISABLE | \
> - TCR_SHARED_OUTER | \
> - TCR_SHARED_INNER | \
> - TCR_IRGN_WBWA | \
> - TCR_ORGN_WBWA | \
> - TCR_T0SZ(ZYNQMO_VA_BITS)
> -
> -#define MEMORY_ATTR PMD_SECT_AF | PMD_SECT_INNER_SHARE |\
> - PMD_ATTRINDX(MT_NORMAL) | \
> - PMD_TYPE_SECT
> -#define DEVICE_ATTR PMD_SECT_AF | PMD_SECT_PXN |\
> - PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_NGNRNE) | \
> - PMD_TYPE_SECT
> -
> -/* 4K size is required to place 512 entries in each level */
> -#define TLB_TABLE_SIZE 0x1000
> -
> -struct attr_tbl {
> - u32 num;
> - u64 attr;
> -};
> -
> -static struct attr_tbl attr_tbll1t0[4] = { {16, 0x0},
> -{8, DEVICE_ATTR},
> -{32, MEMORY_ATTR},
> -{456, DEVICE_ATTR}
> - };
> -static struct attr_tbl attr_tbll2t3[4] = { {0x180, DEVICE_ATTR},
> -{0x40, 0x0},
> -{0x3F, DEVICE_ATTR},
> -{0x1, MEMORY_ATTR}
> - };
> -
> -/*
> - * This mmu table looks as below
> - * Level 0 table contains two entries to 512GB sizes. One is Level1 Table 0
> - * and other Level1 Table1.
> - * Level1 Table0 contains entries for each 1GB from 0 to 511GB.
> - * Level1 Table1 contains entries for each 1GB from 512GB to 1TB.
> - * Level2 Table0, Level2 Table1, Level2 Table2 and Level2 Table3 contains
> - * entries for each 2MB starting from 0GB, 1GB, 2GB and 3GB respectively.
> - */
> -static void zynqmp_mmu_setup(void)
> -{
> - int el;
> - u32 index_attr;
> - u64 i, section_l1t0, section_l1t1;
> - u64 section_l2t0, section_l2t1, section_l2t2, section_l2t3;
> - u64 *level0_table = (u64 *)gd->arch.tlb_addr;
> - u64 *level1_table_0 = (u64 *)(gd->arch.tlb_addr + TLB_TABLE_SIZE);
> - u64 *level1_table_1 = (u64 *)(gd->arch.tlb_addr + (2 * TLB_TABLE_SIZE));
> - u64 *level2_table_0 = (u64 *)(gd->arch.tlb_addr + (3 * TLB_TABLE_SIZE));
> - u64 *level2_table_1 = (u64 *)(gd->arch.tlb_addr + (4 * TLB_TABLE_SIZE));
> - u64 *level2_table_2 = (u64 *)(gd->arch.tlb_addr + (5 * TLB_TABLE_SIZE));
> - u64 *level2_table_3 = (u64 *)(gd->arch.tlb_addr + (6 * TLB_TABLE_SIZE));
> -
> - level0_table[0] =
> - (u64)level1_table_0 | PMD_TYPE_TABLE;
> - level0_table[1] =
> - (u64)level1_table_1 | PMD_TYPE_TABLE;
> -
> - /*
> - * set level 1 table 0, covering 0 to 512GB
> - * set level 1 table 1, covering 512GB to 1TB
> - */
> - section_l1t0 = 0;
> - section_l1t1 = BLOCK_SIZE_L0;
> -
> - index_attr = 0;
> - for (i = 0; i < 512; i++) {
> - level1_table_0[i] = section_l1t0;
> - level1_table_0[i] |= attr_tbll1t0[index_attr].attr;
> - attr_tbll1t0[index_attr].num--;
> - if (attr_tbll1t0[index_attr].num == 0)
> - index_attr++;
> - level1_table_1[i] = section_l1t1;
> - level1_table_1[i] |= DEVICE_ATTR;
> - section_l1t0 += BLOCK_SIZE_L1;
> - section_l1t1 += BLOCK_SIZE_L1;
> - }
> -
> - level1_table_0[0] =
> - (u64)level2_table_0 | PMD_TYPE_TABLE;
> - level1_table_0[1] =
> - (u64)level2_table_1 | PMD_TYPE_TABLE;
> - level1_table_0[2] =
> - (u64)level2_table_2 | PMD_TYPE_TABLE;
> - level1_table_0[3] =
> - (u64)level2_table_3 | PMD_TYPE_TA
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this series. thanks! Jagan. The following changes since commit 595af9db2422fa5ae734cfe615415b17a5098f34: Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-02-21 07:56:16 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 674f3609aad39f099a5c3605643a6be124504b96: spi: spi-uclass: Set slave wordlen with SPI_DEFAULT_WORDLEN (2016-02-23 16:14:46 +0530) Christophe Ricard (2): spi: omap3: Remove unused variable irqstatus in omap3_spi_txrx spi: spi-uclass: Set slave wordlen with SPI_DEFAULT_WORDLEN Michal Simek (1): ARM: zynq: Wire-up saving environment to QSPI Mugunthan V N (6): dm: implement a DMA uclass dma: Kconfig: Add TI_EDMA3 entry sf: spi_flash: use dma to copy data from mmap region if platform supports spi: ti_qspi: compile out spi_flash_copy_mmap when CONFIG_DMA is defined drivers: dma: ti-edma3: convert driver to adopt driver model defconfig: am437x_sk_evm: enable dma driver model configs/am437x_sk_evm_defconfig | 1 + drivers/dma/Kconfig | 22 +++ drivers/dma/Makefile| 2 + drivers/dma/dma-uclass.c| 72 ++ drivers/dma/ti-edma3.c | 82 ++- drivers/mtd/spi/spi_flash.c | 9 + drivers/spi/omap3_spi.c | 2 - drivers/spi/spi-uclass.c| 1 + drivers/spi/ti_qspi.c | 2 +- include/configs/zynq-common.h | 4 ++ include/dm/uclass-id.h | 1 + include/dma.h | 86 + 12 files changed, 279 insertions(+), 5 deletions(-) create mode 100644 drivers/dma/dma-uclass.c create mode 100644 include/dma.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] tegra: Replace home grown mmu code with generic table approach
On 22.2.2016 19:28, Stephen Warren wrote:
> On 02/21/2016 06:57 PM, Alexander Graf wrote:
>> Now that we have nice table driven page table creating code that gives
>> us everything we need, move to that.
>
>> diff --git a/include/configs/tegra210-common.h
>> b/include/configs/tegra210-common.h
>
>> +#define CONFIG_SYS_FULL_VA
>> +#define CONFIG_SYS_MEM_MAP {\
>> +{\
>> +.base = 0x0UL,\
>> +.size = 0x8000UL,\
>> +.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |\
>> + PTE_BLOCK_NON_SHARE |\
>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN\
>> +}, {\
>> +.base = 0x8000UL,\
>> +.size = 0xff8000UL,\
>> +.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |\
>> + PTE_BLOCK_INNER_SHARE\
>> +},\
>> +}
>
> I'd prefer a layout that didn't align the closing } for different
> nesting levels in the same column. To avoid indenting everything a lot,
> it seems simplest to pull the final } back into the first column.
>
> I believe the .size field of the second entry in the array only needs to
> be 0x8000. Testing with a PCIe Ethernet card on p2371-2180 (the
> driver for which sets up noncached entries in the page tables, hence
> should exercise all this code) confirms that.
>
> While recent Tegra systems do support more than 2GB of RAM, U-Boot will
> itself only use the first 2GB, so that PAs over 4GB are not used. See
> board_get_usable_ram_top() in arch/arm/mach-tegra/board2.c. That's
> because some peripherals can only access 32-bit PAs, and the simplest
> way to accommodate that is to ignore any RAM above the 32-bit limit.
Didn't you use mtest to test memory above of 2GB?
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] test/py: Add option to skip SPL signature checking
Provide user option to skip SPL signature verification for cases where
u-boot is build with SPL support but full U-Boot is also verified
without SPL.
If you want to support this feature please add env__spl_skipped = True
to your boardenv configuration file.
For example Xilinx Zynq is using this feature where the same U-Boot
binary is checked with SPL and without SPL(with FSBL).
Signed-off-by: Michal Simek
Tested-by: Stephen Warren
Acked-by: Stephen Warren
---
Changes in v2:
- nits in commit message
- Rename to env_spl_skipped from env__spl_skipped
test/py/u_boot_console_base.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index d6502c6e64cb..b48d07261ff2 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -307,7 +307,9 @@ class ConsoleBase(object):
config_spl = bcfg.get('config_spl', 'n') == 'y'
config_spl_serial_support = bcfg.get('config_spl_serial_support',
'n') == 'y'
-if config_spl and config_spl_serial_support:
+config_spl_skip = self.config.env.get('env_spl_skipped',
+ False)
+if config_spl and config_spl_serial_support and not
config_spl_skip:
m = self.p.expect([pattern_u_boot_spl_signon] +
self.bad_patterns)
if m != 0:
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: Add option to skip SPL signature checking
On 22.2.2016 18:29, Stephen Warren wrote:
> On 02/22/2016 05:52 AM, Michal Simek wrote:
>> Provide user option to skip SPL signature verification for cases where
>> u-boot is build with SPL support but full U-Boot is also verified
>> without SPL.
>> If you want to support this feature please add env__spl_skipped = True
>> to your boardenv configuration file.
>
> Nit: Blank line between those paragraphs?
fixed
>
>>
>> For example Xilinx Zynq is using this feature where the same u-boot
>> binary is checked with SPL and without SPL(with FSBL).
>
> Nit: U-Boot not u-boot?
fixed.
>
>> diff --git a/test/py/u_boot_console_base.py
>> b/test/py/u_boot_console_base.py
>
>> config_spl = bcfg.get('config_spl', 'n') == 'y'
>> config_spl_serial_support =
>> bcfg.get('config_spl_serial_support',
>>'n') == 'y'
>> -if config_spl and config_spl_serial_support:
>> +config_spl_skip = self.config.env.get('env__spl_skipped',
>> + False)
>
> That's not a config file (.config or autoconf.mk), but a boardenv value.
> I'd suggest renaming it boardenv_spl_skipped or env_spl_skipped.
env_spl_skipped is used now.
Currently env__net_dhcp_server names are used. It is also board specific.
Maybe make sense to just rename all these to boardenv_XXX.
> Tested-by: Stephen Warren
>
> Once renamed,
> Acked-by: Stephen Warren
I have added to v2 but feel free to reply if I should do any change.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] board: ls1043ardb: move sec_init to board_init
sec_init() which was earlier called in misc_init_r()
is now done in board_init() before PPA init as SEC
block will be used during PPA image validation.
Signed-off-by: Aneesh Bansal
---
The patchset is dependent on
http://patchwork.ozlabs.org/patch/571339/
board/freescale/ls1043ardb/ls1043ardb.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/board/freescale/ls1043ardb/ls1043ardb.c
b/board/freescale/ls1043ardb/ls1043ardb.c
index eff09aa..aa2c962 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -117,6 +117,23 @@ int board_init(void)
enable_layerscape_ns_access();
#endif
+#ifdef CONFIG_SECURE_BOOT
+ /* In case of Secure Boot, the IBR configures the SMMU
+* to allow only Secure transactions.
+* SMMU must be reset in bypass mode.
+* Set the ClientPD bit and Clear the USFCFG Bit
+*/
+ u32 val;
+ val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+ out_le32(SMMU_SCR0, val);
+ val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+ out_le32(SMMU_NSCR0, val);
+#endif
+
+#ifdef CONFIG_FSL_CAAM
+ sec_init();
+#endif
+
#ifdef CONFIG_FSL_LS_PPA
ppa_init_pre(&ppa_entry);
@@ -136,21 +153,6 @@ int config_board_mux(void)
int misc_init_r(void)
{
config_board_mux();
-#ifdef CONFIG_SECURE_BOOT
- /* In case of Secure Boot, the IBR configures the SMMU
-* to allow only Secure transactions.
-* SMMU must be reset in bypass mode.
-* Set the ClientPD bit and Clear the USFCFG Bit
-*/
- u32 val;
- val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
- out_le32(SMMU_SCR0, val);
- val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
- out_le32(SMMU_NSCR0, val);
-#endif
-#ifdef CONFIG_FSL_CAAM
- return sec_init();
-#endif
return 0;
}
#endif
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ls1043ardb: PPA: add PPA validation in case of secure boot
As part of Secure Boot Chain of trust, PPA image must be validated
before the image is started.
The code for the same has been added.
Signed-off-by: Aneesh Bansal
---
The patchset is dependent on
http://patchwork.ozlabs.org/patch/571339/
arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 22 ++
arch/arm/include/asm/fsl_secure_boot.h | 16
2 files changed, 38 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
index db767f9..804c4d7 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
@@ -18,6 +18,9 @@
#include
#endif
#include
+#ifdef CONFIG_CHAIN_OF_TRUST
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -69,12 +72,31 @@ static int parse_ppa_firmware_fit_image(const void
**raw_image_addr,
int conf_node_off, fw_node_off;
char *conf_node_name = NULL;
+#ifdef CONFIG_CHAIN_OF_TRUST
+ int ret;
+ uintptr_t ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR;
+ uintptr_t ppa_img_addr = 0;
+#endif
+
#ifdef CONFIG_SYS_LS_PPA_FW_IN_NOR
fit_hdr = (void *)CONFIG_SYS_LS_PPA_FW_ADDR;
#else
#error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
#endif
+#ifdef CONFIG_CHAIN_OF_TRUST
+ ppa_img_addr = (uintptr_t)fit_hdr;
+ if (fsl_check_boot_mode_secure() != 0) {
+ ret = fsl_secboot_validate(ppa_esbc_hdr,
+ CONFIG_PPA_KEY_HASH,
+ &ppa_img_addr);
+ if (ret != 0)
+ printf("PPA validation failed\n");
+ else
+ printf("PPA validation Successful\n");
+ }
+#endif
+
conf_node_name = LS_PPA_FIT_CNF_NAME;
if (fdt_check_header(fit_hdr)) {
diff --git a/arch/arm/include/asm/fsl_secure_boot.h
b/arch/arm/include/asm/fsl_secure_boot.h
index 0da0599..d275dd1 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -56,6 +56,22 @@
/* The address needs to be modified according to NOR memory map */
#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x600a
+#ifdef CONFIG_SYS_LS_PPA_FW_IN_NOR
+#ifdef CONFIG_LS1043A
+#define CONFIG_SYS_LS_PPA_ESBC_ADDR0x600c
+#endif
+#else
+#error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
+#endif
+
+/* Define the key hash here if SRK used for signing PPA image is
+ * different from SRK hash put in SFP used for U-Boot.
+ * Example
+ * #define CONFIG_PPA_KEY_HASH \
+ * "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
+ */
+#define CONFIG_PPA_KEY_HASHNULL
+
#include
#endif /* #ifdef CONFIG_CHAIN_OF_TRUST */
#endif
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] ARM: zynq: zynqmp: Enable DCC serial driver by default
Compile DCC serial driver by default.
Signed-off-by: Michal Simek
---
Changes in v2: None
include/configs/xilinx_zynqmp.h | 9 +++--
include/configs/zynq-common.h | 8 ++--
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 28622dec1882..8a9ad03cb102 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -53,12 +53,9 @@
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 0x200)
/* Serial setup */
-#if defined(CONFIG_ZYNQMP_DCC)
-# define CONFIG_ARM_DCC
-# define CONFIG_CPU_ARMV8
-#else
-# define CONFIG_ZYNQ_SERIAL
-#endif
+#define CONFIG_ARM_DCC
+#define CONFIG_CPU_ARMV8
+#define CONFIG_ZYNQ_SERIAL
#define CONFIG_CONS_INDEX 0
#define CONFIG_BAUDRATE115200
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index e8c3ef0c3872..ec4884878165 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -36,12 +36,8 @@
#define CONFIG_SYS_BAUDRATE_TABLE \
{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
-/* DCC driver */
-#if defined(CONFIG_ZYNQ_DCC)
-# define CONFIG_ARM_DCC
-#else
-# define CONFIG_ZYNQ_SERIAL
-#endif
+#define CONFIG_ARM_DCC
+#define CONFIG_ZYNQ_SERIAL
#define CONFIG_ZYNQ_GPIO
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] serial: dcc: Move driver to DM
Enabling this driver requires some DT changes.
Adding DCC to root or main bus:
dcc: dcc {
compatible = "arm,dcc";
u-boot,dm-pre-reloc;
};
Extend alias list to link DCC:
serial0 = &uart0;
serial1 = &uart1;
serial2 = &dcc;
Change stdout-path to point to dcc port.
stdout-path = "serial2:115200n8";
Also add support for debug uart to help with early debug.
Signed-off-by: Michal Simek
---
Changes in v2:
- Extend Kconfig entry description
drivers/serial/Kconfig | 11 +
drivers/serial/arm_dcc.c | 63 +---
2 files changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index fac317610e2a..92d4212123d2 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -119,6 +119,17 @@ config DEBUG_UART_UARTLITE
You will need to provide parameters to make this work. The driver will
be available until the real driver-model serial is running.
+config DEBUG_UART_ARM_DCC
+ bool "ARM DCC"
+ help
+ Select this to enable a debug UART using the ARM JTAG DCC port.
+ The DCC port can be used for very early debugging and doesn't require
+ any additional setting like address/baudrate/clock. On systems without
+ any serial interface this is the easiest way how to get console.
+ Every ARM core has own DCC port which is the part of debug interface.
+ This port is available at least on ARMv6, ARMv7, ARMv8 and XScale
+ architectures.
+
config DEBUG_UART_ZYNQ
bool "Xilinx Zynq"
help
diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c
index 4624666e8a2c..07981e18ee49 100644
--- a/drivers/serial/arm_dcc.c
+++ b/drivers/serial/arm_dcc.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2004-2007 ARM Limited.
* Copyright (C) 2008 Jean-Christophe PLAGNIOL-VILLARD
+ * Copyright (C) 2015 - 2016 Xilinx, Inc, Michal Simek
*
* SPDX-License-Identifier:GPL-2.0
*
@@ -16,6 +17,7 @@
*/
#include
+#include
#include
#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V7)
@@ -94,12 +96,7 @@
#define TIMEOUT_COUNT 0x400
-static int arm_dcc_init(void)
-{
- return 0;
-}
-
-static int arm_dcc_getc(void)
+static int arm_dcc_getc(struct udevice *dev)
{
int ch;
register unsigned int reg;
@@ -112,7 +109,7 @@ static int arm_dcc_getc(void)
return ch;
}
-static void arm_dcc_putc(char ch)
+static int arm_dcc_putc(struct udevice *dev, char ch)
{
register unsigned int reg;
unsigned int timeout_count = TIMEOUT_COUNT;
@@ -123,41 +120,57 @@ static void arm_dcc_putc(char ch)
break;
}
if (timeout_count == 0)
- return;
+ return -EAGAIN;
else
write_dcc(ch);
+
+ return 0;
}
-static int arm_dcc_tstc(void)
+static int arm_dcc_pending(struct udevice *dev, bool input)
{
register unsigned int reg;
- can_read_dcc(reg);
+ if (input) {
+ can_read_dcc(reg);
+ } else {
+ can_write_dcc(reg);
+ }
return reg;
}
-static void arm_dcc_setbrg(void)
-{
-}
+static const struct dm_serial_ops arm_dcc_ops = {
+ .putc = arm_dcc_putc,
+ .pending = arm_dcc_pending,
+ .getc = arm_dcc_getc,
+};
+
+static const struct udevice_id arm_dcc_ids[] = {
+ { .compatible = "arm,dcc", },
+ { }
+};
-static struct serial_device arm_dcc_drv = {
+U_BOOT_DRIVER(serial_dcc) = {
.name = "arm_dcc",
- .start = arm_dcc_init,
- .stop = NULL,
- .setbrg = arm_dcc_setbrg,
- .putc = arm_dcc_putc,
- .puts = default_serial_puts,
- .getc = arm_dcc_getc,
- .tstc = arm_dcc_tstc,
+ .id = UCLASS_SERIAL,
+ .of_match = arm_dcc_ids,
+ .ops= &arm_dcc_ops,
+ .flags = DM_FLAG_PRE_RELOC,
};
-void arm_dcc_initialize(void)
+#ifdef CONFIG_DEBUG_UART_ARM_DCC
+
+#include
+
+static inline void _debug_uart_init(void)
{
- serial_register(&arm_dcc_drv);
}
-__weak struct serial_device *default_serial_console(void)
+static inline void _debug_uart_putc(int ch)
{
- return &arm_dcc_drv;
+ arm_dcc_putc(NULL, ch);
}
+
+DEBUG_UART_FUNCS
+#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] serial: dcc: Move driver to DM
On 23.2.2016 07:38, Simon Glass wrote:
> Hi Michal,
>
> On 22 February 2016 at 08:54, Michal Simek wrote:
>> On 19.2.2016 21:55, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On 18 February 2016 at 09:01, Michal Simek wrote:
Enabling this driver requires some DT changes.
Adding DCC to root or main bus:
dcc: dcc {
compatible = "arm,dcc";
u-boot,dm-pre-reloc;
};
Extend alias list to link DCC:
serial0 = &uart0;
serial1 = &uart1;
serial2 = &dcc;
Change stdout-path to point to dcc port.
stdout-path = "serial2:115200n8";
Also add support for debug uart to help with early debug.
Signed-off-by: Michal Simek
---
drivers/serial/Kconfig | 5
drivers/serial/arm_dcc.c | 63
+---
2 files changed, 43 insertions(+), 25 deletions(-)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index fac317610e2a..7c18a6218b1f 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -119,6 +119,11 @@ config DEBUG_UART_UARTLITE
You will need to provide parameters to make this work. The
driver will
be available until the real driver-model serial is running.
+config DEBUG_UART_ARM_DCC
+ bool "ARM DCC"
+ help
+ Select this to enable a debug UART using the ARM DCC port.
>>>
>>> Can you please expand this - what is DCC? What parts support it? What is it
>>> for?
>>
>> Sure will do.
>>
>>>
+
config DEBUG_UART_ZYNQ
bool "Xilinx Zynq"
help
diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c
index 4624666e8a2c..07981e18ee49 100644
--- a/drivers/serial/arm_dcc.c
+++ b/drivers/serial/arm_dcc.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2004-2007 ARM Limited.
* Copyright (C) 2008 Jean-Christophe PLAGNIOL-VILLARD
+ * Copyright (C) 2015 - 2016 Xilinx, Inc, Michal Simek
*
* SPDX-License-Identifier:GPL-2.0
*
@@ -16,6 +17,7 @@
*/
#include
+#include
#include
#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V7)
@@ -94,12 +96,7 @@
#define TIMEOUT_COUNT 0x400
-static int arm_dcc_init(void)
-{
- return 0;
-}
-
-static int arm_dcc_getc(void)
+static int arm_dcc_getc(struct udevice *dev)
{
int ch;
register unsigned int reg;
@@ -112,7 +109,7 @@ static int arm_dcc_getc(void)
return ch;
}
-static void arm_dcc_putc(char ch)
+static int arm_dcc_putc(struct udevice *dev, char ch)
{
register unsigned int reg;
unsigned int timeout_count = TIMEOUT_COUNT;
@@ -123,41 +120,57 @@ static void arm_dcc_putc(char ch)
break;
}
if (timeout_count == 0)
- return;
+ return -EAGAIN;
else
write_dcc(ch);
+
+ return 0;
}
-static int arm_dcc_tstc(void)
+static int arm_dcc_pending(struct udevice *dev, bool input)
{
register unsigned int reg;
- can_read_dcc(reg);
+ if (input) {
>>>
>>> Don't need the {} here
>>>
+ can_read_dcc(reg);
+ } else {
+ can_write_dcc(reg);
+ }
>>
>> Unfortunately I do. can_read/write_dcc are macros.
>
> What goes wrong if you leave them out? But if you need them, that's OK.
CC drivers/serial/arm_dcc.o
drivers/serial/arm_dcc.c: In function ‘arm_dcc_pending’:
drivers/serial/arm_dcc.c:136:2: error: ‘else’ without a previous ‘if’
else
^
make[1]: *** [drivers/serial/arm_dcc.o] Error 1
make: *** [drivers/serial] Error 2
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
