- 30 3月, 2021 15 次提交
-
-
由 Roger Pau Monné 提交于
The path in the Linux kernel dts directory is rockchip/rk3326-odroid-go2.dtb. That also seems to match the FDT path set on other boards (ie: rock64-rk3328 for example). Signed-off-by: NRoger Pau Monne <royger@FreeBSD.org> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Roger Pau Monné 提交于
Remove the unset of the EFI loader, it's possible for U-Boot to provide a EFI environment on this board, and it's also required by the FreeBSD loader which mandated EFI on Aarch64. Signed-off-by: NRoger Pau Monné <royger@FreeBSD.org> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Christoph Muellner 提交于
On Puma we have the environment at an offset of 16 kiB. On the eMMC this gives us 16 kiB for the environment before the SPL starts. On the SPI NOR we also have 16 kiB until end of flash. So let's increase the environment size from 8 kiB to its maximum of 16 kiB for both MMC and SPI NOR. Signed-off-by: NChristoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Christoph Muellner 提交于
A commit from last year re-imported the DTS files form the upstream kernel. By doing so the VDD_LOG regulator in the board's DTS was dropped. Let's restore this, but move it into the u-boot overlay to prevent this issue in the future. Fixes: 167efc2c ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux") Signed-off-by: NChristoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Peter Robinson 提交于
The Rock960 doesn't have SPI flash on-board, but the bits get enabled by default which means when booting we get some errors. Explicitly disable it to stop the errors. Signed-off-by: NPeter Robinson <pbrobinson@gmail.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Peter Robinson 提交于
Drop a irrelevent comment now the related configs have moved to the various config files. Signed-off-by: NPeter Robinson <pbrobinson@gmail.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
Adds the needed target option and drivers needed for correct bringup. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
This brings the actual rk3368-lion devicetree files from Linux 5.10 instead of using something separate. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
This is the state as of v5.10 + the recently added timer0 phandle targetted at the 5.12 merge window. With this the non-mainline nodes like the dmc move to a separate rk3368-u-boot.dtsi that is included from the board-specific -u-boot.dtsi files, similar to how rk3399 does this. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
This is the state as of v5.10 in Linux. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
With the STACK_R_ADDR at 0x600000 (6MB) we're competing with with the loading address of either u-boot or atf parts, so move that away to 0x4000000 (64MB) similar to rk3399. Only lion currently sets that at all but not sheep the second rk3368 board, so just move that to the Kconfig for rk3368 similar to rk3399 as well. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
To prevent running out of memory, increase SYS_MALLOC_F_LEN to 0x4000 similar to what rk3399 uses. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
Mimicing for example the rk3399, set the SYS_BOOTM_LEN to 64MB so that regular kernel images can get loaded without problems. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Heiko Stuebner 提交于
CONFIG_SYS_LOAD_ADDR currently is at 0x00280000 which is only 512KB behind the area where we load u-boot to, which depending on u-boot size may overlap at some point. So for safety just pick the same value rk3399 has and set CONFIG_SYS_LOAD_ADDR to 0x00800800 on rk3368 as well. Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Roger Pau Monné 提交于
Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL. Removing the setting from the defconfig allows U-Boot to load successfully. Signed-off-by: NRoger Pau Monné <royger@FreeBSD.org> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
- 29 3月, 2021 1 次提交
-
-
git://git.denx.de/u-boot-dm由 Tom Rini 提交于
binman support for expanding entries, connections misc fixes and improvements to sandbox, etc. x86 CBFS improvements x86 coreboot improvements
-
- 27 3月, 2021 24 次提交
-
-
由 Heinrich Schuchardt 提交于
On RISC-V the symbols __dyn_sym_start, dyn_sym_end are referenced in efi_runtime_relocate(). Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 T Karthik Reddy 提交于
Add spi memory operations to relocate manually when CONFIG_NEEDS_MANUAL_RELOC is enabled. Signed-off-by: NT Karthik Reddy <t.karthik.reddy@xilinx.com> Acked-by: NAshok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: NMichal Simek <michal.simek@xilinx.com> Reviewed-by: NPratyush Yadav <p.yadav@ti.com>
-
由 Simon Glass 提交于
Add a few more internal checks to make sure offsets are correct, before updating the dtb. To make this easier, update the functions which add a property to return that property,. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
So far we have only needed to add subnodes to empty notds, so have not had to deal with ordering. However this feature is needed for binman's expanded nodes, since there may be another node in the same section. While libfdt adds new properties after existing properties, it adds new subnodes before existing subnodes. This means that we must reorder the nodes in the cached version, so that the ordering remains consistent. Update the sync implementation to sync existing subnodes first, then add new ones, then tidy up the ordering in the cached version. Update the test to cover this behaviour. Also improve the comment about property syncing while we are here. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add a new test that adds a subnode alongside an existing one, as well as adding properties to a subnode. This will expand to adding multiple subnodes in future patches. Put a node after the one we are adding to so we can check that things sync correctly. The testAddNode() test should be in the TestNode class since it is a node test, so move it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Once the tree has been synced, thus potentially moving things around in the fdt, we set _cached_offsets to False so that a refresh will happen next time a property is accessed. This 'lazy' refresh doesn't really save much time, since refresh is a very fast operation, just a single walk of the tree. Also, having the refresh happen in the bowels of property access it makes it harder to figure out what is going on. Simplify the code by always doing a refresh before and after a sync. Set _cached_offsets to True immediately after this, in the Refresh() function, since this makes more sense than doing it in the caller. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
If a property does not yet have an offset, then that means it exists in the cache'd fdt but has not yet been synced back to the flat tree. Use the dirty flag for this so we don't need to check the offset too. Improve the comments for Prop and Node to make it clear what an offset of None means. Also clear the dirty flag after the property is synced. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add the node name too so it is easy to see which node failed. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Sometimes it is useful to specify the default alignment for all entries in a section, such as when word-alignment is necessary, for example. It is tedious and error-prone to specify this individually for each section. Add a property to control this for a section. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Generally the content of sections is not built until the final assembly of the image. This is partly to avoid wasting time, since the entries within sections may change multiple times as binman works through its various stages. This works quite well since sections exist in a strict hierarchy, so they can be processed in a depth-first manner. However the 'collection' entry type does not have this luxury. If it contains a section within its 'content' list, then it must produce the section contents, if available. That section is typically a sibling node, i.e. not part oc the collection's hierarchy. Add a new 'required' argument to section.GetData() to support this. When required is True, any referenced sections are immediately built. If this is not possible (because one of the subentries does not have its data yet) then an error is produced. The test for this uses a 'collection' entry type, referencing a section as its first member. This forces a call to _BuildSectionData() with required set to False, at first, then True later, when the image is assembled. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The vblock entry type includes code to collect the data from a number of other entries (not necessarily subentries) and concatenating it. This is a useful feature for other entry types. Make it a base class, so that vblock can use it, along with other entry types. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present there is a command-line flag to disable substitution of expanded entries. Add an option to the entry node as well, so it can be controlled at the node level. Add a test to cover this. Fix up the comment to the checkSymbols() function it uses, while we are here. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Two test devicetree files currently have 192 as their unique number. Fix this by separating them out. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Provide the model information through sysinfo so that it shows up on boot. For memconfig 4 pins are provided, for 16 combinations. For SKU ID there are two options: - two pins provided in a ternary arrangement, for 9 combinations. - reading from the EC Add a binding doc and drop the unused #defines as well. Example: U-Boot 2021.01-rc5 CPU: Intel(R) Celeron(R) CPU N3450 @ 1.10GHz DRAM: 3.9 GiB MMC: sdmmc@1b,0: 1, emmc@1c,0: 2 Video: 1024x768x32 @ b0000000 Model: Google Coral (memconfig 5, SKU 3) This depends on the GPIO series: http://patchwork.ozlabs.org/project/uboot/list/?series=228126Signed-off-by: NSimon Glass <sjg@chromium.org> Acked-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
Some boards may want to show the SKU ID or other information obtained at runtime. Allow this to come from sysinfo. The board can then provide a sysinfo driver to provide it. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
It is not possible to remove the state before driver model is uninited, since the devices are allocated in the memory buffer. Also it is not possible to uninit driver model afterwards, since the RAM has been freed. Drop the uninit altogether, since it is not actually necessary. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
When there is no command line, we cannot enable this feature. Add a check to avoid a build error. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add an extra condition here since we cannot put x86 tables in a bloblist when bloblists are not supported. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The U_BOOT_CMDREP_COMPLETE() macro produces a build error if CONFIG_CMDLINE is not enabled. Fix this by updating the macro to provide the 'repeatable' arugment in this case. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Move this documentation over to reST. Move the example files into a files/ directory so they are still separate. Do a few minor updates while we are here: - Tidy up sandbox build instructions - Update my github account name - Add some talks and links Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Export this function always so it can be used behind IS_ENABLED() instead of requiring an #ifdef. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The _SUPPORT suffix is from an earlier time and interferes with use of the CONFIG_IS_ENABLED() macro. Rename the option to drop the suffix. Tidy up the TODO that prompted this. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This feature was dropped from U-Boot some time ago: f12f96cf (sf: Drop spl_flash_get_sw_write_prot") However, we do need a way to see if a flash device is write-protected, since if it is, it may not be possible to write to do (i.e. failing to write is expected). I am not sure of the correct layer to implement this, so this patch is a stab at it. If spi-flash makes sense then I will add to the 'sf' also. Re the points mentioned in the removal commit: 1) This kind of requirement can be achieved using existing flash operations and flash locking API calls instead of making a separate flash API. Which uclass is this? 2) Technically there is no real hardware user for this API to use in the source tree. I do want coral (at least) to support this. 3) Having a flash operations API for simple register read bits also make difficult to extend the flash operations. This new patch only mentions write-protect being on or off, rather than the actual mechanism. 4) Instead of touching generic code, it is possible to have this functionality inside spinor operations in the form of flash hooks or fixups for associated flash chips. That sounds to me like what drivers are for. But we still need some sort of API for it to be accessible. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present bootstage silently ignores new records if it runs out of space. It is sometimes obvious by looking at the report, but the IDs are not contiguous, so it is easy to miss. Aad a message so that action can be taken. Signed-off-by: NSimon Glass <sjg@chromium.org>
-