June 2018 - U-Boot

[U-Boot] [PATCH V2 1/4] imx: mx7: psci: add cpu hotplug support
by Anson Huang 25 Jun '18

25 Jun '18

This patch adds cpu hotplug support, previous imx_cpu_off implementation is NOT safe, a CPU can NOT power down itself in runtime, it will cause system bus hang due to pending transaction. So need to use other online CPU to kill it when it is ready for killed. Here use SRC parameter register and a magic number of ~0 as handshake for killing a offline CPU, when the online CPU checks the psci_affinity_info, it will help kill the offline CPU according to the magic number stored in SRC parameter register. Signed-off-by: Anson Huang <Anson.Huang(a)nxp.com> --- changes since V1: Defining magic number for CPU handshake; Improving SRC GPR register offset by using macros definition. no function change. arch/arm/mach-imx/mx7/psci-mx7.c | 41 ++++++++++++++++++++++++++++++++++++---- arch/arm/mach-imx/mx7/psci.S | 14 ++++++++++++++ 2 files changed, 51 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c index 7dc49bd..a5cccac 100644 --- a/arch/arm/mach-imx/mx7/psci-mx7.c +++ b/arch/arm/mach-imx/mx7/psci-mx7.c @@ -34,6 +34,14 @@ #define CCM_ROOT_WDOG 0xbb80 #define CCM_CCGR_WDOG1 0x49c0 +#define imx_cpu_gpr_entry_offset(cpu) \ + (SRC_BASE_ADDR + SRC_GPR1_MX7D + cpu * 8) +#define imx_cpu_gpr_para_offset(cpu) \ + (imx_cpu_gpr_entry_offset(cpu) + 4) + +#define IMX_CPU_SYNC_OFF ~0 +#define IMX_CPU_SYNC_ON 0 + static inline void imx_gpcv2_set_m_core_pgc(bool enable, u32 offset) { writel(enable, GPC_IPS_BASE_ADDR + offset); @@ -69,7 +77,7 @@ __secure void imx_enable_cpu_ca7(int cpu, bool enable) __secure int imx_cpu_on(int fn, int cpu, int pc) { - writel(pc, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D); + writel(pc, imx_cpu_gpr_entry_offset(cpu)); imx_gpcv2_set_core1_power(true); imx_enable_cpu_ca7(cpu, true); return 0; @@ -77,12 +85,37 @@ __secure int imx_cpu_on(int fn, int cpu, int pc) __secure int imx_cpu_off(int cpu) { - imx_enable_cpu_ca7(cpu, false); - imx_gpcv2_set_core1_power(false); - writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4); + /* + * We use the cpu jumping argument register to sync with + * imx_cpu_affinity() which is running on cpu0 to kill the cpu. + */ + writel(IMX_CPU_SYNC_OFF, imx_cpu_gpr_para_offset(cpu)); + return 0; } +__secure int imx_cpu_affinity(int cpu) +{ + u32 val; + + /* always ON for CPU0 */ + if (cpu == 0) + return PSCI_AFFINITY_LEVEL_ON; + + /* CPU1 is waiting for killed */ + if (readl(imx_cpu_gpr_para_offset(cpu)) == IMX_CPU_SYNC_OFF) { + imx_enable_cpu_ca7(cpu, false); + imx_gpcv2_set_core1_power(false); + writel(IMX_CPU_SYNC_ON, imx_cpu_gpr_para_offset(cpu)); + return PSCI_AFFINITY_LEVEL_OFF; + } + + val = readl(SRC_BASE_ADDR + SRC_A7RCR1) & + (1 << BP_SRC_A7RCR1_A7_CORE1_ENABLE); + + return val ? PSCI_AFFINITY_LEVEL_ON : PSCI_AFFINITY_LEVEL_OFF; +} + __secure void imx_system_reset(void) { struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR; diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S index 89dcf88..d6d19d5 100644 --- a/arch/arm/mach-imx/mx7/psci.S +++ b/arch/arm/mach-imx/mx7/psci.S @@ -57,4 +57,18 @@ psci_system_off: 3: wfi b 3b +.globl psci_affinity_info +psci_affinity_info: + push {lr} + + mov r0, #ARM_PSCI_RET_INVAL + cmp r2, #0 + bne out_affinity + + and r0, r1, #0xff + bl imx_cpu_affinity + +out_affinity: + pop {pc} + .popsection -- 2.7.4

1 3

[U-Boot] [PATCH 1/2] imx: imx6: Add comment to gpr_init function
by Michael Trimarchi 24 Jun '18

24 Jun '18

This function can be used only for some of the nxp SoC. Make it explicit in the comment. This adjust a bit commit 3aa4b703b483f165dd ("imx: imx6: Move gpr_init() function to soc.c") Signed-off-by: Michael Trimarchi <michael(a)amarulasolutions.com> --- arch/arm/mach-imx/mx6/soc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c index e8b6f77..2c87c6e 100644 --- a/arch/arm/mach-imx/mx6/soc.c +++ b/arch/arm/mach-imx/mx6/soc.c @@ -649,6 +649,11 @@ void imx_setup_hdmi(void) } #endif + +/* + * gpr_init() function is common for boards using MX6S, MX6DL, MX6D, + * MX6Q and MX6QP processors + */ void gpr_init(void) { struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR; -- 2.7.4

2 3

[U-Boot] Size of FDT image
by Yousf Ateya 24 Jun '18

24 Jun '18

Dears, I am calculating images check-sum in common/bootm.c (in function do_bootm_states <https://git.denx.de/?p=u-boot.git;a=blob;f=common/bootm.c;h=9493a306cd038d8…>) for security reasons. I am using contents of images structure to do so. Code is similar to this: int os_cs = checksum(images.os.image_start, images.os.image_len); //Always > consistent > int initrd_cs = checksum(images.initrd_start, images.initrd_end - > images.initrd_start); //Always consistent > int ft_cs = checksum(images.ft_addr, images.ft_len); //Changes after power > reset > > printf("Checksums: OS %d, initrd %d, FTD %d\n", os_cs, initrd_cs, ft_cs); > Both OS, and initrd images are working perfectly. FDT image checksum is the same through software reboots, but it changes after power reset (fully remove power, and connect power again); Which makes me suspect garbage data at end of images.ft_addr. I tried to do partial checksum for FTD image (only 80% of its size) int ft_cs = checksum(images.ft_addr, images.ft_len * 0.8); //Always > consistent > Then checksum worked perfectly through power resets. But it is not good idea to check-sum part of image only. I think there is unused area at the end of image length that changes in power resets. Is there a way to get actual FDT image length? Using version v2017.11 <https://git.denx.de/?p=u-boot.git;a=shortlog;h=refs/tags/v2017.11> -- This e-mail message is intended only for the use of the intended recipient(s). The information contained therein may be confidential or privileged, and its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please return it immediately to its sender at the above address and destroy it.

1 0

[U-Boot] Make menuconfig error - Status
by Duncan Hare 24 Jun '18

24 Jun '18

duncan@debian:~/archive$ git clone git://git.denx.de/u-boot.git Cloning into 'u-boot'... remote: Counting objects: 559898, done. remote: Compressing objects: 100% (97298/97298), done. Receiving objects: 100% (559898/559898), 113.79 MiB | 294.00 KiB/s, done. remote: Total 559898 (delta 462692), reused 551394 (delta 454519) Resolving deltas: 100% (462692/462692), done. duncan@debian:~/archive$ cd u-boot duncan@debian:~/archive/u-boot$ make menuconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/mconf.o YACC scripts/kconfig/zconf.tab.c scripts/kconfig/zconf.y:44 parser name defined to default :"parse" "scripts/kconfig/zconf.y", line 97: junk after `%%' in definition section Segmentation fault scripts/Makefile.lib:228: recipe for target 'scripts/kconfig/zconf.tab.c' failed make[1]: *** [scripts/kconfig/zconf.tab.c] Error 139 Makefile:492: recipe for target 'menuconfig' failed make: *** [menuconfig] Error 2 Where are we on this? Is there a fix? Thanks Duncan Hare 714 931 7952

2 2

[U-Boot] [PATCH 0/6] x86: efi: payload: Various fixes
by Bin Meng 24 Jun '18

24 Jun '18

This series includes 3 patches that were previously sent to ML but not applied, along with some new patches with various fixes on efi x86 payload support. For [01: efi.h: Do not use config options] and [02: x86: Change __kernel_size_t conditionals to use compiler provided defines], the changes are mainly adding some comments to describe the changes in more details. This series is available at u-boot-x86/efi2-working for testing. Alexander Graf (1): efi.h: Do not use config options Bin Meng (5): x86: Change __kernel_size_t conditionals to use compiler provided defines efi: stub: Move the use_uart assignment immediately after exit_boot_services() call x86: efi-x86_payload: Enable PRE_CONSOLE_BUFFER x86: efi: payload: Count in conventional memory above 4GB in DRAM bank cmd: efi: Fix wrong memory descriptor end address arch/x86/cpu/efi/payload.c | 3 +-- arch/x86/include/asm/posix_types.h | 3 ++- cmd/efi.c | 2 +- configs/efi-x86_payload32_defconfig | 2 ++ configs/efi-x86_payload64_defconfig | 2 ++ include/efi.h | 24 +++++++++++------------- lib/efi/Makefile | 4 ++-- lib/efi/efi_stub.c | 6 +++--- 8 files changed, 24 insertions(+), 22 deletions(-) -- 2.7.4

2 19

[U-Boot] [PATCH v2] patman: Support using a particular SMTP server
by Simon Glass 23 Jun '18

23 Jun '18

Some environments require providing the '--smtp-server' argument to 'git send-email'. Add support for this. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v2: - Fix 'get' typo tools/patman/README | 1 + tools/patman/gitutil.py | 6 +++++- tools/patman/patman.py | 5 ++++- 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/tools/patman/README b/tools/patman/README index 606780e2ed..7917fc8bdc 100644 --- a/tools/patman/README +++ b/tools/patman/README @@ -107,6 +107,7 @@ patman.py. For reference, the useful ones (at the moment) shown below ignore_errors: True process_tags: False verbose: True +smtp_server: /path/to/sendmail <<< diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py index 64ac0c8d3d..9905bb0bbd 100644 --- a/tools/patman/gitutil.py +++ b/tools/patman/gitutil.py @@ -332,7 +332,8 @@ def BuildEmailList(in_list, tag=None, alias=None, raise_on_error=True): return result def EmailPatches(series, cover_fname, args, dry_run, raise_on_error, cc_fname, - self_only=False, alias=None, in_reply_to=None, thread=False): + self_only=False, alias=None, in_reply_to=None, thread=False, + smtp_server=None): """Email a patch series. Args: @@ -348,6 +349,7 @@ def EmailPatches(series, cover_fname, args, dry_run, raise_on_error, cc_fname, Should be a message ID that this is in reply to. thread: True to add --thread to git send-email (make all patches reply to cover-letter or first patch in series) + smtp_server: SMTP server to use to send patches Returns: Git command that was/would be run @@ -405,6 +407,8 @@ def EmailPatches(series, cover_fname, args, dry_run, raise_on_error, cc_fname, to = BuildEmailList([os.getenv('USER')], '--to', alias, raise_on_error) cc = [] cmd = ['git', 'send-email', '--annotate'] + if smtp_server: + cmd.append('--smtp-server=%s' % smtp_server) if in_reply_to: if type(in_reply_to) != str: in_reply_to = in_reply_to.encode('utf-8') diff --git a/tools/patman/patman.py b/tools/patman/patman.py index 8d2c78235a..7c8ba441b3 100755 --- a/tools/patman/patman.py +++ b/tools/patman/patman.py @@ -60,6 +60,8 @@ parser.add_option('--no-check', action='store_false', dest='check_patch', help="Don't check for patch compliance") parser.add_option('--no-tags', action='store_false', dest='process_tags', default=True, help="Don't process subject tags as aliaes") +parser.add_option('--smtp-server', type='str', + help="Specify the SMTP server to 'git send-email'") parser.add_option('-T', '--thread', action='store_true', dest='thread', default=False, help='Create patches as a single thread') @@ -165,7 +167,8 @@ else: if its_a_go: cmd = gitutil.EmailPatches(series, cover_fname, args, options.dry_run, not options.ignore_bad_tags, cc_file, - in_reply_to=options.in_reply_to, thread=options.thread) + in_reply_to=options.in_reply_to, thread=options.thread, + smtp_server=options.smtp_server) else: print(col.Color(col.RED, "Not sending emails due to errors/warnings")) -- 2.18.0.rc1.244.gcf134e6275-goog

1 1

[U-Boot] [PATCH v3 1/2] patman: add option for limiting the Cc list
by Chris Packham 23 Jun '18

23 Jun '18

Many mailing-lists consider a long Cc list a sign of spam and will either drop the message or mark it for moderation. Because patman automatically invokes get_maintainer.pl the Cc list can expand unexpectedly. Allow the user to specify a limit for the Cc list. This limit is applied after removing any known bouncing addresses. By default no limit is applied. Signed-off-by: Chris Packham <judge.packham(a)gmail.com> --- I've fallen foul of the u-boot ML Cc limit a few times recently. I'm not sure what the actual limit is so I've left patman's default behaviour unlimited. Changes in v3: - update func_test Changes in v2: - make default None to allow limit 0 to suppress the list completely tools/patman/func_test.py | 3 ++- tools/patman/patman.py | 4 +++- tools/patman/series.py | 5 ++++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/tools/patman/func_test.py b/tools/patman/func_test.py index 85372f3c0ade..3f7e03214470 100644 --- a/tools/patman/func_test.py +++ b/tools/patman/func_test.py @@ -149,7 +149,8 @@ class TestFunctional(unittest.TestCase): patchstream.InsertCoverLetter(cover_fname, series, count) series.DoChecks() cc_file = series.MakeCcFile(process_tags, cover_fname, - not ignore_bad_tags, add_maintainers) + not ignore_bad_tags, add_maintainers, + None) cmd = gitutil.EmailPatches(series, cover_fname, args, dry_run, not ignore_bad_tags, cc_file, in_reply_to=in_reply_to, thread=None) diff --git a/tools/patman/patman.py b/tools/patman/patman.py index 8d2c78235a7e..e01510df9c0f 100755 --- a/tools/patman/patman.py +++ b/tools/patman/patman.py @@ -38,6 +38,8 @@ parser.add_option('-i', '--ignore-errors', action='store_true', parser.add_option('-m', '--no-maintainers', action='store_false', dest='add_maintainers', default=True, help="Don't cc the file maintainers automatically") +parser.add_option('-l', '--limit-cc', dest='limit', type='int', + default=None, help='Limit the cc list to LIMIT entries [default: %default]') parser.add_option('-n', '--dry-run', action='store_true', dest='dry_run', default=False, help="Do a dry run (create but don't email patches)") parser.add_option('-p', '--project', default=project.DetectProject(), @@ -157,7 +159,7 @@ else: cc_file = series.MakeCcFile(options.process_tags, cover_fname, not options.ignore_bad_tags, - options.add_maintainers) + options.add_maintainers, options.limit) # Email the patches out (giving the user time to check / cancel) cmd = '' diff --git a/tools/patman/series.py b/tools/patman/series.py index d526d4ee91d3..2735afaf88fe 100644 --- a/tools/patman/series.py +++ b/tools/patman/series.py @@ -202,7 +202,7 @@ class Series(dict): print(col.Color(col.RED, str)) def MakeCcFile(self, process_tags, cover_fname, raise_on_error, - add_maintainers): + add_maintainers, limit): """Make a cc file for us to use for per-commit Cc automation Also stores in self._generated_cc to make ShowActions() faster. @@ -215,6 +215,7 @@ class Series(dict): add_maintainers: Either: True/False to call the get_maintainers to CC maintainers List of maintainers to include (for testing) + limit: Limit the length of the Cc list Return: Filename of temp file created """ @@ -238,6 +239,8 @@ class Series(dict): print(col.Color(col.YELLOW, 'Skipping "%s"' % x)) cc = set(cc) - set(settings.bounces) cc = [m.encode('utf-8') if type(m) != str else m for m in cc] + if limit is not None: + cc = cc[:limit] all_ccs += cc print(commit.patch, ', '.join(set(cc)), file=fd) self._generated_cc[commit.patch] = cc -- 2.17.1

2 5

[U-Boot] memory info hand off on 32 bit arm
by valerij zaporogeci 23 Jun '18

23 Jun '18

Hi, could someone please answer these questions. On 32 bit arm, when interfacing with linux without device tree, ATAGs are used for hand off. The questions are about MEM32 atags. First, is it possible that there will be more than one MEM32 atag on a platform? in the 32 bit arm realm? thus - more than 1 SDRAM region. If so, then: are those regions (atags representing them) guaranteed to: 1) represent real disjoint areas in system space (no redundant splitting into adjacent areas) 2) not overlap and have no zero size 3) be ordered in ascending order in atag list I couldn't find any specification on this anywhere, maybe this will be read by someone who knows how uboot does prepare ATAGs and will be kind enough to answer. For which I thank in advance.

1 0

[U-Boot] buileman does not report error on qemu-x86_64
by Bin Meng 23 Jun '18

23 Jun '18

Hi Simon, Henrich, When I used buildman to build x86 targets, buildman did not complain any error on qemu-x86_64. But if I manually run 'make qemu-x86_64_defconfig;make', I get: Node '/binman/u-boot-spl-with-ucode-ptr': Cannot locate _dt_ucode_base_size symbol in u-boot This is quite weird. I tried to roll back to some older version U-Boot (like v2017.09), but the issue is still the same. Even if I reset the commit to the very first version that introduced the qemu-x86_64 support, I still got the same build error. Do you know anything that could cause this? Regards, Bin

1 1

[U-Boot] [BUG] qemu-x86_64_defconfig fails with panic("TSC frequency is ZERO");
by Heinrich Schuchardt 23 Jun '18

23 Jun '18

Hello Bin, Simon, sometimes qemu-x86_64_defconfig fails with panic("TSC frequency is ZERO") in drivers/timer/tsc_timer.c. The system may hang in an endless reboot loop with this error or recover after reboot. Do we need to panic? Or could we use some default value? Qemu version used for testing: 2.8.1. Best regards Heinrich

2 1