March 2019 - U-Boot

Re: [U-Boot] Custom SPL for im.X6UL
by Peng Fan 11 Mar '19

11 Mar '19

Hi > -----Original Message----- > From: Araya, Jose [mailto:j.araya@sensopart.de] > Sent: 2019年3月11日 16:50 > To: Peng Fan <peng.fan(a)nxp.com> > Subject: AW: [U-Boot] Custom SPL for im.X6UL > > Hi Peng, > > thanks for answering! Just a follow up question: > > Does the U-boot from NXP run in OCRAM or in DRAM? For i.MX6UL, NXP released U-Boot runs from DRAM, no SPL. > > I read that a multi-stage boot is faster and more efficient, that makes me > think that if I use a single-stage boot it should run in OCRAM (which is limited) > and that's why the multi-stage (which uses DRAM) is actually faster. That's > why my question arises. You could use the upstream uboot for i.MX6UL, it supports SPL runs from OCRAM. Regards, Peng. > > Source: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom > munity.nxp.com%2Fthread%2F438580&data=02%7C01%7Cpeng.fan%40 > nxp.com%7C96b71f4edfc34b0b0ef008d6a5fe9d99%7C686ea1d3bc2b4c6fa92 > cd99c5c301635%7C0%7C0%7C636878910318937272&sdata=yyE40Ut0 > no9nQHAWWusnk2reszG2WuEOI0Po7pr6ahI%3D&reserved=0 > > Thanks! > > Moises > > -----Ursprüngliche Nachricht----- > Von: Peng Fan <peng.fan(a)nxp.com> > Gesendet: Samstag, 9. März 2019 02:11 > An: Araya, Jose <j.araya(a)sensopart.de>; u-boot(a)lists.denx.de > Betreff: RE: [U-Boot] Custom SPL for im.X6UL > > > > > -----Original Message----- > > From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Araya, > > Jose > > Sent: 2019年3月9日 0:59 > > To: u-boot(a)lists.denx.de > > Subject: [U-Boot] Custom SPL for im.X6UL > > > > Hello everyone, > > > > I would like to ask what would be a good starting point to have a > > custom multi-stage booting for the NXP i.mx6UL processor? > > > > Basically I need to be able to configure an FPGA before the U-Boot is > executed. > > The reason for that is that the PGA must be configured so that the > > im6UL can have a physical connection to the DRAM. To clarify: > > > > > > - In the circuit, the DRAM will be multiplexed by an FPGA. If the > FPGA > > is not configured, the imx6UL has no access to the DRAM. > > > > - The imx6UL has a direct SPI connection to the flash and to the > FPGA, > > so all I need is to take the bitstream from a given location in the > > FLASH and load it into the FPGA, then just wait for a flag (GPIO?) > > saying that the FPGA was successfully configured and keep the booting > > process in the processor as normal. > > > > > > As I haven't done yet anything similar, just wanted to know if you > > have any recommendations regarding where to start and some hints to > proceed. > > SPL might help here, because it runs in OCRAM. > > Regards, > Peng. > > > > > Thanks in advance! > > > > Bests, > > > > Jose Moises > > > > > > > > > > SensoPart Industriesensorik GmbH > > Am Wiedenbach 1 | 79695 Wieden Amtsgericht Freiburg HRB 660163 > > Gesch?ftsf?hrer: Dr. Theodor Wanner > > > [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.sensopart.com%2F%2Fimages%2Foutlook%2Fsi_sensopart.png&data= > > > 02%7C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18 > > > c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63687678551123 > > > 6465&sdata=kdlCeiA68J03mVvsfo7LLum%2BJaK6n9Tj%2BzEDIsW3XhQ > > %3D&reserved=0] > > > <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.sensopart.com%2F&data=02%7C01%7CPeng.Fan%40nxp.com%7C642 > > > 764588c8048fdcb1b08d6a40fe18c%7C686ea1d3bc2b4c6fa92cd99c5c301635 > > %7C0%7C1%7C636876785511236465&sdata=5grDBEFPHFgII%2FwJx8 > N > > qvbDCljp9ye%2F9R8T6AeCT12Q%3D&reserved=0> > > > [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.sensopart.com%2F%2Fimages%2Foutlook%2Fsi_linkedin.png&data=0 > > > 2%7C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6368767855112 > 36 > > > 465&sdata=DB4s4lvXipPogJ%2BWE61YNv9p7vbx4gThM6EjFkXCjuI%3D > > &reserved=0] > > > <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > > ww.linkedin.com%2Fcompany%2Fsensopart%2F&data=02%7C01%7CPe > > > ng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c%7C686ea1d3 > > > bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636876785511236465&sda > > > ta=JsDOBDl5aedr8pz1zQtw55WDxdkZGiXEfrhF8GMYRAQ%3D&reserved > > =0> > > > [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.sensopart.com%2F%2Fimages%2Foutlook%2Fsi_youtube.png&data=0 > > > 2%7C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6368767855112 > 36 > > > 465&sdata=xRbXYdLlBnsXaGA1sPjNfIcX%2B6KPR6l7eWdrLWRj00s%3D& > > amp;reserved=0] > > > <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > > ww.youtube.com%2Fuser%2FSensoPart&data=02%7C01%7CPeng.Fan% > > > 40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c%7C686ea1d3bc2b4c6f > > > a92cd99c5c301635%7C0%7C1%7C636876785511236465&sdata=bJ0Mk > > > iBcIQoumP38uQkP4nkdW%2F12VPaJ7I3Yy7Bv%2BFc%3D&reserved=0> > > > [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.sensopart.com%2F%2Fimages%2Foutlook%2Fsi_xing.png&data=02%7 > > > C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c%7C > > > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636876785511236465 > > > &sdata=niGCFmUw1RdHcjD6TLM6JZfRnmDl00qxt9MxBNbe9S4%3D&a > > mp;reserved=0] > > > <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > > ww.xing.com%2Fcompanies%2Fsensopartindustriesensorikgmbh&data= > > > 02%7C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18 > > > c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63687678551123 > > > 6465&sdata=oZbv4D67KSKBRPfXBYrsObcwnxCFeaYXn%2FYrhbw4MlE%3 > > D&reserved=0> > > > > Informationen gem. Art. 13 DSGVO f?r unsere Kunden, Partner, > > Lieferanten finden Sie in unserer Erkl?rung zum Datenschutz unter > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > > w.sensopart.com%2Fde%2Fdatenschutz&data=02%7C01%7CPeng.Fan% > > > 40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c%7C686ea1d3bc2b4c6f > > > a92cd99c5c301635%7C0%7C1%7C636876785511246465&sdata=vzn3U > > cNFUwrp%2BLKvXwaB9DH7QYABRfOTvHKlXgEQJgg%3D&reserved=0 > > > > > > > > > [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.sensopart.com%2Fimages%2Foutlook%2Fmi_hmiia.png&data=02%7C > > > 01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c%7C6 > > > 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636876785511246465& > > > amp;sdata=mWq4QGgoEzawlEWaZpbY3GssRiEbZhyGtht5Qej2owQ%3D&amp > > ;reserved=0] > > > > Besuchen Sie uns auf der > > HANNOVER MESSE Industrial Automation > > 01. - 05.04.2019 | Halle 017, Stand E42/4 > > > Newsletter > > abonnieren<https://emea01.safelinks.protection.outlook.com/?url=http%3 > > > A %2F%2Fwww.sensopart.com%2Fde%2Fueber-uns%2Faktuelles%2Fnewslet > te > > > r-abonnieren&data=02%7C01%7CPeng.Fan%40nxp.com%7C642764588 > > > c8048fdcb1b08d6a40fe18c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > > > 7C0%7C636876785511246465&sdata=QG8bvU6oo5QciMTQ%2FanXET1 > > roDou9OP6ZnZLDHmV53s%3D&reserved=0> > > > > > > _______________________________________________ > > U-Boot mailing list > > U-Boot(a)lists.denx.de > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists. > > denx.de%2Flistinfo%2Fu-boot&data=02%7C01%7CPeng.Fan%40nxp.co > > > m%7C642764588c8048fdcb1b08d6a40fe18c%7C686ea1d3bc2b4c6fa92cd99 > > > c5c301635%7C0%7C0%7C636876785511246465&sdata=N3T2bB6QmP > > KnMtrxmjA%2BuqlUelZwxxNJhMiaEZRij7I%3D&reserved=0

1 0

[U-Boot] [PATCH] dts: force dtb recompilation
by Patrick Delaunay 11 Mar '19

11 Mar '19

The dependency for .dtb = .dts is not enough in dts Makefile, as the dts files are dts pre-proprocessed (include dtsi files, as specific *-u-boot.dtsi). For arm architecture, the dependency is correctly managed in makefile of arch/arm/dts with .cmd files, it is needed to execute make in this directory. Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- Issue see on stm32mp1 board stm32mp157c-ed1.dts is included in stm32mp157c-ev1.dts and dependency is not correctly managed (ev1 is not recompiled when ed1 is modified) dts/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/dts/Makefile b/dts/Makefile index a7a6043..bcd611f 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -17,7 +17,6 @@ ifneq ($(EXT_DTB),) DTB := $(EXT_DTB) else DTB := $(ARCH_PATH)/$(DEVICE_TREE).dtb -dtb_depends += $(DTB:.dtb=.dts) endif $(obj)/dt-spl.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE @@ -28,7 +27,7 @@ $(obj)/dt.dtb: $(DTB) FORCE targets += dt.dtb dt-spl.dtb -$(DTB): $(dtb_depends) +$(DTB): $(dtb_depends) FORCE ifeq ($(EXT_DTB),) $(Q)$(MAKE) $(build)=$(ARCH_PATH) $@ endif -- 2.7.4

4 3

[U-Boot] [PATCH v3 1/1] efi_loader: Fix serial console size detection
by Heinrich Schuchardt 11 Mar '19

11 Mar '19

From: Matthias Brugger <mbrugger(a)suse.com> Function term_read_reply tries to read from the serial console until the end_char was read. This can hang forever if we are, for some reason, not able to read the full response (e.g. serial buffer too small, frame error). This patch moves the timeout detection into term_read_reply() to assure we will make progress. Fixes: 6bb591f704 ("efi_loader: query serial console size reliably") Signed-off-by: Matthias Brugger <mbrugger(a)suse.com> Throw missing error when an incomplete reply for the cursor position is received. Change type of argument of term_get_char() *s32. This renders the function reusable in efi_cin_read_key(). Reviewed-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- v3 Throw missing error when an incomplete reply for the cursor position is received. Change type of argument of term_get_char() *s32. This renders the function reusable in efi_cin_read_key(). v2 move timeout into term_get_char --- lib/efi_loader/efi_console.c | 62 ++++++++++++++++++++---------------- 1 file changed, 35 insertions(+), 27 deletions(-) diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index 66c33a551d5..8e0965bfc89 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -62,6 +62,21 @@ static struct simple_text_output_mode efi_con_mode = { .cursor_visible = 1, }; +static int term_get_char(s32 *c) +{ + u64 timeout; + + /* Wait up to 100 ms for a character */ + timeout = timer_get_us() + 100000; + + while (!tstc()) + if (timer_get_us() > timeout) + return 1; + + *c = getc(); + return 0; +} + /* * Receive and parse a reply from the terminal. * @@ -72,34 +87,36 @@ static struct simple_text_output_mode efi_con_mode = { */ static int term_read_reply(int *n, int num, char end_char) { - char c; + s32 c; int i = 0; - c = getc(); - if (c != cESC) + if (term_get_char(&c) || c != cESC) return -1; - c = getc(); - if (c != '[') + + if (term_get_char(&c) || c != '[') return -1; n[0] = 0; while (1) { - c = getc(); - if (c == ';') { - i++; - if (i >= num) + if (!term_get_char(&c)) { + if (c == ';') { + i++; + if (i >= num) + return -1; + n[i] = 0; + continue; + } else if (c == end_char) { + break; + } else if (c > '9' || c < '0') { return -1; - n[i] = 0; - continue; - } else if (c == end_char) { - break; - } else if (c > '9' || c < '0') { + } + + /* Read one more decimal position */ + n[i] *= 10; + n[i] += c - '0'; + } else { return -1; } - - /* Read one more decimal position */ - n[i] *= 10; - n[i] += c - '0'; } if (i != num - 1) return -1; @@ -196,7 +213,6 @@ static int query_console_serial(int *rows, int *cols) { int ret = 0; int n[2]; - u64 timeout; /* Empty input buffer */ while (tstc()) @@ -216,14 +232,6 @@ static int query_console_serial(int *rows, int *cols) ESC "[999;999H" /* Move to bottom right corner */ ESC "[6n"); /* Query cursor position */ - /* Allow up to one second for a response */ - timeout = timer_get_us() + 1000000; - while (!tstc()) - if (timer_get_us() > timeout) { - ret = -1; - goto out; - } - /* Read {rows,cols} */ if (term_read_reply(n, 2, 'R')) { ret = 1; -- 2.20.1

1 0

[U-Boot] [PATCH v2 1/1] efi_loader: Patch non-runtime code out at ExitBootServices already
by Heinrich Schuchardt 11 Mar '19

11 Mar '19

From: Alexander Graf <agraf(a)suse.de> While discussing something compeltely different, Ard pointed out that it might be legal to omit calling SetVirtualAddressMap altogether. There is even a patch on the Linux Kernel Mailing List that implements such behavior by now: https://patchwork.kernel.org/patch/10782393/ While that sounds great, we currently rely on the SetVirtualAddressMap call to remove all references to code that would not work outside of boot services. So let's patch out those bits already on the call to ExitBootServices, so that we can successfully run even when an OS chooses to omit any call to SetVirtualAddressMap. Reported-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Alexander Graf <agraf(a)suse.de> OpenBSD is not calling SetVirtualAddressMap on ARM 32 bit. Adjust selftest: expect 'U-Boot' instead of 'resetting'. Reviewed-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- v2 Adjust selftest: expect 'U-Boot' instead of 'resetting'. --- include/efi_loader.h | 2 ++ lib/efi_loader/efi_boottime.c | 1 + lib/efi_loader/efi_runtime.c | 29 ++++++++++++++++++++--------- test/py/tests/test_efi_selftest.py | 4 ++-- 4 files changed, 25 insertions(+), 11 deletions(-) diff --git a/include/efi_loader.h b/include/efi_loader.h index 512880ab8fb..82db7775c72 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -310,6 +310,8 @@ void efi_save_gd(void); void efi_restore_gd(void); /* Call this to relocate the runtime section to an address space */ void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map); +/* Call this when we start to live in a runtime only world */ +void efi_runtime_detach(ulong offset); /* Call this to set the current device name */ void efi_set_bootdev(const char *dev, const char *devnr, const char *path); /* Add a new object to the object list. */ diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index bd8b8a17ae7..233bca78e0a 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -1967,6 +1967,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(efi_handle_t image_handle, bootm_disable_interrupts(); /* Disable boot time services */ + efi_runtime_detach((ulong)gd->relocaddr); systab.con_in_handle = NULL; systab.con_in = NULL; systab.con_out_handle = NULL; diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index 636dfdab39d..17d22d429e2 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -276,15 +276,11 @@ struct efi_runtime_detach_list_struct { void *patchto; }; -static const struct efi_runtime_detach_list_struct efi_runtime_detach_list[] = { +static struct efi_runtime_detach_list_struct efi_runtime_detach_list[] = { { /* do_reset is gone */ .ptr = &efi_runtime_services.reset_system, .patchto = efi_reset_system, - }, { - /* invalidate_*cache_all are gone */ - .ptr = &efi_runtime_services.set_virtual_address_map, - .patchto = &efi_unimplemented, }, { /* RTC accessors are gone */ .ptr = &efi_runtime_services.get_time, @@ -328,7 +324,15 @@ static bool efi_runtime_tobedetached(void *p) return false; } -static void efi_runtime_detach(ulong offset) +/** + * efi_runtime_detach() - Remove any dependency on non-runtime sections + * + * This function patches all remaining code to be self-sufficient inside + * runtime sections. Any calls to non-runtime will be removed after this. + * + * @offset: relocaddr for pre-set_v_a_space, offset to VA after + */ +__efi_runtime void efi_runtime_detach(ulong offset) { int i; ulong patchoff = offset - (ulong)gd->relocaddr; @@ -344,6 +348,8 @@ static void efi_runtime_detach(ulong offset) /* Update CRC32 */ efi_update_table_header_crc32(&efi_runtime_services.hdr); + + invalidate_icache_all(); } /* Relocate EFI runtime to uboot_reloc_base = offset */ @@ -430,19 +436,25 @@ void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map) * @virtmap: virtual address mapping information * Return: status code */ -static efi_status_t EFIAPI efi_set_virtual_address_map( +static __efi_runtime efi_status_t EFIAPI efi_set_virtual_address_map( unsigned long memory_map_size, unsigned long descriptor_size, uint32_t descriptor_version, struct efi_mem_desc *virtmap) { + static __efi_runtime_data bool is_patched; int n = memory_map_size / descriptor_size; int i; int rt_code_sections = 0; + if (is_patched) + return EFI_INVALID_PARAMETER; + EFI_ENTRY("%lx %lx %x %p", memory_map_size, descriptor_size, descriptor_version, virtmap); + is_patched = true; + /* * TODO: * Further down we are cheating. While really we should implement @@ -514,8 +526,7 @@ static efi_status_t EFIAPI efi_set_virtual_address_map( map->physical_start + gd->relocaddr; efi_runtime_relocate(new_offset, map); - /* Once we're virtual, we can no longer handle - complex callbacks */ + /* We need to repatch callbacks for their new VA */ efi_runtime_detach(new_offset); return EFI_EXIT(EFI_SUCCESS); } diff --git a/test/py/tests/test_efi_selftest.py b/test/py/tests/test_efi_selftest.py index 36b35ee536b..6f5b2b8f406 100644 --- a/test/py/tests/test_efi_selftest.py +++ b/test/py/tests/test_efi_selftest.py @@ -20,7 +20,7 @@ def test_efi_selftest(u_boot_console): if m != 0: raise Exception('Failures occurred during the EFI selftest') u_boot_console.run_command(cmd='', wait_for_echo=False, wait_for_prompt=False); - m = u_boot_console.p.expect(['resetting', 'U-Boot']) + m = u_boot_console.p.expect(['U-Boot']) if m != 0: raise Exception('Reset failed during the EFI selftest') u_boot_console.restart_uboot(); @@ -46,7 +46,7 @@ def test_efi_selftest_watchdog_reboot(u_boot_console): assert '\'watchdog reboot\'' in output u_boot_console.run_command(cmd='setenv efi_selftest watchdog reboot') u_boot_console.run_command(cmd='bootefi selftest', wait_for_prompt=False) - m = u_boot_console.p.expect(['resetting', 'U-Boot']) + m = u_boot_console.p.expect(['U-Boot']) if m != 0: raise Exception('Reset failed in \'watchdog reboot\' test') u_boot_console.restart_uboot(); -- 2.20.1

1 0

Re: [U-Boot] [U-Boot-DM] pre-reloc fdt scan for non-top-level nodes
by Simon Glass 10 Mar '19

10 Mar '19

(We don't use the -dm mailing list...perhaps it should be deleted?) On Wed, 27 Feb 2019 at 09:22, viktor babrian <viktor.babrian(a)gmail.com> wrote: > Hi, > > as far as I understood, the pre-reloc device binding of drivers having > DM_FLAG_PRE_RELOC flag set is only performed for top-level devices - > at least that is what I experience. Is this intentional? What is the > concept there? > I am trying to use a spi slave display that is by default described as > a node under root/soc/spiX. We have the device working under Linux. I > understand these displays are not supported as is in u-boot so I > ported some Linux code and made some minor mods in the video uclass. > Still I do not have memory reserved for the frame-buffer and debugging > shows that it is because bind() is not invoked pre-reloc. And it is > not invoked because dm_extended_scan_fdt() parses top-level nodes > only. > I wonder if that pre-reloc scan is so for some purpose because a > recursive scan would seemingly be justified in my case. > (or am I just missing something?) > > Any comments are welcome, > Thanks, > Viktor > _______________________________________________ > U-Boot-DM mailing list > U-Boot-DM(a)lists.denx.de > https://lists.denx.de/listinfo/u-boot-dm >

1 1

[U-Boot] [PATCH 0/2] syscon: update syscon_regmap_lookup_by_phandle
by Patrick Delaunay 10 Mar '19

10 Mar '19

Change the function syscon_regmap_lookup_by_phandle() introduced by commit 6c3af1f24e4b ("syscon: dm: Add a new method to get a regmap from DTS") to have Linux-compatible syscon API and add test for this case: phandle to node with generic "syscon" compatible not bound as syscon UCLASS by default. Without the patch the added test failed. And I also update sysreset-syscon driver to use this function and simplify the code, tested on my stm32mp1 board with: rcc_reboot: rcc-reboot@50000000 { compatible = "syscon-reboot"; regmap = <&rcc>; offset = <0x404>; mask = <0x1>; }; rcc: rcc@50000000 { compatible = "st,stm32mp1-rcc", "syscon"; reg = <0x50000000 0x1000>; #clock-cells = <1>; #reset-cells = <1>; }; PS: compatible st,stm32mp1-rcc is bound to driver drivers/misc/stm32_rcc.c Patrick Delaunay (2): syscon: update syscon_regmap_lookup_by_phandle sysreset: use syscon_regmap_lookup_by_phandle arch/sandbox/dts/test.dts | 3 +- drivers/core/syscon-uclass.c | 83 +++++++++++++++++++++++++++----------- drivers/sysreset/sysreset_syscon.c | 15 +------ test/dm/syscon.c | 7 ++++ 4 files changed, 70 insertions(+), 38 deletions(-) -- 2.7.4

2 3

[U-Boot] [PATCH] fdt: Remove duplicate code
by Thierry Reding 10 Mar '19

10 Mar '19

From: Thierry Reding <treding(a)nvidia.com> Commit 6d29cc7dcf2d ("fdt: Fixup only valid memory banks") ended up being merged twice, first as: commit 6d29cc7dcf2d35966aa0b6119fd1cbca0d21d5e6 Author: Thierry Reding <treding(a)nvidia.com> AuthorDate: Tue Jan 30 11:34:17 2018 +0100 Commit: Simon Glass <sjg(a)chromium.org> CommitDate: Sun Feb 18 12:53:38 2018 -0700 fdt: Fixup only valid memory banks Memory banks with address 0 and size 0 are empty and should not be passed to the OS via device tree. Signed-off-by: Thierry Reding <treding(a)nvidia.com> Acked-by: Stephen Warren <swarren(a)nvidia.com> and later again, though this time it was v2: commit ed5af03f9bb8905f1e94d68ab49f22d7f061d75f Author: Thierry Reding <treding(a)nvidia.com> AuthorDate: Thu Feb 15 19:05:59 2018 +0100 Commit: Tom Rini <trini(a)konsulko.com> CommitDate: Fri Feb 23 10:40:50 2018 -0500 fdt: Fixup only valid memory banks Memory banks with address 0 and size 0 are empty and should not be passed to the OS via device tree. Acked-by: Stephen Warren <swarren(a)nvidia.com> Signed-off-by: Thierry Reding <treding(a)nvidia.com> The second version was slightly different, so the main hunk of the patch was applied twice. This isn't harmful because the code is idempotent, but it's wasteful to run the same code twice. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- common/fdt_support.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index 42583e3ed8c8..ab08a0114fee 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -456,12 +456,6 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks) if (!banks) return 0; - for (i = 0; i < banks; i++) - if (start[i] == 0 && size[i] == 0) - break; - - banks = i; - len = fdt_pack_reg(blob, tmp, start, size, banks); err = fdt_setprop(blob, nodeoffset, "reg", tmp, len); -- 2.20.1

2 1

[U-Boot] [PATCHv1 0/4] dm: cache: add dm cache driver
by Dinh Nguyen 10 Mar '19

10 Mar '19

Hi, Add a UCLASS_CACHE dm driver to handling the configuration of cache settings. Place this new driver under /drivers/cache. In this initial revision, the driver is only configuring what I think are essential cache settings. The more comprehensive cache settings can be done in the OS. Dinh Dinh Nguyen (4): ARM: pl310: Add macro's for handling tag and data latency mask dm: cache: Create a uclass for cache controller configs: socfpga: add imply pl310 cache controller ARM: socfpga: use the pl310 driver to configure the cache arch/arm/Kconfig | 1 + arch/arm/include/asm/pl310.h | 3 ++ arch/arm/mach-socfpga/misc.c | 16 ++----- drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/cache/Kconfig | 22 ++++++++++ drivers/cache/Makefile | 3 ++ drivers/cache/cache-l2x0.c | 82 ++++++++++++++++++++++++++++++++++++ drivers/cache/cache-uclass.c | 13 ++++++ include/dm/uclass-id.h | 1 + 10 files changed, 131 insertions(+), 13 deletions(-) create mode 100644 drivers/cache/Kconfig create mode 100644 drivers/cache/Makefile create mode 100644 drivers/cache/cache-l2x0.c create mode 100644 drivers/cache/cache-uclass.c -- 2.20.0

3 10

[U-Boot] [PATCH v3 00/13] net: Add Allwinner EMAC CLK, RESET support
by Jagan Teki 10 Mar '19

10 Mar '19

This is v2 version for Allwinner EMAC CLK, RESET support, which was initially be a part of previous series[1]. Changes for v3: - rebase on master - collecet review tags from Simon - fixed the comment by Simon, keep clk_get_by_indexed_prop() and call clk_get_by_index_tail Changes for v2: - rebase on master - add dm tests for new clk and reset functions. Any inputs? Jagan. [1] https://patchwork.ozlabs.org/cover/1039666/ Jagan Teki (13): clk: sunxi: Implement A10 EMAC clocks net: sunxi_emac: Add CLK support net: sun8i_emac: Retrieve GMAC clock via 'syscon' phandle clk: Get the CLK by index without device clk: Use clk_get_by_index_tail() test/dm: clk: Add clk_get_by_index[_nodev] test reset: Get the RESET by index without device test/dm: reset: Add reset_get_by_index[_nodev] test clk: sunxi: Implement EMAC, GMAC clocks, resets net: sun8i_emac: Add CLK and RESET support clk: sunxi: h3: Implement EPHY CLK and RESET net: sun8i_emac: Add EPHY CLK and RESET support board: sunxi: gmac: Remove Ethernet clock and reset board/sunxi/gmac.c | 8 -- drivers/clk/clk-uclass.c | 75 ++++++++++---- drivers/clk/sunxi/clk_a10.c | 1 + drivers/clk/sunxi/clk_a10s.c | 1 + drivers/clk/sunxi/clk_a31.c | 2 + drivers/clk/sunxi/clk_a64.c | 2 + drivers/clk/sunxi/clk_a83t.c | 2 + drivers/clk/sunxi/clk_h3.c | 6 ++ drivers/clk/sunxi/clk_h6.c | 4 + drivers/clk/sunxi/clk_r40.c | 3 + drivers/net/sun8i_emac.c | 184 ++++++++++++++++++++++++----------- drivers/net/sunxi_emac.c | 28 ++++-- drivers/reset/reset-uclass.c | 53 ++++++---- include/clk.h | 15 +++ include/reset.h | 16 +++ test/dm/clk.c | 21 ++++ test/dm/reset.c | 23 +++++ 17 files changed, 336 insertions(+), 108 deletions(-) -- 2.18.0.321.gffc6fa0e3

3 24

[U-Boot] Pincontroller not getting initialized on imx6 in SPL with SPL_PINCTRL and OF_CONTROL
by Adam Ford 10 Mar '19

10 Mar '19

I am trying to remove the manual pinmuxing code from the board file. In an effort to accomplish this, I am trying to get SPL_OF_CONTROL and SPL_PINCTRL to let me use the device tree(s) to initialize pin muxing. I have the following defined: CONFIG_SPL_PINCTRL=y CONFIG_SPL_PINCTRL_FULL=y CONFIG_SPL_PINCTRL_GENERIC=y CONFIG_SPL_PINMUX=y along with CONFIG_PINCTRL_IMX=y CONFIG_PINCTRL_IMX6=y I put some debugging code into the imx6 pinctrl and I can see that U-Boot initializes it, but that same debug message doesn't appear in SPL. I looked through the spl build directory, and I can see the drivers have been built, and the map file shows they exist, but for some reason, it doesn't initalize. If I remove the UART pin-muxing from my board file, the text for SPL doesn't' appear at all, so it's clear pinctrl isn't setting up the proper muxing yet. I am trying to figure out how/where the pinctrl system gets initialized in SPL, and I was hoping someone might have some insight. thanks, adam

3 6