Skip to content
Snippets Groups Projects
  1. Aug 07, 2023
  2. May 06, 2023
  3. Apr 28, 2023
  4. Apr 25, 2023
  5. Apr 07, 2023
    • Hai Pham's avatar
      ARM: rmobile: Add R-Car Generation 4 support · 5a3b0742
      Hai Pham authored
      
      This adds R-Car Generation 4 (Gen4) support as Renesas ARM64 SoC.
      
      In this version, reusing R-Car Gen3 lowlevel initialize routine [1]
      and R-Car Gen3 memory map tables [2] .
      
      [1] arch/arm/mach-rmobile/lowlevel_init_gen3.S
      [2] arch/arm/mach-rmobile/memmap-gen3.c
      
      Reviewed-by: default avatarMarek Vasut <marek.vasut+renesas@mailbox.org>
      Signed-off-by: default avatarHai Pham <hai.pham.ud@renesas.com>
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@mailbox.org>
      [Marek: - Enable DTO support by default
              - Sort the Kconfig lists
      	- Select RCAR_64 Kconfig option to pull in all the shared
      	  Kconfig options with Gen3, and use where applicable to
      	  deduplicate entries.
      	- Fix reference [2] typo in commit message
      	- Drop config options moved to Kconfig, rename rest to CFG_
      	  accordingly to synchronize with upstream changes. Drop
      	  removed CONFIG_VERY_BIG_RAM.
              - Move board size limit to arch/Kconfig
      	- Move GICR_BASE to headers instead of common config]
      5a3b0742
  6. Mar 30, 2023
  7. Mar 27, 2023
  8. Jan 10, 2023
  9. Dec 13, 2022
  10. Dec 05, 2022
  11. Nov 10, 2022
    • Tom Rini's avatar
      Convert CONFIG_SYS_MONITOR_LEN to Kconfig · 08574ed3
      Tom Rini authored
      
      This converts the following to Kconfig:
         CONFIG_SYS_MONITOR_LEN
      
      To do this, we set a default of 0 for everyone because there are a
      number of cases where we define CONFIG_SYS_MONITOR_LEN but the only
      impact is that we set TOTAL_MALLOC_LEN to be CONFIG_SYS_MALLOC_LEN +
      CONFIG_ENV_SIZE, so we must continue to allow all boards to set this
      value. Update the SPL code to use 200 KB as the default raw U-Boot size
      directly, if we don't have a real CONFIG_SYS_MONITOR_LEN value.
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      08574ed3
  12. Nov 07, 2022
  13. Oct 31, 2022
  14. Oct 19, 2022
    • André Przywara's avatar
      sunxi: Kconfig: introduce SUNXI_MINIMUM_DRAM_MB · 1bf98bd4
      André Przywara authored
      
      Traditionally we assumed that every Allwinner board would come with at
      least 256 MB of DRAM, and set our DRAM layout accordingly. This affected
      both the default load addresses, but also U-Boot's own address
      expectations (like being loaded at 160 MB).
      
      Some SoCs come with co-packaged DRAM, but only provide 32 or 64MB. So
      far we special-cased those *chips*, as there was only one chip per DRAM
      size. However new chips force us to take a more general approach.
      
      Introduce a Kconfig symbol, which provides the minimum DRAM size of the
      board. If nothing else is specified, we use 256 MB, and default to
      smaller values for those co-packaged SoCs.
      Then select the different DRAM maps according to this new symbol, so
      that different SoCs with the same DRAM size can share those definitions.
      
      Inspired by an idea from Icenowy.
      
      This is just refactoring: compiled for all boards before and after this
      patch: the binaries were identical.
      
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarJernej Skrabec <jernej.skrabec@gmail.com>
      1bf98bd4
  15. Sep 26, 2022
  16. Sep 18, 2022
  17. Jun 23, 2022
    • Andrew Scull's avatar
      test: fuzz: Add framework for fuzzing · 36f641c5
      Andrew Scull authored and Tom Rini's avatar Tom Rini committed
      
      Add the basic infrastructure for declaring fuzz tests and a command to
      invoke them.
      
      Signed-off-by: default avatarAndrew Scull <ascull@google.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      36f641c5
    • Andrew Scull's avatar
      sandbox: Add support for Address Sanitizer · 1e578ed2
      Andrew Scull authored and Tom Rini's avatar Tom Rini committed
      
      Add CONFIG_ASAN to build with the Address Sanitizer. This only works
      with the sandbox so the config is likewise dependent. The resulting
      executable will have ASAN instrumentation, including the leak detector
      that can be disabled with the ASAN_OPTIONS environment variable:
      
         ASAN_OPTIONS=detect_leaks=0 ./u-boot
      
      Since u-boot uses its own dlmalloc, dynamic allocations aren't
      automatically instrumented, but stack variables and globals are.
      
      Instrumentation could be added to dlmalloc to poison and unpoison memory
      as it is allocated and deallocated, and to introduce redzones between
      allocations. Alternatively, the sandbox may be able to play games with
      the system allocator and somehow still keep the required memory
      abstraction. No effort to address dynamic allocation is made by this
      patch.
      
      The config is not yet enabled for any targets by default.
      
      Signed-off-by: default avatarAndrew Scull <ascull@google.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      1e578ed2
  18. Jun 06, 2022
    • Tom Rini's avatar
      Migrate CUSTOM_SYS_INIT_SP_ADDR to Kconfig using system-constants.h · eaf6ea6a
      Tom Rini authored
      
      - Make all users of CUSTOM_SYS_INIT_SP_ADDR reference SYS_INIT_SP_ADDR
      - Introduce HAS_CUSTOM_SYS_INIT_SP_ADDR to allow for setting the stack
        pointer directly, otherwise we use the common calculation.
      - On some platforms that were using the standard calculation but did not
        set CONFIG_SYS_INIT_RAM_SIZE / CONFIG_SYS_INIT_RAM_ADDR, set them.
      - On a small number of platforms that were not subtracting
        GENERATED_GBL_DATA_SIZE do so now via the standard calculation.
      - CONFIG_SYS_INIT_SP_OFFSET is now widely unused, so remove it from most
        board config header files.
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      eaf6ea6a
    • Tom Rini's avatar
      Convert CONFIG_SYS_BARGSIZE to Kconfig · 6889412a
      Tom Rini authored
      
      This converts the following to Kconfig:
         CONFIG_SYS_BARGSIZE
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      6889412a
  19. May 28, 2022
  20. May 05, 2022
  21. May 02, 2022
  22. Apr 21, 2022
    • This contributor prefers not to receive mails's avatar
      SPL: Do not enable SPL_SYS_MALLOC_SIMPLE without SPL_FRAMEWORK by default · b6169470
      This contributor prefers not to receive mails authored and Tom Rini's avatar Tom Rini committed
      
      On P2020 board is SPL malloc simple always failing with error and loops:
      
        SD boot...
        alloc space exhausted
        Bad trap at PC: f8f8b5f0, SR: 21200, vector=d00
        NIP: 00000000 XER: 00000000 LR: 00000000 REGS: f8f8b5f0 TRAP: 20000000 DAR: 00000000
        MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
      
        GPR00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        Call backtrace:
        Exception in kernel pc f8f8b5f0 signal 0
      
      Inspection showed that gd->malloc_limit is zero. And it is because
      generally SPL_FRAMEWORK initialize SPL's gd->malloc_limit. But when
      SPL_FRAMEWORK is not enabled then in most cases nobody initialize
      gd->malloc_limit and so SPL malloc simple does not work.
      
      So disable SPL_SYS_MALLOC_SIMPLE by default when SPL_FRAMEWORK is not
      enabled. SPL_SYS_MALLOC_SIMPLE can be disabled only by setting
      SPL_SYS_MALLOC_F_LEN to zero. So do it.
      
      This change fixes SPL error "alloc space exhausted" on P2020 board.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      b6169470
  23. Apr 20, 2022
    • Tom Rini's avatar
      am33xx: Update SYS_MALLOC_F_LEN to use 0x2000 as the default · 4448d0c7
      Tom Rini authored
      
      A number of platforms here had already been increasing the size a bit,
      so lets moving all of them up.
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      4448d0c7
    • Tom Rini's avatar
      Kconfig: Change SYS_MALLOC_F_LEN default to 0x2000 · e0568924
      Tom Rini authored
      
      The most commonly used value today is 0x2000 and not 0x400.  Rework the
      Kconfig logic to use this more frequently used value as the default.
      
      Cc: Andrew F. Davis <afd@ti.com>
      Cc: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
      Cc: Alexey Brodkin <abrodkin@synopsys.com>
      Cc: Alison Wang <alison.wang@nxp.com>
      Cc: Anastasiia Lukianenko <anastasiia_lukianenko@epam.com>
      Cc: Andes <uboot@andestech.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Bharat Gooty <bharat.gooty@broadcom.com>
      Cc: David Lechner <david@lechnology.com>
      Cc: Dzmitry Sankouski <dsankouski@gmail.com>
      Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
      Cc: Eugeniy Paltsev <paltsev@synopsys.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Gerald Kerma <dreagle@doukki.net>
      Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
      Cc: Holger Brunck <holger.brunck@hitachienergy.com>
      Cc: Jaehoon Chung <jh80.chung@samsung.com>
      Cc: Jassi Brar <jaswinder.singh@linaro.org>
      Cc: Kristian Amlie <kristian.amlie@northern.tech>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: Liviu Dudau <liviu.dudau@foss.arm.com>
      Cc: Luka Perkov <luka.perkov@sartura.hr>
      Cc: Lukasz Majewski <lukma@denx.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Masami Hiramatsu <masami.hiramatsu@linaro.org>
      Cc: Matthias Brugger <mbrugger@suse.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Minkyu Kang <mk7.kang@samsung.com>
      Cc: Nikita Kiryanov <nikita@compulab.co.il>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
      Cc: Otavio Salvador <otavio@ossystems.com.br>
      Cc: Patrice Chotard <patrice.chotard@foss.st.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Paul Kocialkowski <contact@paulk.fr>
      Cc: Priyanka Jain <priyanka.jain@nxp.com>
      Cc: Rajesh Bhagat <rajesh.bhagat@nxp.com>
      Cc: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
      Cc: Sergey Temerkhanov <s.temerkhanov@gmail.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Stefan Bosch <stefan_b@posteo.net>
      Cc: Stephan Gerhold <stephan@gerhold.net>
      Cc: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
      Cc: Thomas Chou <thomas@wytron.com.tw>
      Cc: Thomas Fitzsimmons <fitzsim@fitzsim.org>
      Cc: Thomas Weber <weber@corscience.de>
      Cc: Tony Dinh <mibodhi@gmail.com>
      Cc: Trevor Woerner <twoerner@gmail.com>
      Cc: Vitaly Andrianov <vitalya@ti.com>
      Cc: Vladimir Zapolskiy <vz@mleia.com>
      Cc: liuhao <liuhao@phytium.com.cn>
      Cc: lixinde <lixinde@phytium.com.cn>
      Cc: shuyiqi <shuyiqi@phytium.com.cn>
      Cc: weichangzheng <weichangzheng@phytium.com.cn>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      Reviewed-by: Thomas Chou's avatarThomas Chou <thomas@wytron.com.tw>
      Reviewed-by: default avatarMasami Hiramatsu <masami.hiramatsu@linaro.org>
      Reviewed-by: default avatarTony Dinh <mibodhi@gmail.com>
      Reviewed-by: Patrice Chotard's avatarPatrice Chotard <patrice.chotard@foss.st.com>
      Reviewed-by: default avatarKristian Amlie <kristian.amlie@northern.tech>
      e0568924
  24. Apr 19, 2022
  25. Apr 14, 2022
    • Tom Rini's avatar
      sandbox: Increase default SYS_MALLOC_LEN · 46d940ce
      Tom Rini authored
      
      Increase the malloc pool on sandbox in order to avoid spurious errors
      such as:
      ___________________ test_ut[ut_dm_dm_test_video_comp_bmp32] ____________________
      test/py/tests/test_ut.py:43: in test_ut
          assert output.endswith('Failures: 0')
      E   AssertionError: assert False
      E    +  where False = <built-in method endswith of str object at 0x7f5de85efb20>('Failures: 0')
      E    +    where <built-in method endswith of str object at 0x7f5de85efb20> = 'Test: dm_test_video_comp_bmp32: video.c\r\r\nSDL renderer does not exist\r\r\ntest/dm/video.c:86, compress_frame_buff..._test_video_comp_bmp32(): 2024 == compress_frame_buffer(uts, dev): Expected 0x7e8 (2024), got 0x1 (1)\r\r\nFailures: 2'.endswith
      
      Cc: Ramon Fried <rfried.dev@gmail.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      46d940ce
  26. Apr 11, 2022
    • Sean Anderson's avatar
      Add valgrind headers to U-Boot · fba0882b
      Sean Anderson authored and Tom Rini's avatar Tom Rini committed
      
      Valgrind uses magic code sequences to define an ABI that the client may use
      to request behavior from the host. In particular, this may be used to
      inform valgrind about custom allocators, such as the one used in U-Boot.
      
      This adds headers defining these sequences to U-Boot. It also adds a config
      option to disable emission of these sequences entirely, in the (likely)
      event that the user does not wish to use valgrind. Note that this option is
      called NVALGRIND upstream, but was renamed (and inverted) to
      CONFIG_VALGRIND. Aside from this and the conversion of a few instances of
      VALGRIND_DO_CLIENT_REQUEST_EXPR to STMT, these headers are unmodified.
      
      These headers were copied from valgrind 3.16.1-4 as distributed in Arch
      Linux. They are licensed with the bzip2 1.16 license. This appears to be a
      BSD license with some clauses from Zlib.
      
      Signed-off-by: default avatarSean Anderson <seanga2@gmail.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      fba0882b
    • Peng Fan's avatar
      Kconfig: Fix SYS_MALLOC_F_LEN for i.MX8MQ · b5989572
      Peng Fan authored and Tom Rini's avatar Tom Rini committed
      
      i.MX8MQ use SYS_MALLOC_F_LEN 0x2000, not 0x10000. The OCRAM_S only has
      32KB memory, use 0x10000 will make SPL not bootable.
      
      Signed-off-by: Peng Fan's avatarPeng Fan <peng.fan@nxp.com>
      Reviewed-by: default avatarMichael Trimarchi <michael@amarulasolutions.com>
      Reviewed-by: default avatarFabio Estevam <festevam@denx.de>
      b5989572
  27. Apr 08, 2022
  28. Apr 07, 2022
    • Fabio Estevam's avatar
      imx8/ls10xx: Use a sane SYS_MALLOC_F_LEN default · 545eceb5
      Fabio Estevam authored and Tom Rini's avatar Tom Rini committed
      
      When adding new features to imx8m boards, such as DM clock support,
      the malloc area can be exhausted.
      
      To avoid such issue, provide a reasonable default for the
      SYS_MALLOC_F_LEN size.
      
      Quoting Tom Rini:
      
      "This seems to be an area where everyone is either:
      - Kicking the value up a bit for themselves
      - Having hard to figure out problems booting the platform because it's
        too small a value until they see someone else picked a larger value.
      
      So lets raise these a bit and get some acks, please."
      
      Suggested-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      Signed-off-by: default avatarFabio Estevam <festevam@denx.de>
      Tested-by: Adam Ford <aford173@gmail.com> #imx8mm-beacon, imx8mn-beacon
      Tested-by: default avatarHeiko Thiery <heiko.thiery@gmail.com>
      545eceb5
  29. Apr 06, 2022
  30. Mar 25, 2022
  31. Feb 09, 2022
  32. Feb 04, 2022
Loading