Re: [PATCH 7/8] xhci: translate virtual addresses into the bus's address space

2020-11-19 Thread Stefan Roese

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

2020-11-19 Thread Nishanth Menon
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

2020-11-19 Thread Joel Peshkin
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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()

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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()

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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()

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Tom Rini
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

2020-11-19 Thread Bin Meng
+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

2020-11-19 Thread Heinrich Schuchardt
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

2020-11-19 Thread Heinrich Schuchardt
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()

2020-11-19 Thread Andy Shevchenko
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()

2020-11-19 Thread Robert Marko
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

2020-11-19 Thread Priit Laes
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()

2020-11-19 Thread Heinrich Schuchardt
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, &var);
+   if (!efi_var_mem_find(vendor, variable_name, &var) && *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()

2020-11-19 Thread Andy Shevchenko
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

2020-11-19 Thread Anand Moon
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 stat

[PATCH 7/8] xhci: translate virtual addresses into the bus's address space

2020-11-19 Thread Nicolas Saenz Julienne
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)&ctrl->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()

2020-11-19 Thread Nicolas Saenz Julienne
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()

2020-11-19 Thread Nicolas Saenz Julienne
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", &len);
+
+   /* 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, &na, &ns);
+   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, &pna, &pns);
+   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*)&cpu_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", &len);
+
+   /* 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 fo

[PATCH 2/8] rpi: Add identifier for the new CM4

2020-11-19 Thread Nicolas Saenz Julienne
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()

2020-11-19 Thread Nicolas Saenz Julienne
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

2020-11-19 Thread Nicolas Saenz Julienne
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, &cpu, &bus, &size);
+   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

2020-11-19 Thread Nicolas Saenz Julienne
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, ®ion, 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(&tmp, brcm_pcie_encode_ibar_size(rc_bar2_size),
-- 
2.29.2



[PATCH 0/8] Raspberry Pi 400/Compute Module 4 support

2020-11-19 Thread Nicolas Saenz Julienne
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

2020-11-19 Thread Nicolas Saenz Julienne
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

2020-11-19 Thread Otto Meier

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 Speed

Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04

2020-11-19 Thread Otto Meier

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

2020-11-19 Thread Oliver Graute
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

2020-11-19 Thread Patrick DELAUNAY
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

2020-11-19 Thread Michael Opdenacker
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

2020-11-19 Thread Michael Opdenacker
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]

2020-11-19 Thread Piotr Lobacz
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

2020-11-19 Thread 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: 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&q=1&e=29cccebd-0f84-49bd-a69e-c1c8a1916260&u=https%3A%2F%2Fgitlab.denx.de%2Fu-boot%2Fu-boot

 Greets
 Alex

 [1] 
 https://protect2.fireeye.com/v1/url?k=582063cf-07bb5ac3-5821e880-000babff3563-5e

[PATCH 1/1] fs: fat: avoid NULL dereference when root dir is full

2020-11-19 Thread Heinrich Schuchardt
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

2020-11-19 Thread Andre Przywara
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
+++ b/arch

RE: [PATCH] common/board_r: make sure to call initr_dm() before initr_trace()

2020-11-19 Thread Pragnesh Patel


>-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

2020-11-19 Thread Tan, Ley Foon



> -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

2020-11-19 Thread Leo Liang
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

2020-11-19 Thread Tan, Ley Foon



> -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

2020-11-19 Thread Patrick Delaunay
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(&uts);
+   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

2020-11-19 Thread Patrick Delaunay
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

2020-11-19 Thread Patrick Delaunay
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

2020-11-19 Thread Kever Yang

Hi Hugh,

    After this patch set, only one board is still using the "spi0 = 
&spi1" 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 = &spi1 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 &spi5. 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]

2020-11-19 Thread Kever Yang

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/