Re: [PATCH 7/8] xhci: translate virtual addresses into the bus's address space
Hi Bin, Hi Nicolas, On 20.11.20 01:31, Bin Meng wrote: +Stefan On Fri, Nov 20, 2020 at 1:49 AM Nicolas Saenz Julienne wrote: So far we've been content with passing physical addresses when configuring memory addresses into XHCI controllers, but not all platforms have buses with transparent mappings. Specifically the Raspberry Pi 4 might introduce an offset to memory accesses incoming from its PCIe port. Introduce xhci_virt_to_bus() and xhci_bus_to_virt() to cater with these limitations and make sure we don't break non DM users. I believe this was already addressed by Stefan before, to support xHCI in MIPS. I believe from taking a quick look at the code, that Nicolas not only needs to transfer between phys and virt addresses, but also needs to support different "offsets" on multiple devices. IIUTC, it's an extension to the already available support for mapped addresses (virtual != physical). BTW: Do we really need to support non-DM code with this new approach in this late phase of DM conversion? Thanks, Stefan Signed-off-by: Nicolas Saenz Julienne --- drivers/usb/host/xhci-mem.c | 45 +++- drivers/usb/host/xhci-ring.c | 11 + drivers/usb/host/xhci.c | 4 ++-- include/usb/xhci.h | 22 +- 4 files changed, 54 insertions(+), 28 deletions(-) Regards, Bin Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH] power: regulator: Kconfig: add a dependency for POWER_SUPPORT for SPL
power/regulator will not be built if just CONFIG_SPL_DM_REGULATOR is enabled. It needs CONFIG_SPL_POWER_SUPPORT to be enabled as well. For example, if we just need a GPIO regulator in SPL: CONFIG_DM_REGULATOR=y CONFIG_SPL_DM_REGULATOR=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_SPL_DM_REGULATOR_GPIO=y Will not suffice, since the entire regulator build for SPL depends on CONFIG_SPL_POWER_SUPPORT. Elaborate that information in the Kconfig dependency. Signed-off-by: Nishanth Menon --- drivers/power/regulator/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig index d431102462a8..fbbea18c7d1b 100644 --- a/drivers/power/regulator/Kconfig +++ b/drivers/power/regulator/Kconfig @@ -18,7 +18,7 @@ config DM_REGULATOR config SPL_DM_REGULATOR bool "Enable regulators for SPL" - depends on DM_REGULATOR + depends on DM_REGULATOR && SPL_POWER_SUPPORT ---help--- Regulators are seldom needed in SPL. Even if they are accessed, some code space can be saved by accessing the PMIC registers directly. -- 2.25.1.377.g2d2118b814c1
[PATCH] Add optional salt to AUTOBOOT_STOP_STR_SHA256
From: Joel Peshkin
Adds an optional SALT value to AUTOBOOT_STOP_STR_SHA256. If a string
followed by a ":" is prepended to the sha256, the portion to the left
of the colon will be used as a salt and the password will be appended
to the salt before the sha256 is computed and compared.
Signed-off-by: Joel Peshkin
---
common/Kconfig.boot | 5 -
common/autoboot.c | 10 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 3f6d9c1..8a98672 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -819,7 +819,10 @@ config AUTOBOOT_STOP_STR_SHA256
This option adds the feature to only stop the autobooting,
and therefore boot into the U-Boot prompt, when the input
string / password matches a values that is encypted via
- a SHA256 hash and saved in the environment.
+ a SHA256 hash and saved in the environment variable
+ "bootstopkeysha256". If the value in that variable
+ includes a ":", the portion prior to the ":" will be treated
+ as a salt value.
config AUTOBOOT_USE_MENUKEY
bool "Allow a specify key to run a menu from the environment"
diff --git a/common/autoboot.c b/common/autoboot.c
index e628baf..0c4e6ff 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -80,6 +80,7 @@ static int passwd_abort_sha256(uint64_t etime)
u8 sha_env[SHA256_SUM_LEN];
u8 *sha;
char *presskey;
+ char *c;
const char *algo_name = "sha256";
u_int presskey_len = 0;
int abort = 0;
@@ -89,6 +90,14 @@ static int passwd_abort_sha256(uint64_t etime)
if (sha_env_str == NULL)
sha_env_str = AUTOBOOT_STOP_STR_SHA256;
+ presskey = malloc_cache_aligned(MAX_DELAY_STOP_STR);
+ c = strstr(sha_env_str, ":");
+ if (c) {
+ /* preload presskey with salt */
+ memcpy(presskey, sha_env_str, c - sha_env_str);
+ presskey_len += c - sha_env_str;
+ sha_env_str = c + 1;
+ }
/*
* Generate the binary value from the environment hash value
* so that we can compare this value with the computed hash
@@ -100,7 +109,6 @@ static int passwd_abort_sha256(uint64_t etime)
return 0;
}
- presskey = malloc_cache_aligned(MAX_DELAY_STOP_STR);
sha = malloc_cache_aligned(SHA256_SUM_LEN);
size = SHA256_SUM_LEN;
/*
--
1.8.3.1
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH] common: fit: add missing newline
On Mon, Nov 16, 2020 at 10:01:31PM +0100, Michael Walle wrote: > The debug statement doesn't end with a newline. Add it. > > Signed-off-by: Michael Walle Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5] env: mmc: Correct partition comparison in mmc_offset_try_partition
On Tue, Nov 17, 2020 at 12:32:08PM +0900, Hoyeonjiki Kim wrote:
> The function mmc_offset_try_partition searches the MMC partition for
> locating environment data, by comparing the partition names with config
> "u-boot,mmc-env-parition". However, it only compares the first word-size
> bytes (size of 'const char *'), which may make the function to find
> unintended partition.
>
> Correct the function not to partially compare the partition name with
> config "u-boot,mmc-env-partition".
>
> Fixes: c9e87ba66540 ("env: Save environment at the end of an MMC partition")
> Signed-off-by: Hoyeonjiki Kim
> Reviewed-by: Wolfgang Denk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] tools: image-host.c: use random instead of rand
On Fri, Nov 13, 2020 at 04:37:46PM +0100, Philippe Reynes wrote: > According to the manpage of rand, it is recommended > to use random instead of rand. This commit updates > the function get_random_data to use random. > > Reported-by: Coverity (CID: 312953) > Signed-off-by: Philippe Reynes > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] arm: vexpress: don't reset flags in board_init to avoid losing previous ones
On Sun, Nov 15, 2020 at 12:54:10PM +0100, Arnaud Aujon Chevallier wrote: > Re-submitted because of missing description and signed-off. > > flags reset in board_init caused bugs when executing command like editenv > because the reallocated flag was lost. > > Tested-by: Michael Opdenacker > Signed-off-by: Arnaud Aujon Chevallier Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 26/28] fs/squashfs: sqfs_read: remove buggy offset functionality
On Tue, Nov 03, 2020 at 12:11:24PM +0100, Richard Genoud wrote: > offset is the offset in the file read, not the offset in the destination > buffer. > If the offset is not null, this will lead to a memory corruption. > So, for now, we are returning an error if the offset is used. > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 28/28] fs/squashfs: implement exists() function
On Tue, Nov 03, 2020 at 12:11:26PM +0100, Richard Genoud wrote: > This permits to find a file and use the distro_bootcmd > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] tools: image-host.c: use correct variable for strerrno
On Fri, Nov 13, 2020 at 03:15:18PM +0100, Philippe Reynes wrote: > In the function get_random_data, strerrno is called with > the variable ret (which is the return of the function > clock_gettime). It should be called with errnor. This > commit fixes this mistake. > > Reported-by: Coverity (CID: 312956) > Signed-off-by: Philippe Reynes > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 24/28] fs/squashfs: sqfs_probe: use sqfs_decompressor_init() return value
On Tue, Nov 03, 2020 at 12:11:22PM +0100, Richard Genoud wrote: > sqfs_decompressor_init() returns a value, so it's better to use it than > to force the return value to EINVAL (it could be ENOMEM) > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 25/28] fs/squashfs: sqfs_read: don't write beyond buffer size
On Tue, Nov 03, 2020 at 12:11:23PM +0100, Richard Genoud wrote: > The length of the buffer wasn't taken into account when writing to the > given buffer. > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 23/28] fs/squashfs: sqfs_probe: reset cur_dev/cur_part_info to NULL on error
On Tue, Nov 03, 2020 at 12:11:21PM +0100, Richard Genoud wrote: > Resetting the context on error will prevent some checks like: > if (!ctx.cur_dev) > To pass when the probe method has failed > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 21/28] fs/squashfs: sqfs_probe: fix possible memory leak on error
On Tue, Nov 03, 2020 at 12:11:19PM +0100, Richard Genoud wrote: > If SquashFS magic number is invalid, there's a memory leak. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 20/28] fs/squashfs: sqfs_read: fix memory leak on finfo.blk_sizes
On Tue, Nov 03, 2020 at 12:11:18PM +0100, Richard Genoud wrote: > finfo.blk_sizes may not be freed in case of error in the for loop > Setting it to null and freeing it at the end makes prevents that from > happening. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 17/28] fs/squashfs: sqfs_frag_lookup: simplify error handling
On Tue, Nov 03, 2020 at 12:11:15PM +0100, Richard Genoud wrote: > For consistency with other functions. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 16/28] fs/squashfs: sqfs_read: fix another memory leak
On Tue, Nov 03, 2020 at 12:11:14PM +0100, Richard Genoud wrote: > data_buffer was allocated in a loop and freed only once. > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 18/28] fs/squashfs: sqfs_get_abs_path: fix error check
On Tue, Nov 03, 2020 at 12:11:16PM +0100, Richard Genoud wrote: > the return value of sqfs_tokenize(rel_tokens, rc, rel); wasn't checked. > (but "ret" value was !) > This is obviouly a typo. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 19/28] fs/squashfs: sqfs_get_abs_path: fix possible memory leak on error
On Tue, Nov 03, 2020 at 12:11:17PM +0100, Richard Genoud wrote: > if sqfs_tokenize(rel_tokens, rc, rel); fails, the function exits > without freeing the array base_tokens. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 14/28] fs/squashfs: sqfs_read: remove useless sqfs_closedir()
On Tue, Nov 03, 2020 at 12:11:12PM +0100, Richard Genoud wrote: > as sqfs_opendir failed, there's no need to call sqfs_closedir > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 15/28] fs/squashfs: sqfs_read: fix memory leak
On Tue, Nov 03, 2020 at 12:11:13PM +0100, Richard Genoud wrote: > sqfs_closedir() should be called to free memory allocated by > sqfs_opendir() > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 11/28] fs/squashfs: sqfs_size: fix dangling pointer dirs->entry
On Tue, Nov 03, 2020 at 12:11:09PM +0100, Richard Genoud wrote: > dirs->entry shouldn't be left dangling as it could be freed twice. > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 13/28] fs/squashfs: sqfs_read: fix dangling pointer dirs->entry
On Tue, Nov 03, 2020 at 12:11:11PM +0100, Richard Genoud wrote: > dirs->entry shouldn't be left dangling as it could be freed twice. > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 09/28] fs/squashfs: sqfs_read_inode_table: fix dangling pointer
On Tue, Nov 03, 2020 at 12:11:07PM +0100, Richard Genoud wrote: > inode_table should not be left dangling as it may be freed in sqfs_opendir > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 07/28] fs/squashfs: sqfs_search_dir: fix dangling pointer
On Tue, Nov 03, 2020 at 12:11:05PM +0100, Richard Genoud wrote: > dirs->entry shouldn't be left dangling as it could be freed twice. > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 12/28] fs/squashfs: sqfs_size: remove useless sqfs_closedir()
On Tue, Nov 03, 2020 at 12:11:10PM +0100, Richard Genoud wrote: > as sqfs_opendir failed, there's no need to call sqfs_closedir > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 08/28] fs/squashfs: sqfs_search_dir: fix memory leaks
On Tue, Nov 03, 2020 at 12:11:06PM +0100, Richard Genoud wrote: > path, target, res, rem and sym_tokens were not free on error nor success. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 10/28] fs/squashfs: sqfs_concat_tokens: check if malloc succeeds
On Tue, Nov 03, 2020 at 12:11:08PM +0100, Richard Genoud wrote: > memory allocation should always be checked > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 06/28] fs/squashfs: sqfs_read_directory_table: fix memory leak
On Tue, Nov 03, 2020 at 12:11:04PM +0100, Richard Genoud wrote: > pos_list wasn't freed on every error > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 05/28] fs/squashfs: sqfs_split_path: fix memory leak and dangling pointers
On Tue, Nov 03, 2020 at 12:11:03PM +0100, Richard Genoud wrote: > *file and *dir were not freed on error > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 04/28] fs/squashfs: sqfs_closedir: fix memory leak
On Tue, Nov 03, 2020 at 12:11:02PM +0100, Richard Genoud wrote: > sqfs_dirs wasn't freed anywhere. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 03/28] fs/squashfs: sqfs_opendir: simplify error handling
On Tue, Nov 03, 2020 at 12:11:01PM +0100, Richard Genoud wrote: > Using only one label permits to prevents bugs when moving code around. > > Reviewed-by: Joao Marcos Costa > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 01/28] fs/squashfs: fix board hang-up when calling .exists()
On Tue, Nov 03, 2020 at 12:10:59PM +0100, Richard Genoud wrote: > add missing squashfs function to prevent dangling or null pointers. > For exemple, when calling test [ -e somefile ], squashfs.exists may be > called. > > Signed-off-by: Richard Genoud > Reviewed-by: Joao Marcos Costa Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 02/28] fs/squashfs: sqfs_opendir: fix some memory leaks and dangling pointers
On Tue, Nov 03, 2020 at 12:11:00PM +0100, Richard Genoud wrote: > When trying to load an non-existing file, the cpu hangs! > > Signed-off-by: Richard Genoud Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/4] fs: btrfs: initialize @ret to 0 to prevent uninitialized return value
On Sat, Oct 31, 2020 at 09:07:51AM +0800, Qu Wenruo wrote: > In show_dir() if we hit a ROOT_ITEM, we can exit with uninitialized > @ret. > > Fix it by initializing it to 0. > > Reported-by: Coverity CID 312955 > Signed-off-by: Qu Wenruo > Reviewed-by: Marek Behún Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] env: typo enougth
On Fri, Oct 30, 2020 at 06:11:12AM +0100, Heinrich Schuchardt wrote: > %s/enougth/enough/ > > Signed-off-by: Heinrich Schuchardt > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] drivers: led: bcm6858: set the correct led polarity register
On Thu, Oct 29, 2020 at 06:27:34PM +0100, Steven Lawrance wrote: > This change sets the output (hardware) polarity register instead of the > input (software) polarity register for the bcm6858 LED controller. The > logic was inverted (a LED configued active high behaved as active low). > > Signed-off-by: Steven Lawrance > Reviewed-by: Philippe Reynes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] km/ppc: use Kconfig for MEMTEST configuration
On Thu, Oct 29, 2020 at 01:54:54PM +0100, Holger Brunck wrote: > Also change back SYS_MEMTEST_END to 0x00f0. 0xe0 was wrong and > introduced due to the global Kconfig migration of this option in u-boot. > > CC: Heiko Schocher > CC: Tom Rini > Signed-off-by: Holger Brunck Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] fs: btrfs: inode: handle uninitialized type before returning it
On Sat, Oct 31, 2020 at 09:07:49AM +0800, Qu Wenruo wrote: > In btrfs_lookup_path() the local variable @type should always be updated > after we hit any file/dir. > > But if @filename is NULL from the very beginning, then we don't > initialize it and return it directly. > > To prevent such problem from happening, we initialize @type to > BTRFS_FT_UNKNOWN. > For normal execution route, it will get updated for each filename we > resolved. > Buf if we didn't find any path, we check if the type is still FT_UNKNOWN > and ret == 0. If true we know there is something wrong, just return > -EUCLEAN to inform the caller. > > Reported-by: Coverity CID 312958 > Signed-off-by: Qu Wenruo > Reviewed-by: Marek Behún Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: Fix index off by 1 for inode SQFS_LDIR_TYPE
On Fri, Oct 30, 2020 at 01:41:58PM +, Gerard Koskamp wrote: > I've created a squashfs file system with Yocto (it use squashfs-tools) > and u-boot command sqfsls give the error:'Error while searching inode: > unknown type.' > After some digging in the code I found that the index is off by 1. > This patch fix this issue and I can successful use the sqfsls command. > After search for the squashfs format I found a link talk about a > similar issue but this time in the documentation. The link is: > https://github.com/AgentD/squashfs-tools-ng/commit/e6588526838caece9529 > > Signed-off-by: Gerard Koskamp > Tested-by: Joao Marcos Costa Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] km: replace hardcoded address for imported environment
On Thu, Oct 29, 2020 at 01:48:01PM +0100, Holger Brunck wrote: > From: Matteo Ghidoni > > Instead of using an hard coded address, make use of an > already defined address for importing the environment > for ramfs and nfs boot. This allows boards having different > mapping to use the same code. > > CC: Heiko Schocher > CC: Tom Rini > Signed-off-by: Matteo Ghidoni > Signed-off-by: Holger Brunck Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] tools: dumpimage: Remove remaining mentions of the -i option
On Mon, Oct 26, 2020 at 10:40:24AM -0500, Tyler Hicks wrote:
> The -i option of the dumpimage tool has been removed so it should no
> longer be documented in the README file. Refer readers to the tool's
> help output rather than maintain a copy of the usage in the README.
>
> Finally, adjust the example dumpfile invocation in imagetool.h to use
> the -o option instead of the removed -i option.
>
> Fixes: 12b831879a76 ("tools: dumpimage: Simplify arguments")
> Signed-off-by: Tyler Hicks
> Cc: Martyn Welch
> Acked-by: Martyn Welch
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 27/28] fs/squashfs: sqfs_read: fragmented files are not supported
On Tue, Nov 03, 2020 at 12:11:25PM +0100, Richard Genoud wrote: > The code for reading a fragmented file is not functionnal. > It's better to signal this to the user. > > Signed-off-by: Richard Genoud This change causes the test.py squashfs tests to fail. I am unsure if the problem is with the tests or this exposing further problems in the code. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 22/28] fs/squashfs: sqfs_close/sqfs_read_sblk: set ctxt.sblk to NULL after free
On Tue, Nov 03, 2020 at 12:11:20PM +0100, Richard Genoud wrote: > This will prevent a double free error if sqfs_close() is called twice. > > Signed-off-by: Richard Genoud This change causes the test.py squashfs tests to fail. I am unsure if the problem is with the tests or this exposing further problems in the code. -- Tom signature.asc Description: PGP signature
Re: [PATCH 7/8] xhci: translate virtual addresses into the bus's address space
+Stefan On Fri, Nov 20, 2020 at 1:49 AM Nicolas Saenz Julienne wrote: > > So far we've been content with passing physical addresses when > configuring memory addresses into XHCI controllers, but not all > platforms have buses with transparent mappings. Specifically the > Raspberry Pi 4 might introduce an offset to memory accesses incoming > from its PCIe port. > > Introduce xhci_virt_to_bus() and xhci_bus_to_virt() to cater with these > limitations and make sure we don't break non DM users. I believe this was already addressed by Stefan before, to support xHCI in MIPS. > > Signed-off-by: Nicolas Saenz Julienne > --- > drivers/usb/host/xhci-mem.c | 45 +++- > drivers/usb/host/xhci-ring.c | 11 + > drivers/usb/host/xhci.c | 4 ++-- > include/usb/xhci.h | 22 +- > 4 files changed, 54 insertions(+), 28 deletions(-) > Regards, Bin
Re: [PATCH v2 3/4] efi_selftest: implement exception test for sandbox
On 17.11.20 00:53, Simon Glass wrote:
> On Wed, 11 Nov 2020 at 16:30, Heinrich Schuchardt wrote:
>>
>> Provide a unit test that causes an illegal instruction to occur.
>>
>> The test can be run with the following commands:
>>
>> => setenv efi_selftest exception
>> => bootefi selftest
>>
>> This might be the output:
>>
>> Executing 'exception'
>> EFI application triggers exception.
>> Illegal instruction
>> pc = 0x1444d016, pc_reloc = 0xaa078e8dd016
>> UEFI image [0x:0x] '/\selftest'
>> UEFI image [0x1444b000:0x14451fff] pc=0x2016 '/bug.efi'
>> Resetting ...
>>
>> It would tell us that the exception was triggered by an instruction
>> 0x2016 bytes after the load address of the binary with filename /bug.efi.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> v2:
>> no change
>> ---
>> lib/efi_selftest/efi_selftest_miniapp_exception.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> Reviewed-by: Simon Glass
>
>>
>> diff --git a/lib/efi_selftest/efi_selftest_miniapp_exception.c
>> b/lib/efi_selftest/efi_selftest_miniapp_exception.c
>> index 63c63d75f1..59b7e5100a 100644
>> --- a/lib/efi_selftest/efi_selftest_miniapp_exception.c
>> +++ b/lib/efi_selftest/efi_selftest_miniapp_exception.c
>> @@ -33,6 +33,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
>> asm volatile (".word 0xe7f7defb\n");
>> #elif defined(CONFIG_RISCV)
>> asm volatile (".word 0x\n");
>> +#elif defined(CONFIG_SANDBOX)
>> + asm volatile (".word 0x\n");
>
> Does this work on ARM hosts?
Yes it works on aarch64.
Best regards
Heinrich
>
>
>> #elif defined(CONFIG_X86)
>> asm volatile (".word 0x\n");
>> #endif
>> --
>> 2.28.0
>>
Re: [PATCH v2 1/4] sandbox: add handler for exceptions
On 17.11.20 00:53, Simon Glass wrote: > Hi Heinrich, > > On Wed, 11 Nov 2020 at 16:30, Heinrich Schuchardt wrote: >> >> Add a handler for SIGILL, SIGBUS, SIGSEGV. >> >> When an exception occurs print the program counter and the loaded >> UEFI binaries and reset the system if CONFIG_SANDBOX_CRASH_RESET=y >> or exit to the OS otherwise. >> >> Signed-off-by: Heinrich Schuchardt >> --- >> v2: >> add a customizing switch >> set SA_NODEFER flag for sigaction >> --- >> arch/sandbox/Kconfig | 9 >> arch/sandbox/cpu/os.c | 40 +++ >> arch/sandbox/cpu/start.c | 4 >> arch/sandbox/lib/interrupts.c | 35 ++ >> include/os.h | 17 +++ >> 5 files changed, 105 insertions(+) > > Reviewed-by: Simon Glass > > Do you think a command-line flag might be useful too/instead? > For my needs the CONFIG flag is enough. I could not find the mail for patch 2/4 in my inbox. I have tested on aarch64 that the exception work here too. Best regards Heinrich
Re: [PATCH v1] linux/compat.h: Remove debug() from spin_lock_irqsave()
Update Tom's address
On Thu, Nov 19, 2020 at 9:26 PM Andy Shevchenko
wrote:
>
> It seems nobody tested the debug() option in spin_lock_irqsave().
> Currently, when #define DEBUG, it spoils the compiler with
>
> In file included from drivers/usb/dwc3/gadget.c:18:
> drivers/usb/dwc3/gadget.c: In function ‘dwc3_gadget_set_selfpowered’:
> include/log.h:235:4: warning: ‘flags’ is used uninitialized in this function
> [-Wuninitialized]
> 235 |printf(pr_fmt(fmt), ##args); \
> |^~
> drivers/usb/dwc3/gadget.c:1347:17: note: ‘flags’ was declared here
> 1347 | unsigned long flags;
> | ^
>
> and so on...
> Drop useless debug() call to make compiler happy.
>
> Fixes: 0c06db598367 ("lib, linux: move linux specific defines to
> linux/compat.h")
> Cc: Heiko Schocher
> Cc: Tom Rini
> Signed-off-by: Andy Shevchenko
> ---
> include/linux/compat.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compat.h b/include/linux/compat.h
> index 38549baa251d..3d0acbd582ef 100644
> --- a/include/linux/compat.h
> +++ b/include/linux/compat.h
> @@ -248,7 +248,7 @@ typedef int wait_queue_head_t;
> #define spin_lock_init(lock) do {} while (0)
> #define spin_lock(lock) do {} while (0)
> #define spin_unlock(lock) do {} while (0)
> -#define spin_lock_irqsave(lock, flags) do { debug("%lu\n", flags); } while
> (0)
> +#define spin_lock_irqsave(lock, flags) do {} while (0)
> #define spin_unlock_irqrestore(lock, flags) do { flags = 0; } while (0)
>
> #define DEFINE_MUTEX(...)
> --
> 2.29.2
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 1/4] IPQ40xx: clk: use dev_read_addr()
On Wed, Oct 28, 2020 at 1:56 PM Robert Marko wrote:
>
> Lets convert the driver to use dev_read_addr() instead of the
> devfdt_get_addr().
>
> While we are here, lets also alphabetise the includes.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> ---
> arch/arm/mach-ipq40xx/clock-ipq4019.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-ipq40xx/clock-ipq4019.c
> b/arch/arm/mach-ipq40xx/clock-ipq4019.c
> index 31ae9719e8..1f385665cc 100644
> --- a/arch/arm/mach-ipq40xx/clock-ipq4019.c
> +++ b/arch/arm/mach-ipq40xx/clock-ipq4019.c
> @@ -8,8 +8,8 @@
> *
> */
>
> -#include
> #include
> +#include
> #include
> #include
>
> @@ -35,7 +35,7 @@ static int msm_clk_probe(struct udevice *dev)
> {
> struct msm_clk_priv *priv = dev_get_priv(dev);
>
> - priv->base = devfdt_get_addr(dev);
> + priv->base = dev_read_addr(dev);
> if (priv->base == FDT_ADDR_T_NONE)
> return -EINVAL;
>
> --
> 2.28.0
>
Hi,
Is there something I can improve in the patch series?
Regards,
Robert
Re: [linux-sunxi] [PATCH] sunxi: Add arm64 FEL support
On Thu, Nov 19, 2020 at 10:54:42AM +, Andre Przywara wrote:
> So far we did not support the BootROM based FEL USB debug mode on the
> 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
> SPL runs in AArch64.
> Returning back to AArch32 was not working as expected, since the RMR
> reset into 32-bit mode always starts execution in the BootROM, but not
> in the FEL routine.
>
> After some debug and research and with help via IRC, the CPU hotplug
> mechanism emerged as a solution: If a certain R_CPUCFG register contains
> some magic, the BootROM will immediately branch to an address stored in
> some other register. This works well for our purposes.
>
> Enable the FEL feature by providing early AArch32 code to first save the
> FEL state, *before* initially entering AArch64.
> If we eventually determine that we should return to FEL, we reset back
> into AArch32, and use the CPU hotplug mechanism to run some small
> AArch32 code snippet that restores the initially saved FEL state.
>
> That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
> tool, with it returning into FEL mode, so that other payloads can be
> transferred via FEL as well.
>
> Tested on A64, H5 and H6.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/cpu/armv8/Makefile | 2 +
> arch/arm/cpu/armv8/fel_utils.S | 78 +
> arch/arm/include/asm/arch-sunxi/boot0.h | 14 +
> include/configs/sunxi-common.h | 2 -
> 4 files changed, 94 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/cpu/armv8/fel_utils.S
Don't you want to also update board/sunxi/README.sunxi64 ?
>
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index 93d26f98568..f7b4a5ee46c 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC) += smccc-call.o
>
> ifndef CONFIG_SPL_BUILD
> obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o
> +else
> +obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o
> endif
> obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o
> sec_firmware_asm.o
>
> diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
> new file mode 100644
> index 000..334fdef7fa0
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fel_utils.S
> @@ -0,0 +1,78 @@
> +/*
> + * Utility functions for FEL mode, when running SPL in AArch64.
> + *
> + * Copyright (c) 2017 Arm Ltd.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * We don't overwrite save_boot_params() here, to save the FEL state upon
> + * entry, since this would run *after* the RMR reset, which clobbers that
> + * state.
> + * Instead we store the state _very_ early in the boot0 hook, *before*
> + * resetting to AArch64.
> + */
> +
> +/*
> + * The FEL routines in BROM run in AArch32.
> + * Reset back into 32-bit mode here and restore the saved FEL state
> + * afterwards.
> + * Resetting back into AArch32/EL3 using the RMR always enters the BROM,
> + * but we can use the CPU hotplug mechanism to branch back to our code
> + * immediately.
> + */
> +ENTRY(return_to_fel)
> + /*
> + * the RMR reset will clear all registers, so save the arguments
> + * (LR and SP) in the fel_stash structure, which we read anyways later
> + */
> + adr x2, fel_stash
> + str w0, [x2]
> + str w1, [x2, #4]
> +
> + adr x1, fel_stash_addr // to find the fel_stash address in AA32
> + str w2, [x1]
> +
> + ldr x0, =0xfa50392f // CPU hotplug magic
> +#ifndef CONFIG_MACH_SUN50I_H6
> + ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
> + str w0, [x2, #0x8]
> +#else
> + ldr x2, =(SUNXI_RTC_BASE + 0x1b8) // BOOT_CPU_HP_FLAG_REG
> + str w0, [x2], #0x4
> +#endif
> + adr x0, back_in_32
> + str w0, [x2]
> +
> + dsb sy
> + isb sy
> + mov x0, #2 // RMR reset into AArch32
> + dsb sy
> + msr RMR_EL3, x0
> + isb sy
> +1: wfi
> + b 1b
> +
> +/* AArch32 code to restore the state from fel_stash and return back to FEL.
> */
> +back_in_32:
> + .word 0xe59f0028 // ldr r0, [pc, #40] ; load fel_stash address
> + .word 0xe5901008 // ldr r1, [r0, #8]
> + .word 0xe129f001 // msr CPSR_fc, r1
> + .word 0xf57ff06f // isb
> + .word 0xe590d000 // ldr sp, [r0]
> + .word 0xe590e004 // ldr lr, [r0, #4]
> + .word 0xe5901010 // ldr r1, [r0, #16]
> + .word 0xee0c1f10 // mcr 15, 0, r1, cr12, cr0, {0} ; VBAR
> + .word 0xe590100c // ldr r1, [r0, #12]
> + .word 0xee011f10 // mcr 15, 0, r1, cr1, cr0, {0} ; SCTLR
> + .word 0xf57ff06f // isb
> + .word 0xe12fff1e // bx lr ; return to FEL
>
[PATCH 1/1] efi_loader: parameter check in GetNextVariableName()
If GetNextVariableName() is called with a non-existing combination of
VariableName and VendorGuid, return EFI_INVALID_PARAMETER.
If GetNextVariableName() is called with a string that is not zero
terminated, return EFI_INVALID_PARAMETER.
Reformat a line over 80 characters.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_var_mem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
index 1d2b44580f..9633143fae 100644
--- a/lib/efi_loader/efi_var_mem.c
+++ b/lib/efi_loader/efi_var_mem.c
@@ -304,8 +304,8 @@ efi_get_variable_mem(u16 *variable_name, const efi_guid_t
*vendor, u32 *attribut
}
efi_status_t __efi_runtime
-efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16
*variable_name,
- efi_guid_t *vendor)
+efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size,
+ u16 *variable_name, efi_guid_t *vendor)
{
struct efi_var_entry *var;
efi_uintn_t old_size;
@@ -313,8 +313,13 @@ efi_get_next_variable_name_mem(efi_uintn_t
*variable_name_size, u16 *variable_na
if (!variable_name_size || !variable_name || !vendor)
return EFI_INVALID_PARAMETER;
+
+ if (u16_strnlen(variable_name, *variable_name_size) ==
+ *variable_name_size)
+ return EFI_INVALID_PARAMETER;
- efi_var_mem_find(vendor, variable_name, );
+ if (!efi_var_mem_find(vendor, variable_name, ) && *variable_name)
+ return EFI_INVALID_PARAMETER;
if (!var)
return EFI_NOT_FOUND;
--
2.29.2
[PATCH v1] linux/compat.h: Remove debug() from spin_lock_irqsave()
It seems nobody tested the debug() option in spin_lock_irqsave().
Currently, when #define DEBUG, it spoils the compiler with
In file included from drivers/usb/dwc3/gadget.c:18:
drivers/usb/dwc3/gadget.c: In function ‘dwc3_gadget_set_selfpowered’:
include/log.h:235:4: warning: ‘flags’ is used uninitialized in this function
[-Wuninitialized]
235 |printf(pr_fmt(fmt), ##args); \
|^~
drivers/usb/dwc3/gadget.c:1347:17: note: ‘flags’ was declared here
1347 | unsigned long flags;
| ^
and so on...
Drop useless debug() call to make compiler happy.
Fixes: 0c06db598367 ("lib, linux: move linux specific defines to
linux/compat.h")
Cc: Heiko Schocher
Cc: Tom Rini
Signed-off-by: Andy Shevchenko
---
include/linux/compat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 38549baa251d..3d0acbd582ef 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -248,7 +248,7 @@ typedef int wait_queue_head_t;
#define spin_lock_init(lock) do {} while (0)
#define spin_lock(lock) do {} while (0)
#define spin_unlock(lock) do {} while (0)
-#define spin_lock_irqsave(lock, flags) do { debug("%lu\n", flags); } while (0)
+#define spin_lock_irqsave(lock, flags) do {} while (0)
#define spin_unlock_irqrestore(lock, flags) do { flags = 0; } while (0)
#define DEFINE_MUTEX(...)
--
2.29.2
Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04
Hi Otto, On Thu, 19 Nov 2020 at 21:23, Otto Meier wrote: > > Hi, > > I have extended the previous post. > > > > with these modifications i get: > > U-Boot 2021.01-rc2-00047-g9324c9a823-dirty (Nov 19 2020 - 15:33:00 > +0100) odroid-c2 > > Model: Hardkernel ODROID-C2 > SoC: Amlogic Meson GXBB (S905) Revision 1f:c (0:1) > DRAM: 2 GiB > MMC: mmc@72000: 0, mmc@74000: 1 > In:serial > Out: serial > Err: serial > Net: Could not get PHY for ethernet@c941: addr -1 > No ethernet found. > > Hit any key to stop autoboot: 0 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = cdff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[226] > MESON EMMC status = c5ff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[226] > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = cdff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[226] > Card did not respond to voltage select! : -110 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = cdff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[226] > MESON EMMC status = c5ff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[226] > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 00ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[226] > Card did not respond to voltage select! : -110 > MMC Device 2 not found > no mmc device at slot 2 > starting USB... > > Hope this shed more light on the issue. > > Following you find the output of 2020.04 with this mod. > > and working reading off mmc info of the emmc > > => mmc dev 1 > MESON EMMC status = c5ff > MESON EMMC status = c5ff > MESON EMMC status = c8ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = cdff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[206] > MESON EMMC status = c5ff > MESON EMMC status = 01ff2800 > meson_dm_mmc_send_cmd[206] > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = d9fe > MESON EMMC status = d9fe > MESON EMMC status = d9fe > MESON EMMC status = d9fe > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC status = 01ff2000 > MESON EMMC status = c5ff > MESON EMMC
[PATCH 7/8] xhci: translate virtual addresses into the bus's address space
So far we've been content with passing physical addresses when
configuring memory addresses into XHCI controllers, but not all
platforms have buses with transparent mappings. Specifically the
Raspberry Pi 4 might introduce an offset to memory accesses incoming
from its PCIe port.
Introduce xhci_virt_to_bus() and xhci_bus_to_virt() to cater with these
limitations and make sure we don't break non DM users.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/usb/host/xhci-mem.c | 45 +++-
drivers/usb/host/xhci-ring.c | 11 +
drivers/usb/host/xhci.c | 4 ++--
include/usb/xhci.h | 22 +-
4 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b002d6f166..e8d435d644 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -110,7 +110,7 @@ static void xhci_scratchpad_free(struct xhci_ctrl *ctrl)
ctrl->dcbaa->dev_context_ptrs[0] = 0;
- free((void *)(uintptr_t)le64_to_cpu(ctrl->scratchpad->sp_array[0]));
+ free(xhci_bus_to_virt(ctrl,
le64_to_cpu(ctrl->scratchpad->sp_array[0])));
free(ctrl->scratchpad->sp_array);
free(ctrl->scratchpad);
ctrl->scratchpad = NULL;
@@ -216,8 +216,8 @@ static void *xhci_malloc(unsigned int size)
* @param link_trbsflag to indicate whether to link the trbs or NOT
* @return none
*/
-static void xhci_link_segments(struct xhci_segment *prev,
- struct xhci_segment *next, bool link_trbs)
+static void xhci_link_segments(struct xhci_ctrl *ctrl, struct xhci_segment
*prev,
+ struct xhci_segment *next, bool link_trbs)
{
u32 val;
u64 val_64 = 0;
@@ -226,7 +226,7 @@ static void xhci_link_segments(struct xhci_segment *prev,
return;
prev->next = next;
if (link_trbs) {
- val_64 = virt_to_phys(next->trbs);
+ val_64 = xhci_virt_to_bus(ctrl, next->trbs);
prev->trbs[TRBS_PER_SEGMENT-1].link.segment_ptr =
cpu_to_le64(val_64);
@@ -304,7 +304,8 @@ static struct xhci_segment *xhci_segment_alloc(void)
* @param link_trbsflag to indicate whether to link the trbs or NOT
* @return pointer to the newly created RING
*/
-struct xhci_ring *xhci_ring_alloc(unsigned int num_segs, bool link_trbs)
+struct xhci_ring *xhci_ring_alloc(struct xhci_ctrl *ctrl, unsigned int
num_segs,
+ bool link_trbs)
{
struct xhci_ring *ring;
struct xhci_segment *prev;
@@ -327,12 +328,12 @@ struct xhci_ring *xhci_ring_alloc(unsigned int num_segs,
bool link_trbs)
next = xhci_segment_alloc();
BUG_ON(!next);
- xhci_link_segments(prev, next, link_trbs);
+ xhci_link_segments(ctrl, prev, next, link_trbs);
prev = next;
num_segs--;
}
- xhci_link_segments(prev, ring->first_seg, link_trbs);
+ xhci_link_segments(ctrl, prev, ring->first_seg, link_trbs);
if (link_trbs) {
/* See section 4.9.2.1 and 6.4.4.1 */
prev->trbs[TRBS_PER_SEGMENT-1].link.control |=
@@ -354,6 +355,7 @@ static int xhci_scratchpad_alloc(struct xhci_ctrl *ctrl)
struct xhci_hccr *hccr = ctrl->hccr;
struct xhci_hcor *hcor = ctrl->hcor;
struct xhci_scratchpad *scratchpad;
+ uint64_t val_64;
int num_sp;
uint32_t page_size;
void *buf;
@@ -371,8 +373,9 @@ static int xhci_scratchpad_alloc(struct xhci_ctrl *ctrl)
scratchpad->sp_array = xhci_malloc(num_sp * sizeof(u64));
if (!scratchpad->sp_array)
goto fail_sp2;
- ctrl->dcbaa->dev_context_ptrs[0] =
- cpu_to_le64((uintptr_t)scratchpad->sp_array);
+
+ val_64 = xhci_virt_to_bus(ctrl, scratchpad->sp_array);
+ ctrl->dcbaa->dev_context_ptrs[0] = cpu_to_le64((uintptr_t)val_64);
xhci_flush_cache((uintptr_t)>dcbaa->dev_context_ptrs[0],
sizeof(ctrl->dcbaa->dev_context_ptrs[0]));
@@ -393,8 +396,8 @@ static int xhci_scratchpad_alloc(struct xhci_ctrl *ctrl)
xhci_flush_cache((uintptr_t)buf, num_sp * page_size);
for (i = 0; i < num_sp; i++) {
- uintptr_t ptr = (uintptr_t)buf + i * page_size;
- scratchpad->sp_array[i] = cpu_to_le64(ptr);
+ val_64 = xhci_virt_to_bus(ctrl, buf + i * page_size);
+ scratchpad->sp_array[i] = cpu_to_le64(val_64);
}
xhci_flush_cache((uintptr_t)scratchpad->sp_array,
@@ -484,9 +487,9 @@ int xhci_alloc_virt_device(struct xhci_ctrl *ctrl, unsigned
int slot_id)
}
/* Allocate endpoint 0 ring */
- virt_dev->eps[0].ring = xhci_ring_alloc(1, true);
+ virt_dev->eps[0].ring = xhci_ring_alloc(ctrl, 1, true);
- byte_64 = virt_to_phys(virt_dev->out_ctx->bytes);
+
[PATCH 8/8] mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()
This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
when relevant.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/mmc/sdhci.c | 7 ---
include/mmc.h | 10 ++
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 0628934312..2086d7cdb1 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
static void sdhci_reset(struct sdhci_host *host, u8 mask)
{
@@ -103,7 +102,8 @@ static void sdhci_prepare_dma(struct sdhci_host *host,
struct mmc_data *data,
mmc_get_dma_dir(data));
if (host->flags & USE_SDMA) {
- sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
+ sdhci_writel(host,
+mmc_phys_to_bus(host->mmc,
(ulong)host->start_addr),
SDHCI_DMA_ADDRESS);
}
#if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
@@ -162,7 +162,8 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data)
start_addr &=
~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
- sdhci_writel(host,
phys_to_bus((ulong)start_addr),
+ sdhci_writel(host,
+mmc_phys_to_bus(host->mmc,
(ulong)start_addr),
SDHCI_DMA_ADDRESS);
}
}
diff --git a/include/mmc.h b/include/mmc.h
index 1d377e0281..805a3b2215 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
struct bd_info;
@@ -977,4 +978,13 @@ static inline enum dma_data_direction
mmc_get_dma_dir(struct mmc_data *data)
return data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
}
+static inline dma_addr_t mmc_phys_to_bus(struct mmc *mmc, phys_addr_t addr)
+{
+#if CONFIG_IS_ENABLED(DM_MMC)
+ return dev_phys_to_bus(mmc->dev, addr);
+#else
+ return phys_to_bus(addr);
+#endif
+}
+
#endif /* _MMC_H_ */
--
2.29.2
[PATCH 4/8] dm: Introduce xxx_get_dma_range()
Add the follwing functions to get a specific device's DMA ranges:
- dev_get_dma_range()
- ofnode_get_dma_range()
- of_get_dma_range()
- fdt_get_dma_range()
They are specially useful in oder to be able validate a physical address
space range into a bus's and to convert addresses from and to address
spaces.
Signed-off-by: Nicolas Saenz Julienne
---
common/fdt_support.c | 72 ++
drivers/core/of_addr.c | 68 +++
drivers/core/ofnode.c | 9 ++
drivers/core/read.c| 5 +++
include/dm/of_addr.h | 17 ++
include/dm/ofnode.h| 16 ++
include/dm/read.h | 6
include/fdt_support.h | 14
8 files changed, 207 insertions(+)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 5ae75df3c6..78dc7906bd 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1342,6 +1342,78 @@ u64 fdt_translate_dma_address(const void *blob, int
node_offset,
return __of_translate_address(blob, node_offset, in_addr, "dma-ranges");
}
+int fdt_get_dma_range(const void *blob, int node, phys_addr_t *cpu,
+ dma_addr_t *bus, u64 *size)
+{
+ bool found_dma_ranges = false;
+ const fdt32_t *ranges;
+ int na, ns, pna, pns;
+ int parent = node;
+ u64 cpu_addr;
+ int ret = 0;
+ int len;
+
+ /* Find the closest dma-ranges property */
+ while (parent >= 0) {
+ ranges = fdt_getprop(blob, parent, "dma-ranges", );
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (ranges && len > 0)
+ break;
+
+ /* Once we find 'dma-ranges', then a missing one is an error */
+ if (found_dma_ranges && !ranges) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (ranges)
+ found_dma_ranges = true;
+
+ parent = fdt_parent_offset(blob, parent);
+ }
+
+ if (!ranges || parent < 0) {
+ debug("no dma-ranges found for node %s\n",
+ fdt_get_name(blob, node, NULL));
+ ret = -ENODEV;
+ goto out;
+ }
+
+ /* switch to that node */
+ node = parent;
+ parent = fdt_parent_offset(blob, node);
+ if (parent < 0) {
+ printf("Found dma-ranges in root node, shoudln't happen\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* Get the address sizes both for the bus and its parent */
+ of_match_bus(blob, node)->count_cells(blob, node, , );
+ if (!OF_CHECK_COUNTS(na, ns)) {
+ printf("%s: Bad cell count for %s\n", __FUNCTION__,
+ fdt_get_name(blob, node, NULL));
+ return -EINVAL;
+ goto out;
+ }
+
+ of_match_bus(blob, parent)->count_cells(blob, parent, , );
+ if (!OF_CHECK_COUNTS(pna, pns)) {
+ printf("%s: Bad cell count for %s\n", __FUNCTION__,
+ fdt_get_name(blob, parent, NULL));
+ return -EINVAL;
+ goto out;
+ }
+
+ *bus = fdt_read_number(ranges, na);
+ cpu_addr = fdt_read_number(ranges + na, pna);
+ *cpu = fdt_translate_dma_address(blob, node, (const fdt32_t*)_addr);
+ *size = fdt_read_number(ranges + na + pna, ns);
+out:
+ return ret;
+}
+
/**
* fdt_node_offset_by_compat_reg: Find a node that matches compatiable and
* who's reg property matches a physical cpu address
diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index ca34d84922..8457e04a25 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -325,6 +325,74 @@ u64 of_translate_dma_address(const struct device_node
*dev, const __be32 *in_add
return __of_translate_address(dev, in_addr, "dma-ranges");
}
+int of_get_dma_range(const struct device_node *dev, phys_addr_t *cpu,
+dma_addr_t *bus, u64 *size)
+{
+ bool found_dma_ranges = false;
+ struct device_node parent;
+ int na, ns, pna, pns;
+ const __be32 *ranges;
+ int ret = 0;
+ int len;
+
+ /* Find the closest dma-ranges property */
+ while (dev) {
+ ranges = of_get_property(dev, "dma-ranges", );
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (ranges && len > 0)
+ break;
+
+ /* Once we find 'dma-ranges', then a missing one is an error */
+ if (found_dma_ranges && !ranges) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (ranges)
+ found_dma_ranges = true;
+
+ dev = of_get_parent(dev);
+ }
+
+ if (!dev || !ranges) {
+ debug("no dma-ranges found for node %s\n",
+
[PATCH 2/8] rpi: Add identifier for the new CM4
The Raspberry Pi Foundation released the new Compute Module 4which we
want to detect, so we can enable Ethernet on it and know the correct
device tree file name.
Note that this sets the Ethernet option to true since the official CM4
IO board has an Ethernet port. But that might not be the case when using
custom ones.
Signed-off-by: Nicolas Saenz Julienne
---
---
board/raspberrypi/rpi/rpi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index ce60a24352..4ffd23c6ac 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -162,6 +162,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-4-b.dtb",
true,
},
+ [0x14] = {
+ "Compute Modue 4",
+ DTB_DIR "bcm2711-rpi-cm4.dtb",
+ true,
+ },
};
static const struct rpi_model rpi_models_old_scheme[] = {
--
2.29.2
[PATCH 6/8] dm: Introduce dev_phys_to_bus()/dev_bus_to_phys()
These functions, instead of relying on hard-coded platform-specific
address translations, make use of the DMA constraints provided by the DM
core. This allows for per-device translations.
Signed-off-by: Nicolas Saenz Julienne
---
include/phys2bus.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/phys2bus.h b/include/phys2bus.h
index dc9b8e5a25..a380063af4 100644
--- a/include/phys2bus.h
+++ b/include/phys2bus.h
@@ -21,4 +21,20 @@ static inline unsigned long bus_to_phys(unsigned long bus)
}
#endif
+#if CONFIG_IS_ENABLED(DM)
+#include
+
+static inline dma_addr_t dev_phys_to_bus(struct udevice *dev,
+phys_addr_t phys)
+{
+ return phys - dev->dma_offset;
+}
+
+static inline phys_addr_t dev_bus_to_phys(struct udevice *dev,
+ dma_addr_t bus)
+{
+ return bus + dev->dma_offset;
+}
+#endif
+
#endif
--
2.29.2
[PATCH 5/8] dm: Introduce DMA constraints into the core device model
Calculating the DMA offset between a bus address space and CPU's every
time we call phys_to_bus() and bus_to_phys() isn't ideal performance
wise. This information is static and available before initializing the
devices so parse it before the probe call an provide the DMA offset it
in 'struct udevice' for the DMA code to use it.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/core/device.c | 24
include/dm/device.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 4b3dcb3b37..4255bea24d 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -421,6 +421,28 @@ fail:
return ret;
}
+void device_get_dma_constraints(struct udevice *dev)
+{
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
+
+ if (!dev_of_valid(dev))
+ return;
+
+ ret = dev_get_dma_range(dev, , , );
+ if (ret) {
+ /* Don't complain if no 'dma-ranges' were found */
+ if (ret != -ENODEV)
+ dm_warn("%s: failed to get DMA range, %d\n",
+ dev->name, ret);
+ return;
+ }
+
+ dev->dma_offset = cpu - bus;
+}
+
int device_probe(struct udevice *dev)
{
const struct driver *drv;
@@ -482,6 +504,8 @@ int device_probe(struct udevice *dev)
goto fail;
}
+ device_get_dma_constraints(dev);
+
ret = uclass_pre_probe_device(dev);
if (ret)
goto fail;
diff --git a/include/dm/device.h b/include/dm/device.h
index 5bef484247..59f711e3dd 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -161,6 +161,7 @@ struct udevice {
#ifdef CONFIG_DEVRES
struct list_head devres_head;
#endif
+ u64 dma_offset;
};
/* Maximum sequence number supported */
--
2.29.2
[PATCH 3/8] pci: pcie-brcmstb: Fix inbound window configurations
So far we've assumed a fixed configuration for inbound windows as we had a single user for this controller. But the controller's DMA constraints were improved starting with BCM2711's B1 revision of the SoC, notably available in CM4 and Pi400. They allow for wider inbound windows. We can now cover the whole address space, whereas before we where limited to the lower 3GB. This information is passed to us through DT's 'dma-ranges' property and it's specially important for us to honor it them since some interactions with the board's co-processor assume we're doing so (specifically the XHCI firmware load operation, which is handled by the co-processor after u-boot has correctly configured the PCIe controller). Signed-off-by: Nicolas Saenz Julienne --- drivers/pci/pcie_brcmstb.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c index dade79e9c8..f6e8ad0d0a 100644 --- a/drivers/pci/pcie_brcmstb.c +++ b/drivers/pci/pcie_brcmstb.c @@ -432,6 +432,7 @@ static int brcm_pcie_probe(struct udevice *dev) struct pci_controller *hose = dev_get_uclass_priv(ctlr); struct brcm_pcie *pcie = dev_get_priv(dev); void __iomem *base = pcie->base; + struct pci_region region; bool ssc_good = false; int num_out_wins = 0; u64 rc_bar2_offset, rc_bar2_size; @@ -468,13 +469,10 @@ static int brcm_pcie_probe(struct udevice *dev) MISC_CTRL_SCB_ACCESS_EN_MASK | MISC_CTRL_CFG_READ_UR_MODE_MASK | MISC_CTRL_MAX_BURST_SIZE_128); - /* -* TODO: When support for other SoCs than BCM2711 is added we may -* need to use the base address and size(s) provided in the dma-ranges -* property. -*/ - rc_bar2_offset = 0; - rc_bar2_size = 0xc000; + + pci_get_dma_regions(dev, , 0); + rc_bar2_offset = region.bus_start - region.phys_start; + rc_bar2_size = 1ULL << fls64(region.size - 1); tmp = lower_32_bits(rc_bar2_offset); u32p_replace_bits(, brcm_pcie_encode_ibar_size(rc_bar2_size), -- 2.29.2
[PATCH 0/8] Raspberry Pi 400/Compute Module 4 support
This series could be split into at least two or even three parts, but I kept it as is for now as it contains all the changes needed in order to have u-boot working on the new Raspberry Pi 400 and Raspberry Pi Compute Module 4. There are core changes, specifically with regard to cpu to bus address space translations. So far we had relied on hardcoded values but RPi needs per device translations as it has at least three distinct bus address spaces with different offsets. So it's a good opportunity to implement bus tranlations the right way by parsing DT's dma-ranges. I'm not that familiar with u-boot's device/driver model so I might have made some sille assumptions. Sorry in advance. :) --- Nicolas Saenz Julienne (8): rpi: Add identifier for the new RPi400 rpi: Add identifier for the new CM4 pci: pcie-brcmstb: Fix inbound window configurations dm: Introduce xxx_get_dma_range() dm: Introduce DMA constraints into the core device model dm: Introduce dev_phys_to_bus()/dev_bus_to_phys() xhci: translate virtual addresses into the bus's address space mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys() board/raspberrypi/rpi/rpi.c | 10 + common/fdt_support.c | 72 drivers/core/device.c| 24 drivers/core/of_addr.c | 68 ++ drivers/core/ofnode.c| 9 + drivers/core/read.c | 5 +++ drivers/mmc/sdhci.c | 7 ++-- drivers/pci/pcie_brcmstb.c | 12 +++--- drivers/usb/host/xhci-mem.c | 45 +++--- drivers/usb/host/xhci-ring.c | 11 -- drivers/usb/host/xhci.c | 4 +- include/dm/device.h | 1 + include/dm/of_addr.h | 17 + include/dm/ofnode.h | 16 include/dm/read.h| 6 +++ include/fdt_support.h| 14 +++ include/mmc.h| 10 + include/phys2bus.h | 16 include/usb/xhci.h | 22 ++- 19 files changed, 331 insertions(+), 38 deletions(-) -- 2.29.2
[PATCH 1/8] rpi: Add identifier for the new RPi400
The Raspberry Pi Foundation released the new RPi400 which we want to
detect, so we can enable Ethernet on it and know the correct device tree
file name.
So far the Raspberry Pi foundation is using the RPi4b device-tree file
to boot RPi400. I see no reason not to do the same as they are
completely compatible.
Signed-off-by: Nicolas Saenz Julienne
---
board/raspberrypi/rpi/rpi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 6b1fa5fc14..ce60a24352 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -157,6 +157,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-4-b.dtb",
true,
},
+ [0x13] = {
+ "400",
+ DTB_DIR "bcm2711-rpi-4-b.dtb",
+ true,
+ },
};
static const struct rpi_model rpi_models_old_scheme[] = {
--
2.29.2
Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04
Hi, I have extended the previous post. with these modifications i get: U-Boot 2021.01-rc2-00047-g9324c9a823-dirty (Nov 19 2020 - 15:33:00 +0100) odroid-c2 Model: Hardkernel ODROID-C2 SoC: Amlogic Meson GXBB (S905) Revision 1f:c (0:1) DRAM: 2 GiB MMC: mmc@72000: 0, mmc@74000: 1 In: serial Out: serial Err: serial Net: Could not get PHY for ethernet@c941: addr -1 No ethernet found. Hit any key to stop autoboot: 0 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = cdff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[226] MESON EMMC status = c5ff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[226] MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = cdff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[226] Card did not respond to voltage select! : -110 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = cdff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[226] MESON EMMC status = c5ff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[226] MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 00ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[226] Card did not respond to voltage select! : -110 MMC Device 2 not found no mmc device at slot 2 starting USB... Hope this shed more light on the issue. Following you find the output of 2020.04 with this mod. and working reading off mmc info of the emmc => mmc dev 1 MESON EMMC status = c5ff MESON EMMC status = c5ff MESON EMMC status = c8ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = cdff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[206] MESON EMMC status = c5ff MESON EMMC status = 01ff2800 meson_dm_mmc_send_cmd[206] MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = d9fe MESON EMMC status = d9fe MESON EMMC status = d9fe MESON EMMC status = d9fe MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 MESON EMMC status = c5ff MESON EMMC status = 01ff2000 switch to partitions #0, OK mmc1(part 0) is current device => mmc info Device: mmc@74000 Manufacturer ID: 15 OEM: 100 Name: CJTD4 Bus
Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04
Hi,
with these modifications i get:
U-Boot 2021.01-rc2-00047-g9324c9a823-dirty (Nov 19 2020 - 15:33:00
+0100) odroid-c2
Model: Hardkernel ODROID-C2
SoC: Amlogic Meson GXBB (S905) Revision 1f:c (0:1)
DRAM: 2 GiB
MMC: mmc@72000: 0, mmc@74000: 1
In: serial
Out: serial
Err: serial
Net: Could not get PHY for ethernet@c941: addr -1
No ethernet found.
Hit any key to stop autoboot: 0
MESON EMMC status = c5ff
MESON EMMC status = 01ff2000
MESON EMMC status = c5ff
MESON EMMC status = cdff
MESON EMMC status = 01ff2800
meson_dm_mmc_send_cmd[226]
MESON EMMC status = c5ff
MESON EMMC status = 01ff2800
meson_dm_mmc_send_cmd[226]
MESON EMMC status = c5ff
MESON EMMC status = 01ff2000
MESON EMMC status = c5ff
MESON EMMC status = cdff
MESON EMMC status = 01ff2800
meson_dm_mmc_send_cmd[226]
Card did not respond to voltage select! : -110
MESON EMMC status = c5ff
MESON EMMC status = 01ff2000
MESON EMMC status = c5ff
MESON EMMC status = cdff
MESON EMMC status = 01ff2800
meson_dm_mmc_send_cmd[226]
MESON EMMC status = c5ff
MESON EMMC status = 01ff2800
meson_dm_mmc_send_cmd[226]
MESON EMMC status = c5ff
MESON EMMC status = 01ff2000
MESON EMMC status = c5ff
MESON EMMC status = 00ff2000
MESON EMMC status = c5ff
MESON EMMC status = 01ff2800
meson_dm_mmc_send_cmd[226]
Card did not respond to voltage select! : -110
MMC Device 2 not found
no mmc device at slot 2
starting USB...
Hope this shed more light on the issue.
Best regards
Am 19.11.20 um 12:50 schrieb Jaehoon Chung:
Hi,
On 11/19/20 12:54 AM, Otto Meier wrote:
Hi,
i have reverted the commit fe95905ffed57d617cad81a71ac419d53aaa1ebf
and set regulator-allways-on in meson-gxbb-odroidc2.dts.
And i also applied "PATCH V2] mmc: display an error number to debug"
from list and disabled CONFIG_MMC_DEBUG
after that i got the following result:
U-Boot 2021.01-rc2-00047-g9324c9a823-dirty (Nov 18 2020 - 16:38:40 +0100)
odroid-c2
Model: Hardkernel ODROID-C2
SoC: Amlogic Meson GXBB (S905) Revision 1f:c (0:1)
DRAM: 2 GiB
MMC: mmc@72000: 0, mmc@74000: 1
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@c941
Hit any key to stop autoboot: 0
Card did not respond to voltage select! : -110
Card did not respond to voltage select! : -110
MMC Device 2 not found
no mmc device at slot 2
starting USB...
Bus usb@c910: USB DWC2
scanning bus usb@c910 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Device 0: unknown device
Speed: 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
DHCP client bound to address 192.168.20.199 (3767 ms)
*** Warning: no boot file name; using 'C0A814C7.img'
Using ethernet@c941 device
It Does not seem to have fixed it. The above mentioned patch
prints ERROR 110. I'm not able to bisect.
Perhaps if any other reason comes to mind. I will try and test it.
I think your targets's status is something special. I'm not sure but it seems
that something is affected.
Frankly, it's difficult to me about finding correct problem without Odroid-c2.
But TIMEOUT is returned two locations.
When i saw your previous log, i guess that it's below location.
/* use 10s timeout */
start = get_timer(0);
do {
status = meson_read(mmc, MESON_SD_EMMC_STATUS);
} while(!(status & STATUS_END_OF_CHAIN) && get_timer(start) < 1);
if (!(status & STATUS_END_OF_CHAIN))
ret = -ETIMEDOUT;
else if (status & STATUS_RESP_TIMEOUT)
ret = -ETIMEDOUT;
else if (status & STATUS_ERR_MASK)
ret = -EIO;
To Workaround check, increase timeout value from 1000 to other value.
And check which condition is hit, plz. likes below.
do {
status = meson_read(mmc, MESON_SD_EMMC_STATUS);
printf("MESON EMMC status = %08x\n", status);
} while(!(status & STATUS_END_OF_CHAIN) && get_timer(start) < 100);
if (!(status & STATUS_END_OF_CHAIN)) {
printf("%s[%d]\n",__func__,__LINE__);
ret = -ETIMEDOUT;
} else if (status & STATUS_RESP_TIMEOUT) {
printf("%s[%d]\n",__func__,__LINE__);
ret = -ETIMEDOUT;
} else if (status & STATUS_ERR_MASK)
ret = -EIO;
Sorry for not being able to help you much.
Best Regards,
Jaehoon Chung
Best regards
otto
Am 18.11.20 um 13:23 schrieb Jaehoon Chung:
On 11/18/20 8:44 PM, Otto Meier wrote:
Hi,
it is not a new issue, since u-boot 2020.07 this issue exists.
even by using the repo you mention the error exist.
Yes, git repo doesn't matter. When i have checked, you are using almost latest
u-boot. (commit 9324c9a823)
If it's existed since 2020.07, it seems that relevant to below commit.
commit fe95905ffed57d617cad81a71ac419d53aaa1ebf
Author: Haibo Chen
Date: Mon Jun 15 17:18:12 2020 +0800
mmc:
Re: [PATCH v1 2/7] board: toradex: add apalis-imx8x 2gb wb it v1.1a module support
On 22/10/20, Igor Opaniuk wrote: > From: Igor Opaniuk > > * With the SCU FW from the latest Toradex BSP 5.0.0 (SCU FW 1.5.1) > ETH PHY encounters bring up problems after reset, this will be fixed > soon on SCU FW side. Hello Igor, are these ETH Phy problems also in NXP provided SCU FW 1.5.1/ 1.6.0? Because I observe some phy clk issue after upgrading from SCU FW 1.2.6 to 1.5.1/1.6.0. (iMX8QM) Best regards, Oliver
RE: [PATCH 2/3] log: use debug uart to output trace before LOG init
Hi Simon,
> From: Simon Glass
> Sent: mercredi 11 novembre 2020 15:32
> To: Patrick DELAUNAY ; Heinrich Schuchardt
>
> +Heinrich Schuchardt
OK
> On Fri, 6 Nov 2020 at 10:55, Patrick Delaunay wrote:
> >
> > Use the debug uart functions to output the traces before the log
> > initialization (when CONFIG_LOG is not activated) as it is done in
> > puts/putc function in console.c.
> >
> > This patch allows to display the first U-Boot traces (with macro
> > debug) when CONFIG_DEBUG_UART is activated and not only drop them.
> >
> > For example for traces in board_f.c requested by the macro debug, when
> > LOG_DEBUG is defined and CONFIG_LOG is activated.
> >
> > Signed-off-by: Patrick Delaunay
> > ---
> >
> > common/log.c | 11 +++
> > 1 file changed, 11 insertions(+)
>
> Reviewed-by: Simon Glass
>
> Again this needs a sandbox test
I am preparing a sandbox test for v2.
But I think I will replace printascii() by console function, puts()
To use all supported feature of console.c
=> DEBUG_UART / PRE_CONSOLE_BUFFER / CONSOLE_RECORD
CONSOLE_RECORD is needed by unitary test...
> >
> > diff --git a/common/log.c b/common/log.c index aadf533fb2..aa5505943f
> > 100644
> > --- a/common/log.c
> > +++ b/common/log.c
> > @@ -7,6 +7,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -245,6 +246,16 @@ int _log(enum log_category_t cat, enum
> > log_level_t level, const char *file,
> >
> > if (!(gd->flags & GD_FLG_LOG_READY)) {
> > gd->log_drop_count++;
> > +
> > + /* manage droppped trace at default level with debug
> > + uart */
>
> dropped
>
OK
> > + if (IS_ENABLED(CONFIG_DEBUG_UART) &&
> > + (rec.level <= CONFIG_LOG_DEFAULT_LEVEL ||
> rec.force_debug)) {
> > + va_start(args, fmt);
> > + vsnprintf(buf, sizeof(buf), fmt, args);
> > + printascii(buf);
> > + va_end(args);
> > + }
> > +
> > return -ENOSYS;
> > }
> > va_start(args, fmt);
> > --
> > 2.17.1
> >
Thanks for the review
Patrick
Re: [PATCH v2] time: Fix get_ticks being non-monotonic
Hi, Sorry, no messaging quoting, I was not subscribed to the list at that time. Merging this change into master actually broke the SPL on Atmel/Microchip SAMA5D3, at least booting from MMC: RomBOOT Could not initialize timer (err -11) Could not initialize timer (err -11) Could not initialize timer (err -11) ... I'll look for a fix, but suggestions are welcome! Cheers, Michael. -- Michael Opdenacker, CEO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v3] arm: vexpress: don't reset flags in board_init to avoid losing previous ones
Tested-by: Michael Opdenacker -- Michael Opdenacker, CEO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: Booting on RK3399[Please note, mail behalf by s...@google.com]
Hi Kever, thanks for your reply, so i should change baud rate in bl31 to see it? how can i handle it? Best Regards Piotr -- Sent from: http://u-boot.10912.n7.nabble.com/
Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04
Hi,
On 11/19/20 12:54 AM, Otto Meier wrote:
> Hi,
>
> i have reverted the commit fe95905ffed57d617cad81a71ac419d53aaa1ebf
> and set regulator-allways-on in meson-gxbb-odroidc2.dts.
>
> And i also applied "PATCH V2] mmc: display an error number to debug"
> from list and disabled CONFIG_MMC_DEBUG
>
> after that i got the following result:
>
>
> U-Boot 2021.01-rc2-00047-g9324c9a823-dirty (Nov 18 2020 - 16:38:40 +0100)
> odroid-c2
>
> Model: Hardkernel ODROID-C2
> SoC: Amlogic Meson GXBB (S905) Revision 1f:c (0:1)
> DRAM: 2 GiB
> MMC: mmc@72000: 0, mmc@74000: 1
> In: serial
> Out: serial
> Err: serial
> Net: eth0: ethernet@c941
> Hit any key to stop autoboot: 0
> Card did not respond to voltage select! : -110
> Card did not respond to voltage select! : -110
> MMC Device 2 not found
> no mmc device at slot 2
> starting USB...
> Bus usb@c910: USB DWC2
> scanning bus usb@c910 for devices... 2 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
>
> Device 0: unknown device
> Speed: 1000, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> BOOTP broadcast 5
> DHCP client bound to address 192.168.20.199 (3767 ms)
> *** Warning: no boot file name; using 'C0A814C7.img'
> Using ethernet@c941 device
>
> It Does not seem to have fixed it. The above mentioned patch
> prints ERROR 110. I'm not able to bisect.
> Perhaps if any other reason comes to mind. I will try and test it.
I think your targets's status is something special. I'm not sure but it seems
that something is affected.
Frankly, it's difficult to me about finding correct problem without Odroid-c2.
But TIMEOUT is returned two locations.
When i saw your previous log, i guess that it's below location.
/* use 10s timeout */
start = get_timer(0);
do {
status = meson_read(mmc, MESON_SD_EMMC_STATUS);
} while(!(status & STATUS_END_OF_CHAIN) && get_timer(start) < 1);
if (!(status & STATUS_END_OF_CHAIN))
ret = -ETIMEDOUT;
else if (status & STATUS_RESP_TIMEOUT)
ret = -ETIMEDOUT;
else if (status & STATUS_ERR_MASK)
ret = -EIO;
To Workaround check, increase timeout value from 1000 to other value.
And check which condition is hit, plz. likes below.
do {
status = meson_read(mmc, MESON_SD_EMMC_STATUS);
printf("MESON EMMC status = %08x\n", status);
} while(!(status & STATUS_END_OF_CHAIN) && get_timer(start) < 100);
if (!(status & STATUS_END_OF_CHAIN)) {
printf("%s[%d]\n",__func__,__LINE__);
ret = -ETIMEDOUT;
} else if (status & STATUS_RESP_TIMEOUT) {
printf("%s[%d]\n",__func__,__LINE__);
ret = -ETIMEDOUT;
} else if (status & STATUS_ERR_MASK)
ret = -EIO;
Sorry for not being able to help you much.
Best Regards,
Jaehoon Chung
>
> Best regards
> otto
>
>
>
>
> Am 18.11.20 um 13:23 schrieb Jaehoon Chung:
>> On 11/18/20 8:44 PM, Otto Meier wrote:
>>> Hi,
>>>
>>> it is not a new issue, since u-boot 2020.07 this issue exists.
>>> even by using the repo you mention the error exist.
>> Yes, git repo doesn't matter. When i have checked, you are using almost
>> latest u-boot. (commit 9324c9a823)
>>
>> If it's existed since 2020.07, it seems that relevant to below commit.
>>
>> commit fe95905ffed57d617cad81a71ac419d53aaa1ebf
>> Author: Haibo Chen
>> Date: Mon Jun 15 17:18:12 2020 +0800
>>
>> mmc: retry CMD1 in mmc_send_op_cond() until the eMMC is ready
>>
>> According to eMMC specification v5.1 section 6.4.3, we should issue
>> CMD1 repeatedly in the idle state until the eMMC is ready even if
>> mmc_send_op_cond() send CMD1 with argument = 0. Otherwise some eMMC
>> devices seems to enter the inactive mode after mmc_complete_op_cond()
>> issued CMD0 when the eMMC device is busy.
>>
>> Signed-off-by: Haibo Chen
>> Reviewed-by: Peng Fan
>>
>> Could you check it?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>
>>> I allways use : make odroid-c2_defconfig with no other config option set to
>>> build u-boot.
>>>
>>> Best regards
>>>
>>> Otto
>>>
>>> Am 18.11.20 um 09:12 schrieb Alexander Dahl:
Hei hei,
FWIW see below,
Am Dienstag, 17. November 2020, 20:08:21 CET schrieb Otto Meier:
> Dear Jaehoon Chung,
>
> I cloned github.com/u-boot which i believe is the master repo.
That seems to be an up to date mirror. However, according to [1] and [2]
the
real upstream repository is here:
https://protect2.fireeye.com/v1/url?k=6b6d3e43-34f6074f-6b6cb50c-000babff3563-39827ce0c87bb58b=1=29cccebd-0f84-49bd-a69e-c1c8a1916260=https%3A%2F%2Fgitlab.denx.de%2Fu-boot%2Fu-boot
Greets
Alex
[1]
[PATCH 1/1] fs: fat: avoid NULL dereference when root dir is full
When trying to create a file in the full root directory of a FAT32
filesystem a NULL dereference can be observed.
When the root directory of a FAT16 filesystem is full fill_dir_slot() must
return -1 to signal that a new directory entry could not be allocated.
Fixes: cd2d727fff7e ("fs: fat: allocate a new cluster for root directory of
fat32")
Signed-off-by: Heinrich Schuchardt
---
fs/fat/fat_write.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index a2682b5f46..fc932df953 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -260,9 +260,8 @@ fill_dir_slot(fat_itr *itr, const char *l_name)
flush_dir(itr);
/* allocate a cluster for more entries */
- if (!fat_itr_next(itr))
- if (!itr->dent &&
- (!itr->is_root || itr->fsdata->fatsize == 32) &&
+ if (!fat_itr_next(itr) && !itr->dent)
+ if ((itr->is_root && itr->fsdata->fatsize != 32) ||
new_dir_table(itr))
return -1;
}
--
2.28.0
[PATCH] sunxi: Add arm64 FEL support
So far we did not support the BootROM based FEL USB debug mode on the
64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
SPL runs in AArch64.
Returning back to AArch32 was not working as expected, since the RMR
reset into 32-bit mode always starts execution in the BootROM, but not
in the FEL routine.
After some debug and research and with help via IRC, the CPU hotplug
mechanism emerged as a solution: If a certain R_CPUCFG register contains
some magic, the BootROM will immediately branch to an address stored in
some other register. This works well for our purposes.
Enable the FEL feature by providing early AArch32 code to first save the
FEL state, *before* initially entering AArch64.
If we eventually determine that we should return to FEL, we reset back
into AArch32, and use the CPU hotplug mechanism to run some small
AArch32 code snippet that restores the initially saved FEL state.
That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
tool, with it returning into FEL mode, so that other payloads can be
transferred via FEL as well.
Tested on A64, H5 and H6.
Signed-off-by: Andre Przywara
---
arch/arm/cpu/armv8/Makefile | 2 +
arch/arm/cpu/armv8/fel_utils.S | 78 +
arch/arm/include/asm/arch-sunxi/boot0.h | 14 +
include/configs/sunxi-common.h | 2 -
4 files changed, 94 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/cpu/armv8/fel_utils.S
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index 93d26f98568..f7b4a5ee46c 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC) += smccc-call.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o
+else
+obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o
endif
obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o
sec_firmware_asm.o
diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
new file mode 100644
index 000..334fdef7fa0
--- /dev/null
+++ b/arch/arm/cpu/armv8/fel_utils.S
@@ -0,0 +1,78 @@
+/*
+ * Utility functions for FEL mode, when running SPL in AArch64.
+ *
+ * Copyright (c) 2017 Arm Ltd.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+/*
+ * We don't overwrite save_boot_params() here, to save the FEL state upon
+ * entry, since this would run *after* the RMR reset, which clobbers that
+ * state.
+ * Instead we store the state _very_ early in the boot0 hook, *before*
+ * resetting to AArch64.
+ */
+
+/*
+ * The FEL routines in BROM run in AArch32.
+ * Reset back into 32-bit mode here and restore the saved FEL state
+ * afterwards.
+ * Resetting back into AArch32/EL3 using the RMR always enters the BROM,
+ * but we can use the CPU hotplug mechanism to branch back to our code
+ * immediately.
+ */
+ENTRY(return_to_fel)
+ /*
+* the RMR reset will clear all registers, so save the arguments
+* (LR and SP) in the fel_stash structure, which we read anyways later
+*/
+ adr x2, fel_stash
+ str w0, [x2]
+ str w1, [x2, #4]
+
+ adr x1, fel_stash_addr // to find the fel_stash address in AA32
+ str w2, [x1]
+
+ ldr x0, =0xfa50392f // CPU hotplug magic
+#ifndef CONFIG_MACH_SUN50I_H6
+ ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
+ str w0, [x2, #0x8]
+#else
+ ldr x2, =(SUNXI_RTC_BASE + 0x1b8) // BOOT_CPU_HP_FLAG_REG
+ str w0, [x2], #0x4
+#endif
+ adr x0, back_in_32
+ str w0, [x2]
+
+ dsb sy
+ isb sy
+ mov x0, #2 // RMR reset into AArch32
+ dsb sy
+ msr RMR_EL3, x0
+ isb sy
+1: wfi
+ b 1b
+
+/* AArch32 code to restore the state from fel_stash and return back to FEL. */
+back_in_32:
+ .word 0xe59f0028 // ldr r0, [pc, #40] ; load fel_stash address
+ .word 0xe5901008 // ldr r1, [r0, #8]
+ .word 0xe129f001 // msr CPSR_fc, r1
+ .word 0xf57ff06f // isb
+ .word 0xe590d000 // ldr sp, [r0]
+ .word 0xe590e004 // ldr lr, [r0, #4]
+ .word 0xe5901010 // ldr r1, [r0, #16]
+ .word 0xee0c1f10 // mcr 15, 0, r1, cr12, cr0, {0} ; VBAR
+ .word 0xe590100c // ldr r1, [r0, #12]
+ .word 0xee011f10 // mcr 15, 0, r1, cr1, cr0, {0} ; SCTLR
+ .word 0xf57ff06f // isb
+ .word 0xe12fff1e // bx lr ; return to FEL
+fel_stash_addr:
+ .word 0x // receives fel_stash addr, by AA64 code above
+ENDPROC(return_to_fel)
diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
b/arch/arm/include/asm/arch-sunxi/boot0.h
index 54c144afd8c..46d0f0666c2 100644
--- a/arch/arm/include/asm/arch-sunxi/boot0.h
+++
RE: [PATCH] common/board_r: make sure to call initr_dm() before initr_trace()
>-Original Message-
>From: Simon Glass
>Sent: 18 November 2020 20:07
>To: Pragnesh Patel
>Cc: Heinrich Schuchardt ; U-Boot Mailing List b...@lists.denx.de>
>Subject: Re: [PATCH] common/board_r: make sure to call initr_dm() before
>initr_trace()
>
>[External Email] Do not click links or attachments unless you recognize the
>sender and know the content is safe
>
>Hi Pragnesh,
>
>On Mon, 16 Nov 2020 at 22:23, Pragnesh Patel
>wrote:
>>
>> Hi,
>>
>> >-Original Message-
>> >From: Simon Glass
>> >Sent: 17 November 2020 05:23
>> >To: Pragnesh Patel
>> >Cc: Heinrich Schuchardt ; U-Boot Mailing List > >b...@lists.denx.de>
>> >Subject: Re: [PATCH] common/board_r: make sure to call initr_dm()
>> >before
>> >initr_trace()
>> >
>> >[External Email] Do not click links or attachments unless you
>> >recognize the sender and know the content is safe
>> >
>> >Hi,
>> >
>> >On Sun, 15 Nov 2020 at 05:16, Pragnesh Patel
>> >
>> >wrote:
>> >>
>> >> Hi Heinrich,
>> >>
>> >> >-Original Message-
>> >> >From: Heinrich Schuchardt
>> >> >Sent: 12 November 2020 18:02
>> >> >To: Pragnesh Patel
>> >> >Cc: U-Boot Mailing List ; Simon Glass
>> >> >
>> >> >Subject: Re: [PATCH] common/board_r: make sure to call initr_dm()
>> >> >before
>> >> >initr_trace()
>> >> >
>> >> >[External Email] Do not click links or attachments unless you
>> >> >recognize the sender and know the content is safe
>> >> >
>> >> >On 11/12/20 12:18 PM, Pragnesh Patel wrote:
>> >> >> Tracing need timer ticks and initr_dm() will make gd->timer and
>> >> >> gd->dm_root is equal to NULL, so make sure that initr_dm() to
>> >> >> call before tracing got enabled.
>> >> >>
>> >> >> Signed-off-by: Pragnesh Patel
>> >> >> ---
>> >> >> common/board_r.c | 6 +++---
>> >> >> 1 file changed, 3 insertions(+), 3 deletions(-)
>> >> >>
>> >> >> diff --git a/common/board_r.c b/common/board_r.c index
>> >> >> 29dd7d26d9..7140a39947 100644
>> >> >> --- a/common/board_r.c
>> >> >> +++ b/common/board_r.c
>> >> >> @@ -693,6 +693,9 @@ static int run_main_loop(void)
>> >> >> * TODO: perhaps reset the watchdog in the initcall function after
>> >> >> each
>call?
>> >> >> */
>> >> >> static init_fnc_t init_sequence_r[] = {
>> >> >> +#ifdef CONFIG_DM
>> >> >> + initr_dm,
>> >> >> +#endif
>> >> >> initr_trace,
>> >> >> initr_reloc,
>> >> >> /* TODO: could x86/PPC have this also perhaps? */ @@
>> >> >> -718,9
>> >> >> +721,6 @@ static init_fnc_t init_sequence_r[] = {
>> >> >> initr_noncached,
>> >> >> #endif
>> >> >> initr_of_live,
>> >> >> -#ifdef CONFIG_DM
>> >> >> - initr_dm,
>> >> >> -#endif
>> >> >
>> >> >You are moving initr_of_live before initr_of_live. I doubt this
>> >> >will work for boards that have CONFIG_OF_LIVE=y.
>> >>
>> >> yes you are right. It will not work for CONFIG_OF_LIVE.
>> >>
>> >> >
>> >> >Can't we move initr_trace down in the code to after both
>> >> >initr_of_live and initr_dm?
>> >> >
>> >> >@Simon:
>> >> >Please, advise.
>> >>
>> >> I am okay with this suggestion.
>> >
>> >Actually can we use the early timer for this case?
>> >
>> >DM init is a part of U-Boot and not being able to trace it would be
>unfortunate.
>>
>> Got it.
>>
>> If someone wants to use tracing without TIMER_EARLY then
>>
>> - initr_dm() will make gd->dm_root = NULL; and gd->timer = NULL; and
>> __cyg_profile_func_enter () will call timer_get_us() -> get_ticks() ->
>dm_timer_init().
>>
>> dm_timer_init() will not able to initialize timer and return an error.
>>
>> We need to find any solution for this.
>
>How about we make TRACE select or depend on TIMER_EARLY?
I am okay with this. Better to make TRACE select TIMER_EARLY.
>
>Regards,
>Simon
RE: [RESEND v2 09/22] arm: socfpga: Add handoff data support for Diamond Mesa
> -Original Message-
> From: Lim, Elly Siew Chin
> Sent: Tuesday, November 10, 2020 2:44 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
>
> Subject: [RESEND v2 09/22] arm: socfpga: Add handoff data support for
> Diamond Mesa
>
> Diamond Mesa support both HPS handoff data and DDR handoff data.
> HPS handoff data support re-use Straix10 and Agilex code. DDR handoff data
> is newly introduced in Diamond Mesa.
>
> Signed-off-by: Siew Chin Lim
> ---
> arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 19 ++
> arch/arm/mach-socfpga/wrap_handoff_soc64.c | 40
> ++
> 2 files changed, 59 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> index 68e0278384..c38b232065 100644
> --- a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> +++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
[...]
> + } else {
> +#ifdef CONFIG_TARGET_SOCFPGA_DM
> + temp = readl(handoff_address);
> + if (temp == SOC64_HANDOFF_DDR_UMCTL2_MAGIC) {
> + debug("%s: umctl2 handoff data =\n{\n",
> + __func__);
> + } else if (temp == SOC64_HANDOFF_DDR_PHY_MAGIC) {
> + debug("%s: PHY handoff data =\n{\n",
> + __func__);
> + } else if (temp ==
> SOC64_HANDOFF_DDR_PHY_INIT_ENGINE_MAGIC) {
> + debug("%s: PHY engine handoff data =\n{\n",
> + __func__);
> + }
> +
> + debug("handoff table address = 0x%p table length = 0x%x\n",
> + table_x32, table_len);
> +
> + if (temp == SOC64_HANDOFF_DDR_UMCTL2_MAGIC ||
> + temp == SOC64_HANDOFF_DDR_PHY_MAGIC ||
> + temp ==
> SOC64_HANDOFF_DDR_PHY_INIT_ENGINE_MAGIC) {
> + /* Using handoff from Quartus tools if exists */
> + for (i = 0; i < table_len; i++) {
> + *table_x32 = readl(handoff_address +
> +
> SOC64_HANDOFF_OFFSET_DATA + (i * 4));
Change 4 to sizeof().
Regards
Ley Foon
Re: [PATCH] riscv: fix the wrong swap value register
On Fri, Nov 13, 2020 at 08:47:51PM +0900, Brad Kim wrote: > Not s2 register, t1 register is correct > Fortunately, it works because t1 register has a garbage value > > Signed-off-by: Brad Kim > Reviewed-by: Lukas Auer > --- > arch/riscv/cpu/start.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > index bbc737ed9a..8589509e01 100644 > --- a/arch/riscv/cpu/start.S > +++ b/arch/riscv/cpu/start.S > @@ -123,7 +123,7 @@ call_board_init_f_0: >* wait for initialization to complete. >*/ > la t0, hart_lottery > - li s2, 1 > + li t1, 1 > amoswap.w s2, t1, 0(t0) > bnezs2, wait_for_gd_init > #else Reviewed-by: Leo Liang
RE: [RESEND v2 08/22] arm: socfpga: Restructure Stratix10 and Agilex handoff code
> -Original Message- > From: Lim, Elly Siew Chin > Sent: Tuesday, November 10, 2020 2:44 PM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Tan, Ley Foon > ; See, Chin Liang ; > Simon Goldschmidt ; Chee, Tien Fong > ; Westergreen, Dalon > ; Simon Glass ; Gan, > Yau Wai ; Lim, Elly Siew Chin > > Subject: [RESEND v2 08/22] arm: socfpga: Restructure Stratix10 and Agilex > handoff code > > Restructure Stratix10 and Agilex handoff code to used by all SOC64 devices, > in preparation to support handoff for Diamond Mesa. > > Remove wrap_pinmux_config_s10.c. Add wrap_handoff_soc64.c which > contains the generic function to parse the handoff data. > > Update system_manager_soc64.c to use generic handoff function in > wrap_handoff_soc64.c. > > Signed-off-by: Siew Chin Lim > --- [] > diff --git a/arch/arm/mach-socfpga/system_manager_soc64.c > b/arch/arm/mach-socfpga/system_manager_soc64.c > index cdda881efd..f94bf5ecd6 100644 > --- a/arch/arm/mach-socfpga/system_manager_soc64.c > +++ b/arch/arm/mach-socfpga/system_manager_soc64.c > @@ -1,12 +1,13 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Copyright (C) 2016-2018 Intel Corporation > + * Copyright (C) 2016-2020 Intel Corporation > * > */ > > #include > #include > #include > +#include Sort in alphanumerical order. [...] > } > diff --git a/arch/arm/mach-socfpga/wrap_handoff_soc64.c > b/arch/arm/mach-socfpga/wrap_handoff_soc64.c > new file mode 100644 > index 00..672bdd5230 > --- /dev/null > +++ b/arch/arm/mach-socfpga/wrap_handoff_soc64.c > @@ -0,0 +1,73 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Intel Corporation > + * > + */ > + > +#include > +#include > +#include > +#include > +#include "log.h" Sort in alphanumerical order. [...] Regards Ley Foon
[PATCH 1/3] test: cmd_ut_category: raise a error when the test is not found
Raise an error when test is not found, for example with manual test
with bad test name, as following, doesn't raise an error
=> ut lib bad
Failures: 0
After the patch:
=> ut lib bad
lib test bad not found
Failures: 1
This patch allows also to detect tests which don't respect the expected
format with "prefix" used in cmd_ut_category and defined in ut_subtest
(./test/py/conftest.py). When I execute "make qcheck" this patch detects
2 issues, corrected by the 2 next patches.
Signed-off-by: Patrick Delaunay
---
test/cmd_ut.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/test/cmd_ut.c b/test/cmd_ut.c
index 8f0bc688a2..6a752e6456 100644
--- a/test/cmd_ut.c
+++ b/test/cmd_ut.c
@@ -20,6 +20,7 @@ int cmd_ut_category(const char *name, const char *prefix,
struct unit_test_state uts = { .fail_count = 0 };
struct unit_test *test;
int prefix_len = prefix ? strlen(prefix) : 0;
+ int nb_tests = 0;
if (argc == 1)
printf("Running %d %s tests\n", n_ents, name);
@@ -47,6 +48,12 @@ int cmd_ut_category(const char *name, const char *prefix,
uts.start = mallinfo();
test->func();
+ nb_tests++;
+ }
+
+ if (argc > 1 && nb_tests == 0) {
+ printf("%s test %s not found\n", name, argv[1]);
+ uts.fail_count = 1;
}
printf("Failures: %d\n", uts.fail_count);
--
2.17.1
[PATCH 3/3] test: correct the test prefix in ut str
Align the prefix used in cmd_ut_category function and name of tests
for ut str.
This patch solves the issues detected by "make qcheck" after previous
patch.
Fixes: fdc79a6b125d ("lib: Add a function to convert a string to upper case")
Signed-off-by: Patrick Delaunay
---
test/str_ut.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/str_ut.c b/test/str_ut.c
index ef1205dbbd..cd5045516d 100644
--- a/test/str_ut.c
+++ b/test/str_ut.c
@@ -19,7 +19,7 @@ static const char str3[] = "0xbI'm sorry you're alive.";
/* Declare a new str test */
#define STR_TEST(_name, _flags)UNIT_TEST(_name, _flags,
str_test)
-static int str_test_upper(struct unit_test_state *uts)
+static int str_upper(struct unit_test_state *uts)
{
char out[TEST_STR_SIZE];
@@ -55,7 +55,7 @@ static int str_test_upper(struct unit_test_state *uts)
return 0;
}
-STR_TEST(str_test_upper, 0);
+STR_TEST(str_upper, 0);
static int run_strtoul(struct unit_test_state *uts, const char *str, int base,
ulong expect_val, int expect_endp_offset, bool upper)
--
2.17.1
[PATCH 2/3] test: correct the test prefix in ut cmd_mem
Align the prefix used in cmd_ut_category function and name of tests
for ut mem.
This patch solves the issues detected by "make qcheck" after previous
patch.
Fixes: 550a9e7902ce ("cmd: Update the memory-search command")
Signed-off-by: Patrick Delaunay
---
test/cmd/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/cmd/mem.c b/test/cmd/mem.c
index fa6770e8c0..fbaa8a4b3c 100644
--- a/test/cmd/mem.c
+++ b/test/cmd/mem.c
@@ -15,6 +15,6 @@ int do_ut_mem(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
struct unit_test *tests = ll_entry_start(struct unit_test, mem_test);
const int n_ents = ll_entry_count(struct unit_test, mem_test);
- return cmd_ut_category("cmd_mem", "cmd_mem_", tests, n_ents, argc,
+ return cmd_ut_category("cmd_mem", "mem_test_", tests, n_ents, argc,
argv);
}
--
2.17.1
Re: [PATCH 0/2] rockchip: Fix SPI boot on Pinebook Pro and RK3399-ROC-PC
Hi Hugh,
After this patch set, only one board is still using the "spi0 =
" alias, could you correct it at the same time?
rk3399-puma-haikou-u-boot.dtsi
Thanks,
- Kever
On 2020/11/15 上午2:06, Hugh Cole-Baker wrote:
Commit c4cea2bbf995 ("rockchip: Enable building a SPI ROM image on bob")
added an alias spi1 referring to spi@ff1d, however in several boards
there was already an alias spi0 referring to the same node, and having
both aliases present broke booting U-Boot from SPI flash.
This series removes the spi0 alias from the Pinebook Pro and
RK3399-ROC-PC and sets the default bus for SPI flash to 1, so that the
correct device is used. The Rockpro64 board, which was also affected,
has already had the same type of fix applied.
The rk3399 Puma board also has an alias spi0 = in its dts, but I
haven't touched its configuration as it seems to have a more complex
setup where spi1 is already an alias that points to I don't
have one of these boards to test with, but I suspect it wasn't affected
by the addition of the spi1 alias in rk3399-u-boot.dtsi.
Hugh Cole-Baker (2):
rockchip: pinebook-pro: default to SPI bus 1 for SPI-flash
rockchip: rk3399-roc-pc: default to SPI bus 1 for SPI-flash
arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4
configs/pinebook-pro-rk3399_defconfig| 2 ++
configs/roc-pc-mezzanine-rk3399_defconfig| 1 +
configs/roc-pc-rk3399_defconfig | 1 +
5 files changed, 4 insertions(+), 8 deletions(-)
Re: Booting on RK3399[Please note, mail behalf by s...@google.com]
Hi Piotr, On 2020/11/16 下午10:55, Piotr Lobacz wrote: Hi all, i also have a firefly-rk3399 and got problems booting atf >= 1.4 with whatever optee i use. Only rockchip blob is working for me. I know that i'm doing something wrong but dunno what. The command for building atf is: # make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 LOG_LEVEL=40 DEBUG=0 CRASH_REPORTING=1 SPD=opteed bl31 and i only generate uboot.img and trust.img using rockchip build.sh script with command # ./buid.sh uboot Rockchip has added this trust_merger app to their u-boot source code. The build.sh script builds u-boot and executes make.sh script from u-boot which runs trust_merger. But for some reason it does not work atf >= 1.4. I don't know what exectly but what i can tell, i do not see any logs from bl31. For atf 1.3 with rockchip bl32 blob i can see logs: No find bl30.bin Load uboot, ReadLba = 4000 Load OK, addr=0x20, size=0xda214 RunBL31 0x1 @ 105506 us NOTICE: BL31: v1.3(release):d43a527de NOTICE: BL31: Built : 15:41:07, Nov 16 2020 INFO:GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO:plat_rockchip_pmu_init(1331): pd status 3e INFO:BL31: Initializing runtime services INFO:BL31: Initializing BL32 INF [0x0] TEE-CORE:init_primary_helper:337: Initializing (1.1.0-266-gee81607c #1 Mon Aug 17 09:23:30 UTC 2020 aarch64) INF [0x0] TEE-CORE:init_primary_helper:338: Release version: 1.2 INF [0x0] TEE-CORE:init_teecore:83: teecore inits done INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 U-Boot 2017.09 (Nov 11 2020 - 10:27:07 +0100) And this is what i get for 2.3 atf version: find part:trust OK. first_lba:0x6000. Trust Addr:0x6000, 0x58334c42 No find bl30.bin Load uboot, ReadLba = 4000 Load OK, addr=0x20, size=0xda214 RunBL31 0x4 @ 105604 us U-Boot 2017.09 (Nov 11 2020 - 10:27:07 +0100) Model: Firefly-RK3399 Board PreSerial: 2 DRAM: 3.8 GiB Sysmem: init Relocation Offset is: f5beb000 Using default environment There is no NOTICE or INFO log. The bl32 blob is the same so i suspect for 99% that bl31 was not initialized. This log shows everything is going well, there is no log from bl31 because the serial setting is different in U-Boot and ATF, eg. ATF may use a different baud rate so you can't see the serial output. Thanks, - Kever Can anybody help me solving this issue? Because currently i'm with no more ideas and this is really frustrating... Best Regards Piotr Łobacz -- Sent from: http://u-boot.10912.n7.nabble.com/
