[U-Boot] [PATCH] bootm: fix size arg of flush_cache() in bootm_load_os().
Variable _load_end_ points to end address of uncompressed buffer
(*not* uncomress_buffer_end / sizeof(ulong)), so multipling uncompressed
size with sizeof(ulong) is grossly incorrect in flush_cache().
It might lead to access of address beyond valid memory range and hang the CPU.
Tested on MIPS architecture by using compressed(gzip, lzma)
and uncompressed uImage.
Signed-off-by: Purna Chandra Mandal
---
common/bootm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/bootm.c b/common/bootm.c
index 58936ca..99d574d 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -435,7 +435,7 @@ static int bootm_load_os(bootm_headers_t *images, unsigned
long *load_end,
bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
return err;
}
- flush_cache(load, (*load_end - load) * sizeof(ulong));
+ flush_cache(load, *load_end - load);
debug(" kernel loaded at 0x%08lx, end = 0x%08lx\n", load, *load_end);
bootstage_mark(BOOTSTAGE_ID_KERNEL_LOADED);
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] x86: qemu: setup PM IO base for ACPI in southbridge
On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: > Enable ACPI IO space for piix4 (for pc board) and ich9 (for q35 board) > > Signed-off-by: Miao Yan > --- > Changes in v2: > - add ACPI_PM1_BASE in Kconfig > - drop PCI device ID checks > > arch/x86/cpu/qemu/Kconfig | 7 +++ > arch/x86/cpu/qemu/qemu.c| 29 + > arch/x86/include/asm/arch-qemu/device.h | 2 ++ > arch/x86/include/asm/arch-qemu/qemu.h | 5 + > 4 files changed, 43 insertions(+) > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] x86: config option for loading ACPI table from QEMU
On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: > This patch adds a config option for loading ACPI table from QEMU. When > enabled, > U-Boot won't generate ACPI tables, but use those provided by QEMU. > > Signed-off-by: Miao Yan > --- > arch/x86/Kconfig | 9 + > arch/x86/cpu/qemu/Makefile | 2 ++ > arch/x86/lib/Makefile | 2 ++ > 3 files changed, 13 insertions(+) > Reviewed-by: Bin Meng Tested-by: Bin Meng But please see one nits below: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f07567c..26c8d83 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -358,6 +358,15 @@ config GENERATE_ACPI_TABLE > by the operating system. It defines platform-independent interfaces > for configuration and power management monitoring. > > +config QEMU_ACPI_TABLE > + bool "load ACPI table from QEMU fw_cfg interface" nits: load -> Load I can fix this when applying. > + depends on GENERATE_ACPI_TABLE && QEMU > + default y > + help > + By default, U-Boot generates its own ACPI tables. This option, if > + enabled, disables U-Boot's version and loads ACPI tables generated > + by QEMU. > + [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] x86: qemu: re-structure qemu_fwcfg_list_firmware()
On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: > Re-write the logic in qemu_fwcfg_list_firmware(), add a function > qemu_fwcfg_read_firmware_list() to handle reading firmware list. > > Signed-off-by: Miao Yan > --- > Changes in v2: > - coding style fix > - add comments in header file > > arch/x86/cpu/qemu/fw_cfg.c| 63 > +-- > arch/x86/include/asm/fw_cfg.h | 9 --- > 2 files changed, 55 insertions(+), 17 deletions(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] x86: qemu: add the ability to load and link ACPI tables from QEMU
On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: > This patch adds the ability to load and link ACPI tables provided by QEMU. > QEMU tells guests how to load and patch ACPI tables through its fw_cfg > interface, by adding a firmware file 'etc/table-loader'. Guests are > supposed to parse this file and execute corresponding QEMU commands. > > Signed-off-by: Miao Yan > --- > Changes in v2: > - add function comment > - improve error handling > > arch/x86/cpu/qemu/fw_cfg.c| 253 > ++ > arch/x86/include/asm/fw_cfg.h | 61 ++ > arch/x86/lib/acpi_table.c | 4 + > 3 files changed, 318 insertions(+) > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] x86: config option for loading ACPI table from QEMU
Hi Bin, 2016-01-20 16:46 GMT+08:00 Bin Meng : > On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: >> This patch adds a config option for loading ACPI table from QEMU. When >> enabled, >> U-Boot won't generate ACPI tables, but use those provided by QEMU. >> >> Signed-off-by: Miao Yan >> --- >> arch/x86/Kconfig | 9 + >> arch/x86/cpu/qemu/Makefile | 2 ++ >> arch/x86/lib/Makefile | 2 ++ >> 3 files changed, 13 insertions(+) >> > > Reviewed-by: Bin Meng > Tested-by: Bin Meng > > But please see one nits below: > >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >> index f07567c..26c8d83 100644 >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -358,6 +358,15 @@ config GENERATE_ACPI_TABLE >> by the operating system. It defines platform-independent interfaces >> for configuration and power management monitoring. >> >> +config QEMU_ACPI_TABLE >> + bool "load ACPI table from QEMU fw_cfg interface" > > nits: load -> Load > > I can fix this when applying. Thanks, I just found this patch breaks git bisect, I'll submit v3 to fix this as well as the typo. > >> + depends on GENERATE_ACPI_TABLE && QEMU >> + default y >> + help >> + By default, U-Boot generates its own ACPI tables. This option, if >> + enabled, disables U-Boot's version and loads ACPI tables generated >> + by QEMU. >> + > > [snip] > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] x86: config option for loading ACPI table from QEMU
Hi Miao, On Wed, Jan 20, 2016 at 5:15 PM, Miao Yan wrote: > Hi Bin, > > 2016-01-20 16:46 GMT+08:00 Bin Meng : >> On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: >>> This patch adds a config option for loading ACPI table from QEMU. When >>> enabled, >>> U-Boot won't generate ACPI tables, but use those provided by QEMU. >>> >>> Signed-off-by: Miao Yan >>> --- >>> arch/x86/Kconfig | 9 + >>> arch/x86/cpu/qemu/Makefile | 2 ++ >>> arch/x86/lib/Makefile | 2 ++ >>> 3 files changed, 13 insertions(+) >>> >> >> Reviewed-by: Bin Meng >> Tested-by: Bin Meng >> >> But please see one nits below: >> >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >>> index f07567c..26c8d83 100644 >>> --- a/arch/x86/Kconfig >>> +++ b/arch/x86/Kconfig >>> @@ -358,6 +358,15 @@ config GENERATE_ACPI_TABLE >>> by the operating system. It defines platform-independent >>> interfaces >>> for configuration and power management monitoring. >>> >>> +config QEMU_ACPI_TABLE >>> + bool "load ACPI table from QEMU fw_cfg interface" >> >> nits: load -> Load >> >> I can fix this when applying. > > Thanks, I just found this patch breaks git bisect, I'll submit v3 to > fix this as well as the typo. > > Uh, I've tested building your patches via buildman, no errors. What do you see? >> >>> + depends on GENERATE_ACPI_TABLE && QEMU >>> + default y >>> + help >>> + By default, U-Boot generates its own ACPI tables. This option, if >>> + enabled, disables U-Boot's version and loads ACPI tables generated >>> + by QEMU. >>> + >> >> [snip] >> Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] x86: config option for loading ACPI table from QEMU
Hi Bin, 2016-01-20 17:18 GMT+08:00 Bin Meng : > Hi Miao, > > On Wed, Jan 20, 2016 at 5:15 PM, Miao Yan wrote: >> Hi Bin, >> >> 2016-01-20 16:46 GMT+08:00 Bin Meng : >>> On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: This patch adds a config option for loading ACPI table from QEMU. When enabled, U-Boot won't generate ACPI tables, but use those provided by QEMU. Signed-off-by: Miao Yan --- arch/x86/Kconfig | 9 + arch/x86/cpu/qemu/Makefile | 2 ++ arch/x86/lib/Makefile | 2 ++ 3 files changed, 13 insertions(+) >>> >>> Reviewed-by: Bin Meng >>> Tested-by: Bin Meng >>> >>> But please see one nits below: >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f07567c..26c8d83 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -358,6 +358,15 @@ config GENERATE_ACPI_TABLE by the operating system. It defines platform-independent interfaces for configuration and power management monitoring. +config QEMU_ACPI_TABLE + bool "load ACPI table from QEMU fw_cfg interface" >>> >>> nits: load -> Load >>> >>> I can fix this when applying. >> >> Thanks, I just found this patch breaks git bisect, I'll submit v3 to >> fix this as well as the typo. >> >> > > Uh, I've tested building your patches via buildman, no errors. What do you > see? If you enable CONFIG_GENERATE_ACPI_TABLE and QEMU_ACPI_TABLE, you'll see: arch/x86/lib/built-in.o: In function `write_tables': /home/myan/work/u-boot-x86/arch/x86/lib/tables.c:57: undefined reference to `write_acpi_tables' make: *** [u-boot] Error Because write_acpi_tables() are defined in [PATCH 0/4]. With default config you won't see it. Is this OK ? > >>> + depends on GENERATE_ACPI_TABLE && QEMU + default y + help + By default, U-Boot generates its own ACPI tables. This option, if + enabled, disables U-Boot's version and loads ACPI tables generated + by QEMU. + >>> >>> [snip] >>> > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/8] x86: Use the IRQ device when setting up the mptable
On Wed, Jan 20, 2016 at 12:32 PM, Simon Glass wrote: > Instead of searching for the device tree node, use the IRQ device which has > a record of it. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Add new patch to use the IRQ device when setting up the mptable > > Changes in v2: None > > arch/x86/cpu/irq.c| 16 > arch/x86/lib/mpspec.c | 14 +++--- > 2 files changed, 11 insertions(+), 19 deletions(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] dm: x86: quark: Add an interrupt driver
On Wed, Jan 20, 2016 at 12:32 PM, Simon Glass wrote: > Add a driver for interrupts on quark and move the code currently in > cpu_irq_init() into its probe() method. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v3: None > Changes in v2: None > > arch/x86/cpu/quark/Makefile | 2 +- > arch/x86/cpu/quark/irq.c| 49 > + > arch/x86/cpu/quark/quark.c | 25 --- > arch/x86/dts/galileo.dts| 2 +- > 4 files changed, 51 insertions(+), 27 deletions(-) > create mode 100644 arch/x86/cpu/quark/irq.c > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/8] x86: Drop the irq router compatible string
On Wed, Jan 20, 2016 at 12:32 PM, Simon Glass wrote: > We use driver model for this now, so we don't need this string. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Add new patch to drop the irq router compatible string > > Changes in v2: None > > include/fdtdec.h | 1 - > lib/fdtdec.c | 1 - > 2 files changed, 2 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/8] dm: x86: queensbay: Add an interrupt driver
On Wed, Jan 20, 2016 at 12:32 PM, Simon Glass wrote: > Add a driver for interrupts on queensbay and move the code currently in > cpu_irq_init() into its probe() method. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v3: None > Changes in v2: None > > arch/x86/cpu/queensbay/Makefile | 2 +- > arch/x86/cpu/queensbay/irq.c| 65 > + > arch/x86/cpu/queensbay/tnc.c| 37 --- > arch/x86/dts/crownbay.dts | 2 +- > 4 files changed, 67 insertions(+), 39 deletions(-) > create mode 100644 arch/x86/cpu/queensbay/irq.c > Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] x86: config option for loading ACPI table from QEMU
Hi Miao, On Wed, Jan 20, 2016 at 5:26 PM, Miao Yan wrote: > Hi Bin, > > 2016-01-20 17:18 GMT+08:00 Bin Meng : >> Hi Miao, >> >> On Wed, Jan 20, 2016 at 5:15 PM, Miao Yan wrote: >>> Hi Bin, >>> >>> 2016-01-20 16:46 GMT+08:00 Bin Meng : On Wed, Jan 20, 2016 at 12:24 PM, Miao Yan wrote: > This patch adds a config option for loading ACPI table from QEMU. When > enabled, > U-Boot won't generate ACPI tables, but use those provided by QEMU. > > Signed-off-by: Miao Yan > --- > arch/x86/Kconfig | 9 + > arch/x86/cpu/qemu/Makefile | 2 ++ > arch/x86/lib/Makefile | 2 ++ > 3 files changed, 13 insertions(+) > Reviewed-by: Bin Meng Tested-by: Bin Meng But please see one nits below: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f07567c..26c8d83 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -358,6 +358,15 @@ config GENERATE_ACPI_TABLE > by the operating system. It defines platform-independent > interfaces > for configuration and power management monitoring. > > +config QEMU_ACPI_TABLE > + bool "load ACPI table from QEMU fw_cfg interface" nits: load -> Load I can fix this when applying. >>> >>> Thanks, I just found this patch breaks git bisect, I'll submit v3 to >>> fix this as well as the typo. >>> >>> >> >> Uh, I've tested building your patches via buildman, no errors. What do you >> see? > > If you enable CONFIG_GENERATE_ACPI_TABLE and QEMU_ACPI_TABLE, you'll see: > > arch/x86/lib/built-in.o: In function `write_tables': > /home/myan/work/u-boot-x86/arch/x86/lib/tables.c:57: undefined > reference to `write_acpi_tables' > make: *** [u-boot] Error > > Because write_acpi_tables() are defined in [PATCH 0/4]. With default > config you won't see it. Is this OK ? > Ah, yes! buildman only builds with default configuration so it is not exposed. So I assume you may defer the Makefile changes to patch#4. Thanks for pointing this out! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4
Hi! I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim that this configuration is unsupported, but it enables fairly quick development and was very useful for me in past. Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before I start bisecting it, I wanted to ask if someone has idea what might be responsible? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4
Hi Pavel, On 20.01.2016 10:31, Pavel Machek wrote: I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim that this configuration is unsupported, but it enables fairly quick development and was very useful for me in past. Yes, I use this chainloading also quite frequently on some platforms. It should generally work on platforms with SPL support. Where the preloader / SPL / BootROM has initialized the base HW and the SDRAM. So that the U-Boot proper can get loaded into SDRAM. So it should also work on SoCFPGA. I have to admit, that I haven't tested it lately on SoCFPGA though. Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before I start bisecting it, I wanted to ask if someone has idea what might be responsible? As mentioned above, I've not tested on this platform lately, sorry. But I assume that you also test the latest release version, yes? And current master as well. Also failing there? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] x86: qemu: re-structure qemu_fwcfg_list_firmware()
Re-write the logic in qemu_fwcfg_list_firmware(), add a function
qemu_fwcfg_read_firmware_list() to handle reading firmware list.
Signed-off-by: Miao Yan
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
arch/x86/cpu/qemu/fw_cfg.c| 63 +--
arch/x86/include/asm/fw_cfg.h | 9 ---
2 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/arch/x86/cpu/qemu/fw_cfg.c b/arch/x86/cpu/qemu/fw_cfg.c
index 0599214..bcd34af 100644
--- a/arch/x86/cpu/qemu/fw_cfg.c
+++ b/arch/x86/cpu/qemu/fw_cfg.c
@@ -10,10 +10,13 @@
#include
#include
#include
+#include
static bool fwcfg_present;
static bool fwcfg_dma_present;
+static LIST_HEAD(fw_list);
+
/* Read configuration item using fw_cfg PIO interface */
static void qemu_fwcfg_read_entry_pio(uint16_t entry,
uint32_t size, void *address)
@@ -162,29 +165,61 @@ static int qemu_fwcfg_setup_kernel(void *load_addr, void
*initrd_addr)
return 0;
}
-static int qemu_fwcfg_list_firmware(void)
+static int qemu_fwcfg_read_firmware_list(void)
{
int i;
uint32_t count;
- struct fw_cfg_files *files;
+ struct fw_file *file;
+ struct list_head *entry;
+
+ /* don't read it twice */
+ if (!list_empty(&fw_list))
+ return 0;
qemu_fwcfg_read_entry(FW_CFG_FILE_DIR, 4, &count);
if (!count)
return 0;
count = be32_to_cpu(count);
- files = malloc(count * sizeof(struct fw_cfg_file));
- if (!files)
- return -ENOMEM;
-
- files->count = count;
- qemu_fwcfg_read_entry(FW_CFG_INVALID,
- count * sizeof(struct fw_cfg_file),
- files->files);
-
- for (i = 0; i < files->count; i++)
- printf("%-56s\n", files->files[i].name);
- free(files);
+ for (i = 0; i < count; i++) {
+ file = malloc(sizeof(*file));
+ if (!file) {
+ printf("error: allocating resource\n");
+ goto err;
+ }
+ qemu_fwcfg_read_entry(FW_CFG_INVALID,
+ sizeof(struct fw_cfg_file), &file->cfg);
+ file->addr = 0;
+ list_add_tail(&file->list, &fw_list);
+ }
+
+ return 0;
+
+err:
+ list_for_each(entry, &fw_list) {
+ file = list_entry(entry, struct fw_file, list);
+ free(file);
+ }
+
+ return -ENOMEM;
+}
+
+static int qemu_fwcfg_list_firmware(void)
+{
+ int ret;
+ struct list_head *entry;
+ struct fw_file *file;
+
+ /* make sure fw_list is loaded */
+ ret = qemu_fwcfg_read_firmware_list();
+ if (ret)
+ return ret;
+
+ list_for_each(entry, &fw_list) {
+ file = list_entry(entry, struct fw_file, list);
+ printf("%-56s\n", file->cfg.name);
+ }
+
return 0;
}
diff --git a/arch/x86/include/asm/fw_cfg.h b/arch/x86/include/asm/fw_cfg.h
index fb110fa..2acf43e 100644
--- a/arch/x86/include/asm/fw_cfg.h
+++ b/arch/x86/include/asm/fw_cfg.h
@@ -12,6 +12,8 @@
#define FW_DMA_PORT_LOW0x514
#define FW_DMA_PORT_HIGH 0x518
+#include
+
enum qemu_fwcfg_items {
FW_CFG_SIGNATURE= 0x00,
FW_CFG_ID = 0x01,
@@ -67,9 +69,10 @@ struct fw_cfg_file {
char name[FW_CFG_MAX_FILE_PATH];
};
-struct fw_cfg_files {
- __be32 count;
- struct fw_cfg_file files[];
+struct fw_file {
+ struct fw_cfg_file cfg; /* firmware file information */
+ unsigned long addr; /* firmware file in-memory address */
+ struct list_head list; /* list node to link to fw_list */
};
struct fw_cfg_dma_access {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] x86: config option for loading ACPI table from QEMU
This patch adds a config option for loading ACPI table from QEMU. When enabled, U-Boot won't generate ACPI tables, but use those provided by QEMU. Signed-off-by: Miao Yan Reviewed-by: Bin Meng Tested-by: Bin Meng --- Changes in v3: - fix a build error - make it [PATCH 4/4] arch/x86/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f07567c..a995e32 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -358,6 +358,15 @@ config GENERATE_ACPI_TABLE by the operating system. It defines platform-independent interfaces for configuration and power management monitoring. +config QEMU_ACPI_TABLE + bool "Load ACPI table from QEMU fw_cfg interface" + depends on GENERATE_ACPI_TABLE && QEMU + default y + help + By default, U-Boot generates its own ACPI tables. This option, if + enabled, disables U-Boot's version and loads ACPI tables generated + by QEMU. + config GENERATE_SMBIOS_TABLE bool "Generate an SMBIOS (System Management BIOS) table" default y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] x86: qemu: setup PM IO base for ACPI in southbridge
Enable ACPI IO space for piix4 (for pc board) and ich9 (for q35 board)
Signed-off-by: Miao Yan
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
arch/x86/cpu/qemu/Kconfig | 7 +++
arch/x86/cpu/qemu/qemu.c| 29 +
arch/x86/include/asm/arch-qemu/device.h | 2 ++
arch/x86/include/asm/arch-qemu/qemu.h | 5 +
4 files changed, 43 insertions(+)
diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig
index 4f98621..6808c9a 100644
--- a/arch/x86/cpu/qemu/Kconfig
+++ b/arch/x86/cpu/qemu/Kconfig
@@ -17,4 +17,11 @@ config SYS_CAR_SIZE
hex
default 0x1
+config ACPI_PM1_BASE
+ hex
+ default 0xe400
+ help
+ ACPI Power Managment 1 (PM1) i/o-mapped base address.
+ This device is defined in ACPI specification, with 16 bytes in size.
+
endif
diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index 46111c9..b794cfe 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -15,6 +15,31 @@
static bool i440fx;
+static void enable_pm_piix(void)
+{
+ u8 en;
+ u16 cmd;
+
+ /* Set the PM I/O base */
+ x86_pci_write_config32(PIIX_PM, PMBA, CONFIG_ACPI_PM1_BASE | 1);
+
+ /* Enable access to the PM I/O space */
+ cmd = x86_pci_read_config16(PIIX_PM, PCI_COMMAND);
+ cmd |= PCI_COMMAND_IO;
+ x86_pci_write_config16(PIIX_PM, PCI_COMMAND, cmd);
+
+ /* PM I/O Space Enable (PMIOSE) */
+ en = x86_pci_read_config8(PIIX_PM, PMREGMISC);
+ en |= PMIOSE;
+ x86_pci_write_config8(PIIX_PM, PMREGMISC, en);
+}
+
+static void enable_pm_ich9(void)
+{
+ /* Set the PM I/O base */
+ x86_pci_write_config32(ICH9_PM, PMBA, CONFIG_ACPI_PM1_BASE | 1);
+}
+
static void qemu_chipset_init(void)
{
u16 device, xbcs;
@@ -53,10 +78,14 @@ static void qemu_chipset_init(void)
xbcs = x86_pci_read_config16(PIIX_ISA, XBCS);
xbcs |= APIC_EN;
x86_pci_write_config16(PIIX_ISA, XBCS, xbcs);
+
+ enable_pm_piix();
} else {
/* Configure PCIe ECAM base address */
x86_pci_write_config32(PCI_BDF(0, 0, 0), PCIEX_BAR,
CONFIG_PCIE_ECAM_BASE | BAR_EN);
+
+ enable_pm_ich9();
}
qemu_fwcfg_init();
diff --git a/arch/x86/include/asm/arch-qemu/device.h
b/arch/x86/include/asm/arch-qemu/device.h
index 75a435e..38ab798 100644
--- a/arch/x86/include/asm/arch-qemu/device.h
+++ b/arch/x86/include/asm/arch-qemu/device.h
@@ -13,6 +13,8 @@
#define PIIX_ISA PCI_BDF(0, 1, 0)
#define PIIX_IDE PCI_BDF(0, 1, 1)
#define PIIX_USB PCI_BDF(0, 1, 2)
+#define PIIX_PMPCI_BDF(0, 1, 3)
+#define ICH9_PMPCI_BDF(0, 0x1f, 0)
#define I440FX_VGA PCI_BDF(0, 2, 0)
#define QEMU_Q35 PCI_BDF(0, 0, 0)
diff --git a/arch/x86/include/asm/arch-qemu/qemu.h
b/arch/x86/include/asm/arch-qemu/qemu.h
index b67d342..a85eee8 100644
--- a/arch/x86/include/asm/arch-qemu/qemu.h
+++ b/arch/x86/include/asm/arch-qemu/qemu.h
@@ -33,4 +33,9 @@
#define LOW_RAM_ADDR 0x34
#define HIGH_RAM_ADDR 0x35
+/* PM registers */
+#define PMBA 0x40
+#define PMREGMISC 0x80
+#define PMIOSE (1 << 0)
+
#endif /* _ARCH_QEMU_H_ */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] add support for loading ACPI tables from QEMU
Currently, if CONFIG_GENERATE_ACPI_TABLE is defined, U-Boot will generate ACPI tables itlself, this patchset adds the ability to load the ACPI tables generated by QEMU. Changes in v3: - fix a build error in patch 3/4 - re-order patch 3/4 and patch 4/4 in v2 Changes in v2: - Drop [PATCH 4/4] x86: qemu: loading ACPI table from QEMU, add a config option CONFIG_QEMU_ACPI_TABLE - various cleanups Miao Yan (4): x86: qemu: re-structure qemu_fwcfg_list_firmware() x86: qemu: setup PM IO base for ACPI in southbridge x86: qemu: add the ability to load and link ACPI tables from QEMU x86: config option for loading ACPI table from QEMU arch/x86/Kconfig| 9 + arch/x86/cpu/qemu/Kconfig | 7 + arch/x86/cpu/qemu/Makefile | 2 + arch/x86/cpu/qemu/fw_cfg.c | 316 ++-- arch/x86/cpu/qemu/qemu.c| 29 +++ arch/x86/include/asm/arch-qemu/device.h | 2 + arch/x86/include/asm/arch-qemu/qemu.h | 5 + arch/x86/include/asm/fw_cfg.h | 70 ++- arch/x86/lib/Makefile | 2 + arch/x86/lib/acpi_table.c | 4 + 10 files changed, 429 insertions(+), 17 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] x86: qemu: add the ability to load and link ACPI tables from QEMU
This patch adds the ability to load and link ACPI tables provided by QEMU.
QEMU tells guests how to load and patch ACPI tables through its fw_cfg
interface, by adding a firmware file 'etc/table-loader'. Guests are
supposed to parse this file and execute corresponding QEMU commands.
Signed-off-by: Miao Yan
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
Change in v3:
- fix a build error
- make it [PATCH 3/4]
arch/x86/cpu/qemu/Makefile| 2 +
arch/x86/cpu/qemu/fw_cfg.c| 253 ++
arch/x86/include/asm/fw_cfg.h | 61 ++
arch/x86/lib/Makefile | 2 +
arch/x86/lib/acpi_table.c | 4 +
5 files changed, 322 insertions(+)
diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
index 176ea54..801413a 100644
--- a/arch/x86/cpu/qemu/Makefile
+++ b/arch/x86/cpu/qemu/Makefile
@@ -8,4 +8,6 @@ ifndef CONFIG_EFI_STUB
obj-y += car.o dram.o
endif
obj-y += cpu.o fw_cfg.o qemu.o
+ifndef CONFIG_QEMU_ACPI_TABLE
obj-$(CONFIG_GENERATE_ACPI_TABLE) += acpi.o dsdt.o
+endif
diff --git a/arch/x86/cpu/qemu/fw_cfg.c b/arch/x86/cpu/qemu/fw_cfg.c
index bcd34af..5ea7a6e 100644
--- a/arch/x86/cpu/qemu/fw_cfg.c
+++ b/arch/x86/cpu/qemu/fw_cfg.c
@@ -10,7 +10,10 @@
#include
#include
#include
+#include
+#include
#include
+#include
static bool fwcfg_present;
static bool fwcfg_dma_present;
@@ -204,6 +207,256 @@ err:
return -ENOMEM;
}
+#ifdef CONFIG_QEMU_ACPI_TABLE
+static struct fw_file *qemu_fwcfg_find_file(const char *name)
+{
+ struct list_head *entry;
+ struct fw_file *file;
+
+ list_for_each(entry, &fw_list) {
+ file = list_entry(entry, struct fw_file, list);
+ if (!strcmp(file->cfg.name, name))
+ return file;
+ }
+
+ return NULL;
+}
+
+/*
+ * This function allocates memory for ACPI tables
+ *
+ * @entry : BIOS linker command entry which tells where to allocate memory
+ * (either high memory or low memory)
+ * @addr : The address that should be used for low memory allcation. If the
+ * memory allocation request is 'ZONE_HIGH' then this parameter will
+ * be ignored.
+ * @return: 0 on success, or negative value on failure
+ */
+static int bios_linker_allocate(struct bios_linker_entry *entry,
+ unsigned long *addr)
+{
+ uint32_t size, align;
+ struct fw_file *file;
+ unsigned long aligned_addr;
+
+ align = le32_to_cpu(entry->alloc.align);
+ /* align must be power of 2 */
+ if (align & (align - 1)) {
+ printf("error: wrong alignment %u\n", align);
+ return -EINVAL;
+ }
+
+ file = qemu_fwcfg_find_file(entry->alloc.file);
+ if (!file) {
+ printf("error: can't find file %s\n", entry->alloc.file);
+ return -ENOENT;
+ }
+
+ size = be32_to_cpu(file->cfg.size);
+
+ /*
+* ZONE_HIGH means we need to allocate from high memory, since
+* malloc space is already at the end of RAM, so we directly use it.
+* If allocation zone is ZONE_FSEG, then we use the 'addr' passed
+* in which is low memory
+*/
+ if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH) {
+ aligned_addr = (unsigned long)memalign(align, size);
+ if (!aligned_addr) {
+ printf("error: allocating resource\n");
+ return -ENOMEM;
+ }
+ } else if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG) {
+ aligned_addr = ALIGN(*addr, align);
+ } else {
+ printf("error: invalid allocation zone\n");
+ return -EINVAL;
+ }
+
+ debug("bios_linker_allocate: allocate file %s, size %u, zone %d, align
%u, addr 0x%lx\n",
+ file->cfg.name, size, entry->alloc.zone, align, aligned_addr);
+
+ qemu_fwcfg_read_entry(be16_to_cpu(file->cfg.select),
+ size, (void *)aligned_addr);
+ file->addr = aligned_addr;
+
+ /* adjust address for low memory allocation */
+ if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG)
+ *addr = (aligned_addr + size);
+
+ return 0;
+}
+
+/*
+ * This function patches ACPI tables previously loaded
+ * by bios_linker_allocate()
+ *
+ * @entry : BIOS linker command entry which tells how to patch
+ * ACPI tables
+ * @return: 0 on success, or negative value on failure
+ */
+static int bios_linker_add_pointer(struct bios_linker_entry *entry)
+{
+ struct fw_file *dest, *src;
+ uint32_t offset = le32_to_cpu(entry->pointer.offset);
+ uint64_t pointer = 0;
+
+ dest = qemu_fwcfg_find_file(entry->pointer.dest_file);
+ if (!dest || !dest->addr)
+ return -ENOENT;
+ src = qemu_fwcfg_find_file(entry->pointer.src_file);
+ if (!src || !src->addr)
+ return -ENOENT;
[U-Boot] [PATCH] wandboard: fix variable name so PXE boot works
All boards that support PXE booting use the pxefile_addr_r variable. Standardise wandboard with this variable as pxe_addr_r isn't used anywhere else so it's a typo. Signed-off-by: Peter Robinson --- include/configs/wandboard.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 4c8e9e9..8fb0abc 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -150,7 +150,7 @@ "if test $fdtfile = undefined; then " \ "echo WARNING: Could not determine dtb to use; fi; \0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ - "pxe_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ "ramdisk_addr_r=0x1300\0" \ "ramdiskaddr=0x1300\0" \ "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \ -- 2.5.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: fix variable name so PXE boot works
On Wed, Jan 20, 2016 at 8:00 AM, Peter Robinson wrote: > All boards that support PXE booting use the pxefile_addr_r variable. > Standardise > wandboard with this variable as pxe_addr_r isn't used anywhere else so it's a > typo. > > Signed-off-by: Peter Robinson Acked-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4
Hi! > I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim > that this configuration is unsupported, but it enables fairly quick > development and was very useful for me in past. > > Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before > I start bisecting it, I wanted to ask if someone has idea what might > be responsible? When I merge 1c84cc6e3badb31e55bdf05ff2d3f8f058a5da47, I get: U-Boot 2016.01-rc2-01393-gc28dfb5 (Jan 20 2016 - 10:42:36 +0100) CPU: Altera SoCFPGA Platform FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0 BOOT: SD/MMC External Transceiver (1.8V) Watchdog enabled I2C: ready DRAM: 1 GiB Error binding driver 'socfpga_dwmmc' Some drivers failed to bind Error binding driver 'generic_simple_bus' Some drivers failed to bind initcall sequence 3ffb10a4 failed at call 01003257 (err=-96) ### ERROR ### Please RESET the board ### (But that's not failure I was looking for). Commit 0c890879fe2a5731df7aee3dd38e455008fa9977 worked ok. Commit 8e535af2e441030f5e4b940a3756a0d92646b5fe breaks compilation (previous one worked ok in my config). LD lib/built-in.o LD u-boot board/altera/cyclone5-socdk/built-in.o: In function `g_dnl_board_usb_cable_connected': /home/pavel/amp/u-boot/board/altera/cyclone5-socdk/socfpga.c:25: multiple definition of `board_init' arch/arm/mach-socfpga/built-in.o::(.text.board_init+0x0): first defined here board/altera/cyclone5-socdk/built-in.o: In function `s_init': /home/pavel/amp/u-boot/board/altera/cyclone5-socdk/socfpga.c:17: multiple definition of `s_init' ... Disabling "CONFIG_USB" fixes compilation for me, and can get back to u-boot that starts but then pritns "initcall sequence 3ffb1300 failed at call 01003263 (err=-96)". Commit 07806977878130dd27dfc926ef7002041f6cf288 seems to break compilation again (previous one worked), with: drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init': drivers/usb/host/dwc2.c:1027:40: error: 'CONFIG_USB_DWC2_REG_ADDR' undeclared (first use in this function) priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR; ^ drivers/usb/host/dwc2.c:1027:40: note: each undeclared identifier is reported only once for each function it appears in I'm able to get it back to compile when I rip out complete USB support. I have merged 68909e823eb4074a7e559e0c03d16533813c86cf, and now it fails to boot at all. While bisecting, this commit jumped to my attention: commit 574967c241301b924748ce205f29f494e32967fe Author: Marek Vasut Date: Tue Dec 22 04:16:01 2015 +0100 arm: socfpga: Enable simple bus in SPL on all boards The simple bus support must be enabled in SPL, otherwise the boards will not be able to parse the DT and will fail to boot. Signed-off-by: Marek Vasut Cc: Dinh Nguyen That's probably is biting me. Any idea which commit introduced this "U-Boot proper needs U-Boot-SPL to have CONFIG_SPL_SIMPLE_BUS=y dependency? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4
Hi! > On 20.01.2016 10:31, Pavel Machek wrote: > >I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim > >that this configuration is unsupported, but it enables fairly quick > >development and was very useful for me in past. > > Yes, I use this chainloading also quite frequently on some platforms. > It should generally work on platforms with SPL support. Where the > preloader / SPL / BootROM has initialized the base HW and the SDRAM. > So that the U-Boot proper can get loaded into SDRAM. So it should > also work on SoCFPGA. I have to admit, that I haven't tested it > lately on SoCFPGA though. > > >Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before > >I start bisecting it, I wanted to ask if someone has idea what might > >be responsible? > > As mentioned above, I've not tested on this platform lately, sorry. > But I assume that you also test the latest release version, yes? > And current master as well. Also failing there? I have not got to current master. I retested 2016.01 now, and used config not based on my previous one, but based on defconfig, and it seems to work. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] board: ti: ks2_evm: remove board_eth_init when CONFIG_DM_ETH is defined
remove board_eth_init when CONFIG_DM_ETH is defined
Signed-off-by: Mugunthan V N
---
board/ti/ks2_evm/board.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index 73d94a6..7d1709c 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -56,6 +56,7 @@ int board_init(void)
}
#ifdef CONFIG_DRIVER_TI_KEYSTONE_NET
+#ifndef CONFIG_DM_ETH
int get_eth_env_param(char *env_name)
{
char *env;
@@ -105,6 +106,7 @@ int board_eth_init(bd_t *bis)
return 0;
}
#endif
+#endif
#ifdef CONFIG_SPL_BUILD
void spl_board_init(void)
--
2.7.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/8] driver model bring-up of keystone net on k2hk, k2l, k2e and k2g evm
This patch series enables keystone net to adopt driver model. This has been tested on the following evms (logs [1]) by tftp zImage from server. * k2hk evm * k2l evm * k2e evm * k2g evm Also pushed a branch for testing [2] [1] - http://pastebin.ubuntu.com/14581762/ [2] - git://git.ti.com/~mugunthanvnm/ti-u-boot/mugunth-ti-u-boot.git dm-keystone-net Mugunthan V N (8): board: ti: ks2_evm: remove board_eth_init when CONFIG_DM_ETH is defined drivers: net: phy: micrel: fix build errors with CONFIG_DM_ETH drivers: net: keystone_net: convert driver to adopt device driver model defconfig: k2hk_evm_defconfig: enable net driver model defconfig: k2l_evm_defconfig: enable net driver model defconfig: k2e_evm_defconfig: enable net driver model ARM: dts: k2g: Add keystone net dts files defconfig: k2g_evm_defconfig: enable net driver model arch/arm/dts/k2g-evm.dts| 12 ++ arch/arm/dts/k2g-netcp.dtsi | 151 arch/arm/dts/k2g.dtsi | 13 ++ board/ti/ks2_evm/board.c| 2 + configs/k2e_evm_defconfig | 1 + configs/k2g_evm_defconfig | 1 + configs/k2hk_evm_defconfig | 1 + configs/k2l_evm_defconfig | 1 + drivers/net/keystone_net.c | 418 +++- drivers/net/phy/micrel.c| 6 +- 10 files changed, 562 insertions(+), 44 deletions(-) create mode 100644 arch/arm/dts/k2g-netcp.dtsi -- 2.7.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8] drivers: net: phy: micrel: fix build errors with CONFIG_DM_ETH
When Micrel phy is selected without CONFIG_PHY_MICREL_KSZ9031 or
CONFIG_PHY_MICREL_KSZ9021 there is a build warning. Fixing this
by adding proper ifdefs
drivers/net/phy/micrel.c:370:39: error: array type has incomplete element type
static const struct ksz90x1_reg_field ksz9031_ctl_grp[] =
^
drivers/net/phy/micrel.c:372:39: error: array type has incomplete element type
static const struct ksz90x1_reg_field ksz9031_clk_grp[] =
^
drivers/net/phy/micrel.c: In function ‘ksz9031_of_config’:
drivers/net/phy/micrel.c:377:23: error: array type has incomplete element type
struct ksz90x1_ofcfg ofcfg[] = {
^
drivers/net/phy/micrel.c:379:13: error: ‘ksz90x1_rxd_grp’ undeclared (first use
in this function)
{ MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW, 2, ksz90x1_rxd_grp, 4 },
^
drivers/net/phy/micrel.c:379:13: note: each undeclared identifier is reported
only once for each function it appears in
drivers/net/phy/micrel.c:380:13: error: ‘ksz90x1_txd_grp’ undeclared (first use
in this function)
{ MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW, 2, ksz90x1_txd_grp, 4 },
^
drivers/net/phy/micrel.c:386:3: warning: implicit declaration of function
‘ksz90x1_of_config_group’ [-Wimplicit-function-declaration]
ret = ksz90x1_of_config_group(phydev, &(ofcfg[i]));
^
drivers/net/phy/micrel.c:377:23: warning: unused variable ‘ofcfg’
[-Wunused-variable]
struct ksz90x1_ofcfg ofcfg[] = {
^
drivers/net/phy/micrel.c: At top level:
drivers/net/phy/micrel.c:370:39: warning: ‘ksz9031_ctl_grp’ defined but not
used [-Wunused-variable]
static const struct ksz90x1_reg_field ksz9031_ctl_grp[] =
^
drivers/net/phy/micrel.c:372:39: warning: ‘ksz9031_clk_grp’ defined but not
used [-Wunused-variable]
static const struct ksz90x1_reg_field ksz9031_clk_grp[] =
^
scripts/Makefile.build:277: recipe for target 'drivers/net/phy/micrel.o' failed
make[1]: *** [drivers/net/phy/micrel.o] Error 1
Makefile:1201: recipe for target 'drivers/net/phy' failed
make: *** [drivers/net/phy] Error 2
make: *** Waiting for unfinished jobs
Signed-off-by: Mugunthan V N
---
drivers/net/phy/micrel.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 19b6bc7..73ed42a 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -260,7 +260,8 @@ static int ksz90x1_of_config_group(struct phy_device
*phydev,
#define CTRL1000_CONFIG_MASTER (1 << 11)
#define CTRL1000_MANUAL_CONFIG (1 << 12)
-#ifdef CONFIG_DM_ETH
+#if defined(CONFIG_DM_ETH) && (defined(CONFIG_PHY_MICREL_KSZ9021) || \
+ defined(CONFIG_PHY_MICREL_KSZ9031))
static const struct ksz90x1_reg_field ksz9021_clk_grp[] = {
{ "txen-skew-ps", 4, 0, 0x7 }, { "txc-skew-ps", 4, 4, 0x7 },
{ "rxdv-skew-ps", 4, 8, 0x7 }, { "rxc-skew-ps", 4, 12, 0x7 },
@@ -366,7 +367,8 @@ static struct phy_driver ksz9021_driver = {
#define MII_KSZ9031_MMD_ACCES_CTRL 0x0d
#define MII_KSZ9031_MMD_REG_DATA 0x0e
-#ifdef CONFIG_DM_ETH
+#if defined(CONFIG_DM_ETH) && (defined(CONFIG_PHY_MICREL_KSZ9021) || \
+ defined(CONFIG_PHY_MICREL_KSZ9031))
static const struct ksz90x1_reg_field ksz9031_ctl_grp[] =
{ { "txen-skew-ps", 4, 0, 0x7 }, { "rxdv-skew-ps", 4, 4, 0x7 } };
static const struct ksz90x1_reg_field ksz9031_clk_grp[] =
--
2.7.0.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8] defconfig: k2hk_evm_defconfig: enable net driver model
enable net driver model for k2hk evm as keystone_net supports driver model Signed-off-by: Mugunthan V N --- configs/k2hk_evm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/k2hk_evm_defconfig b/configs/k2hk_evm_defconfig index 940d483..f49d820 100644 --- a/configs/k2hk_evm_defconfig +++ b/configs/k2hk_evm_defconfig @@ -13,3 +13,4 @@ CONFIG_DM=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_DM_ETH=y -- 2.7.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8] defconfig: k2l_evm_defconfig: enable net driver model
enable net driver model for k2l evm as keystone_net supports driver model Signed-off-by: Mugunthan V N --- configs/k2l_evm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/k2l_evm_defconfig b/configs/k2l_evm_defconfig index 1b21ed0..6f5ac18 100644 --- a/configs/k2l_evm_defconfig +++ b/configs/k2l_evm_defconfig @@ -13,3 +13,4 @@ CONFIG_DM=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_DM_ETH=y -- 2.7.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8] ARM: dts: k2g: Add keystone net dts files
Add keystone net DT support for k2g evm.
Signed-off-by: Mugunthan V N
---
arch/arm/dts/k2g-evm.dts| 12
arch/arm/dts/k2g-netcp.dtsi | 151
arch/arm/dts/k2g.dtsi | 13
3 files changed, 176 insertions(+)
create mode 100644 arch/arm/dts/k2g-netcp.dtsi
diff --git a/arch/arm/dts/k2g-evm.dts b/arch/arm/dts/k2g-evm.dts
index de50e8f..0ca36ef 100644
--- a/arch/arm/dts/k2g-evm.dts
+++ b/arch/arm/dts/k2g-evm.dts
@@ -19,3 +19,15 @@
stdout-path = &uart0;
};
};
+
+&mdio {
+ status = "okay";
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ phy-mode = "rgmii-id";
+ };
+};
+
+&gbe0 {
+ phy-handle = <ðphy0>;
+};
diff --git a/arch/arm/dts/k2g-netcp.dtsi b/arch/arm/dts/k2g-netcp.dtsi
new file mode 100644
index 000..6f0ff86
--- /dev/null
+++ b/arch/arm/dts/k2g-netcp.dtsi
@@ -0,0 +1,151 @@
+/*
+ * Device Tree Source for Keystone 2 Galileo Netcp driver
+ *
+ * Copyright 2015 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+qmss: qmss@402 {
+ compatible = "ti,keystone-navigator-qmss-l";
+ dma-coherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* power-domains = <&k2g_pds K2G_DEV_NSS0>; */
+ /* clocks = <&k2g_clks K2G_DEV_NSS0 K2G_DEV_NSS_VCLK>; */
+ clock-names = "nss_vclk";
+ ranges;
+ queue-range = <0 0x80>;
+ linkram0= <0x402 0x7ff>;
+
+ qmgrs {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ qmgr0 {
+ managed-queues = <0 0x80>;
+ reg = <0x410 0x800>,
+ <0x404 0x100>,
+ <0x408 0x800>,
+ <0x40c 0x800>;
+ reg-names = "peek", "config",
+ "region", "push";
+ };
+
+ };
+ queue-pools {
+ qpend {
+ qpend-0 {
+ qrange = <77 8>;
+ interrupts =<0 308 0xf04 0 309 0xf04 0 310 0xf04
+0 311 0xf04 0 312 0xf04 0 313 0xf04
+0 314 0xf04 0 315 0xf04>;
+ qalloc-by-id;
+ };
+ };
+ general-purpose {
+ gp-0 {
+ qrange = <112 8>;
+ };
+ netcp-tx {
+ qrange = <5 8>;
+ qalloc-by-id;
+ };
+ };
+ };
+
+ descriptor-regions {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ region-12 {
+ id = <12>;
+ region-spec = <1023 128>; /* num_desc desc_size */
+ link-index = <0x400>;
+ };
+ };
+}; /* qmss */
+
+knav_dmas: knav_dmas@0 {
+ compatible = "ti,keystone-navigator-dma";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* power-domains = <&k2g_pds K2G_DEV_NSS0>; */
+ /* clocks = <&k2g_clks K2G_DEV_NSS0 K2G_DEV_NSS_VCLK>; */
+ clock-names = "nss_vclk";
+ ranges;
+ ti,navigator-cloud-address = <0x40c 0x40c 0x40c 0x40c>;
+
+ dma_gbe: dma_gbe@0 {
+ reg = <0x401 0x100>,
+ <0x4011000 0x2a0>, /* 21 Tx channels */
+ <0x4012000 0x400>, /* 32 Rx channels */
+ <0x4010100 0x80>,
+ <0x4013000 0x400>; /* 32 Rx flows */
+ reg-names = "global", "txchan", "rxchan",
+ "txsched", "rxflow";
+ };
+
+};
+
+gbe_subsys: subsys@420 {
+ compatible = "syscon";
+ reg = <0x420 0x100>;
+};
+
+netcp: netcp@400 {
+ reg = <0x2620110 0x8>;
+ reg-names = "efuse";
+ compatible = "ti,netcp-1.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* power-domains = <&k2g_pds K2G_DEV_NSS0>; */
+ /* clocks = <&k2g_clks K2G_DEV_NSS0 K2G_DEV_NSS_ESW_CLK>; */
+ clock-names = "ethss_clk";
+
+ /* NetCP address range */
+ ranges = <0 0x400 0x100>;
+
+ dma-coherent;
+
+ ti,navigator-dmas = <&dma_gbe 0>, <&dma_gbe 5>;
+ ti,navigator-dma-names = "netrx0", "nettx";
+
+ netcp-devices {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ gbe@20 {
+ label = "netcp-gbe";
+
[U-Boot] [PATCH 3/8] drivers: net: keystone_net: convert driver to adopt device driver model
Adopt keystone_net driver to adopt device driver model
Signed-off-by: Mugunthan V N
---
drivers/net/keystone_net.c | 418 -
1 file changed, 376 insertions(+), 42 deletions(-)
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 209fae9..21ebaeb 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -10,6 +10,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -18,10 +20,15 @@
#include
#include
#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+#ifndef CONFIG_DM_ETH
unsigned int emac_open;
static struct mii_dev *mdio_bus;
static unsigned int sys_has_mdio = 1;
+#endif
#ifdef KEYSTONE2_EMAC_GIG_ENABLE
#define emac_gigabit_enable(x) keystone2_eth_gigabit_enable(x)
@@ -36,40 +43,44 @@ static unsigned int sys_has_mdio = 1;
static u8 rx_buffs[RX_BUFF_NUMS * RX_BUFF_LEN] __aligned(16);
+#ifndef CONFIG_DM_ETH
struct rx_buff_desc net_rx_buffs = {
.buff_ptr = rx_buffs,
.num_buffs = RX_BUFF_NUMS,
.buff_len = RX_BUFF_LEN,
.rx_flow= 22,
};
-
-#ifndef CONFIG_SOC_K2G
-static void keystone2_net_serdes_setup(void);
#endif
-int keystone2_eth_read_mac_addr(struct eth_device *dev)
-{
- struct eth_priv_t *eth_priv;
- u32 maca = 0;
- u32 macb = 0;
-
- eth_priv = (struct eth_priv_t *)dev->priv;
+#ifdef CONFIG_DM_ETH
- /* Read the e-fuse mac address */
- if (eth_priv->slave_port == 1) {
- maca = __raw_readl(MAC_ID_BASE_ADDR);
- macb = __raw_readl(MAC_ID_BASE_ADDR + 4);
- }
-
- dev->enetaddr[0] = (macb >> 8) & 0xff;
- dev->enetaddr[1] = (macb >> 0) & 0xff;
- dev->enetaddr[2] = (maca >> 24) & 0xff;
- dev->enetaddr[3] = (maca >> 16) & 0xff;
- dev->enetaddr[4] = (maca >> 8) & 0xff;
- dev->enetaddr[5] = (maca >> 0) & 0xff;
+enum link_type {
+ LINK_TYPE_MAC_TO_MAC_AUTO = 0,
+ LINK_TYPE_MAC_TO_PHY_MODE = 1,
+ LINK_TYPE_MAC_TO_MAC_FORCED_MODE = 2,
+ LINK_TYPE_MAC_TO_FIBRE_MODE = 3,
+ LINK_TYPE_MAC_TO_PHY_NO_MDIO_MODE = 4,
+ LINK_TYPE_10G_MAC_TO_PHY_MODE = 10,
+ LINK_TYPE_10G_MAC_TO_MAC_FORCED_MODE = 11,
+};
- return 0;
-}
+struct ks2_eth_priv {
+ struct udevice *dev;
+ struct phy_device *phydev;
+ struct mii_dev *mdio_bus;
+ int phy_addr;
+ phy_interface_t phy_if;
+ int sgmii_link_type;
+ void*mdio_base;
+ struct rx_buff_desc net_rx_buffs;
+ struct pktdma_cfg *netcp_pktdma;
+ void*hd;
+ int slave_port;
+ enum link_type link_type;
+ boolemac_open;
+ boolhas_mdio;
+};
+#endif
/* MDIO */
@@ -140,6 +151,7 @@ static int keystone2_mdio_write(struct mii_dev *bus,
return 0;
}
+#ifndef CONFIG_DM_ETH
static void __attribute__((unused))
keystone2_eth_gigabit_enable(struct eth_device *dev)
{
@@ -163,6 +175,31 @@ static void __attribute__((unused))
EMAC_MACCONTROL_GIGFORCE | EMAC_MACCONTROL_GIGABIT_ENABLE,
DEVICE_EMACSL_BASE(eth_priv->slave_port - 1) + CPGMACSL_REG_CTL);
}
+#else
+static void __attribute__((unused))
+ keystone2_eth_gigabit_enable(struct udevice *dev)
+{
+ struct ks2_eth_priv *priv = dev_get_priv(dev);
+ u_int16_t data;
+
+ if (priv->has_mdio) {
+ data = keystone2_mdio_read(priv->mdio_bus, priv->phy_addr,
+ MDIO_DEVAD_NONE, 0);
+ /* speed selection MSB */
+ if (!(data & (1 << 6)))
+ return;
+ }
+
+ /*
+* Check if link detected is giga-bit
+* If Gigabit mode detected, enable gigbit in MAC
+*/
+ writel(readl(DEVICE_EMACSL_BASE(priv->slave_port - 1) +
+CPGMACSL_REG_CTL) |
+ EMAC_MACCONTROL_GIGFORCE | EMAC_MACCONTROL_GIGABIT_ENABLE,
+ DEVICE_EMACSL_BASE(priv->slave_port - 1) + CPGMACSL_REG_CTL);
+}
+#endif
#ifdef CONFIG_SOC_K2G
int keystone_rgmii_config(struct phy_device *phy_dev)
@@ -401,6 +438,58 @@ int ethss_stop(void)
return 0;
}
+struct ks2_serdes ks2_serdes_sgmii_156p25mhz = {
+ .clk = SERDES_CLOCK_156P25M,
+ .rate = SERDES_RATE_5G,
+ .rate_mode = SERDES_QUARTER_RATE,
+ .intf = SERDES_PHY_SGMII,
+ .loopback = 0,
+};
+
+#ifndef CONFIG_SOC_K2G
+static void keystone2_net_serdes_setup(void)
+{
+ ks2_serdes_init(CONFIG_KSNET_SERDES_SGMII_BASE,
+ &ks2_serdes_sgmii_156p25mhz,
+ CONFIG_KSNET_SERDES_LANES_PER_SGMII);
+
+#if defined(CONFIG_SOC_K2E
[U-Boot] [PATCH 6/8] defconfig: k2e_evm_defconfig: enable net driver model
enable net driver model for k2e evm as keystone_net supports driver model Signed-off-by: Mugunthan V N --- configs/k2e_evm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig index 9fb9dac..5616be9 100644 --- a/configs/k2e_evm_defconfig +++ b/configs/k2e_evm_defconfig @@ -13,3 +13,4 @@ CONFIG_DM=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_DM_ETH=y -- 2.7.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] defconfig: k2g_evm_defconfig: enable net driver model
enable net driver model for k2g evm as keystone_net supports driver model Signed-off-by: Mugunthan V N --- configs/k2g_evm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig index 7bdf7a4..7cebacd 100644 --- a/configs/k2g_evm_defconfig +++ b/configs/k2g_evm_defconfig @@ -12,3 +12,4 @@ CONFIG_DM=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_DM_ETH=y -- 2.7.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] common/console.c: Remove unused inline functions
clang-3.8 reports that these functions are unused, remove them.
Signed-off-by: Tom Rini
---
common/console.c | 48
1 file changed, 48 deletions(-)
diff --git a/common/console.c b/common/console.c
index bc37b6d..b3f5fdc 100644
--- a/common/console.c
+++ b/common/console.c
@@ -227,11 +227,6 @@ static void console_puts(int file, const char *s)
}
}
-static inline void console_printdevs(int file)
-{
- iomux_printdevs(file);
-}
-
static inline void console_doenv(int file, struct stdio_dev *dev)
{
iomux_doenv(file, dev->name);
@@ -265,11 +260,6 @@ static inline void console_puts(int file, const char *s)
stdio_devices[file]->puts(stdio_devices[file], s);
}
-static inline void console_printdevs(int file)
-{
- printf("%s\n", stdio_devices[file]->name);
-}
-
static inline void console_doenv(int file, struct stdio_dev *dev)
{
console_setfile(file, dev);
@@ -653,44 +643,6 @@ void clear_ctrlc(void)
ctrlc_was_pressed = 0;
}
-#ifdef CONFIG_MODEM_SUPPORT_DEBUG
-char screen[1024];
-char *cursor = screen;
-int once = 0;
-inline void dbg(const char *fmt, ...)
-{
- va_list args;
- uinti;
- charprintbuffer[CONFIG_SYS_PBSIZE];
-
- if (!once) {
- memset(screen, 0, sizeof(screen));
- once++;
- }
-
- va_start(args, fmt);
-
- /* For this to work, printbuffer must be larger than
-* anything we ever want to print.
-*/
- i = vsnprintf(printbuffer, sizeof(printbuffer), fmt, args);
- va_end(args);
-
- if ((screen + sizeof(screen) - 1 - cursor)
- < strlen(printbuffer) + 1) {
- memset(screen, 0, sizeof(screen));
- cursor = screen;
- }
- sprintf(cursor, printbuffer);
- cursor += strlen(printbuffer);
-
-}
-#else
-static inline void dbg(const char *fmt, ...)
-{
-}
-#endif
-
/** U-Boot INIT FUNCTIONS */
struct stdio_dev *search_device(int flags, const char *name)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] serial: Remove serial_putc_raw_dev
clang-3.8 reports that serial_putc_raw_dev in serial_ns16550.c is
unused. Further investigation shows that we have 3 places that
implement this function and no callers, remove.
Signed-off-by: Tom Rini
---
arch/powerpc/cpu/mpc512x/serial.c | 12
arch/powerpc/cpu/mpc5xxx/serial.c | 11 ---
drivers/serial/serial_ns16550.c | 11 ---
3 files changed, 34 deletions(-)
diff --git a/arch/powerpc/cpu/mpc512x/serial.c
b/arch/powerpc/cpu/mpc512x/serial.c
index 4105a28..ac77ddc 100644
--- a/arch/powerpc/cpu/mpc512x/serial.c
+++ b/arch/powerpc/cpu/mpc512x/serial.c
@@ -203,18 +203,6 @@ void serial_putc_dev(unsigned int idx, const char c)
out_8(&psc->tfdata_8, c);
}
-void serial_putc_raw_dev(unsigned int idx, const char c)
-{
- volatile immap_t *im = (immap_t *) CONFIG_SYS_IMMR;
- volatile psc512x_t *psc = (psc512x_t *) &im->psc[idx];
-
- /* Wait for last character to go. */
- while (!(in_be16(&psc->psc_status) & PSC_SR_TXEMP))
- ;
-
- out_8(&psc->tfdata_8, c);
-}
-
void serial_puts_dev(unsigned int idx, const char *s)
{
while (*s)
diff --git a/arch/powerpc/cpu/mpc5xxx/serial.c
b/arch/powerpc/cpu/mpc5xxx/serial.c
index cb5b0bf..bccdcf7 100644
--- a/arch/powerpc/cpu/mpc5xxx/serial.c
+++ b/arch/powerpc/cpu/mpc5xxx/serial.c
@@ -112,17 +112,6 @@ void serial_putc_dev (unsigned long dev_base, const char c)
psc->psc_buffer_8 = c;
}
-void serial_putc_raw_dev(unsigned long dev_base, const char c)
-{
- volatile struct mpc5xxx_psc *psc = (struct mpc5xxx_psc *)dev_base;
- /* Wait for last character to go. */
- while (!(psc->psc_status & PSC_SR_TXEMP))
- ;
-
- psc->psc_buffer_8 = c;
-}
-
-
void serial_puts_dev (unsigned long dev_base, const char *s)
{
while (*s) {
diff --git a/drivers/serial/serial_ns16550.c b/drivers/serial/serial_ns16550.c
index 799ef6a..fcb1e95 100644
--- a/drivers/serial/serial_ns16550.c
+++ b/drivers/serial/serial_ns16550.c
@@ -127,11 +127,6 @@ static void _serial_putc(const char c, const int port)
NS16550_putc(PORT, c);
}
-static void _serial_putc_raw(const char c, const int port)
-{
- NS16550_putc(PORT, c);
-}
-
static void _serial_puts(const char *s, const int port)
{
while (*s) {
@@ -165,12 +160,6 @@ serial_putc_dev(unsigned int dev_index,const char c)
}
static inline void
-serial_putc_raw_dev(unsigned int dev_index,const char c)
-{
- _serial_putc_raw(c,dev_index);
-}
-
-static inline void
serial_puts_dev(unsigned int dev_index,const char *s)
{
_serial_puts(s,dev_index);
--
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 2/3] ARMv8/layerscape: Add FSL PPA support
Hi Prabhakar, Thanks for your feedback! > -Original Message- > From: Prabhakar Kushwaha > Sent: 2016年1月19日 22:07 > To: Zhiqiang Hou ; u-boot@lists.denx.de; > albert.u.b...@aribaud.net; mingkai...@freescale.com; york...@freescale.com > Cc: le...@freescale.com; prabha...@freescale.com; > bhupesh.sha...@freescale.com; s...@chromium.org; bmeng...@gmail.com; > h...@denx.de; joe.hershber...@ni.com; ma...@denx.de; Zhiqiang Hou > ; Hou Zhiqiang > Subject: RE: [PATCH 2/3] ARMv8/layerscape: Add FSL PPA support > > > -Original Message- > > From: Zhiqiang Hou [mailto:zhiqiang@freescale.com] > > Sent: Tuesday, January 19, 2016 6:10 PM > > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; > > mingkai...@freescale.com; york...@freescale.com > > Cc: le...@freescale.com; prabha...@freescale.com; > > bhupesh.sha...@freescale.com; s...@chromium.org; bmeng...@gmail.com; > > h...@denx.de; joe.hershber...@ni.com; ma...@denx.de; Zhiqiang Hou > > ; Hou Zhiqiang > > Subject: [PATCH 2/3] ARMv8/layerscape: Add FSL PPA support > > > > From: Hou Zhiqiang > > > > The FSL Primary Protected Application (PPA) is a software component > > loaded during boot which runs in TrustZone and remains resident after boot. > > > > Signed-off-by: Hou Zhiqiang > > --- > > arch/arm/cpu/armv8/fsl-layerscape/Makefile | 1 + > > arch/arm/cpu/armv8/fsl-layerscape/ppa.c| 196 > > + > > arch/arm/cpu/armv8/fsl-layerscape/ppa_entry.S | 37 + > > arch/arm/include/asm/arch-fsl-layerscape/ppa.h | 15 ++ > > 4 files changed, 249 insertions(+) > > create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ppa.c > > create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ppa_entry.S > > create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/ppa.h > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile > > b/arch/arm/cpu/armv8/fsl-layerscape/Makefile > > index cce7405..27bfeb1 100644 > > --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile > > @@ -10,6 +10,7 @@ obj-y += soc.o > > obj-$(CONFIG_MP) += mp.o > > obj-$(CONFIG_OF_LIBFDT) += fdt.o > > obj-$(CONFIG_SPL) += spl.o > > +obj-$(CONFIG_FSL_LS_PPA) += ppa.o ppa_entry.o > > > > ifneq ($(CONFIG_FSL_LSCH3),) > > obj-y += fsl_lsch3_speed.o > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c > > b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c > > new file mode 100644 > > index 000..15e4f8b > > --- /dev/null > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c > > @@ -0,0 +1,196 @@ > > +/* > > + * Copyright 2015 Freescale Semiconductor, Inc. > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +DECLARE_GLOBAL_DATA_PTR; > > + > > +extern void c_runtime_cpu_setup(void); > > + > > +#define LS_PPA_FIT_FIRMWARE_IMAGE "firmware" > > +#define LS_PPA_FIT_CNF_NAME"config@1" > > +#define PPA_MEM_SIZE_ENV_VAR "ppamemsize" > > + > > +/* > > > > > > +#include > > +#include > > +#include > > +#include > > + > > +ADDR_BASE_SCFG: > > +.long 0x0157 > > If I am correct it is address of BOOLPTR. This address looks to be specific to > LS1043. > For other SoC it may change > Yes, I will make it a common interface for ARMv8 Layerscape platform in next version. > > > + > > +ENTRY(ppa_init) > > +/* Save stack pointer for EL2 */ > > +mov x1, sp > > +msr sp_el2, x1 > > + > > +/* Set boot loc pointer */ > > +adr x4, 1f > > +adr x1, ADDR_BASE_SCFG > > +ldr w2, [x1] > > +mov x1, x4 > > +rev w3, w1 > > +str w3, [x2, #0x604] > > It is LS1043 specific > > > > +lsr x1, x4, #32 > > +rev w3, w1 > > +str w3, [x2, #0x600] > Same as above > Thanks, Zhiqiang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ls2085a: Correct the model & board name of RDB and QDS
* LS2085ARDB and LS2085AQDS host LS2080A and LS2085A,
So update model and board name.
Signed-off-by: Ashish Kumar
---
arch/arm/dts/fsl-ls2080a-qds.dts|2 +-
arch/arm/dts/fsl-ls2080a-rdb.dts|2 +-
board/freescale/ls2080aqds/ls2080aqds.c |3 +--
board/freescale/ls2080ardb/ls2080ardb.c |4 +---
4 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/fsl-ls2080a-qds.dts b/arch/arm/dts/fsl-ls2080a-qds.dts
index 547ec27..7b1dae8 100644
--- a/arch/arm/dts/fsl-ls2080a-qds.dts
+++ b/arch/arm/dts/fsl-ls2080a-qds.dts
@@ -11,7 +11,7 @@
#include "fsl-ls2080a.dtsi"
/ {
- model = "Freescale Layerscape 2080a QDS Board";
+ model = "Freescale Layerscape 2085a QDS Board";
compatible = "fsl,ls2080a-qds", "fsl,ls2080a";
aliases {
diff --git a/arch/arm/dts/fsl-ls2080a-rdb.dts b/arch/arm/dts/fsl-ls2080a-rdb.dts
index 1a1813b..71d1969 100644
--- a/arch/arm/dts/fsl-ls2080a-rdb.dts
+++ b/arch/arm/dts/fsl-ls2080a-rdb.dts
@@ -11,7 +11,7 @@
#include "fsl-ls2080a.dtsi"
/ {
- model = "Freescale Layerscape 2080a RDB Board";
+ model = "Freescale Layerscape 2085a RDB Board";
compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";
aliases {
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
b/board/freescale/ls2080aqds/ls2080aqds.c
index aa256a2..fe20f3a 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -61,8 +61,7 @@ int checkboard(void)
"100 separate SSCG"};
int clock;
- cpu_name(buf);
- printf("Board: %s-QDS, ", buf);
+ printf("Board: LS2085A-QDS, ");
sw = QIXIS_READ(arch);
printf("Board Arch: V%d, ", sw >> 4);
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
b/board/freescale/ls2080ardb/ls2080ardb.c
index c63b639..ccf98c9 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -54,10 +54,8 @@ unsigned long long get_qixis_addr(void)
int checkboard(void)
{
u8 sw;
- char buf[15];
- cpu_name(buf);
- printf("Board: %s-RDB, ", buf);
+ printf("Board: LS2085A-RDB, ");
sw = QIXIS_READ(arch);
printf("Board Arch: V%d, ", sw >> 4);
--
1.7.6.GIT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARMv8/layerscape: Add mmu_init API
Hi Prabhakar,
Thanks for your feedback!
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: 2016年1月19日 21:54
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; mingkai...@freescale.com; york...@freescale.com
> Cc: le...@freescale.com; prabha...@freescale.com;
> bhupesh.sha...@freescale.com; s...@chromium.org; bmeng...@gmail.com;
> h...@denx.de; joe.hershber...@ni.com; ma...@denx.de; Zhiqiang Hou
> ; Hou Zhiqiang
> Subject: RE: [PATCH 1/3] ARMv8/layerscape: Add mmu_init API
>
> > -Original Message-
> > From: Zhiqiang Hou [mailto:zhiqiang@freescale.com]
> > Sent: Tuesday, January 19, 2016 6:10 PM
> > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net;
> > mingkai...@freescale.com; york...@freescale.com
> > Cc: le...@freescale.com; prabha...@freescale.com;
> > bhupesh.sha...@freescale.com; s...@chromium.org; bmeng...@gmail.com;
> > h...@denx.de; joe.hershber...@ni.com; ma...@denx.de; Zhiqiang Hou
> > ; Hou Zhiqiang
> > Subject: [PATCH 1/3] ARMv8/layerscape: Add mmu_init API
> >
> > From: Hou Zhiqiang
> >
> > Expose this API to make it reuseable when u-boot turn into other EL
> > from EL3.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 24
> >
> > include/common.h| 1 +
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > index 6ea28ed..df5670f 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > @@ -403,6 +403,30 @@ void enable_caches(void)
> > final_mmu_setup();
> > __asm_invalidate_tlb_all();
> > }
> > +
> > +static void mmu_disable(void)
> > +{
> > + if (get_sctlr() & CR_M)
> > + set_sctlr(get_sctlr() & ~CR_M);
> > +}
> > +
> > +static void mmu_enable(void)
> > +{
> > + if (!(get_sctlr() & CR_M))
> > + set_sctlr(get_sctlr() | CR_M);
> > +}
> > +
> > +void mmu_init(void)
>
> Name of function is not mapping about what it is doing.
> This function assume MMU is already enabled with early_table and it will setup
> final_mmu_setup.
>
This function map basically with what it is doing except some I-cache operations
that will be remove from this func, and not assume the early_mmu_setup.
It assumes the relocation has been done.
> > +{
> > + mmu_disable();
> > + dcache_disable();
> > + icache_disable();
> > + final_mmu_setup();
> > + __asm_invalidate_tlb_all();
> > + mmu_enable();
> > + icache_enable();
> > + set_sctlr(get_sctlr() | CR_C);
> > +}
> > #endif
>
> If I am correct board_init_r deploy final_mmu_setup via enable_caches().
> Why cannot existing framework be used.
>
This patch aims to make final_mmu_setup() can be called flexibly in case as
When it return from PPA and execute at EL2, the MMU must be initialized
for the current EL.
Yes, the enable_caches() will call the __weak__ mmu_setup() if MMU wasn't
enabled. But for fsl layerscape platforms, the MMU has been enabled by early
mmu setup, so the __weak__ mmu_setup won't be called.
I am not know cache and mmu so much, and have some question:
For ARM:
Why there isn't a isolate API for mmu_setup, but invoke it from dcache_enable()?
If data cache won't be used, the MMU also cannot be used?
> >
> > static inline u32 initiator_type(u32 cluster, int init_id) diff --git
> > a/include/common.h b/include/common.h index 75c78d5..57a9b30 100644
> > --- a/include/common.h
> > +++ b/include/common.h
> > @@ -757,6 +757,7 @@ voidflush_dcache_range(unsigned long start,
> > unsigned long stop);
> > void invalidate_dcache_range(unsigned long start, unsigned long
> > stop);
> > void invalidate_dcache_all(void);
> > void invalidate_icache_all(void);
> > +void mmu_init(void);
> >
> > enum {
> > /* Disable caches (else flush caches but leave them active) */
> > --
> > 2.1.0.27.g96db324
Thanks,
Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
These patches depend on the series patches(http://patchwork.ozlabs.org/patch/567250/). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] armv8/ls1043aqds: Spilt off board device tree
Move new /chosen node out of the board device tree.
Signed-off-by: Wenbin Song
---
arch/arm/dts/Makefile | 2 +-
arch/arm/dts/fsl-ls1043a-qds-duart.dts | 20 ++
arch/arm/dts/fsl-ls1043a-qds.dts | 124 -
arch/arm/dts/fsl-ls1043a-qds.dtsi | 123
configs/ls1043aqds_defconfig | 2 +-
5 files changed, 145 insertions(+), 126 deletions(-)
create mode 100644 arch/arm/dts/fsl-ls1043a-qds-duart.dts
delete mode 100644 arch/arm/dts/fsl-ls1043a-qds.dts
create mode 100644 arch/arm/dts/fsl-ls1043a-qds.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7706b41..302456c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -96,7 +96,7 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \
ls1021a-twr-duart.dtb ls1021a-twr-lpuart.dtb
dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb
-dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds.dtb \
+dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-rdb.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
diff --git a/arch/arm/dts/fsl-ls1043a-qds-duart.dts
b/arch/arm/dts/fsl-ls1043a-qds-duart.dts
new file mode 100644
index 000..2715b3d
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1043a-qds-duart.dts
@@ -0,0 +1,20 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright (C) 2015, Freescale Semiconductor
+ *
+ * Wenbin Song
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "fsl-ls1043a-qds.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &duart0;
+ };
+};
diff --git a/arch/arm/dts/fsl-ls1043a-qds.dts b/arch/arm/dts/fsl-ls1043a-qds.dts
deleted file mode 100644
index 7435222..000
--- a/arch/arm/dts/fsl-ls1043a-qds.dts
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- * Device Tree Include file for Freescale Layerscape-1043A family SoC.
- *
- * Copyright (C) 2015, Freescale Semiconductor
- *
- * Mingkai Hu
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-/dts-v1/;
-/include/ "fsl-ls1043a.dtsi"
-
-/ {
- model = "LS1043A QDS Board";
-};
-
-&i2c0 {
- status = "okay";
- pca9547@77 {
- compatible = "philips,pca9547";
- reg = <0x77>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- i2c@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0>;
-
- rtc@68 {
- compatible = "dallas,ds3232";
- reg = <0x68>;
- /* IRQ10_B */
- interrupts = <0 150 0x4>;
- };
- };
-
- i2c@2 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x2>;
-
- ina220@40 {
- compatible = "ti,ina220";
- reg = <0x40>;
- shunt-resistor = <1000>;
- };
-
- ina220@41 {
- compatible = "ti,ina220";
- reg = <0x41>;
- shunt-resistor = <1000>;
- };
- };
-
- i2c@3 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x3>;
-
- eeprom@56 {
- compatible = "at24,24c512";
- reg = <0x56>;
- };
-
- eeprom@57 {
- compatible = "at24,24c512";
- reg = <0x57>;
- };
-
- adt7461a@4c {
- compatible = "adt7461a";
- reg = <0x4c>;
- };
- };
- };
-};
-
-&ifc {
- #address-cells = <2>;
- #size-cells = <1>;
- /* NOR, NAND Flashes and FPGA on board */
- ranges = <0x0 0x0 0x0 0x6000 0x0800
- 0x2 0x0 0x0 0x7e80 0x0001
- 0x3 0x0 0x0 0x7fb0 0x0100>;
- status = "okay";
-
- nor@0,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "cfi-flash";
- reg = <0x0 0x0 0x800>;
- bank-width = <2>;
- device-width = <1>;
- };
-
- nand@2,0 {
[U-Boot] [PATCH v2 1/3] armv8/ls1043aqds: Select lpuart pins of various muxes
From: Shaohui Xie
Set Board Configuration Register to select the lpuart pins of various
muxes.
Signed-off-by: Shaohui Xie
Signed-off-by: Mingkai Hu
---
board/freescale/ls1043aqds/ls1043aqds.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
b/board/freescale/ls1043aqds/ls1043aqds.c
index d6696ca..4e38cb0 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -40,6 +40,9 @@ enum {
#define CFG_SD_MUX3_MUX4 0x1 /* MUX4 */
#define CFG_SD_MUX4_SLOT3 0x0 /* SLOT3 TX/RX1 */
#define CFG_SD_MUX4_SLOT1 0x1 /* SLOT1 TX/RX3 */
+#define CFG_UART_MUX_MASK 0x6
+#define CFG_UART_MUX_SHIFT 1
+#define CFG_LPUART_EN 0x1
int checkboard(void)
{
@@ -218,7 +221,19 @@ void board_retimer_init(void)
int board_early_init_f(void)
{
+#ifdef CONFIG_LPUART
+ u8 uart;
+#endif
fsl_lsch2_early_init_f();
+#ifdef CONFIG_LPUART
+ /*
+* we use lpuart1 as system console.
+*/
+ uart = QIXIS_READ(brdcfg[14]);
+ uart &= ~CFG_UART_MUX_MASK;
+ uart |= CFG_LPUART_EN << CFG_UART_MUX_SHIFT;
+ QIXIS_WRITE(brdcfg[14], uart);
+#endif
return 0;
}
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] armv8/ls1043aqds: Add lpuart support
Add lpuart support using the driver model.
Signed-off-by: Wenbin Song
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/fsl-ls1043a-qds-lpuart.dts | 20
arch/arm/dts/fsl-ls1043a.dtsi | 54 +
configs/ls1043aqds_lpuart_defconfig | 10 ++
include/configs/ls1043aqds.h| 7 +
5 files changed, 92 insertions(+)
create mode 100644 arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
create mode 100644 configs/ls1043aqds_lpuart_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 302456c..a51275c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -97,6 +97,7 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \
dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb
dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
+ fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
diff --git a/arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
b/arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
new file mode 100644
index 000..24168ad
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
@@ -0,0 +1,20 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright (C) 2015, Freescale Semiconductor
+ *
+ * Wenbin Song
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "fsl-ls1043a-qds.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &lpuart0;
+ };
+};
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index 85ea81e..12ea0ab 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -182,5 +182,59 @@
interrupts = <0 55 0x4>;
clocks = <&clockgen 4 0>;
};
+
+ lpuart0: serial@295 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x295 0x0 0x1000>;
+ interrupts = <0 48 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart1: serial@296 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x296 0x0 0x1000>;
+ interrupts = <0 49 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart2: serial@297 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x297 0x0 0x1000>;
+ interrupts = <0 50 0x4>;
+ clock-names = "ipg";
+ clocks = <&sysclk>;
+ status = "disabled";
+ };
+
+ lpuart3: serial@298 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x298 0x0 0x1000>;
+ interrupts = <0 51 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart4: serial@299 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x299 0x0 0x1000>;
+ interrupts = <0 52 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart5: serial@29a {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x29a 0x0 0x1000>;
+ interrupts = <0 53 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
};
};
diff --git a/configs/ls1043aqds_lpuart_defconfig
b/configs/ls1043aqds_lpuart_defconfig
new file mode 100644
index 000..2d6bb7b
--- /dev/null
+++ b/configs/ls1043aqds_lpuart_defconfig
@@ -0,0 +1,10 @@
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,LPUART"
+CONFIG_ARM=y
+CONFIG_TARGET_LS1043AQDS=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-qds-lpuart"
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_DM_SPI=y
+CONFIG_FSL_LPUART=y
+CONFIG_DM_SERIAL=y
diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h
index 398f1c3..438476f 100644
--- a/include/configs/ls1043aqds.h
+++ b/include/configs/ls1043aqds.h
@@ -88,6 +88,13 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_SYS_FSL_PBL_RCW
board/freescale/ls1043aqds/ls1043aqds_rcw_sd_ifc.cfg
#endif
+/*
+ * LPUART
+ */
+#ifdef CONFIG_LPUART
+#define CON
Re: [U-Boot] [PATCH v2 1/3] armv8/ls1043aqds: Select lpuart pins of various muxes
Hi: all,
This patch depends on the series
patches(http://patchwork.ozlabs.org/patch/567250/).
Regards
Wenbin Song
-Original Message-
From: Wenbin Song [mailto:wenbin.s...@nxp.com]
Sent: Wednesday, January 20, 2016 8:26 PM
To: york...@freescale.com; Mingkai Hu ; Qianyu Gong
; Shaohui Xie ; Wenbin Song
; u-boot@lists.denx.de; bmeng...@gmail.com
Cc: Shaohui Xie ; Mingkai Hu
Subject: [PATCH v2 1/3] armv8/ls1043aqds: Select lpuart pins of various muxes
From: Shaohui Xie
Set Board Configuration Register to select the lpuart pins of various muxes.
Signed-off-by: Shaohui Xie
Signed-off-by: Mingkai Hu
---
board/freescale/ls1043aqds/ls1043aqds.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
b/board/freescale/ls1043aqds/ls1043aqds.c
index d6696ca..4e38cb0 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -40,6 +40,9 @@ enum {
#define CFG_SD_MUX3_MUX4 0x1 /* MUX4 */
#define CFG_SD_MUX4_SLOT3 0x0 /* SLOT3 TX/RX1 */
#define CFG_SD_MUX4_SLOT1 0x1 /* SLOT1 TX/RX3 */
+#define CFG_UART_MUX_MASK 0x6
+#define CFG_UART_MUX_SHIFT 1
+#define CFG_LPUART_EN 0x1
int checkboard(void)
{
@@ -218,7 +221,19 @@ void board_retimer_init(void)
int board_early_init_f(void)
{
+#ifdef CONFIG_LPUART
+ u8 uart;
+#endif
fsl_lsch2_early_init_f();
+#ifdef CONFIG_LPUART
+ /*
+* we use lpuart1 as system console.
+*/
+ uart = QIXIS_READ(brdcfg[14]);
+ uart &= ~CFG_UART_MUX_MASK;
+ uart |= CFG_LPUART_EN << CFG_UART_MUX_SHIFT;
+ QIXIS_WRITE(brdcfg[14], uart);
+#endif
return 0;
}
--
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 v2 3/3] armv8/ls1043aqds: Add lpuart support
Hi: all,
This patch depends on the series
patches(http://patchwork.ozlabs.org/patch/567250/).
Regards
Wenbin Song
-Original Message-
From: Wenbin Song [mailto:wenbin.s...@nxp.com]
Sent: Wednesday, January 20, 2016 8:26 PM
To: york...@freescale.com; Mingkai Hu ; Qianyu Gong
; Shaohui Xie ; Wenbin Song
; u-boot@lists.denx.de; bmeng...@gmail.com
Subject: [PATCH v2 3/3] armv8/ls1043aqds: Add lpuart support
Add lpuart support using the driver model.
Signed-off-by: Wenbin Song
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/fsl-ls1043a-qds-lpuart.dts | 20
arch/arm/dts/fsl-ls1043a.dtsi | 54 +
configs/ls1043aqds_lpuart_defconfig | 10 ++
include/configs/ls1043aqds.h| 7 +
5 files changed, 92 insertions(+)
create mode 100644 arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
create mode 100644 configs/ls1043aqds_lpuart_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
302456c..a51275c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -97,6 +97,7 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \
dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb
dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
+ fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
diff --git a/arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
b/arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
new file mode 100644
index 000..24168ad
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1043a-qds-lpuart.dts
@@ -0,0 +1,20 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright (C) 2015, Freescale Semiconductor
+ *
+ * Wenbin Song
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "fsl-ls1043a-qds.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &lpuart0;
+ };
+};
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index 85ea81e..12ea0ab 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -182,5 +182,59 @@
interrupts = <0 55 0x4>;
clocks = <&clockgen 4 0>;
};
+
+ lpuart0: serial@295 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x295 0x0 0x1000>;
+ interrupts = <0 48 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart1: serial@296 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x296 0x0 0x1000>;
+ interrupts = <0 49 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart2: serial@297 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x297 0x0 0x1000>;
+ interrupts = <0 50 0x4>;
+ clock-names = "ipg";
+ clocks = <&sysclk>;
+ status = "disabled";
+ };
+
+ lpuart3: serial@298 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x298 0x0 0x1000>;
+ interrupts = <0 51 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart4: serial@299 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x299 0x0 0x1000>;
+ interrupts = <0 52 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart5: serial@29a {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x29a 0x0 0x1000>;
+ interrupts = <0 53 0x4>;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
};
};
diff --git a/configs/ls1043aqds_lpuart_defconfig
b/configs/ls1043aqds_lpuart_defconfig
new file mode 100644
index 000..2d6bb7b
--- /dev/null
+++ b/configs/ls1043aqds_lpuart_defconfig
@@ -0,0 +1,10 @@
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,LPUART"
+CONFIG_ARM=y
+CONFIG_TARGET_LS1043AQDS=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-qds-lpuart"
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_DM_SP
Re: [U-Boot] [PATCH v2 2/3] armv8/ls1043aqds: Spilt off board device tree
Hi: all,
This patch depends on the series
patches(http://patchwork.ozlabs.org/patch/567250/).
Regards
Wenbin Song
-Original Message-
From: Wenbin Song [mailto:wenbin.s...@nxp.com]
Sent: Wednesday, January 20, 2016 8:26 PM
To: york...@freescale.com; Mingkai Hu ; Qianyu Gong
; Shaohui Xie ; Wenbin Song
; u-boot@lists.denx.de; bmeng...@gmail.com
Subject: [PATCH v2 2/3] armv8/ls1043aqds: Spilt off board device tree
Move new /chosen node out of the board device tree.
Signed-off-by: Wenbin Song
---
arch/arm/dts/Makefile | 2 +-
arch/arm/dts/fsl-ls1043a-qds-duart.dts | 20 ++
arch/arm/dts/fsl-ls1043a-qds.dts | 124 -
arch/arm/dts/fsl-ls1043a-qds.dtsi | 123
configs/ls1043aqds_defconfig | 2 +-
5 files changed, 145 insertions(+), 126 deletions(-) create mode 100644
arch/arm/dts/fsl-ls1043a-qds-duart.dts
delete mode 100644 arch/arm/dts/fsl-ls1043a-qds.dts create mode 100644
arch/arm/dts/fsl-ls1043a-qds.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
7706b41..302456c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -96,7 +96,7 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \
ls1021a-twr-duart.dtb ls1021a-twr-lpuart.dtb
dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb
-dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds.dtb \
+dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-rdb.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
diff --git a/arch/arm/dts/fsl-ls1043a-qds-duart.dts
b/arch/arm/dts/fsl-ls1043a-qds-duart.dts
new file mode 100644
index 000..2715b3d
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1043a-qds-duart.dts
@@ -0,0 +1,20 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright (C) 2015, Freescale Semiconductor
+ *
+ * Wenbin Song
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "fsl-ls1043a-qds.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &duart0;
+ };
+};
diff --git a/arch/arm/dts/fsl-ls1043a-qds.dts b/arch/arm/dts/fsl-ls1043a-qds.dts
deleted file mode 100644
index 7435222..000
--- a/arch/arm/dts/fsl-ls1043a-qds.dts
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- * Device Tree Include file for Freescale Layerscape-1043A family SoC.
- *
- * Copyright (C) 2015, Freescale Semiconductor
- *
- * Mingkai Hu
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-/dts-v1/;
-/include/ "fsl-ls1043a.dtsi"
-
-/ {
- model = "LS1043A QDS Board";
-};
-
-&i2c0 {
- status = "okay";
- pca9547@77 {
- compatible = "philips,pca9547";
- reg = <0x77>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- i2c@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0>;
-
- rtc@68 {
- compatible = "dallas,ds3232";
- reg = <0x68>;
- /* IRQ10_B */
- interrupts = <0 150 0x4>;
- };
- };
-
- i2c@2 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x2>;
-
- ina220@40 {
- compatible = "ti,ina220";
- reg = <0x40>;
- shunt-resistor = <1000>;
- };
-
- ina220@41 {
- compatible = "ti,ina220";
- reg = <0x41>;
- shunt-resistor = <1000>;
- };
- };
-
- i2c@3 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x3>;
-
- eeprom@56 {
- compatible = "at24,24c512";
- reg = <0x56>;
- };
-
- eeprom@57 {
- compatible = "at24,24c512";
- reg = <0x57>;
- };
-
- adt7461a@4c {
- compatible = "adt7461a";
- reg = <0x4c>;
- };
- };
- };
-};
-
-&ifc {
- #address-cells = <2>;
- #size-cells = <1>;
- /* NOR, NAND Flashes and FPGA on board */
- ranges = <0x0 0x0
Re: [U-Boot] [PATCH v5 2/2] usb: eth: add Realtek RTL8152B/RTL8153 DRIVER
On Wednesday, January 20, 2016 at 07:24:52 AM, Ted Chen wrote: > This patch adds driver support for the Realtek RTL8152B/RTL8153 USB > network adapters. > > Signed-off-by: Ted Chen > [swarren, fixed a few compiler warnings] > [swarren, with permission, converted license header to SPDX] > [swarren, removed printf() spew during probe()] > Signed-off-by: Stephen Warren Looks good, Acked-by: Marek Vasut Let's see if others have any comments and I can pick it then. [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Microblaze changes
Hi Ricardo, are you on track on this? Thanks, Michal On 15.1.2016 08:08, Michal Simek wrote: > Hi, > > On 14.1.2016 21:24, Ricardo Ribalda Delgado wrote: >> Hello Michal >> >> I will give a look to it during the next week. Hopefuly by the end of >> it I can give you the patch or an educated estimated. Is this a good >> timeline for you? > > ok. Let's wait one more week and I hope you will have SPL up and running. > > Thanks, > Michal > -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Microblaze changes
I have allocated the whole Friday for this On Wed, Jan 20, 2016 at 2:23 PM, Michal Simek wrote: > Hi Ricardo, > > are you on track on this? > > Thanks, > Michal > > On 15.1.2016 08:08, Michal Simek wrote: >> Hi, >> >> On 14.1.2016 21:24, Ricardo Ribalda Delgado wrote: >>> Hello Michal >>> >>> I will give a look to it during the next week. Hopefuly by the end of >>> it I can give you the patch or an educated estimated. Is this a good >>> timeline for you? >> >> ok. Let's wait one more week and I hope you will have SPL up and running. >> >> Thanks, >> Michal >> > > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ > Maintainer of Linux kernel - Xilinx Zynq ARM architecture > Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform > > -- Ricardo Ribalda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4
Dear Pavel, In message <20160120101901.GA9656@amd> you wrote: > > Commit 8e535af2e441030f5e4b940a3756a0d92646b5fe breaks compilation > (previous one worked ok in my config). Maybe it would help if, for this bisecting, you used the default config? Once the problem is isolated, you can switch back to your custom config. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." - George Bernard Shaw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Tue, Jan 19, 2016 at 10:35 PM, Simon Glass wrote: > Hi, > > On 18 January 2016 at 23:46, Craig McQueen > wrote: >>> Tom Rini wrote: >>> >>> On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: >>> > Hi Craig, >>> > >>> > On 20 December 2015 at 19:07, Craig McQueen >>> > wrote: >>> > > This is to avoid the boot sequence halting due to initial "junk" >>> > > received on serial input. >>> > > >>> > > Signed-off-by: Craig McQueen >>> > > --- >>> > > I have found that on the BeagleBone Black, U-Boot occasionally halts >>> > > at the U-Boot prompt at boot-up, whether power-up, warm external >>> > > reset or software reset. I have seen other people report the same issue. >>> > > >>> > > This seems to be due to U-Boot receiving "junk" data on the serial >>> > > console. The BeagleBone Black has a pull-down resistor which was >>> > > apparently added to try to mitigate this issue, but it doesn't >>> > > entirely fix it. >>> > >>> > I wonder if this can be fixed for that board only? >>> >>> No, and it's not -exactly- a that board only problem. It's a HW design >>> issue >>> that can show up elsewhere too. I _think_ however in this case the answer >>> would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as that's >>> one of the reason various other boards use that set of options. >>> >>> I would suggest bringing this up on the beaglebone list to see what the >>> various people that ship and support these boards think, thanks! >> >> Other options such as CONFIG_AUTOBOOT_KEYED_CTRLC sound like a work-around >> of the problem, rather than a fix of the root-cause. But maybe that's just >> my opinion. Simon Glass' suggestion (clear out the UART input buffer when >> the driver is probed) sounded reasonable, but I haven't tried it. > > Since it seems like a hardware bug, we can only have a workaround. A > real fix would involve fixing the root cause, i.e. fixing the > hardware. > >> >> I think BeagleBone Black definitely needs _some_ sort of fix -- currently >> BBB can randomly fail to boot, which isn't good. If my patch isn't wanted, >> then please implement a suitable alternative. > > How about what Tom suggested? Ctrl-C is not likely to happen by accident. This should be good enough for everyone, it'll look for an exact match over serial "" otherwise it'll ignore everything else: http://lists.denx.de/pipermail/u-boot/2016-January/241286.html Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_mmc: support overriding mmc dev from board code
This enables boards to choose where to/from the environment should be
saved/loaded. They can then for example support using the same device
(dynamically) from which the bootloader was launched to load and save
env data and do not have to define CONFIG_SYS_MMC_ENV_DEV statically.
In my use case, the environment needs to be on the same device I
booted from. It can be the eMMC or an optional SD card.
I therefore would override mmc_get_env_dev in the board code, read the
CPU registers to determine where we booted from and return the
corresponding device index.
Cc: Tom Rini
Cc: Stephen Warren
Cc: Tim Harvey
Cc: Simon Glass
Cc: Hans de Goede
Signed-off-by: Clemens Gruber
---
common/env_mmc.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/common/env_mmc.c b/common/env_mmc.c
index 15aa43d..bdb452e 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -54,6 +54,11 @@ __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32
*env_addr)
return 0;
}
+__weak int mmc_get_env_dev(void)
+{
+ return CONFIG_SYS_MMC_ENV_DEV;
+}
+
int env_init(void)
{
/* use default */
@@ -74,7 +79,7 @@ static unsigned char env_mmc_orig_hwpart;
static int mmc_set_env_part(struct mmc *mmc)
{
uint part = mmc_get_env_part(mmc);
- int dev = CONFIG_SYS_MMC_ENV_DEV;
+ int dev = mmc_get_env_dev();
int ret = 0;
#ifdef CONFIG_SPL_BUILD
@@ -109,7 +114,7 @@ static const char *init_mmc_for_env(struct mmc *mmc)
static void fini_mmc_for_env(struct mmc *mmc)
{
#ifdef CONFIG_SYS_MMC_ENV_PART
- int dev = CONFIG_SYS_MMC_ENV_DEV;
+ int dev = mmc_get_env_dev();
#ifdef CONFIG_SPL_BUILD
dev = 0;
@@ -140,7 +145,8 @@ static unsigned char env_flags;
int saveenv(void)
{
ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
- struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
+ int dev = mmc_get_env_dev();
+ struct mmc *mmc = find_mmc_device(dev);
u32 offset;
int ret, copy = 0;
const char *errmsg;
@@ -167,8 +173,7 @@ int saveenv(void)
goto fini;
}
- printf("Writing to %sMMC(%d)... ", copy ? "redundant " : "",
- CONFIG_SYS_MMC_ENV_DEV);
+ printf("Writing to %sMMC(%d)... ", copy ? "redundant " : "", dev);
if (write_env(mmc, CONFIG_ENV_SIZE, offset, (u_char *)env_new)) {
puts("failed\n");
ret = 1;
@@ -212,7 +217,7 @@ void env_relocate_spec(void)
int crc1_ok = 0, crc2_ok = 0;
env_t *ep;
int ret;
- int dev = CONFIG_SYS_MMC_ENV_DEV;
+ int dev = mmc_get_env_dev();
const char *errmsg = NULL;
ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env1, 1);
@@ -298,7 +303,7 @@ void env_relocate_spec(void)
struct mmc *mmc;
u32 offset;
int ret;
- int dev = CONFIG_SYS_MMC_ENV_DEV;
+ int dev = mmc_get_env_dev();
const char *errmsg;
#ifdef CONFIG_SPL_BUILD
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] tegra: video: Always use write-through cache on LCD
On Mon, Jan 18, 2016 at 01:07:10PM -0700, Stephen Warren wrote: > On 01/14/2016 01:26 PM, Simon Glass wrote: > >This seems to give the best performance, so let's use it always. > > I thought we chose the current cache mode due to display corruption issues > with other modes, but I tested a change that I believe does the same as this > change on Seaboard without any apparent issue so, > > Acked-by: Stephen Warren I think for framebuffers the best option is still write-combine, which would be something like: DCACHE_WRITECOMBINE = DCACHE_OFF | TTB_SECT_B_MASK on ARM v7. Did you ever benchmark that against DCACHE_WRITETHROUGH? It should be faster provided that you never read from the region. Thierry signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv2, 2/5] igep00x0: Cleanup ethernet support
On Wed, Jan 20, 2016 at 06:24:40AM +0100, Heiko Schocher wrote: > Hello Tom, > > Am 04.01.2016 um 23:07 schrieb Enric Balletbò i Serra: > >From: Ladislav Michl > > > >- move chip reset to separate function > >- use CONFIG_SMC911X_BASE instead of hardcoded value > >- remove unneeded local variable from board_eth_init. > > > >Signed-off-by: Ladislav Michl > >Reviewed-by: Tom Rini > >Acked-by: Enric Balletbo Serra > >--- > > board/isee/igep00x0/igep00x0.c | 33 +++-- > > 1 file changed, 19 insertions(+), 14 deletions(-) > > Reviewed-by: Heiko Schocher > > Tom? Is it OK if I apply this patch to u-boot-ubi.git, as the SPL ubi > patches depend on this series? I'll pick up this series (and some other TI platform stuff) in the next day or two, 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 1/8] board: ti: ks2_evm: remove board_eth_init when CONFIG_DM_ETH is defined
On Wed, Jan 20, 2016 at 05:30:50PM +0530, Mugunthan V N wrote: > remove board_eth_init when CONFIG_DM_ETH is defined > > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- 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 3/8] drivers: net: keystone_net: convert driver to adopt device driver model
On Wed, Jan 20, 2016 at 05:30:52PM +0530, Mugunthan V N wrote: > Adopt keystone_net driver to adopt device driver model > > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- 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/8] drivers: net: phy: micrel: fix build errors with CONFIG_DM_ETH
On Wed, Jan 20, 2016 at 05:30:51PM +0530, Mugunthan V N wrote:
> When Micrel phy is selected without CONFIG_PHY_MICREL_KSZ9031 or
> CONFIG_PHY_MICREL_KSZ9021 there is a build warning. Fixing this
build error
> by adding proper ifdefs
>
> drivers/net/phy/micrel.c:370:39: error: array type has incomplete element type
> static const struct ksz90x1_reg_field ksz9031_ctl_grp[] =
>^
> drivers/net/phy/micrel.c:372:39: error: array type has incomplete element type
> static const struct ksz90x1_reg_field ksz9031_clk_grp[] =
>^
> drivers/net/phy/micrel.c: In function ‘ksz9031_of_config’:
> drivers/net/phy/micrel.c:377:23: error: array type has incomplete element type
> struct ksz90x1_ofcfg ofcfg[] = {
>^
> drivers/net/phy/micrel.c:379:13: error: ‘ksz90x1_rxd_grp’ undeclared (first
> use in this function)
>{ MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW, 2, ksz90x1_rxd_grp, 4 },
> ^
> drivers/net/phy/micrel.c:379:13: note: each undeclared identifier is reported
> only once for each function it appears in
> drivers/net/phy/micrel.c:380:13: error: ‘ksz90x1_txd_grp’ undeclared (first
> use in this function)
>{ MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW, 2, ksz90x1_txd_grp, 4 },
> ^
> drivers/net/phy/micrel.c:386:3: warning: implicit declaration of function
> ‘ksz90x1_of_config_group’ [-Wimplicit-function-declaration]
>ret = ksz90x1_of_config_group(phydev, &(ofcfg[i]));
>^
> drivers/net/phy/micrel.c:377:23: warning: unused variable ‘ofcfg’
> [-Wunused-variable]
> struct ksz90x1_ofcfg ofcfg[] = {
>^
> drivers/net/phy/micrel.c: At top level:
> drivers/net/phy/micrel.c:370:39: warning: ‘ksz9031_ctl_grp’ defined but not
> used [-Wunused-variable]
> static const struct ksz90x1_reg_field ksz9031_ctl_grp[] =
>^
> drivers/net/phy/micrel.c:372:39: warning: ‘ksz9031_clk_grp’ defined but not
> used [-Wunused-variable]
> static const struct ksz90x1_reg_field ksz9031_clk_grp[] =
>^
> scripts/Makefile.build:277: recipe for target 'drivers/net/phy/micrel.o'
> failed
> make[1]: *** [drivers/net/phy/micrel.o] Error 1
> Makefile:1201: recipe for target 'drivers/net/phy' failed
> make: *** [drivers/net/phy] Error 2
> make: *** Waiting for unfinished jobs
>
> Signed-off-by: Mugunthan V N
Reviewed-by: Tom Rini
--
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 6/8] defconfig: k2e_evm_defconfig: enable net driver model
On Wed, Jan 20, 2016 at 05:30:55PM +0530, Mugunthan V N wrote: > enable net driver model for k2e evm as keystone_net supports > driver model > > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- 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 5/8] defconfig: k2l_evm_defconfig: enable net driver model
On Wed, Jan 20, 2016 at 05:30:54PM +0530, Mugunthan V N wrote: > enable net driver model for k2l evm as keystone_net supports > driver model > > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- 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 4/8] defconfig: k2hk_evm_defconfig: enable net driver model
On Wed, Jan 20, 2016 at 05:30:53PM +0530, Mugunthan V N wrote: > enable net driver model for k2hk evm as keystone_net supports > driver model > > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- 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 0/4] tegra: Move tegra20 towards the 'new' display bindings
On Tue, Jan 19, 2016 at 09:47:11AM -0700, Stephen Warren wrote: > On 01/18/2016 06:58 PM, Simon Glass wrote: > >Hi Stephen, > > > >On 18 January 2016 at 12:52, Stephen Warren wrote: > >>On 01/14/2016 04:12 PM, Simon Glass wrote: > >>> > >>>Hi Lucas, > >>> > >>>On 14 January 2016 at 13:34, Lucas Stach wrote: > > Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass: > > > >The original tegra20 display driver was written before Linux had > >device tree > >bindings for display. Since then Linux has developed a robust set of > >bindings > >covering various aspects of enabling a display. > > > >This series moves closer to those bindings by using the panel and > >backlight > >as separate drivers. The device tree files for seaboard, ventana and > >harmony > >thereby become almost the same as Linux. > > > >Unfortunately this breaks the other boards, which will need a similar > >sync. > >So I'm not sure how easy it will be to accept this series. Still, it > >seems > >worth sending it out in the hope that board maintainers can help. I > >have > >kept this series separate so that it can progress separately. > > > By pushing display timings into the DT you are actually diverging from > mainline, as mainline doesn't require this, but instead infers the > timings from the panel compatible. Is this a desired goal? > >>> > >>> > >>>This is not divergence. > >> > >> > >>Really? The DT content is different. Isn't that the definition of > >>divergence? > > > >You might infer that from the movie, but divergence really means that > >things are getting further apart. So I think here we have convergence. > > > >> > >>>Please take a look at the patch series. The > >>>device tree files are very close to the same now. The existing U-Boot > >>>support has display timings in the device tree too, so this is not > >>>being added. > >>> > >>>The display timings are a small part of the work, but in the back of > >>>my mind is that we don't want to have a big table of display panel > >>>timings as exists in Linux. This is a waste of space when a board will > >>>only use one panel. > >> > >> > >>That was rather the point of the panel-specific compatible values: To force > >>the DT to contain a semantic definition of the type of panel, rather than a > >>"generic" definition of timings. A benefit of the semantic representation is > >>that if we later find bugs that need to be fixed on certain panels, if we > >>know the panel type, then bug fixes can be applied. Equally, if we enhance > >>the SW to require more data about the panel, that can be added to a driver > >>without the need to change the DT, thus allowing old DTs to continue to > >>work. More semantic rather than purely "syntactic" knowledge is available. > >>However, if we only have a generic timing definition (or other data suitable > >>for current SW features or code-paths), then panel-specific bug fixes will > >>never be possible since SW can't know the identify of the panel. The > >>disadvantage of requiring a mapping table between panel type and display > >>timings was considered reasonable for SW stacks at which DT was targeted > >>(i.e. main OSs rather than HW-specific bootloaders). Even so, to avoid the > >>bloat issue, you can always just #ifdef the mapping table and end up with > >>the same code size; even less perhaps since no timing DT parsing code is > >>required. > >> > >>At least, that was the reasoning when the DT bindings for Tegra panels were > >>first created; IIRC there was discussion of bindings for generic panels, > >>timings, panel power sequences, etc., and they were rejected for the reason > >>I explained above and perhaps others. However, it does seem someone has > >>changed their mind again given that the generic panel-timings binding does > >>exist now. This is one of the many things that sucks about DT; no decision > >>is ever kept, so consistency in design and implementation isn't possible:-( > > > >Sounds a bit contrived to me. > > I believe this approach has been taken after years of experience with DT and > having to retro-fit bug-fixes and new features into existing DTs. > > Still, you'd get the best background from the Linux kernel DT maintainers on > this topic, since they have experience with DT over more years than me. I'm > simply reporting the arguments they've presented. To be fair, the panel bindings came about after the display-timings binding. Perhaps the main reason why the panel bindings are what they are today is because I consider them devices no different at all from peripherals and the like. Back at the time, most of the pushback was because people believed that panels were somehow special in that they would simply require the video timings to make them work, and hence having some generic helpers to parse them from DT would be enough and is what many drivers ended up implementing. But it turned out that there's more
Re: [U-Boot] [PATCH v2 01/50] dm: clk: Add support for decoding clocks from the device tree
Hi Masahiro, On 19 January 2016 at 22:38, Masahiro Yamada wrote: > > Hi Simon, > > > >>> > >>> +/** > >>> + * clk_get_by_index() - look up a clock referenced by a device > >>> + * > >>> + * Parse a device's 'clocks' list, returning information on the indexed > >>> clock, > >>> + * ensuring that it is activated. > >>> + * > >>> + * @dev: Device containing the clock reference > >>> + * @index: Clock index to return (0 = first) > >>> + * @clk_devp: Returns clock device > >>> + * @return:Peripheral ID for the device to control. This is the first > >>> + * argument after the clock node phandle. If there is no > >>> arguemnt, > >>> + * returns 0. Return -ve error code on any error > >>> + */ > >>> +int clk_get_by_index(struct udevice *dev, int index, struct udevice > >>> **clk_devp); > >>> #endif /* _CLK_H_ */ > >> > >> > >> I want #ifdef in the header too, like mine > >> http://patchwork.ozlabs.org/patch/566812/ > > > > I am not keen on that idea since it clutters up header files and we'll > > get a link error anyway if something is missing. Anyway, I've added > > it. > > > > I am afraid there is misunderstanding here. > > Please see my patch carefully. > > > What I mean is like this: > > > #if ... > declaration of function prototype > #else > static inline empty function > #endif > > > This is a common technique to avoid a link error. Do you think this function will be called when device tree is not enabled? I cannot see how it would have any meaning in that case. What is the purpose? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/8] dm: x86: queensbay: Add an interrupt driver
Hi Bin, On 20 January 2016 at 02:28, Bin Meng wrote: > On Wed, Jan 20, 2016 at 12:32 PM, Simon Glass wrote: >> Add a driver for interrupts on queensbay and move the code currently in >> cpu_irq_init() into its probe() method. >> >> Signed-off-by: Simon Glass >> Reviewed-by: Bin Meng >> --- >> >> Changes in v3: None >> Changes in v2: None >> >> arch/x86/cpu/queensbay/Makefile | 2 +- >> arch/x86/cpu/queensbay/irq.c| 65 >> + >> arch/x86/cpu/queensbay/tnc.c| 37 --- >> arch/x86/dts/crownbay.dts | 2 +- >> 4 files changed, 67 insertions(+), 39 deletions(-) >> create mode 100644 arch/x86/cpu/queensbay/irq.c >> > > Tested-by: Bin Meng OK I'm pleased this works - thanks for testing it. I'll leave you to apply it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] ARM: dts: k2g: Add keystone net dts files
On Wed, Jan 20, 2016 at 05:30:56PM +0530, Mugunthan V N wrote: > Add keystone net DT support for k2g evm. > > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- 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 8/8] defconfig: k2g_evm_defconfig: enable net driver model
On Wed, Jan 20, 2016 at 05:30:57PM +0530, Mugunthan V N wrote: > enable net driver model for k2g evm as keystone_net supports > driver model > > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- 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 1/3] ARMv8/layerscape: Add mmu_init API
On 01/20/2016 04:06 AM, Zhiqiang Hou wrote: > I am not know cache and mmu so much, and have some question: > For ARM: > Why there isn't a isolate API for mmu_setup, but invoke it from > dcache_enable()? > If data cache won't be used, the MMU also cannot be used? No. If MMU is not enabled, cacheability cannot be set. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ] board: ls2080a: Add "mcinitcmd" env for MC & DPL deployment
On 01/19/2016 10:59 PM, Pratiyush Mohan Srivastava wrote:
> From: Pratiyush Mohan Srivastava
>
> Environment variable mcinitcmd is defined to initiate MC and DPL deployment
> from the location where it is stored(NOR, NAND, SD, SATA, USB)during u-boot
> booting.If this variable is not defined then macro MC_BOOT_ENV_VAR will be
> null and
> MC will not be booted and DPL will not be applied during U-boot booting.
>
> Signed-off-by: Pratiyush Mohan Srivastava
> Signed-off-by: Prabhakar Kushwaha
> ---
> arch/arm/cpu/armv8/fsl-layerscape/README.lsch3 | 29
> ++
> board/freescale/ls2080aqds/eth.c | 5 +
> board/freescale/ls2080ardb/eth_ls2080rdb.c | 5 +
> 3 files changed, 39 insertions(+)
>
> diff --git a/board/freescale/ls2080aqds/eth.c
> b/board/freescale/ls2080aqds/eth.c
> index 5b9c2d1..db9de77 100644
> --- a/board/freescale/ls2080aqds/eth.c
> +++ b/board/freescale/ls2080aqds/eth.c
> @@ -20,6 +20,7 @@
>
> #include "ls2080aqds_qixis.h"
>
> +#define MC_BOOT_ENV_VAR "mcinitcmd"
>
> #ifdef CONFIG_FSL_MC_ENET
> /* - In LS2080A there are only 16 SERDES lanes, spread across 2 SERDES
> banks.
> @@ -714,6 +715,7 @@ void ls2080a_handle_phy_interface_xsgmii(int i)
> int board_eth_init(bd_t *bis)
> {
> int error;
> + char *mc_boot_env_var;
> #ifdef CONFIG_FSL_MC_ENET
> struct ccsr_gur __iomem *gur = (void *)CONFIG_SYS_FSL_GUTS_ADDR;
> int serdes1_prtcl = (in_le32(&gur->rcwsr[28]) &
> @@ -781,6 +783,9 @@ int board_eth_init(bd_t *bis)
> }
> }
>
> + mc_boot_env_var = getenv(MC_BOOT_ENV_VAR);
> + if (mc_boot_env_var)
> + run_command_list(mc_boot_env_var, -1, 0);
> error = cpu_eth_init(bis);
Why not put the code into cpu_eth_init()?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] tegra: video: Always use write-through cache on LCD
Hi Thierry, On 20 January 2016 at 07:53, Thierry Reding wrote: > On Mon, Jan 18, 2016 at 01:07:10PM -0700, Stephen Warren wrote: >> On 01/14/2016 01:26 PM, Simon Glass wrote: >> >This seems to give the best performance, so let's use it always. >> >> I thought we chose the current cache mode due to display corruption issues >> with other modes, but I tested a change that I believe does the same as this >> change on Seaboard without any apparent issue so, >> >> Acked-by: Stephen Warren > > I think for framebuffers the best option is still write-combine, which > would be something like: > > DCACHE_WRITECOMBINE = DCACHE_OFF | TTB_SECT_B_MASK > > on ARM v7. Did you ever benchmark that against DCACHE_WRITETHROUGH? It > should be faster provided that you never read from the region. This is noticeably slower in my experience. Reading from the region is pretty common - e.g. scrolling. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] tegra: Move tegra20 towards the 'new' display bindings
Hi, On 20 January 2016 at 08:37, Thierry Reding wrote: > On Tue, Jan 19, 2016 at 09:47:11AM -0700, Stephen Warren wrote: >> On 01/18/2016 06:58 PM, Simon Glass wrote: >> >Hi Stephen, >> > >> >On 18 January 2016 at 12:52, Stephen Warren wrote: >> >>On 01/14/2016 04:12 PM, Simon Glass wrote: >> >>> >> >>>Hi Lucas, >> >>> >> >>>On 14 January 2016 at 13:34, Lucas Stach wrote: >> >> Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass: >> > >> >The original tegra20 display driver was written before Linux had >> >device tree >> >bindings for display. Since then Linux has developed a robust set of >> >bindings >> >covering various aspects of enabling a display. >> > >> >This series moves closer to those bindings by using the panel and >> >backlight >> >as separate drivers. The device tree files for seaboard, ventana and >> >harmony >> >thereby become almost the same as Linux. >> > >> >Unfortunately this breaks the other boards, which will need a similar >> >sync. >> >So I'm not sure how easy it will be to accept this series. Still, it >> >seems >> >worth sending it out in the hope that board maintainers can help. I >> >have >> >kept this series separate so that it can progress separately. >> > >> By pushing display timings into the DT you are actually diverging from >> mainline, as mainline doesn't require this, but instead infers the >> timings from the panel compatible. Is this a desired goal? >> >>> >> >>> >> >>>This is not divergence. >> >> >> >> >> >>Really? The DT content is different. Isn't that the definition of >> >>divergence? >> > >> >You might infer that from the movie, but divergence really means that >> >things are getting further apart. So I think here we have convergence. >> > >> >> >> >>>Please take a look at the patch series. The >> >>>device tree files are very close to the same now. The existing U-Boot >> >>>support has display timings in the device tree too, so this is not >> >>>being added. >> >>> >> >>>The display timings are a small part of the work, but in the back of >> >>>my mind is that we don't want to have a big table of display panel >> >>>timings as exists in Linux. This is a waste of space when a board will >> >>>only use one panel. >> >> >> >> >> >>That was rather the point of the panel-specific compatible values: To force >> >>the DT to contain a semantic definition of the type of panel, rather than a >> >>"generic" definition of timings. A benefit of the semantic representation >> >>is >> >>that if we later find bugs that need to be fixed on certain panels, if we >> >>know the panel type, then bug fixes can be applied. Equally, if we enhance >> >>the SW to require more data about the panel, that can be added to a driver >> >>without the need to change the DT, thus allowing old DTs to continue to >> >>work. More semantic rather than purely "syntactic" knowledge is available. >> >>However, if we only have a generic timing definition (or other data >> >>suitable >> >>for current SW features or code-paths), then panel-specific bug fixes will >> >>never be possible since SW can't know the identify of the panel. The >> >>disadvantage of requiring a mapping table between panel type and display >> >>timings was considered reasonable for SW stacks at which DT was targeted >> >>(i.e. main OSs rather than HW-specific bootloaders). Even so, to avoid the >> >>bloat issue, you can always just #ifdef the mapping table and end up with >> >>the same code size; even less perhaps since no timing DT parsing code is >> >>required. >> >> >> >>At least, that was the reasoning when the DT bindings for Tegra panels were >> >>first created; IIRC there was discussion of bindings for generic panels, >> >>timings, panel power sequences, etc., and they were rejected for the reason >> >>I explained above and perhaps others. However, it does seem someone has >> >>changed their mind again given that the generic panel-timings binding does >> >>exist now. This is one of the many things that sucks about DT; no decision >> >>is ever kept, so consistency in design and implementation isn't possible:-( >> > >> >Sounds a bit contrived to me. >> >> I believe this approach has been taken after years of experience with DT and >> having to retro-fit bug-fixes and new features into existing DTs. >> >> Still, you'd get the best background from the Linux kernel DT maintainers on >> this topic, since they have experience with DT over more years than me. I'm >> simply reporting the arguments they've presented. > > To be fair, the panel bindings came about after the display-timings > binding. Perhaps the main reason why the panel bindings are what they > are today is because I consider them devices no different at all from > peripherals and the like. Back at the time, most of the pushback was > because people believed that panels were somehow special in that they > would simply require the video timings to ma
Re: [U-Boot] [PATCH] armv8/ls1043a: Implement workaround for erratum A009660
On 01/19/2016 10:44 PM, Mingkai Hu wrote:
> From: Mingkai Hu
>
> Memory controller performance is not optimal with default internal
> target queue register value, write required value for optimal DDR
> performance.
>
> Signed-off-by: Mingkai Hu
> ---
> arch/arm/cpu/armv8/fsl-layerscape/soc.c | 13 +
> arch/arm/include/asm/arch-fsl-layerscape/config.h | 1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 23d6b73..485f5cd 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -210,6 +210,18 @@ static void erratum_a009929(void)
> #endif
> }
>
> +/*
> + * This erratum requires setting a value to eddrtqcr1 to
> + * optimal the DDR performance.
> + */
> +static void erratum_a009660(void)
> +{
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A009660
> + u32 *eddrtqcr1 = (void *)CONFIG_SYS_FSL_SCFG_ADDR + 0x20c;
> + out_be32(eddrtqcr1, 0x63b20042);
> +#endif
> +}
> +
> void fsl_lsch2_early_init_f(void)
> {
> struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
> @@ -232,6 +244,7 @@ void fsl_lsch2_early_init_f(void)
>
> /* Erratum */
> erratum_a009929();
> + erratum_a009660();
> }
> #endif
>
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> index 49b113d..66399b2 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> @@ -167,6 +167,7 @@
> #define GICC_BASE0x01402000
>
> #define CONFIG_SYS_FSL_ERRATUM_A009929
> +#define CONFIG_SYS_FSL_ERRATUM_A009660
> #else
> #error SoC not defined
> #endif
>
NACK.
Erratum A009660 is cancelled. The workaround is integrated into A008514. Please
revise workaround for A008514. Besides, you are using ARMv7 offset for ARMv8.
Please check if this workaround applies to LS2 SoCs. While you are on it, please
add a comment to LS1 workaround with the word A008514 so we can grep it.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] driver: net: ldpaa_eth: Add support of PHY framework
On 01/19/2016 10:35 PM, Prabhakar Kushwaha wrote: > This patch integrate DPAA2 ethernet driver existing PHY framework. > > Call phy_connect and phy_config as per available DPMAC id defined > in SerDes Protcol. > > Signed-off-by: Pratiyush Mohan Srivastava > Signed-off-by: Prabhakar Kushwaha > --- For future patches related to network, please CC Joe so he is aware your change. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] usb: eth: add Realtek RTL8152B/RTL8153 DRIVER
On 01/19/2016 11:24 PM, Ted Chen wrote: This patch adds driver support for the Realtek RTL8152B/RTL8153 USB network adapters. This looks fine to me, although I didn't take a detailed enough look to actually give and an ack/reviewed-by. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_mmc: support overriding mmc dev from board code
On 01/20/2016 07:43 AM, Clemens Gruber wrote: This enables boards to choose where to/from the environment should be saved/loaded. They can then for example support using the same device (dynamically) from which the bootloader was launched to load and save env data and do not have to define CONFIG_SYS_MMC_ENV_DEV statically. In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index. Reviewed-by: Stephen Warren I was going to ask: What about the HW partition number and offset, but it appears that there is already a method to override those at run-time:-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch V4 1/4] spi: fsl_qspi: fix compile warning for 64-bit platform
On 01/19/2016 08:03 PM, Qianyu Gong wrote: > >> -Original Message- >> From: york sun >> Sent: Wednesday, January 20, 2016 2:42 AM >> To: Qianyu Gong ; u-boot@lists.denx.de >> Cc: Mingkai Hu ; jt...@openedev.com; Yao Yuan >> ; r58...@freescale.com; Gong Qianyu >> >> Subject: Re: [Patch V4 1/4] spi: fsl_qspi: fix compile warning for 64-bit >> platform >> >> On 01/10/2016 06:14 PM, Gong Qianyu wrote: >>> From: Gong Qianyu >>> >>> This patch fixes the following compile warning: >>> drivers/spi/fsl_qspi.c: In function 'fsl_qspi_probe': >>> drivers/spi/fsl_qspi.c:937:15: >>> warning: cast to pointer from integer of different size >>> [-Wint-to-pointer-cast] >>> priv->regs = (struct fsl_qspi_regs *)plat->reg_base; >>>^ >>> Just make the cast explict. >>> >>> Signed-off-by: Gong Qianyu >>> --- >>> V4: >>> - Revise the commit message. >>> V2-V3: >>> - No change. >>> >>> drivers/spi/fsl_qspi.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index >>> feec3e8..9f23c10 100644 >>> --- a/drivers/spi/fsl_qspi.c >>> +++ b/drivers/spi/fsl_qspi.c >>> @@ -936,7 +936,7 @@ static int fsl_qspi_probe(struct udevice *bus) >>> >>> dm_spi_bus->max_hz = plat->speed_hz; >>> >>> - priv->regs = (struct fsl_qspi_regs *)plat->reg_base; >> >> The reg_base is u32. Is it always correct on 64-bit SoC? >> > > So far it's always a u32 type of CCSR address. > >>> + priv->regs = (struct fsl_qspi_regs *)(unsigned long)plat->reg_base; >> >> How about (struct fsl_qspi_regs *)(uintptr_t)plat->reg_base? >> >> York >> > > The size of ''unsigned long'' depends on compilers. It works well with GCC. > > Looks the same. But not sure what is defining CONFIG_USE_STDIN for. > > #ifdef CONFIG_USE_STDIN > /* Provided by gcc. */ > #include > #else > /* Type for `void *' pointers. */ > typedef unsigned long int uintptr_t; > #endif > uintptr_t is specifically defined for this type of use. You can grep it in u-boot to see examples. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] Revert "fdt_support: Add multi-serial support for stdout fixup"
On 13 January 2016 at 20:38, Bin Meng wrote: > This reverts commit 3e303f748cf57fb23e8ec95ab7eac0074be50e2b. > > The fix up in the /aliases node does not work under the following > scenarios: > - Not every non-DM serial driver was written to have a driver name > that conforms the format of "serial%d" or "eserial%d". > - With driver model serial, the stdio_devices[] stores the serial > device node name in the device tree. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - Rewrite the commit message using 'git revert' format. > > common/fdt_support.c | 16 +--- > 1 file changed, 1 insertion(+), 15 deletions(-) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: fix size arg of flush_cache() in bootm_load_os().
On 20 January 2016 at 01:37, Purna Chandra Mandal wrote: > Variable _load_end_ points to end address of uncompressed buffer > (*not* uncomress_buffer_end / sizeof(ulong)), so multipling uncompressed > size with sizeof(ulong) is grossly incorrect in flush_cache(). > It might lead to access of address beyond valid memory range and hang the CPU. > > Tested on MIPS architecture by using compressed(gzip, lzma) > and uncompressed uImage. > > Signed-off-by: Purna Chandra Mandal > --- > > common/bootm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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 8/9] arm: ls1021atwr: Split off board device tree
On 13 January 2016 at 20:39, Bin Meng wrote:
> Move /chosen node out of the board device tree.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - New patch to split off board device tree
>
> arch/arm/dts/Makefile | 2 +-
> arch/arm/dts/ls1021a-twr-duart.dts | 16
> arch/arm/dts/{ls1021a-twr.dts => ls1021a-twr.dtsi} | 3 +--
> configs/ls1021atwr_nor_defconfig | 2 +-
> configs/ls1021atwr_qspi_defconfig | 2 +-
> configs/ls1021atwr_sdcard_qspi_defconfig | 2 +-
> 6 files changed, 21 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/dts/ls1021a-twr-duart.dts
> rename arch/arm/dts/{ls1021a-twr.dts => ls1021a-twr.dtsi} (96%)
Acked-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 4/9] serial: lpuart: Fix several cosmetic issues
On 13 January 2016 at 20:39, Bin Meng wrote: > Clean up the driver codes a little bit, by: > - Use tab instead of space in the macro defines > - Use single line comment whenever possible > - Fix insertion of blank lines > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass > --- > > Changes in v2: None > > drivers/serial/serial_lpuart.c | 35 +++ > 1 file changed, 15 insertions(+), 20 deletions(-) Acked-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 6/9] serial: lpuart: Prepare the driver for DM conversion
On 13 January 2016 at 20:39, Bin Meng wrote: > Create internal routines which take lpuart's register base as > a parameter, in preparation for driver model conversion. > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass > > --- > > Changes in v2: > - Add missing 'base' parameter in the call to _lpuart_serial_tstc() > - Change internal routines' parameter 'reg' to 'base' > > drivers/serial/serial_lpuart.c | 88 > +++--- > 1 file changed, 66 insertions(+), 22 deletions(-) > Acked-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 5/9] serial: lpuart: Call local version of setbrg and putc directly
On 13 January 2016 at 20:39, Bin Meng wrote: > There is no need to go through serial driver subsystem, instead > call the driver's setbrg and putc routines directly. > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass > --- > > Changes in v2: None > > drivers/serial/serial_lpuart.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Acked-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 3/9] serial: lpuart: Move CONFIG_FSL_LPUART to Kconfig
On 15 January 2016 at 14:11, Stefan Agner wrote: > Looks good to me, > > Acked-by: Stefan Agner > > On 13.01.2016 19:39, Bin Meng wrote: >> LPUART is seen on Freescale VF610 and QorIQ Layerscape devices. >> Create a Kconfig option and move it to defconfig for all boards >> that have this serial driver. >> >> Signed-off-by: Bin Meng >> Reviewed-by: Simon Glass >> --- >> >> Changes in v2: None >> >> configs/colibri_vf_defconfig | 1 + >> configs/colibri_vf_dtb_defconfig | 1 + >> configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 1 + >> configs/ls1021aqds_nor_lpuart_defconfig | 1 + >> configs/ls1021atwr_nor_lpuart_defconfig | 1 + >> configs/pcm052_defconfig | 1 + >> configs/vf610twr_defconfig | 1 + >> configs/vf610twr_nand_defconfig | 1 + >> drivers/serial/Kconfig | 6 ++ >> include/configs/colibri_vf.h | 1 - >> include/configs/ls1021aqds.h | 1 - >> include/configs/ls1021atwr.h | 1 - >> include/configs/pcm052.h | 1 - >> include/configs/vf610twr.h | 1 - >> 14 files changed, 14 insertions(+), 5 deletions(-) >> Acked-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 2/9] arm: ls1021atwr: Convert to driver model and enable serial support
On 13 January 2016 at 20:38, Bin Meng wrote: > Convert ls1021atwr_nor to driver model support. As a start, enable > ns16550 serial port driver. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > arch/arm/dts/ls1021a-twr.dts | 4 > arch/arm/dts/ls1021a.dtsi| 4 > configs/ls1021atwr_nor_defconfig | 4 > include/configs/ls1021atwr.h | 2 ++ > 4 files changed, 10 insertions(+), 4 deletions(-) Acked-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 7/9] serial: lpuart: Add driver model serial support
On 13 January 2016 at 20:39, Bin Meng wrote: > This adds driver model support to lpuart serial driver. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - Split to use two separate U_BOOT_DRIVER() > > doc/driver-model/serial-howto.txt | 1 - > drivers/serial/serial_lpuart.c| 167 > ++ > 2 files changed, 167 insertions(+), 1 deletion(-) Acked-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 9/9] arm: ls1021atwr: Enable driver model lpuart serial driver
On 18 January 2016 at 02:39, Huan Wang wrote:
> Hi,
>
>> -Original Message-
>> From: Bin Meng [mailto:bmeng...@gmail.com]
>> Sent: Thursday, January 14, 2016 11:39 AM
>> To: Simon Glass; Stefan Agner; Bhuvanchandra DV; Albert ARIBAUD (3ADEV);
>> York Sun; Alison Wang; U-Boot Mailing List
>> Subject: [PATCH v2 9/9] arm: ls1021atwr: Enable driver model lpuart
>> serial driver
>>
>> Convert ls1021atwr_nor_lpuart to driver model support. As a start,
>> enable lpuart serial port driver.
>>
>> Signed-off-by: Bin Meng
>> Reviewed-by: Simon Glass
>>
>> ---
>>
>> Changes in v2:
>> - Create a ls1021a-twr-lpuart.dts for ls1021atwr_nor_lpuart_defconfig
>>
>> arch/arm/dts/Makefile | 2 +-
>> arch/arm/dts/ls1021a-twr-lpuart.dts | 16
>> configs/ls1021atwr_nor_lpuart_defconfig | 4
>> 3 files changed, 21 insertions(+), 1 deletion(-) create mode 100644
>> arch/arm/dts/ls1021a-twr-lpuart.dts
>>
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>> 02b031e..4bbf661 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -89,7 +89,7 @@ dtb-$(CONFIG_TARGET_BEAGLE_X15) += am57xx-beagle-
>> x15.dtb
>> dtb-$(CONFIG_TARGET_STV0991) += stv0991.dtb
>>
>> dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \
>> - ls1021a-twr-duart.dtb
>> + ls1021a-twr-duart.dtb ls1021a-twr-lpuart.dtb
>> dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
>> fsl-ls2080a-rdb.dtb
>> dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds.dtb \ diff --git
>> a/arch/arm/dts/ls1021a-twr-lpuart.dts b/arch/arm/dts/ls1021a-twr-
>> lpuart.dts
>> new file mode 100644
>> index 000..2941ec0
>> --- /dev/null
>> +++ b/arch/arm/dts/ls1021a-twr-lpuart.dts
>> @@ -0,0 +1,16 @@
>> +/*
>> + * Freescale ls1021a TWR board device tree source
>> + *
>> + * Copyright 2013-2015 Freescale Semiconductor, Inc.
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +/dts-v1/;
>> +#include "ls1021a-twr.dtsi"
>> +
>> +/ {
>> + chosen {
>> + stdout-path = &lpuart0;
>> + };
>> +};
>> diff --git a/configs/ls1021atwr_nor_lpuart_defconfig
>> b/configs/ls1021atwr_nor_lpuart_defconfig
>> index 58cd61f..599342f 100644
>> --- a/configs/ls1021atwr_nor_lpuart_defconfig
>> +++ b/configs/ls1021atwr_nor_lpuart_defconfig
>> @@ -1,7 +1,11 @@
>> CONFIG_ARM=y
>> CONFIG_TARGET_LS1021ATWR=y
>> +CONFIG_DM_SERIAL=y
>> +CONFIG_DEFAULT_DEVICE_TREE="ls1021a-twr-lpuart"
>> CONFIG_SYS_EXTRA_OPTIONS="LPUART"
>> # CONFIG_CMD_SETEXPR is not set
>> +CONFIG_OF_CONTROL=y
>> +CONFIG_DM=y
>> CONFIG_NETDEVICES=y
>> CONFIG_E1000=y
>> CONFIG_FSL_LPUART=y
>> --
>> 1.8.2.1
>
> Reviewed-by: Alison Wang
> Tested-by: Alison Wang
>
>
> Best Regards,
> Alison Wang
Acked-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] FPGA detection failure on Cyclone V soc development kit
I'm having a problem with u-boot 2016.01 failing to detect the FPGA on my Altera Cyclone V SoC Development Kit. On startup, it simply prints "FPGA: Not Altera chip ID" (the ID having been read as all-zero). No amount of messing with jumpers or switches makes a difference. The software on the SD card included in the box appears to work, so on a whim I took the SPL pre-loader from this card and combined it with the main 2016.01 u-boot. This makes the detection succeed, despite Marek baulking at this idea. The "good" SPL identifies as "U-Boot SPL 2013.01.01 (Dec 04 2014 - 08:59:41)" which is a different build date than the main u-boot on the same SD card, so which source code version it was built from is anyone's guess. What's interesting is that Marek's board works with u-boot 2016.01 while mine fails even with the very same binary. The boards are different revisions (his 100-0321003-C1, mine -E1), and the main Cyclone V chips are also different (his 5CSXFC6D6F31C8NES, mine 5CSXFC6D6F31C6N). Any suggestions for what to try next? -- Måns Rullgård ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] checkpatch: ignore request to use ether_addr_copy()
On 01/13/2016 11:23 AM, Stephen Warren wrote: On 12/15/2015 04:41 PM, Joe Hershberger wrote: Hi Stephen, On Tue, Dec 15, 2015 at 5:34 PM, Stephen Warren wrote: On 11/23/2015 04:36 PM, Joe Hershberger wrote: On Fri, Nov 13, 2015 at 10:03 AM, Stephen Warren wrote: From: Stephen Warren The Linux kernel, from which checkpatch originates, contains function ether_addr_copy() to copy Ethernet MAC addresses, and checkpatch warns that it should be used in preference to memcpy() where appropriate. U-Boot doesn't contain ether_addr_copy(), so tell checkpatch not to issue this warning. Signed-off-by: Stephen Warren Acked-by: Joe Hershberger Were you intending someone else to apply this? I think now that Ted Chen has taken over the USB NIC driver (which was patch 2 in this series), this patch should be applied separately. It is assigned to Marek in patchwork. If he's not going to take it, then assign it to me and I'll pull it in. Marek, Are you taking this patch? If not, could you please re-assign it to Joe; I don't believe I can modify patchwork myself. Marek? Tom, are you able to re-assign this patch to Joe in patchwork? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] checkpatch: ignore request to use ether_addr_copy()
On Wed, Jan 20, 2016 at 01:47:55PM -0700, Stephen Warren wrote: > On 01/13/2016 11:23 AM, Stephen Warren wrote: > >On 12/15/2015 04:41 PM, Joe Hershberger wrote: > >>Hi Stephen, > >> > >>On Tue, Dec 15, 2015 at 5:34 PM, Stephen Warren > >> wrote: > >>>On 11/23/2015 04:36 PM, Joe Hershberger wrote: > > On Fri, Nov 13, 2015 at 10:03 AM, Stephen Warren > > wrote: > > > >From: Stephen Warren > > > >The Linux kernel, from which checkpatch originates, contains function > >ether_addr_copy() to copy Ethernet MAC addresses, and checkpatch warns > >that it should be used in preference to memcpy() where appropriate. > >U-Boot doesn't contain ether_addr_copy(), so tell checkpatch not to > >issue > >this warning. > > > >Signed-off-by: Stephen Warren > > > Acked-by: Joe Hershberger > >>> > >>> > >>>Were you intending someone else to apply this? I think now that Ted > >>>Chen has > >>>taken over the USB NIC driver (which was patch 2 in this series), > >>>this patch > >>>should be applied separately. > >> > >>It is assigned to Marek in patchwork. If he's not going to take it, > >>then assign it to me and I'll pull it in. > > > >Marek, > > > >Are you taking this patch? If not, could you please re-assign it to Joe; > >I don't believe I can modify patchwork myself. > > Marek? > > Tom, are you able to re-assign this patch to Joe in patchwork? Which? https://patchwork.ozlabs.org/patch/570547/ ? -- 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] arm, ubifs: fix gcc5.x compiler warning
On Mon, Nov 30, 2015 at 08:47:42AM +0100, Heiko Schocher wrote: > compiling U-Boot for openrd_base_defconfig with > gcc 5.x shows the following warning: > > CC fs/ubifs/super.o > In file included from fs/ubifs/ubifs.h:35:0, > from fs/ubifs/super.c:37: > fs/ubifs/super.c: In function 'atomic_inc': > ./arch/arm/include/asm/atomic.h:55:2: warning: 'flags' is used uninitialized > in this function [-Wuninitialized] > local_irq_save(flags); > ^ > fs/ubifs/super.c: In function 'atomic_dec': > ./arch/arm/include/asm/atomic.h:64:2: warning: 'flags' is used uninitialized > in this function [-Wuninitialized] > local_irq_save(flags); > ^ > CC fs/ubifs/sb.o > [...] > CC fs/ubifs/lpt.o > In file included from include/linux/bitops.h:123:0, > from include/common.h:20, > from include/ubi_uboot.h:17, > from fs/ubifs/ubifs.h:37, > from fs/ubifs/lpt.c:35: > fs/ubifs/lpt.c: In function 'test_and_set_bit': > ./arch/arm/include/asm/bitops.h:57:2: warning: 'flags' is used uninitialized > in this function [-Wuninitialized] > local_irq_save(flags); > ^ > CC fs/ubifs/lpt_commit.o > In file included from include/linux/bitops.h:123:0, > from include/common.h:20, > from include/ubi_uboot.h:17, > from fs/ubifs/ubifs.h:37, > from fs/ubifs/lpt_commit.c:26: > fs/ubifs/lpt_commit.c: In function 'test_and_set_bit': > ./arch/arm/include/asm/bitops.h:57:2: warning: 'flags' is used uninitialized > in this function [-Wuninitialized] > local_irq_save(flags); > ^ > CC fs/ubifs/scan.o > CC fs/ubifs/lprops.o > CC fs/ubifs/tnc.o > In file included from include/linux/bitops.h:123:0, > from include/common.h:20, > from include/ubi_uboot.h:17, > from fs/ubifs/ubifs.h:37, > from fs/ubifs/tnc.c:30: > fs/ubifs/tnc.c: In function 'test_and_set_bit': > ./arch/arm/include/asm/bitops.h:57:2: warning: 'flags' is used uninitialized > in this function [-Wuninitialized] > local_irq_save(flags); > ^ > CC fs/ubifs/tnc_misc.o > > Fix it. > > Signed-off-by: Heiko Schocher I've re-thought this problem. I'm not seeing a better way to work around this problem without further divergence from upstream on these functions, so thanks for doing this! Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/8] m68k: move CONFIG_SYS_TEXT_BASE to defconfig files
On Fri, Dec 11, 2015 at 12:22:24PM +0900, Masahiro Yamada wrote:
> For historical reason, CONFIG_SYS_TEXT_BASE has been specified
> in various ways:
>
> [1] by board/${VENDOR}/${BOARD}/config.mk
>
> [2] by CONFIG_SYS_EXTRA_OPTIONS
> (This was "options" field of boards.cfg before Kconfig conversion)
>
> [3] by include/configs/${BOARD}.h
>
> [4] by configs/${BOARD}_defconfig
>
> Most of M68K boards use either [1] or [2], both of which we want to
> deprecate. Switch them into [4], which is the newest way (Kconfig).
>
> We still allow [3] too, because it is still used by many boards and
> we expect much time for conversion.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Angelo Dureghello
> Reviewed-by: Simon Glass
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] spi: ti_qspi: Use 4-byte opcode for mmap read
On Mon, Nov 23, 2015 at 05:43:36PM +0530, Vignesh R wrote: > ti-qspi driver currently uses 3-byte addressing mode(and opcodes) for > memory-mapped read. This restricts maximum addressable flash size to > 16MB. > Enable the 4-byte addressing(and use 4-byte opcode) for memory-mapped > read to allow access to addresses above 16MB. > > Signed-off-by: Ravi Babu > [vigne...@ti.com: Re-word commit description] > Signed-off-by: Vignesh R Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/8] microblaze: move CONFIG_SYS_TEXT_BASE to defconfig
On Fri, Dec 11, 2015 at 12:22:26PM +0900, Masahiro Yamada wrote: > This is how CONFIG options are defined by Kconfig. > > Signed-off-by: Masahiro Yamada > Acked-by: Michal Simek Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/8] m68k: M54418TWR: drop board/freescale/m54418twr/config.mk
On Fri, Dec 11, 2015 at 12:22:25PM +0900, Masahiro Yamada wrote: > The board/freescale/m54418twr/config.mk defined TEXT_BASE, which has > the same value as CONFIG_SYS_TEXT_BASE. The TEXT_BASE is referenced > by two files: > - arch/m68k/cpu/mcf5445x/start.S and include/ > - include/configs/M54418TWR.h > > Replace the references with CONFIG_SYS_TEXT_BASE and delete > board/freescale/m54418twr/config.mk. > > Signed-off-by: Masahiro Yamada > Acked-by: Angelo Dureghello Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/8] mips: vct: move CONFIG_SYS_TEXT_BASE away from config.mk
On Fri, Dec 11, 2015 at 12:22:27PM +0900, Masahiro Yamada wrote:
> We can delete board/micronas/vct/config.mk by moving the define of
> CONFIG_SYS_TEXT_BASE to somewhere else. Other MIPS boards are
> still defining it in include/config/${BOARD}.h, so I am following
> that way here.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Daniel Schwierzeck
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 5/8] mips: dbau1x00: move CONFIG_SYS_TEXT_BASE away from config.mk
On Fri, Dec 11, 2015 at 12:22:28PM +0900, Masahiro Yamada wrote:
> We can delete board/dbau1x00/config.mk by moving the define of
> CONFIG_SYS_TEXT_BASE to somewhere else. Other MIPS boards are
> still defining it in include/config/${BOARD}.h, so I am following
> that way here.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Daniel Schwierzeck
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 6/8] mips: pb1x00: move CONFIG_SYS_TEXT_BASE away from config.mk
On Fri, Dec 11, 2015 at 12:22:29PM +0900, Masahiro Yamada wrote:
> We can delete board/pb1x00/config.mk by moving the define of
> CONFIG_SYS_TEXT_BASE to somewhere else. Other MIPS boards are
> still defining it in include/config/${BOARD}.h, so I am following
> that way here.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Daniel Schwierzeck
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 7/8] powerpc: yucca: drop redundant CONFIG_SYS_TEXT_BASE from config.mk
On Fri, Dec 11, 2015 at 12:22:30PM +0900, Masahiro Yamada wrote: > The include/configs/yucca.h already has the same define: > #define CONFIG_SYS_TEXT_BASE0xfffb > > Remove the redundant one from board/amcc/yucca/config.mk. > > Signed-off-by: Masahiro Yamada > Acked-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 8/8] kbuild: drop workaround for old style CONFIG_SYS_TEXT_BASE defines
On Fri, Dec 11, 2015 at 12:22:31PM +0900, Masahiro Yamada wrote: > Now, there is no board defining CONFIG_SYS_TEXT_BASE by its config.mk, > so this workaround is no longer needed. > > Signed-off-by: Masahiro Yamada > Acked-by: Stefan Roese 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] ti_omap3_common: Do not define CONFIG_SPL_NAND_SUPPORT
On Wed, Dec 30, 2015 at 02:45:26AM +0100, Ladislav Michl wrote: > Symbol is already defined in ti_armv7_common.h which is included > via ti_armv7_omap.h > > Signed-off-by: Ladislav Michl > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv7: Add missing newline after OMAP die ID
On Sun, Jan 03, 2016 at 06:24:27PM +0100, Ladislav Michl wrote: > Signed-off-by: Ladislav Michl > Acked-by: Enric Balletbo Serra Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv2, 1/5] igep00x0: enable CONFIG_NET_RANDOM_ETHADDR
On Mon, Jan 04, 2016 at 11:07:58PM +0100, Enric Balletbò i Serra wrote: > Enable CONFIG_NET_RANDOM_ETHADDR to generate a random MAC address > when ETHADDR is not set. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: Tom Rini > Reviewed-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv2, 3/5] igep00x0: Do not include config_distro_defaults.h
On Mon, Jan 04, 2016 at 11:08:00PM +0100, Enric Balletbò i Serra wrote: > From: Ladislav Michl > > File is already included: > omap3_igep00x0.h -> ti_omap3_common.h -> ti_armv7_omap.h -> > ti_armv7_common.h -> config_distro_defaults.h > > Signed-off-by: Ladislav Michl > Acked-by: Enric Balletbo Serra > Reviewed-by: Tom Rini > Reviewed-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
