RE: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver

2020-07-19 Thread Pragnesh Patel
Hi Rick,

Any comments on this patch ?

>-Original Message-
>From: U-Boot  On Behalf Of Pragnesh Patel
>Sent: 24 June 2020 13:14
>To: Bin Meng ; Rick Chen 
>Cc: U-Boot Mailing List ; Atish Patra
>; palmerdabb...@google.com; Paul Walmsley ( Sifive)
>; Anup Patel ; Sagar
>Kadam ; Palmer Dabbelt ;
>Jagan Teki ; rick ; Alan
>Kao 
>Subject: RE: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
>
>Hi Rick,
>
>>-Original Message-
>>From: Bin Meng 
>>Sent: 24 June 2020 13:04
>>To: Rick Chen 
>>Cc: Pragnesh Patel ; U-Boot Mailing List >b...@lists.denx.de>; Atish Patra ;
>>palmerdabb...@google.com; Paul Walmsley ( Sifive)
>>; Anup Patel ; Sagar
>>Kadam ; Palmer Dabbelt
>;
>>Jagan Teki ; rick ;
>>Alan Kao 
>>Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
>>
>>[External Email] Do not click links or attachments unless you recognize
>>the sender and know the content is safe
>>
>>Hi Rick,
>>
>>On Wed, Jun 24, 2020 at 2:26 PM Rick Chen  wrote:
>>>
>>> Hi Bin
>>>
>>> > Hi Rick,
>>> >
>>> > On Wed, Jun 24, 2020 at 1:24 PM Pragnesh Patel
>>> >  wrote:
>>> > >
>>> > > Hi Rick,
>>> > >
>>> > > >-Original Message-
>>> > > >From: Rick Chen 
>>> > > >Sent: 24 June 2020 10:44
>>> > > >To: Pragnesh Patel 
>>> > > >Cc: U-Boot Mailing List ; Atish Patra
>>> > > >; palmerdabb...@google.com; Bin Meng
>>> > > >; Paul Walmsley ( Sifive)
>>> > > >; Anup Patel ;
>>> > > >Sagar Kadam ; Palmer Dabbelt
>>> > > >; Jagan Teki ;
>>> > > >rick ; Alan Kao 
>>> > > >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM
>>> > > >driver
>>> > > >
>>> > > >[External Email] Do not click links or attachments unless you
>>> > > >recognize the sender and know the content is safe
>>> > > >
>>> > > >Hi Pragnesh
>>> > > >
>>> > > >> Hi Rick,
>>> > > >>
>>> > > >> >-Original Message-
>>> > > >> >From: Rick Chen 
>>> > > >> >Sent: 24 June 2020 06:30
>>> > > >> >To: Pragnesh Patel 
>>> > > >> >Cc: U-Boot Mailing List ; Atish Patra
>>> > > >> >; palmerdabb...@google.com; Bin Meng
>>> > > >> >; Paul Walmsley ( Sifive)
>>> > > >> >; Anup Patel
>;
>>> > > >> >Sagar Kadam ; Palmer Dabbelt
>>> > > >;
>>> > > >> >Jagan Teki ; rick
>>> > > >> >; Alan Kao 
>>> > > >> >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive
>>> > > >> >PWM driver
>>> > > >> >
>>> > > >> >[External Email] Do not click links or attachments unless you
>>> > > >> >recognize the sender and know the content is safe
>>> > > >> >
>>> > > >> >Hi Pragnesh
>>> > > >> >
>>> > > >> >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
>>> > > >> >> Sent: Friday, May 29, 2020 2:45 PM
>>> > > >> >> To: u-boot@lists.denx.de
>>> > > >> >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com;
>>> > > >> >bmeng...@gmail.com; paul.walms...@sifive.com;
>>> > > >> >anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick Jian-Zhi
>>> > > >> >Chen(陳建志); Pragnesh Patel; Palmer Dabbelt
>>> > > >> >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive
>>> > > >> >> PWM driver
>>> > > >> >>
>>> > > >> >> This patch enables SiFive PWM driver for the SiFive
>>> > > >> >> Unleashed
>>board.
>>> > > >> >>
>>> > > >> >> Signed-off-by: Pragnesh Patel 
>>> > > >> >> ---
>>> > > >> >>  board/sifive/fu540/Kconfig | 2 ++
>>> > > >> >>  1 file changed, 2 insertions(+)
>>> > > >> >>
>>> > > >> >> diff --git a/board/sifive/fu540/Kconfig
>>> > > >> >> b/board/sifive/fu540/Kconfig index
>>> > > >> >86193d7668..683668d059 100644
>>> > > >> >> --- a/board/sifive/fu540/Kconfig
>>> > > >> >> +++ b/board/sifive/fu540/Kconfig
>>> > > >> >> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
>>> > > >> >> imply SMP
>>> > > >> >> imply MISC
>>> > > >> >> imply SIFIVE_OTP
>>> > > >> >> +   imply DM_PWM
>>> > > >> >> +   imply PWM_SIFIVE
>>> > > >> >>
>>> > > >> >
>>> > > >> >This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive.
>>> > > >> >It is weird to introduce here and not appropriate to depend
>>> > > >> >on another
>>> > > >patch.
>>> > > >>
>>> > > >> Do you want me to send this 2 patches separately independent
>>> > > >> of each
>>> > > >other ?
>>> > > >
>>> > > >How about merged [PATCH 2/2] riscv: sifive: fu540: Enable SiFive
>>> > > >PWM driver into [PATCH v2 0/2] Add support for PWM SiFive ?
>>> > >
>>> > > I am okay with it, you can go ahead and merge this patch into PWM
>>series of Yash.
>>> > >
>>> >
>>> > They are separate patches and should keep separate. I am not sure
>>> > what's the issue we want to resolve?
>>>
>>> Nothing about resolve.
>>> Logically if they can be put together, it will be more reasonable.
>>
>>Agree. Thanks for the clarification.
>>
>>That's why I recommend developers submit all related patch sets in a
>>series to help maintainers' work :)
>
>Just to clarify, you are going to merge this patch into [PATCH v2 0/2] Add
>support for PWM SiFive, right ?
>Let me know if I am wrong and you want to resubmit anything from me.
>
>>
>>Regards,
>>Bin


[PATCH] test/py: efi_secboot: remove unused function

2020-07-19 Thread AKASHI Takahiro
'tool_is_in_path' function is no longer used anywhere after Heinrich
has removed 'sudo' version of fixture setup.

Signed-off-by: AKASHI Takahiro 
---
 test/py/tests/test_efi_secboot/conftest.py | 9 -
 1 file changed, 9 deletions(-)

diff --git a/test/py/tests/test_efi_secboot/conftest.py 
b/test/py/tests/test_efi_secboot/conftest.py
index 6c1ea2dcb684..c0943b62501d 100644
--- a/test/py/tests/test_efi_secboot/conftest.py
+++ b/test/py/tests/test_efi_secboot/conftest.py
@@ -8,15 +8,6 @@ from subprocess import call, check_call, check_output, 
CalledProcessError
 import pytest
 from defs import *
 
-# from test/py/conftest.py
-
-
-def tool_is_in_path(tool):
-for path in os.environ["PATH"].split(os.pathsep):
-full_path = os.path.join(path, tool)
-if os.path.isfile(full_path) and os.access(full_path, os.X_OK):
-return True
-return False
 
 #
 # Fixture for UEFI secure boot test
-- 
2.27.0



[PATCH] test/py: efi_secboot: fix additional pylint errors

2020-07-19 Thread AKASHI Takahiro
This is a fixup by autopep8 after the commit ("test/py: efi_secboot:
apply autopep8").

Signed-off-by: AKASHI Takahiro 
---
 test/py/tests/test_efi_secboot/conftest.py | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/test/py/tests/test_efi_secboot/conftest.py 
b/test/py/tests/test_efi_secboot/conftest.py
index c6709700a876..6c1ea2dcb684 100644
--- a/test/py/tests/test_efi_secboot/conftest.py
+++ b/test/py/tests/test_efi_secboot/conftest.py
@@ -87,21 +87,21 @@ def efi_boot_env(request, u_boot_config):
 # db1-update
 check_call('cd %s; %ssign-efi-sig-list -t "2020-04-06" -a -c KEK.crt 
-k KEK.key db db1.esl db1-update.auth'
% (mnt_point, EFITOOLS_PATH), shell=True)
-## dbx (TEST_dbx certificate)
+# dbx (TEST_dbx certificate)
 check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048 -subj 
/CN=TEST_dbx/ -keyout dbx.key -out dbx.crt -nodes -days 365'
% mnt_point, shell=True)
 check_call('cd %s; %scert-to-efi-sig-list -g %s dbx.crt dbx.esl; 
%ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx.esl dbx.auth'
% (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH),
shell=True)
-## dbx_hash (digest of TEST_db certificate)
+# dbx_hash (digest of TEST_db certificate)
 check_call('cd %s; %scert-to-efi-hash-list -g %s -t 0 -s 256 db.crt 
dbx_hash.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx 
dbx_hash.crl dbx_hash.auth'
% (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH),
shell=True)
-## dbx_hash1 (digest of TEST_db1 certificate)
+# dbx_hash1 (digest of TEST_db1 certificate)
 check_call('cd %s; %scert-to-efi-hash-list -g %s -t 0 -s 256 db1.crt 
dbx_hash1.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx 
dbx_hash1.crl dbx_hash1.auth'
% (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH),
shell=True)
-## dbx_db (with TEST_db certificate)
+# dbx_db (with TEST_db certificate)
 check_call('cd %s; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k 
KEK.key dbx db.esl dbx_db.auth'
% (mnt_point, EFITOOLS_PATH),
shell=True)
@@ -112,10 +112,10 @@ def efi_boot_env(request, u_boot_config):
 # Sign image
 check_call('cd %s; sbsign --key db.key --cert db.crt helloworld.efi'
% mnt_point, shell=True)
-## Sign already-signed image with another key
+# Sign already-signed image with another key
 check_call('cd %s; sbsign --key db1.key --cert db1.crt --output 
helloworld.efi.signed_2sigs helloworld.efi.signed'
% mnt_point, shell=True)
-## Digest image
+# Digest image
 check_call('cd %s; %shash-to-efi-sig-list helloworld.efi 
db_hello.hash; %ssign-efi-sig-list -t "2020-04-07" -c KEK.crt -k KEK.key db 
db_hello.hash db_hello.auth'
% (mnt_point, EFITOOLS_PATH, EFITOOLS_PATH),
shell=True)
@@ -126,7 +126,8 @@ def efi_boot_env(request, u_boot_config):
% (mnt_point, EFITOOLS_PATH),
shell=True)
 
-check_call('virt-make-fs --partition=gpt --size=+1M --type=vfat {} 
{}'.format(mnt_point, image_path), shell=True)
+check_call('virt-make-fs --partition=gpt --size=+1M --type=vfat {} 
{}'.format(
+mnt_point, image_path), shell=True)
 check_call('rm -rf {}'.format(mnt_point), shell=True)
 
 except CalledProcessError as exception:
-- 
2.27.0



Re: [PATCH v4 7/7] test/py: efi_secboot: add test for intermediate certificates

2020-07-19 Thread Heinrich Schuchardt
On 7/20/20 7:52 AM, AKASHI Takahiro wrote:
> Heinrich,
>
> On Fri, Jul 17, 2020 at 12:29:06PM +0200, Heinrich Schuchardt wrote:
>> On 17.07.20 09:16, AKASHI Takahiro wrote:
>>> In this test case, an image may have a signature with additional
>>> intermediate certificates. A chain of trust will be followed and all
>>> the certificates in the middle of chain must be verified before loading.
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>
>> Thanks for providing all these tests and for rebasing on 53ce9a6ed98b6
>> ("test: use virt-make-fs to build image").
>
> You should have run autopep8 before your patch:)
>
>> Essentially this patch could have been split into two:
>>
>> * style corrections for existing code
>> * new tests
>
> Will split this patch into several commits.
>
>> Unfortunatly the setup not working correctly. 'make tests' shows:
>>
>> test/py/tests/test_efi_secboot/test_authvar.py F
>> test/py/tests/test_efi_secboot/test_signed.py .F..FF
>> test/py/tests/test_efi_secboot/test_signed_intca.py sss
>> test/py/tests/test_efi_secboot/test_unsigned.py ...
>
> As long as I run the tests in my local environment,
> I've never seen any failures.

Was that after rebasing on efi-2020-10?

>
>> SKIPPED [3] test/py/tests/test_efi_secboot/conftest.py:254: Setup
>> failed: cd build-sandbox/mnt_efisecure; sbsign --key TestCert.key --cert
>> TestCert.crt --addcert TestSub.crt --out helloworld.efi.signed_ab
>> helloworld.efi
>
> Please read the cover letter:
> ===8<===
> Prerequisite
> 
> All the required patches have been merged.
> You can fetch the whole workable repository from here[1].
>
> One patch[2] to sbsigntools must also be applied so that we wil be able
> to sign an image with intermediate certificates. It is required here for
> testing.
>
> (snip)
>
> Test
> 
> - The added new pytest (test_signed_intca.py) passed locally.
> - Travis CI passed, except the new pytest added here due to a new
>   feature in sbsigntools as mentioned above.
> (the latest vesion is still running though.)
> ===>8===

Travis CI skips the tests currently:

test/py/tests/test_efi_secboot/test_authvar.py s
test/py/tests/test_efi_secboot/test_signed.py ss
test/py/tests/test_efi_secboot/test_unsigned.py sss

Tom did not apply
https://patchwork.ozlabs.org/project/uboot/patch/20200714061856.4487-1-xypron.g...@gmx.de/
.

You would have to exchange the Dockerfile at the top of .

>
> I guess that you are not using the latest source of sbsigntools.

I am using Debian sbsigntool version: 0.9.2-2.

If you want to use any patched version of sbsigntool for testing, you
will have to proved the necessary patch for the Dockerfile in
https://gitlab.denx.de/u-boot/gitlab-ci-runner.git

and you will have to build the same sbsigntool for Travis.

>
>
>> If you replace as follows in test/run you get the extra skip messages:
>>
>> %s/--bd/-ra --bd/g
>>
>>> ---
>>>  test/py/tests/test_efi_secboot/conftest.py| 134 -
>>>  test/py/tests/test_efi_secboot/defs.py|   8 +-
>>>  test/py/tests/test_efi_secboot/openssl.cnf|  48 +++
>>>  .../test_efi_secboot/test_signed_intca.py | 135 ++
>>>  4 files changed, 317 insertions(+), 8 deletions(-)
>>>  create mode 100644 test/py/tests/test_efi_secboot/openssl.cnf
>>>  create mode 100644 test/py/tests/test_efi_secboot/test_signed_intca.py
>>>
>>> diff --git a/test/py/tests/test_efi_secboot/conftest.py 
>>> b/test/py/tests/test_efi_secboot/conftest.py
>>> index c6709700a876..20d0cbf3ab01 100644
>>> --- a/test/py/tests/test_efi_secboot/conftest.py
>>> +++ b/test/py/tests/test_efi_secboot/conftest.py
>>> @@ -37,7 +37,7 @@ def efi_boot_env(request, u_boot_config):
>>>  global HELLO_PATH
>>>
>>>  image_path = u_boot_config.persistent_data_dir
>>> -image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME
>>> +image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME + '.img'
>>
>> I would prefer a separate constant for
>> EFI_SECBOOT_IMAGE_NAME + '_intca.img'
>> to ensure that conftest.py and test_signed_intca.py use the same value.
>
> 'separate constant to use the same value?' I don't get your point.
>
> Anyhow, *.py files don't use a image file name directly, but
> get it from a test fixture.
> So I don't think that we need any change here.

It does not make sense to me to define a constant for half of the file
name and still relying on the rest to match between the different Python
tests. Please, provide constants for the whole file names.

>
>>>
>>>  if HELLO_PATH == '':
>>
>> Shouldn't we set HELLO_PATH = 'lib/efi_loader/helloworld.efi' in defs.py
>> and use another variable name here?
>
> An explicit path is a remnant int the past when helloworld was not
> compiled properly.
> So I will delete all the stuff including the code below.
>
>> bin_path = u_boot_config.build_dir + '/' + HELLO_PATH
>>
>>>  HELLO_PATH = u_boot_config.build_dir + 
>>> '/lib/efi_loader/helloworld.efi'
>>
>> Capitalization should only be used

Re: [PATCH v2 1/1] Dockerfile: provide kernel for libguestfs-tools

2020-07-19 Thread Heinrich Schuchardt
On 7/15/20 12:10 AM, Tom Rini wrote:
> On Wed, Jul 15, 2020 at 12:00:25AM +0200, Heinrich Schuchardt wrote:
>> Am 14. Juli 2020 23:28:21 MESZ schrieb Tom Rini :
>>> On Tue, Jul 14, 2020 at 08:18:56AM +0200, Heinrich Schuchardt wrote:
>>>
 The libguestfs-tools use QEMU to mount an image file. This requires a
>>> Linux
 kernel.

 On Ubuntu the kernel (/boot/vmlinuz*) is not readable for normal
>>> users
 (chmod 600), cf.
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725

 Install a kernel and make it readable for all users (chmod 644).

 Signed-off-by: Heinrich Schuchardt 
>>>
>>> This causes the tests to fail now that they're trying to use
>>> libguestfs-tools:
>>> https://gitlab.denx.de/u-boot/u-boot/-/jobs/124872
>>>
>>> I did a quick change to pass in the KVM group to useradd as well, but
>>> that didn't catch.  I suspect that changing /dev/kvm inside the
>>> container won't stick either.  But that shouldn't be fatal as it's
>>> still
>>> fast enough.
>>
>> KVM requires docker --privileged according to what I read.
>>
>> Tests failing that were not excercised before seems to be a step into the 
>> right direction. - But a lot of work before us.
>
> It's not progress as they do pass when I apply the patch I posted the
> other day to fix sudo'ing the tests.  And we may need to have an

Which patch do you relate to?

> off-list chat to make sure everyone with a runner is configured
> consistently.
>

You marked this patch as "changes requested". It is unclear to me what
change you are requesting for this patch.

Best regards

Heinrich


Re: [PATCH v4] riscv: Make SiFive HiFive Unleashed board boot again

2020-07-19 Thread Bin Meng
Hi Rick,

On Mon, Jul 20, 2020 at 2:18 PM Bin Meng  wrote:
>
> From: Bin Meng 
>
> Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
> caused U-Boot failed to boot on SiFive HiFive Unleashed board.
>
> The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
> before the call to riscv_init_ipi(). At that time the timer register
> base (e.g.: the SiFive CLINT device in this case) is unknown yet.
>
> It might be the name riscv_init_ipi() that misleads people to only
> consider it is related to IPI, but in fact the timer capability is
> provided by the same SiFive CLINT device that provides the IPI.
> Timer capability is needed for both UP and SMP.
>
> Considering that the original refactor does have benefits, that it
> makes the IPI code more similar to U-Boot initialization idioms.
> It also removes some quite ugly macros. Let's do the minimal revert
> instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
> consider the SPL case.
>
> Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
> Signed-off-by: Bin Meng 
> Reviewed-by: Sean Anderson 
> ---
>
> Changes in v4:
> - Include Sean's "Reviewed-by" tag
>
> Changes in v3:
> - Simply call riscv_init_ipi() in clint timer functions to avoid
>   some duplications
>
> Changes in v2:
> - Do the minimal partial revert instead of a complete revert, enough
>   to make HiFive Unleashed board boot again.
>
>  arch/riscv/cpu/cpu.c  |  2 +-
>  arch/riscv/lib/sifive_clint.c | 16 
>  common/spl/spl_opensbi.c  |  5 -
>  3 files changed, 13 insertions(+), 10 deletions(-)
>

Since currently FU540 is broken, could you please adjust the patch
order to make this patch show up at the very beginning of the
u-boot-riscv/master tree?

Regards,
Bin


[PATCH v4] riscv: Make SiFive HiFive Unleashed board boot again

2020-07-19 Thread Bin Meng
From: Bin Meng 

Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
caused U-Boot failed to boot on SiFive HiFive Unleashed board.

The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
before the call to riscv_init_ipi(). At that time the timer register
base (e.g.: the SiFive CLINT device in this case) is unknown yet.

It might be the name riscv_init_ipi() that misleads people to only
consider it is related to IPI, but in fact the timer capability is
provided by the same SiFive CLINT device that provides the IPI.
Timer capability is needed for both UP and SMP.

Considering that the original refactor does have benefits, that it
makes the IPI code more similar to U-Boot initialization idioms.
It also removes some quite ugly macros. Let's do the minimal revert
instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
consider the SPL case.

Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
Signed-off-by: Bin Meng 
Reviewed-by: Sean Anderson 
---

Changes in v4:
- Include Sean's "Reviewed-by" tag

Changes in v3:
- Simply call riscv_init_ipi() in clint timer functions to avoid
  some duplications

Changes in v2:
- Do the minimal partial revert instead of a complete revert, enough
  to make HiFive Unleashed board boot again.

 arch/riscv/cpu/cpu.c  |  2 +-
 arch/riscv/lib/sifive_clint.c | 16 
 common/spl/spl_opensbi.c  |  5 -
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index bbd6c15..bfa2d4a 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -107,7 +107,7 @@ int arch_cpu_init_dm(void)
 #endif
}
 
-#ifdef CONFIG_SMP
+#if CONFIG_IS_ENABLED(SMP)
ret = riscv_init_ipi();
if (ret)
return ret;
diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index 78fc6c8..b9a2c64 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int riscv_get_time(u64 *time)
 {
+   /* ensure timer register base has a sane value */
+   riscv_init_ipi();
+
*time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
 
return 0;
@@ -33,6 +36,9 @@ int riscv_get_time(u64 *time)
 
 int riscv_set_timecmp(int hart, u64 cmp)
 {
+   /* ensure timer register base has a sane value */
+   riscv_init_ipi();
+
writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint, hart));
 
return 0;
@@ -40,11 +46,13 @@ int riscv_set_timecmp(int hart, u64 cmp)
 
 int riscv_init_ipi(void)
 {
-   long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
+   if (!gd->arch.clint) {
+   long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
 
-   if (IS_ERR(ret))
-   return PTR_ERR(ret);
-   gd->arch.clint = ret;
+   if (IS_ERR(ret))
+   return PTR_ERR(ret);
+   gd->arch.clint = ret;
+   }
 
return 0;
 }
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index 3440bc0..14f335f 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -79,11 +79,6 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
invalidate_icache_all();
 
 #ifdef CONFIG_SPL_SMP
-   /* Initialize the IPI before we use it */
-   ret = riscv_init_ipi();
-   if (ret)
-   hang();
-
/*
 * Start OpenSBI on all secondary harts and wait for acknowledgment.
 *
-- 
2.7.4



Re: [PATCH v3] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

2020-07-19 Thread Rick Chen
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Monday, July 20, 2020 11:52 AM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Tom Rini; Bin Meng
> Subject: [PATCH v3] azure: gitlab: travis: Update OpenSBI used for RISC-V 
> testing
>
> From: Bin Meng 
>
> Change to use OpenSBI release v0.8 generic platform images for QEMU RISC-V CI 
> testing for azure, gitlab and travis-ci.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v3:
> - rebase on u-boot/master again
>
> Changes in v2:
> - rebase on u-boot/master
>
>  .azure-pipelines.yml | 8 
>  .gitlab-ci.yml   | 8 
>  .travis.yml  | 8 
>  3 files changed, 12 insertions(+), 12 deletions(-)
>

Applied to u-boot-riscv/master!

Thanks,
Rick


Re: [PATCH v4 6/7] efi_loader: signature: rework for intermediate certificates support

2020-07-19 Thread AKASHI Takahiro
Heinrich,

On Fri, Jul 17, 2020 at 12:23:08PM +0200, Heinrich Schuchardt wrote:
> On 17.07.20 09:16, AKASHI Takahiro wrote:
> > In this commit, efi_signature_verify(with_sigdb) will be re-implemented
> > using pcks7_verify_one() in order to support certificates chain, where
> > the signer's certificate will be signed by an intermediate CA (certificate
> > authority) and the latter's certificate will also be signed by another CA
> > and so on.
> >
> > What we need to do here is to search for certificates in a signature,
> > build up a chain of certificates and verify one by one. pkcs7_verify_one()
> > handles most of these steps except the last one.
> >
> > pkcs7_verify_one() returns, if succeeded, the last certificate to verify,
> > which can be either a self-signed one or one that should be signed by one
> > of certificates in "db". Re-worked efi_signature_verify() will take care
> > of this step.
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> 
> With patches 1-6 applied to origin/master (fee68b98fe3890):
> make tests:
> 
> test/py/tests/test_efi_secboot/test_authvar.py F
> test/py/tests/test_efi_secboot/test_signed.py .F..FF
> test/py/tests/test_efi_secboot/test_unsigned.py ...

Even after rebasing the code to fee68b98fe3890,
I have never seen any failures in those cases.
(I use pytest directly instead of 'make tests' though.)

-Takahiro Akashi

> Patches 1-5 pass the test.
> 
> Best regards
> 
> Heinrich


Re: [PATCH v3] riscv: Make SiFive HiFive Unleashed board boot again

2020-07-19 Thread Bin Meng
On Mon, Jul 20, 2020 at 1:06 PM Sean Anderson  wrote:
>
> On 7/20/20 12:33 AM, Bin Meng wrote:
> > From: Bin Meng 
> >
> > Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
> > caused U-Boot failed to boot on SiFive HiFive Unleashed board.
> >
> > The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
> > before the call to riscv_init_ipi(). At that time the timer register
> > base (e.g.: the SiFive CLINT device in this case) is unknown yet.
> >
> > It might be the name riscv_init_ipi() that misleads people to only
> > consider it is related to IPI, but in fact the timer capability is
> > provided by the same SiFive CLINT device that provides the IPI.
> > Timer capability is needed for both UP and SMP.
> >
> > Considering that the original refactor does have benefits, that it
> > makes the IPI code more similar to U-boot initialization idioms.
> > It also removes some quite ugly macros. Let's do the minimal revert
> > instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
> > consider the SPL case.
> >
> > Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
> > Signed-off-by: Bin Meng 
> > ---
> >
> > Changes in v3:
> > - Simply call riscv_init_ipi() in clint timer functions to avoid
> >   some duplications
> >
> > Changes in v2:
> > - Do the minimal partial revert instead of a complete revert, enough
> >   to make HiFive Unleashed board boot again.
> >
> >  arch/riscv/cpu/cpu.c  |  2 +-
> >  arch/riscv/lib/sifive_clint.c | 16 
> >  common/spl/spl_opensbi.c  |  5 -
> >  3 files changed, 13 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > index bbd6c15..bfa2d4a 100644
> > --- a/arch/riscv/cpu/cpu.c
> > +++ b/arch/riscv/cpu/cpu.c
> > @@ -107,7 +107,7 @@ int arch_cpu_init_dm(void)
> >  #endif
> >   }
> >
> > -#ifdef CONFIG_SMP
> > +#if CONFIG_IS_ENABLED(SMP)
> >   ret = riscv_init_ipi();
> >   if (ret)
> >   return ret;
> > diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
> > index 78fc6c8..b9a2c64 100644
> > --- a/arch/riscv/lib/sifive_clint.c
> > +++ b/arch/riscv/lib/sifive_clint.c
> > @@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> >  int riscv_get_time(u64 *time)
> >  {
> > + /* ensure timer register base has a sane value */
> > + riscv_init_ipi();
> > +
> >   *time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
> >
> >   return 0;
> > @@ -33,6 +36,9 @@ int riscv_get_time(u64 *time)
> >
> >  int riscv_set_timecmp(int hart, u64 cmp)
> >  {
> > + /* ensure timer register base has a sane value */
> > + riscv_init_ipi();
> > +
> >   writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint, hart));
> >
> >   return 0;
> > @@ -40,11 +46,13 @@ int riscv_set_timecmp(int hart, u64 cmp)
> >
> >  int riscv_init_ipi(void)
> >  {
> > - long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
> > + if (!gd->arch.clint) {
> > + long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
> >
> > - if (IS_ERR(ret))
> > - return PTR_ERR(ret);
> > - gd->arch.clint = ret;
> > + if (IS_ERR(ret))
> > + return PTR_ERR(ret);
> > + gd->arch.clint = ret;
> > + }
> >
> >   return 0;
> >  }
> > diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
> > index 3440bc0..14f335f 100644
> > --- a/common/spl/spl_opensbi.c
> > +++ b/common/spl/spl_opensbi.c
> > @@ -79,11 +79,6 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
> >   invalidate_icache_all();
> >
> >  #ifdef CONFIG_SPL_SMP
> > - /* Initialize the IPI before we use it */
> > - ret = riscv_init_ipi();
> > - if (ret)
> > - hang();
> > -
> >   /*
> >* Start OpenSBI on all secondary harts and wait for acknowledgment.
> >*
> >
>
> Reviwed-by: Sean Anderson 

There is a typo in the tag. I will include the correct tag in v4.

Regards,
Bin


Re: [PATCH 02/31] mtd: spi-nor: Tidy up error handling / debug code

2020-07-19 Thread Vignesh Raghavendra
Hi Simon,

On 19/07/20 9:45 pm, Simon Glass wrote:
> The -ENODEV error value in spi_nor_read_id() is incorrect since there
> clearly is a device - it just cannot be supported. 

Description 's not entirely accurate... If there is no flash on the SPI
bus, then read ID would return all 0s or 0xFFs depending on the pullups
on the board which would fail to match any flash in the spi-nor-ids table.

So its not just the case of device IDs not recognized or supported by
U-Boot, it maybe that flash is absent altogether.

Regards
Vignesh

> Use -ENOMEDIUM instead
> which has the virtue of being less common.
> 
> Fix the return value in spi_nor_scan().
> 
> Also there are a few printf() statements which should be debug() since
> they bloat the code with unused strings at present. Fix those while here.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/mtd/spi/sf_probe.c | 2 +-
>  drivers/mtd/spi/spi-nor-core.c | 2 +-
>  drivers/mtd/spi/spi-nor-tiny.c | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index 475f6c31db..b959e3453a 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -119,7 +119,7 @@ static int spi_flash_std_erase(struct udevice *dev, u32 
> offset, size_t len)
>   struct erase_info instr;
>  
>   if (offset % mtd->erasesize || len % mtd->erasesize) {
> - printf("SF: Erase offset/length not multiple of erase size\n");
> + debug("SF: Erase offset/length not multiple of erase size\n");
>   return -EINVAL;
>   }
>  
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index fdcd830ce4..0113e70037 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -2470,7 +2470,7 @@ static int spi_nor_init(struct spi_nor *nor)
>* designer) that this is bad.
>*/
>   if (nor->flags & SNOR_F_BROKEN_RESET)
> - printf("enabling reset hack; may not recover from 
> unexpected reboots\n");
> + debug("enabling reset hack; may not recover from 
> unexpected reboots\n");
>   set_4byte(nor, nor->info, 1);
>   }
>  
> diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c
> index 9f676c649d..fa26ea33c8 100644
> --- a/drivers/mtd/spi/spi-nor-tiny.c
> +++ b/drivers/mtd/spi/spi-nor-tiny.c
> @@ -377,7 +377,7 @@ static const struct flash_info *spi_nor_read_id(struct 
> spi_nor *nor)
>   }
>   dev_dbg(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
>   id[0], id[1], id[2]);
> - return ERR_PTR(-ENODEV);
> + return ERR_PTR(-EMEDIUMTYPE);
>  }
>  
>  static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
> @@ -733,7 +733,7 @@ int spi_nor_scan(struct spi_nor *nor)
>  
>   info = spi_nor_read_id(nor);
>   if (IS_ERR_OR_NULL(info))
> - return -ENOENT;
> + return PTR_ERR(info);
>   /* Parse the Serial Flash Discoverable Parameters table. */
>   ret = spi_nor_init_params(nor, info, ¶ms);
>   if (ret)
> 


[PATCH v2 1/2] riscv: dts: hifive-unleashed-a00: Make memory node available to SPL

2020-07-19 Thread Bin Meng
From: Bin Meng 

Make memory node available to SPL in prepration to updates to SiFive
DDR RAM driver to read memory information from DT.

Signed-off-by: Bin Meng 
---

Changes in v2:
- rebase on top of u-boot-riscv/master

 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index 7d838bf..5d0c928 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -20,6 +20,10 @@
u-boot,spl-payload-offset = <0x105000>; /* loader2 @1044KB */
};
 
+   memory@8000 {
+   u-boot,dm-spl;
+   };
+
hfclk {
u-boot,dm-spl;
};
-- 
2.7.4



[PATCH v2 2/2] ram: sifive: Avoid using hardcoded ram base and size

2020-07-19 Thread Bin Meng
From: Bin Meng 

At present the SiFive FU540 RAM driver uses hard-coded memory base
address and size to initialize the DDR controller. This may not be
true when this driver is used on another board based on FU540.

Update the driver to read the memory information from DT and use
that during the initialization.

Signed-off-by: Bin Meng 
---

Changes in v2:
- Change to use fdtdec_setup_mem_size_base() API
- Drop the 2 patches that added a new API in fdtdec

 drivers/ram/sifive/fu540_ddr.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/ram/sifive/fu540_ddr.c b/drivers/ram/sifive/fu540_ddr.c
index f8f8ca9..2eef1e7 100644
--- a/drivers/ram/sifive/fu540_ddr.c
+++ b/drivers/ram/sifive/fu540_ddr.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,9 +40,6 @@
 #define DENALI_PHY_11521152
 #define DENALI_PHY_12141214
 
-#define PAYLOAD_DEST   0x8000
-#define DDR_MEM_SIZE   (8UL * 1024UL * 1024UL * 1024UL)
-
 #define DRAM_CLASS_OFFSET  8
 #define DRAM_CLASS_DDR40xA
 #define OPTIMAL_RMODW_EN_OFFSET0
@@ -65,6 +63,8 @@
 #define PHY_RX_CAL_DQ0_0_OFFSET0
 #define PHY_RX_CAL_DQ1_0_OFFSET16
 
+DECLARE_GLOBAL_DATA_PTR;
+
 struct fu540_ddrctl {
volatile u32 denali_ctl[265];
 };
@@ -235,8 +235,8 @@ static int fu540_ddr_setup(struct udevice *dev)
struct fu540_ddr_params *params = &plat->ddr_params;
volatile u32 *denali_ctl =  priv->ctl->denali_ctl;
volatile u32 *denali_phy =  priv->phy->denali_phy;
-   const u64 ddr_size = DDR_MEM_SIZE;
-   const u64 ddr_end = PAYLOAD_DEST + ddr_size;
+   const u64 ddr_size = priv->info.size;
+   const u64 ddr_end = priv->info.base + ddr_size;
int ret, i;
u32 physet;
 
@@ -302,7 +302,7 @@ static int fu540_ddr_setup(struct udevice *dev)
 | (1 << MULTIPLE_OUT_OF_RANGE_OFFSET));
 
/* set up range protection */
-   fu540_ddr_setup_range_protection(denali_ctl, DDR_MEM_SIZE);
+   fu540_ddr_setup_range_protection(denali_ctl, priv->info.size);
 
/* Mask off port command error interrupt DENALI_CTL_136 */
setbits_le32(DENALI_CTL_136 + denali_ctl,
@@ -314,14 +314,14 @@ static int fu540_ddr_setup(struct udevice *dev)
 
/* check size */
priv->info.size = get_ram_size((long *)priv->info.base,
-  DDR_MEM_SIZE);
+  ddr_size);
 
debug("%s : %lx\n", __func__, priv->info.size);
 
/* check memory access for all memory */
-   if (priv->info.size != DDR_MEM_SIZE) {
+   if (priv->info.size != ddr_size) {
printf("DDR invalid size : 0x%lx, expected 0x%lx\n",
-  priv->info.size, DDR_MEM_SIZE);
+  priv->info.size, (uintptr_t)ddr_size);
return -EINVAL;
}
 
@@ -333,6 +333,11 @@ static int fu540_ddr_probe(struct udevice *dev)
 {
struct fu540_ddr_info *priv = dev_get_priv(dev);
 
+   /* Read memory base and size from DT */
+   fdtdec_setup_mem_size_base();
+   priv->info.base = gd->ram_base;
+   priv->info.size = gd->ram_size;
+
 #if defined(CONFIG_SPL_BUILD)
struct regmap *map;
int ret;
@@ -368,14 +373,9 @@ static int fu540_ddr_probe(struct udevice *dev)
priv->phy = regmap_get_range(map, 1);
priv->physical_filter_ctrl = regmap_get_range(map, 2);
 
-   priv->info.base = CONFIG_SYS_SDRAM_BASE;
-
-   priv->info.size = 0;
return fu540_ddr_setup(dev);
-#else
-   priv->info.base = CONFIG_SYS_SDRAM_BASE;
-   priv->info.size = DDR_MEM_SIZE;
 #endif
+
return 0;
 }
 
-- 
2.7.4



Re: [PATCH v4 7/7] test/py: efi_secboot: add test for intermediate certificates

2020-07-19 Thread AKASHI Takahiro
Heinrich,

On Fri, Jul 17, 2020 at 12:29:06PM +0200, Heinrich Schuchardt wrote:
> On 17.07.20 09:16, AKASHI Takahiro wrote:
> > In this test case, an image may have a signature with additional
> > intermediate certificates. A chain of trust will be followed and all
> > the certificates in the middle of chain must be verified before loading.
> >
> > Signed-off-by: AKASHI Takahiro 
> 
> Thanks for providing all these tests and for rebasing on 53ce9a6ed98b6
> ("test: use virt-make-fs to build image").

You should have run autopep8 before your patch:)

> Essentially this patch could have been split into two:
> 
> * style corrections for existing code
> * new tests

Will split this patch into several commits.

> Unfortunatly the setup not working correctly. 'make tests' shows:
> 
> test/py/tests/test_efi_secboot/test_authvar.py F
> test/py/tests/test_efi_secboot/test_signed.py .F..FF
> test/py/tests/test_efi_secboot/test_signed_intca.py sss
> test/py/tests/test_efi_secboot/test_unsigned.py ...

As long as I run the tests in my local environment,
I've never seen any failures.

> SKIPPED [3] test/py/tests/test_efi_secboot/conftest.py:254: Setup
> failed: cd build-sandbox/mnt_efisecure; sbsign --key TestCert.key --cert
> TestCert.crt --addcert TestSub.crt --out helloworld.efi.signed_ab
> helloworld.efi

Please read the cover letter:
===8<===
Prerequisite

All the required patches have been merged.
You can fetch the whole workable repository from here[1].

One patch[2] to sbsigntools must also be applied so that we wil be able
to sign an image with intermediate certificates. It is required here for
testing.

(snip)

Test

- The added new pytest (test_signed_intca.py) passed locally.
- Travis CI passed, except the new pytest added here due to a new
  feature in sbsigntools as mentioned above.
(the latest vesion is still running though.)
===>8===

I guess that you are not using the latest source of sbsigntools.


> If you replace as follows in test/run you get the extra skip messages:
> 
> %s/--bd/-ra --bd/g
> 
> > ---
> >  test/py/tests/test_efi_secboot/conftest.py| 134 -
> >  test/py/tests/test_efi_secboot/defs.py|   8 +-
> >  test/py/tests/test_efi_secboot/openssl.cnf|  48 +++
> >  .../test_efi_secboot/test_signed_intca.py | 135 ++
> >  4 files changed, 317 insertions(+), 8 deletions(-)
> >  create mode 100644 test/py/tests/test_efi_secboot/openssl.cnf
> >  create mode 100644 test/py/tests/test_efi_secboot/test_signed_intca.py
> >
> > diff --git a/test/py/tests/test_efi_secboot/conftest.py 
> > b/test/py/tests/test_efi_secboot/conftest.py
> > index c6709700a876..20d0cbf3ab01 100644
> > --- a/test/py/tests/test_efi_secboot/conftest.py
> > +++ b/test/py/tests/test_efi_secboot/conftest.py
> > @@ -37,7 +37,7 @@ def efi_boot_env(request, u_boot_config):
> >  global HELLO_PATH
> >
> >  image_path = u_boot_config.persistent_data_dir
> > -image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME
> > +image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME + '.img'
> 
> I would prefer a separate constant for
> EFI_SECBOOT_IMAGE_NAME + '_intca.img'
> to ensure that conftest.py and test_signed_intca.py use the same value.

'separate constant to use the same value?' I don't get your point.

Anyhow, *.py files don't use a image file name directly, but
get it from a test fixture.
So I don't think that we need any change here.

> >
> >  if HELLO_PATH == '':
> 
> Shouldn't we set HELLO_PATH = 'lib/efi_loader/helloworld.efi' in defs.py
> and use another variable name here?

An explicit path is a remnant int the past when helloworld was not
compiled properly.
So I will delete all the stuff including the code below.

> bin_path = u_boot_config.build_dir + '/' + HELLO_PATH
> 
> >  HELLO_PATH = u_boot_config.build_dir + 
> > '/lib/efi_loader/helloworld.efi'
> 
> Capitalization should only be used for constants.
> 
> Best regards
> 
> Heinrich
> 
> > @@ -87,21 +87,21 @@ def efi_boot_env(request, u_boot_config):
> >  # db1-update
> >  check_call('cd %s; %ssign-efi-sig-list -t "2020-04-06" -a -c 
> > KEK.crt -k KEK.key db db1.esl db1-update.auth'
> > % (mnt_point, EFITOOLS_PATH), shell=True)
> > -## dbx (TEST_dbx certificate)
> > +# dbx (TEST_dbx certificate)
> >  check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048 
> > -subj /CN=TEST_dbx/ -keyout dbx.key -out dbx.crt -nodes -days 365'
> > % mnt_point, shell=True)
> >  check_call('cd %s; %scert-to-efi-sig-list -g %s dbx.crt dbx.esl; 
> > %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx.esl 
> > dbx.auth'
> > % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH),
> > shell=True)
> > -## dbx_hash (digest of TEST_db certificate)
> > +# dbx_hash (digest of TEST_db certificate)
> >  check_call('cd %s; %scert-to-efi-has

Re: [PATCH v3] riscv: Make SiFive HiFive Unleashed board boot again

2020-07-19 Thread Sean Anderson
On 7/20/20 12:33 AM, Bin Meng wrote:
> From: Bin Meng 
> 
> Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
> caused U-Boot failed to boot on SiFive HiFive Unleashed board.
> 
> The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
> before the call to riscv_init_ipi(). At that time the timer register
> base (e.g.: the SiFive CLINT device in this case) is unknown yet.
> 
> It might be the name riscv_init_ipi() that misleads people to only
> consider it is related to IPI, but in fact the timer capability is
> provided by the same SiFive CLINT device that provides the IPI.
> Timer capability is needed for both UP and SMP.
> 
> Considering that the original refactor does have benefits, that it
> makes the IPI code more similar to U-boot initialization idioms.
> It also removes some quite ugly macros. Let's do the minimal revert
> instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
> consider the SPL case.
> 
> Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
> Signed-off-by: Bin Meng 
> ---
> 
> Changes in v3:
> - Simply call riscv_init_ipi() in clint timer functions to avoid
>   some duplications
> 
> Changes in v2:
> - Do the minimal partial revert instead of a complete revert, enough
>   to make HiFive Unleashed board boot again.
> 
>  arch/riscv/cpu/cpu.c  |  2 +-
>  arch/riscv/lib/sifive_clint.c | 16 
>  common/spl/spl_opensbi.c  |  5 -
>  3 files changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index bbd6c15..bfa2d4a 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -107,7 +107,7 @@ int arch_cpu_init_dm(void)
>  #endif
>   }
>  
> -#ifdef CONFIG_SMP
> +#if CONFIG_IS_ENABLED(SMP)
>   ret = riscv_init_ipi();
>   if (ret)
>   return ret;
> diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
> index 78fc6c8..b9a2c64 100644
> --- a/arch/riscv/lib/sifive_clint.c
> +++ b/arch/riscv/lib/sifive_clint.c
> @@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  int riscv_get_time(u64 *time)
>  {
> + /* ensure timer register base has a sane value */
> + riscv_init_ipi();
> +
>   *time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
>  
>   return 0;
> @@ -33,6 +36,9 @@ int riscv_get_time(u64 *time)
>  
>  int riscv_set_timecmp(int hart, u64 cmp)
>  {
> + /* ensure timer register base has a sane value */
> + riscv_init_ipi();
> +
>   writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint, hart));
>  
>   return 0;
> @@ -40,11 +46,13 @@ int riscv_set_timecmp(int hart, u64 cmp)
>  
>  int riscv_init_ipi(void)
>  {
> - long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
> + if (!gd->arch.clint) {
> + long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
>  
> - if (IS_ERR(ret))
> - return PTR_ERR(ret);
> - gd->arch.clint = ret;
> + if (IS_ERR(ret))
> + return PTR_ERR(ret);
> + gd->arch.clint = ret;
> + }
>  
>   return 0;
>  }
> diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
> index 3440bc0..14f335f 100644
> --- a/common/spl/spl_opensbi.c
> +++ b/common/spl/spl_opensbi.c
> @@ -79,11 +79,6 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
>   invalidate_icache_all();
>  
>  #ifdef CONFIG_SPL_SMP
> - /* Initialize the IPI before we use it */
> - ret = riscv_init_ipi();
> - if (ret)
> - hang();
> -
>   /*
>* Start OpenSBI on all secondary harts and wait for acknowledgment.
>*
> 

Reviwed-by: Sean Anderson 


[RESEND PATCH v3] riscv: Make SiFive HiFive Unleashed board boot again

2020-07-19 Thread Bin Meng
From: Bin Meng 

Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
caused U-Boot failed to boot on SiFive HiFive Unleashed board.

The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
before the call to riscv_init_ipi(). At that time the timer register
base (e.g.: the SiFive CLINT device in this case) is unknown yet.

It might be the name riscv_init_ipi() that misleads people to only
consider it is related to IPI, but in fact the timer capability is
provided by the same SiFive CLINT device that provides the IPI.
Timer capability is needed for both UP and SMP.

Considering that the original refactor does have benefits, that it
makes the IPI code more similar to U-Boot initialization idioms.
It also removes some quite ugly macros. Let's do the minimal revert
instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
consider the SPL case.

Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
Signed-off-by: Bin Meng 
---

Changes in v3 RESEND:
- Correct the "U-boot" typo (should be U-Boot)

Changes in v3:
- Simply call riscv_init_ipi() in clint timer functions to avoid
  some duplications

Changes in v2:
- Do the minimal partial revert instead of a complete revert, enough
  to make HiFive Unleashed board boot again.

 arch/riscv/cpu/cpu.c  |  2 +-
 arch/riscv/lib/sifive_clint.c | 16 
 common/spl/spl_opensbi.c  |  5 -
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index bbd6c15..bfa2d4a 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -107,7 +107,7 @@ int arch_cpu_init_dm(void)
 #endif
}
 
-#ifdef CONFIG_SMP
+#if CONFIG_IS_ENABLED(SMP)
ret = riscv_init_ipi();
if (ret)
return ret;
diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index 78fc6c8..b9a2c64 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int riscv_get_time(u64 *time)
 {
+   /* ensure timer register base has a sane value */
+   riscv_init_ipi();
+
*time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
 
return 0;
@@ -33,6 +36,9 @@ int riscv_get_time(u64 *time)
 
 int riscv_set_timecmp(int hart, u64 cmp)
 {
+   /* ensure timer register base has a sane value */
+   riscv_init_ipi();
+
writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint, hart));
 
return 0;
@@ -40,11 +46,13 @@ int riscv_set_timecmp(int hart, u64 cmp)
 
 int riscv_init_ipi(void)
 {
-   long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
+   if (!gd->arch.clint) {
+   long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
 
-   if (IS_ERR(ret))
-   return PTR_ERR(ret);
-   gd->arch.clint = ret;
+   if (IS_ERR(ret))
+   return PTR_ERR(ret);
+   gd->arch.clint = ret;
+   }
 
return 0;
 }
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index 3440bc0..14f335f 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -79,11 +79,6 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
invalidate_icache_all();
 
 #ifdef CONFIG_SPL_SMP
-   /* Initialize the IPI before we use it */
-   ret = riscv_init_ipi();
-   if (ret)
-   hang();
-
/*
 * Start OpenSBI on all secondary harts and wait for acknowledgment.
 *
-- 
2.7.4



Re: am654_sdhci: mmc fail to send stop cmd

2020-07-19 Thread Jan Kiszka

On 20.07.20 03:21, Peng Fan wrote:

Hi Jan,


Subject: am654_sdhci: mmc fail to send stop cmd

Hi all,

on one device with one specific SD-card (possibly an aging one), I'm seeing
frequent "mmc fail to send stop cmd" messages, followed by read errors
when loading kernel and dtb. -ETIMEDOUT is returned by mmd_send_cmd.
However, I can always resolve this by simply retrying the stop command like
this:

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
f36d11ddc8..9019d9f2ed 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -406,7 +406,11 @@ static int mmc_read_blocks(struct mmc *mmc, void
*dst, lbaint_t start,  #if !defined(CONFIG_SPL_BUILD) ||
defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
pr_err("mmc fail to send stop cmd\n");  #endif
-   return 0;
+   pr_err("retrying...\n");
+   if (mmc_send_cmd(mmc, &cmd, NULL)) {
+   pr_err("failed again\n");
+   return 0;
+   }
}
}


Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
board-enabling and a bunch of patches from your tree [1]. However, already
4d6da10ce611 exposes the problem.

What could cause this?


Where the timeout happen in driver?

Did you try enlarge the timeout value?


Not sure yet where I could do that. The timeout is detected and reported
by the hardware via SDHCI_INT_STATUS (= 0x18000 in case of an error).

Thanks,
Jan



Regards,
Peng.



Jan

[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.

 ^

Welcome to the club. If you are on TB, I can recommend "Unmangle Outlook
Safelinks" to get rid of this insecurity measure, at least on the client
side.


com%2Fsiemens%2Fu-boot%2Fcommits%2Fjan%2Fiot2050&data=02%7
C01%7CPeng.Fan%40nxp.com%7Cda088100ee5a46cdc37008d82b29779f%7
C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63730680439552710
6&sdata=oiS6nOxxAQykjMyTecz%2FTJY4OW8WiZ2CbszR2mBrXuI%3D&
amp;reserved=0




[PATCH v3] riscv: Make SiFive HiFive Unleashed board boot again

2020-07-19 Thread Bin Meng
From: Bin Meng 

Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
caused U-Boot failed to boot on SiFive HiFive Unleashed board.

The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
before the call to riscv_init_ipi(). At that time the timer register
base (e.g.: the SiFive CLINT device in this case) is unknown yet.

It might be the name riscv_init_ipi() that misleads people to only
consider it is related to IPI, but in fact the timer capability is
provided by the same SiFive CLINT device that provides the IPI.
Timer capability is needed for both UP and SMP.

Considering that the original refactor does have benefits, that it
makes the IPI code more similar to U-boot initialization idioms.
It also removes some quite ugly macros. Let's do the minimal revert
instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
consider the SPL case.

Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
Signed-off-by: Bin Meng 
---

Changes in v3:
- Simply call riscv_init_ipi() in clint timer functions to avoid
  some duplications

Changes in v2:
- Do the minimal partial revert instead of a complete revert, enough
  to make HiFive Unleashed board boot again.

 arch/riscv/cpu/cpu.c  |  2 +-
 arch/riscv/lib/sifive_clint.c | 16 
 common/spl/spl_opensbi.c  |  5 -
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index bbd6c15..bfa2d4a 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -107,7 +107,7 @@ int arch_cpu_init_dm(void)
 #endif
}
 
-#ifdef CONFIG_SMP
+#if CONFIG_IS_ENABLED(SMP)
ret = riscv_init_ipi();
if (ret)
return ret;
diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index 78fc6c8..b9a2c64 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int riscv_get_time(u64 *time)
 {
+   /* ensure timer register base has a sane value */
+   riscv_init_ipi();
+
*time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
 
return 0;
@@ -33,6 +36,9 @@ int riscv_get_time(u64 *time)
 
 int riscv_set_timecmp(int hart, u64 cmp)
 {
+   /* ensure timer register base has a sane value */
+   riscv_init_ipi();
+
writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint, hart));
 
return 0;
@@ -40,11 +46,13 @@ int riscv_set_timecmp(int hart, u64 cmp)
 
 int riscv_init_ipi(void)
 {
-   long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
+   if (!gd->arch.clint) {
+   long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
 
-   if (IS_ERR(ret))
-   return PTR_ERR(ret);
-   gd->arch.clint = ret;
+   if (IS_ERR(ret))
+   return PTR_ERR(ret);
+   gd->arch.clint = ret;
+   }
 
return 0;
 }
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index 3440bc0..14f335f 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -79,11 +79,6 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
invalidate_icache_all();
 
 #ifdef CONFIG_SPL_SMP
-   /* Initialize the IPI before we use it */
-   ret = riscv_init_ipi();
-   if (ret)
-   hang();
-
/*
 * Start OpenSBI on all secondary harts and wait for acknowledgment.
 *
-- 
2.7.4



[PATCH v2] riscv: Make SiFive HiFive Unleashed board boot again

2020-07-19 Thread Bin Meng
From: Bin Meng 

Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
caused U-Boot failed to boot on SiFive HiFive Unleashed board.

The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
before the call to riscv_init_ipi(). At that time the timer register
base (e.g.: the SiFive CLINT device in this case) is unknown yet.

It might be the name riscv_init_ipi() that misleads people to only
consider it is related to IPI, but in fact the timer capability is
provided by the same SiFive CLINT device that provides the IPI.
Timer capability is needed for both UP and SMP.

Considering that the original refactor does have benefits, that it
makes the IPI code more similar to U-boot initialization idioms.
It also removes some quite ugly macros. Let's do the minimal revert
instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
consider the SPL case.

Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
Signed-off-by: Bin Meng 
---

Changes in v2:
- Do the minimal partial revert instead of a complete revert, enough
  to make HiFive Unleashed board boot again.

 arch/riscv/cpu/cpu.c  |  2 +-
 arch/riscv/lib/sifive_clint.c | 16 
 common/spl/spl_opensbi.c  |  5 -
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index bbd6c15..bfa2d4a 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -107,7 +107,7 @@ int arch_cpu_init_dm(void)
 #endif
}
 
-#ifdef CONFIG_SMP
+#if CONFIG_IS_ENABLED(SMP)
ret = riscv_init_ipi();
if (ret)
return ret;
diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index 78fc6c8..3dfafd9 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -24,8 +24,22 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define CLINT_BASE_GET(void)   \
+   do {\
+   long *ret;  \
+   \
+   if (!gd->arch.clint) {  \
+   ret = syscon_get_first_range(RISCV_SYSCON_CLINT); \
+   if (IS_ERR(ret))\
+   return PTR_ERR(ret);\
+   gd->arch.clint = ret;   \
+   }   \
+   } while (0)
+
 int riscv_get_time(u64 *time)
 {
+   CLINT_BASE_GET();
+
*time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
 
return 0;
@@ -33,6 +47,8 @@ int riscv_get_time(u64 *time)
 
 int riscv_set_timecmp(int hart, u64 cmp)
 {
+   CLINT_BASE_GET();
+
writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint, hart));
 
return 0;
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index 3440bc0..14f335f 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -79,11 +79,6 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
invalidate_icache_all();
 
 #ifdef CONFIG_SPL_SMP
-   /* Initialize the IPI before we use it */
-   ret = riscv_init_ipi();
-   if (ret)
-   hang();
-
/*
 * Start OpenSBI on all secondary harts and wait for acknowledgment.
 *
-- 
2.7.4



[PATCH v3] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

2020-07-19 Thread Bin Meng
From: Bin Meng 

Change to use OpenSBI release v0.8 generic platform images for QEMU
RISC-V CI testing for azure, gitlab and travis-ci.

Signed-off-by: Bin Meng 
Reviewed-by: Tom Rini 
---

Changes in v3:
- rebase on u-boot/master again

Changes in v2:
- rebase on u-boot/master

 .azure-pipelines.yml | 8 
 .gitlab-ci.yml   | 8 
 .travis.yml  | 8 
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 97c89fc..303857c 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -295,12 +295,12 @@ jobs:
   grub-mkimage --prefix=\"\" -o ~/grub_x86.efi -O i386-efi normal  
echo lsefimmap lsefi lsefisystab efinet tftp minicmd
   grub-mkimage --prefix=\"\" -o ~/grub_x64.efi -O x86_64-efi normal  
echo lsefimmap lsefi lsefisystab efinet tftp minicmd
   if [[ "${TEST_PY_BD}" == "qemu-riscv32_spl" ]]; then
-  wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv32-bin.tar.xz
 | tar -C /tmp -xJ;
-  export 
OPENSBI=/tmp/opensbi-0.6-rv32-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+  wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
 | tar -C /tmp -xJ;
+  export 
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin;
   fi
   if [[ "${TEST_PY_BD}" == "qemu-riscv64_spl" ]]; then
-  wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv64-bin.tar.xz
 | tar -C /tmp -xJ;
-  export 
OPENSBI=/tmp/opensbi-0.6-rv64-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+  wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
 | tar -C /tmp -xJ;
+  export 
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
   fi
   # the below corresponds to .gitlab-ci.yml "script"
   cd ${WORK_DIR}
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index d2f8646..e8ad3f4 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -21,12 +21,12 @@ stages:
 - grub-mkimage --prefix="" -o ~/grub_x86.efi -O i386-efi normal  echo 
lsefimmap lsefi lsefisystab efinet tftp minicmd
 - grub-mkimage --prefix="" -o ~/grub_x64.efi -O x86_64-efi normal  echo 
lsefimmap lsefi lsefisystab efinet tftp minicmd
 - if [[ "${TEST_PY_BD}" == "qemu-riscv32_spl" ]]; then
-wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv32-bin.tar.xz
 | tar -C /tmp -xJ;
-export 
OPENSBI=/tmp/opensbi-0.6-rv32-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
 | tar -C /tmp -xJ;
+export 
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin;
   fi
 - if [[ "${TEST_PY_BD}" == "qemu-riscv64_spl" ]]; then
-wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv64-bin.tar.xz
 | tar -C /tmp -xJ;
-export 
OPENSBI=/tmp/opensbi-0.6-rv64-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
 | tar -C /tmp -xJ;
+export 
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
   fi
 
   after_script:
diff --git a/.travis.yml b/.travis.yml
index 1ff1408..96fd55f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -204,12 +204,12 @@ before_script:
popd;
 fi
   - if [[ "${TEST_PY_BD}" == "qemu-riscv32_spl" ]]; then
-   wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv32-bin.tar.xz
 | tar -C /tmp -xJ;
-   export 
OPENSBI=/tmp/opensbi-0.6-rv32-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+   wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
 | tar -C /tmp -xJ;
+   export 
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin;
 fi
   - if [[ "${TEST_PY_BD}" == "qemu-riscv64_spl" ]]; then
-   wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv64-bin.tar.xz
 | tar -C /tmp -xJ;
-   export 
OPENSBI=/tmp/opensbi-0.6-rv64-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+   wget -O - 
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
 | tar -C /tmp -xJ;
+   export 
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
 fi
 
 script:
-- 
2.7.4



rk3399-gru-kevin: issues on bringup

2020-07-19 Thread Marty E. Plummer
Greetings.

I've been working on u-boot for rk3399-gru-kevin, Samsung Chromebook
Plus. In theory it should be fairly similar to the Bob chromebook, and
as such my work is largely based on it. Aside from some trivial changes,
and adding chromebook_kevin_defconfig (direct copy of bob's config, with
bob exchanged for kevin where apropriate) there is no major changes done
(current diff at bottom).

After building, I prepare the image like this:

===
$ ./tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader.img
# 0x6 chosen from doc/board/rockchip/rockchip.rst:187
$ dd if=idbloader.img of=start bs=$((0x6)) conv=sync count=1
$ cat u-boot.itb >> start
# 8mb spi flash
$ dd if=start of=flash.bin bs=$((1024*1024*8)) conv=sync count=1
===

and flash it from within a chromeos dev env with a servo, like this:
===
# power down
$ dut-control spi2_buf_en:on spi2_buf_on_flex_en:on spi2_vref:pp3300 
cold_reset:on
# flash
$ sudo flashrom -V --programmer ft2232_spi:type=google-servo-v2 -w flash.bin
# power up
$ dut-control spi2_buf_en:off spi2_buf_on_flex_en:off spi2_vref:off 
cold_reset:off
===

But I do not get any more output than the following: (using the same ddr
config as bob, as it matches what coreboot's source tree has listed
during coreboot's bootup, to the best of my ability to tell.
src/mainboard/google/gru/sdram_params/sdram-lpddr3-generic-4GB-928.c

===
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride

U-Boot SPL 2020.07-10102-g1c4b5038af-dirty (Jul 19 2020 - 22:04:50 -0500)
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
===

Unsure where to proceed from here. I notice that when bob was originally
ported the chosen node had a u-boot,spl-boot-order property and the
config node had u-boot,spl-payload-offset, which is no more, perhaps
there is something to that?

Current changes:

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cee10f533f..0e3e1cc553 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -122,6 +122,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-gru-bob.dtb \
+   rk3399-gru-kevin.dtb \
rk3399-khadas-edge.dtb \
rk3399-khadas-edge-captain.dtb \
rk3399-khadas-edge-v.dtb \

diff --git a/include/dt-bindings/input/linux-event-codes.h 
b/include/dt-bindings/input/linux-event-codes.h
index 87cf351bab..331458c0e7 100644
--- a/include/dt-bindings/input/linux-event-codes.h
+++ b/include/dt-bindings/input/linux-event-codes.h
@@ -749,7 +749,8 @@
 #define SW_ROTATE_LOCK 0x0c  /* set = rotate locked/disabled */
 #define SW_LINEIN_INSERT   0x0d  /* set = inserted */
 #define SW_MUTE_DEVICE 0x0e  /* set = device disabled */
-#define SW_MAX 0x0f
+#define SW_PEN_INSERTED0x0f  /* set = pen inserted */
+#define SW_MAX 0x10
 #define SW_CNT (SW_MAX+1)
 
 /*


Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

2020-07-19 Thread Rick Chen
Hi Bin

> Hi Rick,
>
> On Mon, Jul 20, 2020 at 11:16 AM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Monday, July 20, 2020 10:41 AM
> > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > Cc: Tom Rini; Bin Meng
> > > Subject: Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for 
> > > RISC-V testing
> > >
> > > Hi Rick,
> > >
> > > On Thu, Jul 16, 2020 at 5:15 PM Bin Meng  wrote:
> > > >
> > > > From: Bin Meng 
> > > >
> > > > Change to use OpenSBI release v0.8 generic platform images for QEMU
> > > > RISC-V CI testing for azure, gitlab and travis-ci.
> > > >
> > > > Signed-off-by: Bin Meng 
> > > > Reviewed-by: Tom Rini 
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - rebase on u-boot/master
> > > >
> > > >  .azure-pipelines.yml | 8 
> > > >  .gitlab-ci.yml   | 8 
> > > >  .travis.yml  | 8 
> > > >  3 files changed, 12 insertions(+), 12 deletions(-)
> > > >
> > >
> > > Ping?
> >
> > It still conflict with u-boot/master.
> >
> > Applying: azure: gitlab: travis: Update OpenSBI used for RISC-V testing
> > error: patch failed: .azure-pipelines.yml:299
> > error: .azure-pipelines.yml: patch does not apply
> > error: patch failed: .gitlab-ci.yml:25
> > error: .gitlab-ci.yml: patch does not apply
> >
>
> I suspect this is because u-boot-riscv/master is a little bit old. Can
> you rebase u-boot-riscv/master on top of u-boot/master and retry?

Yes, I have rebased to the latest u-boot/master. But the conflicts still occur

Thanks,
Rick.

>
> Regards,
> Bin


Please pull u-boot-x86

2020-07-19 Thread Bin Meng
Hi Tom,

This PR includes the following changes for v2020.10 release:

- dm: core: Don't show an ACPI warning if there is no ordering
- x86: Enhance MTRR functionality to support multiple CPUs

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=265&view=results

The following changes since commit 49cf75101db58ad3540d8de6749cf0c1d780dc76:

  Merge tag 'mips-pull-2020-07-18' of
https://gitlab.denx.de/u-boot/custodians/u-boot-mips (2020-07-18
11:34:49 -0400)

are available in the git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-x86

for you to fetch changes up to 2a3d9a7af9b3f7abad4d1bc4d40f1d665a54da8f:

  x86: mtrr: Enhance 'mtrr' command to list MTRRs on any CPU
(2020-07-20 09:46:48 +0800)


Simon Glass (26):
  dm: core: Don't show an ACPI warning if there is no ordering
  x86: mp_init: Switch to livetree
  x86: Move MP code into mp_init
  x86: mp_init: Avoid declarations in header files
  x86: mp_init: Switch parameter names in start_aps()
  x86: mp_init: Drop the num_cpus static variable
  x86: mtrr: Fix 'ensable' typo
  x86: mp_init: Set up the CPU numbers at the start
  x86: mp_init: Adjust bsp_init() to return more information
  x86: cpu: Remove unnecessary #ifdefs
  x86: mp: Support APs waiting for instructions
  global_data: Add a generic global_data flag for SMP state
  x86: Set the SMP flag when MP init is complete
  x86: mp: Allow running functions on multiple CPUs
  x86: mp: Park CPUs before running the OS
  x86: mp: Add iterators for CPUs
  x86: mtrr: Use MP calls to list the MTRRs
  x86: Don't enable SMP in SPL
  x86: coral: Update the memory map
  x86: mtrr: Update MTRRs on all CPUs
  x86: mtrr: Add support for writing to MTRRs on any CPU
  x86: mtrr: Update the command to use the new mtrr calls
  x86: mtrr: Restructure so command execution is in one place
  x86: mtrr: Update 'mtrr' to allow setting MTRRs on any CPU
  x86: mp: Add more comments to the module
  x86: mtrr: Enhance 'mtrr' command to list MTRRs on any CPU

 arch/x86/Kconfig  |   7 ++
 arch/x86/cpu/Makefile |   2 +-
 arch/x86/cpu/apollolake/Kconfig   |   1 +
 arch/x86/cpu/cpu.c|  58 +++---
 arch/x86/cpu/i386/cpu.c   |  26 ++-
 arch/x86/cpu/mp_init.c| 528
+++
 arch/x86/cpu/mtrr.c   | 149 +++
 arch/x86/include/asm/mp.h | 137 +++-
 arch/x86/include/asm/mtrr.h   |  51 
 cmd/x86/mtrr.c| 148 +++
 doc/board/google/chromebook_coral.rst |   1 +
 drivers/core/acpi.c   |   2 +-
 include/asm-generic/global_data.h |   1 +
 13 files changed, 925 insertions(+), 186 deletions(-)

Regards,
Bin


Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

2020-07-19 Thread Bin Meng
Hi Rick,

On Mon, Jul 20, 2020 at 11:16 AM Rick Chen  wrote:
>
> Hi Bin
>
> > From: Bin Meng [mailto:bmeng...@gmail.com]
> > Sent: Monday, July 20, 2020 10:41 AM
> > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > Cc: Tom Rini; Bin Meng
> > Subject: Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for 
> > RISC-V testing
> >
> > Hi Rick,
> >
> > On Thu, Jul 16, 2020 at 5:15 PM Bin Meng  wrote:
> > >
> > > From: Bin Meng 
> > >
> > > Change to use OpenSBI release v0.8 generic platform images for QEMU
> > > RISC-V CI testing for azure, gitlab and travis-ci.
> > >
> > > Signed-off-by: Bin Meng 
> > > Reviewed-by: Tom Rini 
> > > ---
> > >
> > > Changes in v2:
> > > - rebase on u-boot/master
> > >
> > >  .azure-pipelines.yml | 8 
> > >  .gitlab-ci.yml   | 8 
> > >  .travis.yml  | 8 
> > >  3 files changed, 12 insertions(+), 12 deletions(-)
> > >
> >
> > Ping?
>
> It still conflict with u-boot/master.
>
> Applying: azure: gitlab: travis: Update OpenSBI used for RISC-V testing
> error: patch failed: .azure-pipelines.yml:299
> error: .azure-pipelines.yml: patch does not apply
> error: patch failed: .gitlab-ci.yml:25
> error: .gitlab-ci.yml: patch does not apply
>

I suspect this is because u-boot-riscv/master is a little bit old. Can
you rebase u-boot-riscv/master on top of u-boot/master and retry?

Regards,
Bin


Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

2020-07-19 Thread Rick Chen
Hi Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Monday, July 20, 2020 10:41 AM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Tom Rini; Bin Meng
> Subject: Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V 
> testing
>
> Hi Rick,
>
> On Thu, Jul 16, 2020 at 5:15 PM Bin Meng  wrote:
> >
> > From: Bin Meng 
> >
> > Change to use OpenSBI release v0.8 generic platform images for QEMU
> > RISC-V CI testing for azure, gitlab and travis-ci.
> >
> > Signed-off-by: Bin Meng 
> > Reviewed-by: Tom Rini 
> > ---
> >
> > Changes in v2:
> > - rebase on u-boot/master
> >
> >  .azure-pipelines.yml | 8 
> >  .gitlab-ci.yml   | 8 
> >  .travis.yml  | 8 
> >  3 files changed, 12 insertions(+), 12 deletions(-)
> >
>
> Ping?

It still conflict with u-boot/master.

Applying: azure: gitlab: travis: Update OpenSBI used for RISC-V testing
error: patch failed: .azure-pipelines.yml:299
error: .azure-pipelines.yml: patch does not apply
error: patch failed: .gitlab-ci.yml:25
error: .gitlab-ci.yml: patch does not apply

Thanks,
Rick

>
> Regards,
> Bin


Re: dtoc code-coverage tests

2020-07-19 Thread Walter Lozano

Hi Simon,

On 19/7/20 15:30, Simon Glass wrote:

Hi Walter,

I am seeing a test failure with code coverage - it is at 99%. It looks
to be due to an exception that doesn't occur in the tests
(UnicodeDecodeError). Could you please take a look?

You should be able to test it by calling scan_driver with a known-bad
unicode sequence.

Yes, I noticed it during my recent work. Sure, I'm glad to help, I'll 
fix it and send a patch.


Regards,

Walter



Re: [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman

2020-07-19 Thread Simon Glass
Hi Bin,

On Sun, 19 Jul 2020 at 19:12, Bin Meng  wrote:
>
> Hi Simon,
>
> On Mon, Jul 20, 2020 at 3:56 AM Simon Glass  wrote:
> >
> > Rockchip-based Chromebooks support booting from SPI flash. It is annoying
> > to have to manually build the SPI image when the SD image is built
> > automatically.
> >
> > This feature is already available for x86 devices, so the existing
> > mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
> > to be provided to indicate that any required binary blobs are present and
> > it is safe to build the ROM.
> >
> > A new 'mkimage' type is added to binman to support building binaries
> > containing mkimagem using a binman definition to configure it. This avoids
> > Makefile/shell/Python code to do the same thing.
> >
> > This series also migrates some rockchip boards to use binman to produce
> > their FIT as well, resulting in removing the fit_spl_optee.sh script.
> >
> > Other archs and the rest of rockchip could be migrated too.
> >
> > This series uses binman to produce a ROM image on two selected
> > Chromebooks, Bob (RK3399) and Jerry (RK3388).
> >
> > Changes in v4:
> > - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
> > - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> > - Update for changes to arch/arm/mach-k3/config.mk
> > - Move the .itb output to a separate rockchip-optee.dtsi file
> > - Add a check for CONFIG_FIT before building the .its
> >
> > Changes in v3:
> > - Add a comment about CONFIG_SPL_FRAMEWORK
> > - Drop rockchip changes which should not be in this patch
> > - Move in the rockchip changes mistakenly in the earlier x86 patch
> > - Drop use of rk322x.dtsi
> > - Add changes to rk3288-u-boot.dtsi instead
> > - Drop leftover debugging
>
> It looks you have applied part of the v3 in u-boot-dm, and sent the
> remaining patches as v4?
>
> I re-assigned this series to you in patchwork.

Yes I applied the binman patches and those that were reviewed.

I am not sure if this shold be an x86 or rockchip series, or perhaps
we just wait until people have had a look.

Regards,
Simon


[PATCH v2 1/2] Revert "riscv: Allow use of reset drivers"

2020-07-19 Thread Bin Meng
From: Bin Meng 

This reverts commit 958a3f464c7f8ef7e10db9feb663e9e80445ce2f.

A more appropriate change below is already in mainline.
Commit fd31e4fd184f ("riscv: Do not build reset.c if SYSRESET is on")

Revert this patch, so that U-Boot can be built successfully for
SiFive Fu540 board.

Signed-off-by: Bin Meng 
Reviewed-by: Sean Anderson 
Reviewed-by: Leo Liang 
---

(no changes since v1)

 arch/riscv/lib/reset.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/riscv/lib/reset.c b/arch/riscv/lib/reset.c
index 6008bbe..8779c61 100644
--- a/arch/riscv/lib/reset.c
+++ b/arch/riscv/lib/reset.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 
-#ifndef CONFIG_SYSRESET
 int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
printf("resetting ...\n");
@@ -17,4 +16,3 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char 
*const argv[])
 
return 0;
 }
-#endif
-- 
2.7.4



[PATCH v2 2/2] Revert "Revert "riscv: sifive: fu540: Add gpio-restart support""

2020-07-19 Thread Bin Meng
From: Bin Meng 

This reverts commit 23da3c682a84a2ad67a67287979dd4f5259ff607.

Now the build failure of sifive_fu540_defconfig board has been fixed,
revert this "revert patch".

Signed-off-by: Bin Meng 
---

Changes in v2:
- rebase on top of u-boot-riscv/master

 board/sifive/fu540/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 4aa1e4c..f3217f6 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -68,5 +68,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply SIFIVE_OTP
imply DM_PWM
imply PWM_SIFIVE
+   imply SYSRESET
+   imply SYSRESET_GPIO
 
 endif
-- 
2.7.4



Re: [PATCH 1/5] sysreset: syscon: Don't assume default value for offset and mask property

2020-07-19 Thread Bin Meng
Hi Rick,

On Mon, Jul 20, 2020 at 10:48 AM Rick Chen  wrote:
>
> Hi Tom
>
> > From: Bin Meng [mailto:bmeng...@gmail.com]
> > Sent: Friday, July 17, 2020 2:54 PM
> > To: Pragnesh Patel
> > Cc: Bin Meng; Rick Jian-Zhi Chen(陳建志); Simon Glass; U-Boot Mailing List; 
> > Sagar Kadam
> > Subject: Re: [PATCH 1/5] sysreset: syscon: Don't assume default value for 
> > offset and mask property
> >
> > Hi Rick,
> >
> > On Fri, Jun 26, 2020 at 1:53 PM Pragnesh Patel  
> > wrote:
> > >
> > > >-Original Message-
> > > >From: Bin Meng 
> > > >Sent: 23 June 2020 11:00
> > > >To: Rick Chen ; Simon Glass ;
> > > >Pragnesh Patel ; Sagar Kadam
> > > >; U-Boot Mailing List 
> > > >Cc: Bin Meng 
> > > >Subject: [PATCH 1/5] sysreset: syscon: Don't assume default value for
> > > >offset and mask property
> > > >
> > > >[External Email] Do not click links or attachments unless you
> > > >recognize the sender and know the content is safe
> > > >
> > > >From: Bin Meng 
> > > >
> > > >Per the DT binding,  is a required property. Let's abort the
> > > >probe if it is missing. For the  property, current codes assume
> > > >a default value of zero, which is not correct either.
> > > >
> > > >Signed-off-by: Bin Meng 
> > > >---
> > > >
> > > > drivers/sysreset/sysreset_syscon.c | 14 --
> > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > >
> > > Reviewed-by: Pragnesh Patel 
> >
> > Would you please take the remaining 3 patches soon?
> > http://patchwork.ozlabs.org/project/uboot/list/?series=185161
>
> May I ask for your opinions about these three SYSRESET patchs. If they
> are OK to be pick up in my next PR, though they have been rejected in
> previous riscv PR ?
> https://www.mail-archive.com/u-boot@lists.denx.de/msg375465.html
>

Now the merge window for v2020.10 is open. It's OK to merge this now.

Regards,
Bin


Re: [PATCH v4 1/7] lib: crypto: add public_key_verify_signature()

2020-07-19 Thread AKASHI Takahiro
Heinrich,

On Sun, Jul 19, 2020 at 10:20:58AM +0200, Heinrich Schuchardt wrote:
> On 7/17/20 9:16 AM, AKASHI Takahiro wrote:
> > This function will be called from x509_check_for_self_signed() and
> > pkcs7_verify_one(), which will be imported from linux in a later patch.
> >
> > While it does exist in linux code and has a similar functionality of
> > rsa_verify(), it calls further linux-specific interfaces inside.
> > That could lead to more files being imported from linux.
> >
> > So simply re-implement it here instead of re-using the code.
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  include/crypto/public_key.h |  2 +-
> >  lib/crypto/public_key.c | 70 -
> >  2 files changed, 70 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
> > index 436a1ee1ee64..3ba90fcc3483 100644
> > --- a/include/crypto/public_key.h
> > +++ b/include/crypto/public_key.h
> > @@ -82,9 +82,9 @@ extern int decrypt_blob(struct kernel_pkey_params *, 
> > const void *, void *);
> >  extern int create_signature(struct kernel_pkey_params *, const void *, 
> > void *);
> >  extern int verify_signature(const struct key *,
> > const struct public_key_signature *);
> > +#endif /* __UBOOT__ */
> >
> >  int public_key_verify_signature(const struct public_key *pkey,
> > const struct public_key_signature *sig);
> > -#endif /* !__UBOOT__ */
> >
> >  #endif /* _LINUX_PUBLIC_KEY_H */
> > diff --git a/lib/crypto/public_key.c b/lib/crypto/public_key.c
> > index e12ebbb3d0c5..71a0e0356beb 100644
> > --- a/lib/crypto/public_key.c
> > +++ b/lib/crypto/public_key.c
> > @@ -25,7 +25,10 @@
> >  #include 
> >  #endif
> >  #include 
> > -#ifndef __UBOOT__
> > +#ifdef __UBOOT__
> > +#include 
> > +#include 
> > +#else
> >  #include 
> >  #endif
> 
> Shouldn't we describe in the header of the file that the code is taken
> (at least partially) from Linux' crypto/asymmetric_keys/public_key.c?
> 
> Please, also state the Linux version number.

Please take a look at the commit c4e961ecec99 ("lib: crypto: add public
key utility") as this file itself was imported in v2020-01. 

While I prefer to add such an information in a commit message,
we should have an explicit rule for inclusion from outer sources
for consistency over the tree if you want to see such an information
in a file.

> >
> > @@ -80,6 +83,71 @@ void public_key_signature_free(struct 
> > public_key_signature *sig)
> >  }
> >  EXPORT_SYMBOL_GPL(public_key_signature_free);
> >
> > +/**
> > + * public_key_verify_signature - Verify a signature using a public key.
> > + *
> > + * @pkey:  Public key
> > + * @sig:   Signature
> > + *
> > + * Verify a signature, @sig, using a RSA public key, @pkey.
> > + *
> > + * Return: 0 - verified, non-zero error code - otherwise
> > + */
> > +int public_key_verify_signature(const struct public_key *pkey,
> > +   const struct public_key_signature *sig)
> > +{
> > +   struct image_sign_info info;
> > +   struct image_region region;
> > +   int ret;
> > +
> > +   pr_devel("==>%s()\n", __func__);
> > +
> > +   if (!pkey || !sig)
> > +   return -EINVAL;
> > +
> > +   if (pkey->key_is_private)
> > +   return -EINVAL;
> > +
> > +   memset(&info, '\0', sizeof(info));
> > +   info.padding = image_get_padding_algo("pkcs-1.5");
> > +   /*
> > +* Note: image_get_[checksum|crypto]_algo takes a string
> > +* argument like ","
> > +* TODO: support other hash algorithms
> > +*/
> > +   if (strcmp(sig->pkey_algo, "rsa") || (sig->s_size * 8) != 2048) {
> > +   pr_warn("Encryption is not RSA2048: %s%d\n",
> > +   sig->pkey_algo, sig->s_size * 8);
> > +   return -ENOPKG;
> > +   }
> > +   if (!strcmp(sig->hash_algo, "sha1")) {
> > +   info.checksum = image_get_checksum_algo("sha1,rsa2048");
> > +   info.name = "sha1,rsa2048";
> > +   } else if (!strcmp(sig->hash_algo, "sha256")) {
> > +   info.checksum = image_get_checksum_algo("sha256,rsa2048");
> > +   info.name = "sha256,rsa2048";
> > +   } else {
> > +   pr_warn("unknown msg digest algo: %s\n", sig->hash_algo);
> > +   return -ENOPKG;
> > +   }
> > +   info.crypto = image_get_crypto_algo(info.name);
> > +   if (unlikely(IS_ERR(info.checksum) || IS_ERR(info.crypto)))
> > +   return -ENOPKG;
> 
> scripts/checkpatch.pl complains:
> 
> WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely()
> internally
> #104: FILE: lib/crypto/public_key.c:134:
> +   if (unlikely(IS_ERR(info.checksum) || IS_ERR(info.crypto)))

Probably I missed it out when checking.

> I cannot find this unlikely in the Linux v5.8-rc4
> crypto/asymmetric_keys/public_key.c file. From where did you copy this code?

As I stated in the commit message, the whole code of this function
was written from the scratch rather than by re-using linux code.

-Takahiro Akashi

Re: [PATCH 1/5] sysreset: syscon: Don't assume default value for offset and mask property

2020-07-19 Thread Rick Chen
Hi Tom

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Friday, July 17, 2020 2:54 PM
> To: Pragnesh Patel
> Cc: Bin Meng; Rick Jian-Zhi Chen(陳建志); Simon Glass; U-Boot Mailing List; 
> Sagar Kadam
> Subject: Re: [PATCH 1/5] sysreset: syscon: Don't assume default value for 
> offset and mask property
>
> Hi Rick,
>
> On Fri, Jun 26, 2020 at 1:53 PM Pragnesh Patel  
> wrote:
> >
> > >-Original Message-
> > >From: Bin Meng 
> > >Sent: 23 June 2020 11:00
> > >To: Rick Chen ; Simon Glass ;
> > >Pragnesh Patel ; Sagar Kadam
> > >; U-Boot Mailing List 
> > >Cc: Bin Meng 
> > >Subject: [PATCH 1/5] sysreset: syscon: Don't assume default value for
> > >offset and mask property
> > >
> > >[External Email] Do not click links or attachments unless you
> > >recognize the sender and know the content is safe
> > >
> > >From: Bin Meng 
> > >
> > >Per the DT binding,  is a required property. Let's abort the
> > >probe if it is missing. For the  property, current codes assume
> > >a default value of zero, which is not correct either.
> > >
> > >Signed-off-by: Bin Meng 
> > >---
> > >
> > > drivers/sysreset/sysreset_syscon.c | 14 --
> > > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > Reviewed-by: Pragnesh Patel 
>
> Would you please take the remaining 3 patches soon?
> http://patchwork.ozlabs.org/project/uboot/list/?series=185161

May I ask for your opinions about these three SYSRESET patchs. If they
are OK to be pick up in my next PR, though they have been rejected in
previous riscv PR ?
https://www.mail-archive.com/u-boot@lists.denx.de/msg375465.html

Thanks,
Rick

>
> Regards,
> Bin


Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

2020-07-19 Thread Bin Meng
Hi Rick,

On Thu, Jul 16, 2020 at 5:15 PM Bin Meng  wrote:
>
> From: Bin Meng 
>
> Change to use OpenSBI release v0.8 generic platform images for QEMU
> RISC-V CI testing for azure, gitlab and travis-ci.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v2:
> - rebase on u-boot/master
>
>  .azure-pipelines.yml | 8 
>  .gitlab-ci.yml   | 8 
>  .travis.yml  | 8 
>  3 files changed, 12 insertions(+), 12 deletions(-)
>

Ping?

Regards,
Bin


RE: [PATCH 4/4] reset: add reset controller driver for SCMI agents

2020-07-19 Thread Peng Fan
> Subject: [PATCH 4/4] reset: add reset controller driver for SCMI agents
> 
> This change introduces a reset controller driver for SCMI agent devices.
> When SCMI agent and SCMI reset domain drivers are enabled, SCMI agent
> binds a reset controller device for each SCMI reset domain protocol devices
> enabled in the FDT.
> 
> SCMI reset driver is embedded upon CONFIG_RESET_SCMI=y. If enabled,
> CONFIG_SCMI_AGENT is also enabled.
> 
> SCMI Reset Domain protocol is defined in the SCMI specification [1].
> 
> Links: [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelo
> per.arm.com%2Farchitectures%2Fsystem-architectures%2Fsoftware-standar
> ds%2Fscmi&data=02%7C01%7Cpeng.fan%40nxp.com%7C68ec2a92529
> e49d46be608d82a6778a9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C637305971181000613&sdata=NWnJw%2BYBsbC1zBkBdq9Jxh9
> Crepk5JdxJlCxNl0diqA%3D&reserved=0
> Signed-off-by: Etienne Carriere 
> ---
> 
>  drivers/firmware/scmi.c|  3 ++
>  drivers/reset/Kconfig  |  8 
>  drivers/reset/Makefile |  1 +
>  drivers/reset/reset-scmi.c | 86
> ++
>  4 files changed, 98 insertions(+)
>  create mode 100644 drivers/reset/reset-scmi.c
> 
> diff --git a/drivers/firmware/scmi.c b/drivers/firmware/scmi.c index
> 9f06718df51..9be53a9cf11 100644
> --- a/drivers/firmware/scmi.c
> +++ b/drivers/firmware/scmi.c
> @@ -402,6 +402,9 @@ static int scmi_bind(struct udevice *dev)
>   case SCMI_PROTOCOL_ID_CLOCK:
>   drv = DM_GET_DRIVER(scmi_clock);
>   break;
> + case SCMI_PROTOCOL_ID_RESET_DOMAIN:
> + drv = DM_GET_DRIVER(scmi_reset_domain);
> + break;
>   default:
>   dev_info(dev, "Ignore unsupported SCMI protocol %u\n",
>protocol_id);
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> 6d535612234..31bd4cd5b45 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -164,4 +164,12 @@ config RESET_RASPBERRYPI
> relevant. This driver provides a reset controller capable of
> interfacing with RPi4's co-processor and model these firmware
> initialization routines as reset lines.
> +
> +config RESET_SCMI
> + bool "Enable SCMI reset domain driver"
> + select SCMI_FIRMWARE
> + help
> +   Enable this option if you want to support reset controller
> +   devices exposed by a SCMI agent based on SCMI reset domain
> +   protocol communication with a SCMI server.
>  endmenu
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index
> 8e0124b8dee..f3c0fbfd8f3 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o
>  obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
>  obj-$(CONFIG_RESET_SYSCON) += reset-syscon.o
>  obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
> +obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
> diff --git a/drivers/reset/reset-scmi.c b/drivers/reset/reset-scmi.c new file
> mode 100644 index 000..e664d91d865
> --- /dev/null
> +++ b/drivers/reset/reset-scmi.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019-2020 Linaro Limited  */ #include 
> +#include  #include  #include  #include
> + #include 
> +
> +enum scmi_reset_domain_message_id {
> + SCMI_RESET_DOMAIN_RESET = 0x4,
> +};
> +
> +#define SCMI_RD_RESET_FLAG_ASSERTBIT(1)
> +#define SCMI_RD_RESET_FLAG_DEASSERT  0
> +
> +struct scmi_rd_reset_in {
> + u32 domain_id;
> + u32 flags;
> + u32 reset_state;
> +};
> +
> +struct scmi_rd_reset_out {
> + s32 status;
> +};
> +
> +static int scmi_reset_set_state(struct reset_ctl *rst, int
> +assert_not_deassert) {
> + struct scmi_rd_reset_in in = {
> + .domain_id = rst->id,
> + .flags = assert_not_deassert ? SCMI_RD_RESET_FLAG_ASSERT :
> +  SCMI_RD_RESET_FLAG_DEASSERT,
> + .reset_state = 0,
> + };
> + struct scmi_rd_reset_out out;
> + struct scmi_msg scmi_msg = {
> + .protocol_id = SCMI_PROTOCOL_ID_RESET_DOMAIN,
> + .message_id = SCMI_RESET_DOMAIN_RESET,
> + .in_msg = (u8 *)&in,
> + .in_msg_sz = sizeof(in),
> + .out_msg = (u8 *)&out,
> + .out_msg_sz = sizeof(out),
> + };
> + int rc;
> +
> + rc = scmi_send_and_process_msg(rst->dev->parent, &scmi_msg);
> + if (rc)
> + return rc;
> +
> + return scmi_to_linux_errno(out.status); }
> +
> +static int scmi_reset_assert(struct reset_ctl *rst) {
> + return scmi_reset_set_state(rst, SCMI_RD_RESET_FLAG_ASSERT); }
> +
> +static int scmi_reset_deassert(struct reset_ctl *rst) {
> + return scmi_reset_set_state(rst, SCMI_RD_RESET_FLAG_DEASSERT); }
> +
> +static int scmi_reset_request(struct reset_ctl *reset_ctl) {
> + return 0;
> +}
> +
> +static int 

RE: [PATCH 3/4] clk: add clock driver for SCMI agents

2020-07-19 Thread Peng Fan


> Subject: [PATCH 3/4] clk: add clock driver for SCMI agents
> 
> This change introduces a clock driver for SCMI agent devices. When SCMI
> agent and SCMI clock drivers are enabled, SCMI agent binds a clock device for
> each SCMI clock protocol devices enabled in the FDT.
> 
> SCMI clock driver is embedded upon CONFIG_CLK_SCMI=y. If enabled,
> CONFIG_SCMI_AGENT is also enabled.
> 
> SCMI Clock protocol is defined in the SCMI specification [1].
> 
> Links: [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelo
> per.arm.com%2Farchitectures%2Fsystem-architectures%2Fsoftware-standar
> ds%2Fscmi&data=02%7C01%7Cpeng.fan%40nxp.com%7C6a1c6d1e102
> 94e81e47708d82a6777b9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C637305971176347870&sdata=4pKZGL17y7QUY%2Bi9XRutLOCe
> 5jBs1y9gMW7vNoUIcC0%3D&reserved=0
> Signed-off-by: Etienne Carriere 
> ---
> 
>  drivers/clk/Kconfig |   8 +++
>  drivers/clk/Makefile|   1 +
>  drivers/clk/clk_scmi.c  | 152
> 
>  drivers/firmware/scmi.c |   3 +
>  4 files changed, 164 insertions(+)
>  create mode 100644 drivers/clk/clk_scmi.c
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> 82cb1874e19..234d6035202 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -152,6 +152,14 @@ config CLK_CDCE9XX
>  Enable the clock synthesizer driver for CDCE913/925/937/949
>  series of chips.
> 
> +config CLK_SCMI
> + bool "Enable SCMI clock driver"
> + select SCMI_FIRMWARE
> + help
> +   Enable this option if you want to support clock devices exposed
> +   by a SCMI agent based on SCMI clock protocol communication
> +   with a SCMI server.
> +
>  source "drivers/clk/analogbits/Kconfig"
>  source "drivers/clk/at91/Kconfig"
>  source "drivers/clk/exynos/Kconfig"
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> d9119545810..76bba77d1f0 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_CLK_K210) += kendryte/
>  obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
>  obj-$(CONFIG_CLK_OWL) += owl/
>  obj-$(CONFIG_CLK_RENESAS) += renesas/
> +obj-$(CONFIG_CLK_SCMI) += clk_scmi.o
>  obj-$(CONFIG_CLK_SIFIVE) += sifive/
>  obj-$(CONFIG_ARCH_SUNXI) += sunxi/
>  obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o diff --git
> a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c new file mode 100644 index
> 000..efe64a6a38f
> --- /dev/null
> +++ b/drivers/clk/clk_scmi.c
> @@ -0,0 +1,152 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019-2020 Linaro Limited  */ #include 
> +#include  #include  #include  #include
> +
> +
> +enum scmi_clock_message_id {
> + SCMI_CLOCK_RATE_SET = 0x5,
> + SCMI_CLOCK_RATE_GET = 0x6,
> + SCMI_CLOCK_CONFIG_SET = 0x7,
> +};
> +
> +#define SCMI_CLK_RATE_ASYNC_NOTIFY   BIT(0)
> +#define SCMI_CLK_RATE_ASYNC_NORESP   (BIT(0) | BIT(1))
> +#define SCMI_CLK_RATE_ROUND_DOWN 0
> +#define SCMI_CLK_RATE_ROUND_UP   BIT(2)
> +#define SCMI_CLK_RATE_ROUND_CLOSEST  BIT(3)
> +
> +struct scmi_clk_state_in {
> + u32 clock_id;
> + u32 attributes;
> +};
> +
> +struct scmi_clk_state_out {
> + s32 status;
> +};
> +
> +static int scmi_clk_gate(struct clk *clk, int enable) {
> + struct scmi_clk_state_in in = {
> + .clock_id = clk->id,
> + .attributes = enable,
> + };
> + struct scmi_clk_state_out out;
> + struct scmi_msg scmi_msg = {
> + .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
> + .message_id = SCMI_CLOCK_CONFIG_SET,
> + .in_msg = (u8 *)&in,
> + .in_msg_sz = sizeof(in),
> + .out_msg = (u8 *)&out,
> + .out_msg_sz = sizeof(out),
> + };
> + int rc;
> +
> + rc = scmi_send_and_process_msg(clk->dev->parent, &scmi_msg);
> + if (rc)
> + return rc;
> +
> + return scmi_to_linux_errno(out.status); }
> +
> +static int scmi_clk_enable(struct clk *clk) {
> + return scmi_clk_gate(clk, 1);
> +}
> +
> +static int scmi_clk_disable(struct clk *clk) {
> + return scmi_clk_gate(clk, 0);
> +}
> +
> +struct scmi_clk_rate_get_in {
> + u32 clock_id;
> +};
> +
> +struct scmi_clk_rate_get_out {
> + s32 status;
> + u32 rate_lsb;
> + u32 rate_msb;
> +};
> +
> +static ulong scmi_clk_get_rate(struct clk *clk) {
> + struct scmi_clk_rate_get_in in = {
> + .clock_id = clk->id,
> + };
> + struct scmi_clk_rate_get_out out;
> + struct scmi_msg scmi_msg = {
> + .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
> + .message_id = SCMI_CLOCK_RATE_GET,
> + .in_msg = (u8 *)&in,
> + .in_msg_sz = sizeof(in),
> + .out_msg = (u8 *)&out,
> + .out_msg_sz = sizeof(out),
> + };
> + int rc;
> +
> + rc = scmi_send_and_process_msg(clk->dev->parent, &scmi_msg);
> + if (rc)
> + return 0;
> +
> + rc = scmi_to_linux_errno(out.status);

RE: [PATCH 2/4] dt-bindings: arm: SCMI bindings documentation

2020-07-19 Thread Peng Fan
> Subject: [PATCH 2/4] dt-bindings: arm: SCMI bindings documentation

Since kernel already has the binding doc, there is no need to add a U-Boot
copy.

Regards,
Peng.

> 
> Dump SCMI DT bindings documentation from Linux kernel source tree
> v5.8-rc1.
> 
> Signed-off-by: Etienne Carriere 
> ---
> 
>  doc/device-tree-bindings/arm/arm,scmi.txt | 197
> ++
>  1 file changed, 197 insertions(+)
>  create mode 100644 doc/device-tree-bindings/arm/arm,scmi.txt
> 
> diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt
> b/doc/device-tree-bindings/arm/arm,scmi.txt
> new file mode 100644
> index 000..1f293ea24cd
> --- /dev/null
> +++ b/doc/device-tree-bindings/arm/arm,scmi.txt
> @@ -0,0 +1,197 @@
> +System Control and Management Interface (SCMI) Message Protocol
> +--
> +
> +The SCMI is intended to allow agents such as OSPM to manage various
> +functions that are provided by the hardware platform it is running on,
> +including power and performance functions.
> +
> +This binding is intended to define the interface the firmware
> +implementing the SCMI as described in ARM document number ARM DEN
> 0056A
> +("ARM System Control and Management Interface Platform Design
> +Document")[0] provide for OSPM in the device tree.
> +
> +Required properties:
> +
> +The scmi node with the following properties shall be under the /firmware/
> node.
> +
> +- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc
> +transports
> +- mboxes: List of phandle and mailbox channel specifiers. It should contain
> +   exactly one or two mailboxes, one for transmitting messages("tx")
> +   and another optional for receiving the notifications("rx") if
> +   supported.
> +- shmem : List of phandle pointing to the shared memory(SHM) area as per
> +   generic mailbox client binding.
> +- #address-cells : should be '1' if the device has sub-nodes, maps to
> +   protocol identifier for a given sub-node.
> +- #size-cells : should be '0' as 'reg' property doesn't have any size
> +   associated with it.
> +- arm,smc-id : SMC id required when using smc or hvc transports
> +
> +Optional properties:
> +
> +- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
> +
> +See Documentation/devicetree/bindings/mailbox/mailbox.txt for more
> +details about the generic mailbox controller and client driver bindings.
> +
> +The mailbox is the only permitted method of calling the SCMI firmware.
> +Mailbox doorbell is used as a mechanism to alert the presence of a
> +messages and/or notification.
> +
> +Each protocol supported shall have a sub-node with corresponding
> +compatible as described in the following sections. If the platform
> +supports dedicated communication channel for a particular protocol, the 3
> properties namely:
> +mboxes, mbox-names and shmem shall be present in the sub-node
> +corresponding to that protocol.
> +
> +Clock/Performance bindings for the clocks/OPPs based on SCMI Message
> +Protocol
> +
> +
> +This binding uses the common clock binding[1].
> +
> +Required properties:
> +- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI
> commands.
> +
> +Power domain bindings for the power domains based on SCMI Message
> +Protocol
> +
> +
> +This binding for the SCMI power domain providers uses the generic power
> +domain binding[2].
> +
> +Required properties:
> + - #power-domain-cells : Should be 1. Contains the device or the power
> +  domain ID value used by SCMI commands.
> +
> +Sensor bindings for the sensors based on SCMI Message Protocol
> +--
> +SCMI provides an API to access the various sensors on the SoC.
> +
> +Required properties:
> +- #thermal-sensor-cells: should be set to 1. This property follows the
> +  thermal device tree bindings[3].
> +
> +  Valid cell values are raw identifiers (Sensor ID)
> +  as used by the firmware. Refer to  platform details
> +  for your implementation for the IDs to use.
> +
> +Reset signal bindings for the reset domains based on SCMI Message
> +Protocol
> +
> +
> +This binding for the SCMI reset domain providers uses the generic reset
> +signal binding[5].
> +
> +Required properties:
> + - #reset-cells : Should be 1. Contains the reset domain ID value used
> +   by SCMI commands.
> +
> +SRAM and Shared Memory for SCMI
> +---
> +
> +A small area of SRAM is reserved for SCMI communication between
> +application processors and SCP.
> +
> +The properties should follow the generic mmio-sram description found in
> +[4]
> +
> +Each sub-node represents the reserved area for SCMI.
> +
> +Required

RE: [PATCH 1/4] firmware: add new driver for SCMI firmwares

2020-07-19 Thread Peng Fan
Hi Etienne,

+Sudeep

> Subject: [PATCH 1/4] firmware: add new driver for SCMI firmwares

Thanks for posting this out.

> 
> This change introduces SCMI agent driver in U-Boot in the firmware U-class.
> 
> SCMI agent driver is designed for platforms that embed a SCMI server in a
> firmware hosted for example by a companion co-processor or the secure
> world of the executing processor.
> 
> SCMI protocols allow an SCMI agent to discover and access external
> resources as clock, reset controllers and many more. SCMI agent and server
> communicate following the SCMI specification [1]. SCMI agent complies with
> the DT bindings defined in the Linux kernel source tree regarding SCMI agent
> description since v5.8-rc1.
> 
> These bindings describe 2 supported message transport layer: using mailbox
> uclass devices or using Arm SMC invocation instruction. Both use a piece or
> shared memory for message data exchange.
> 
> In the current state, the SCMI agent driver does not bind to any SCMI protocol
> to a U-Boot device driver. Former changes will implement dedicated driver 
> (i.e.
> an SCMI clock driver or an SCMI reset controller
> driver) and add bind supported SCMI protocols in scmi_agent_bind().
> 
> Links: [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelo
> per.arm.com%2Farchitectures%2Fsystem-architectures%2Fsoftware-standar
> ds%2Fscmi&data=02%7C01%7Cpeng.fan%40nxp.com%7C39c55064be5
> 04bf248a708d82a6775cd%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C637305971142916174&sdata=5kCgz3kzzk4qHy598u79zz3hV17yV
> zdPxM531sOAnUs%3D&reserved=0
> Signed-off-by: Etienne Carriere 
> ---
> 
>  drivers/firmware/Kconfig  |  15 ++
>  drivers/firmware/Makefile |   1 +
>  drivers/firmware/scmi.c   | 439
> ++
>  include/scmi.h|  82 +++
>  4 files changed, 537 insertions(+)
>  create mode 100644 drivers/firmware/scmi.c  create mode 100644
> include/scmi.h
> 
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index
> b70a2063551..f7c7ee7a5aa 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -1,6 +1,21 @@
>  config FIRMWARE
>   bool "Enable Firmware driver support"
> 
> +config SCMI_FIRMWARE
> + bool "Enable SCMI support"
> + select FIRMWARE
> + select OF_TRANSLATE
> + depends on DM_MAILBOX || ARM_SMCCC
> + help
> +   An SCMI agent communicates with a related SCMI server firmware
> +   located in another sub-system, as a companion micro controller
> +   or a companion host in the CPU system.
> +
> +   Communications between agent (client) and the SCMI server are
> +   based on message exchange. Messages can be exchange over tranport
> +   channels as a mailbox device or an Arm SMCCC service with some
> +   piece of identified shared memory.
> +
>  config SPL_FIRMWARE
>   bool "Enable Firmware driver support in SPL"
>   depends on FIRMWARE
> diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index
> a0c250a473e..3965838179f 100644
> --- a/drivers/firmware/Makefile
> +++ b/drivers/firmware/Makefile
> @@ -2,4 +2,5 @@ obj-$(CONFIG_FIRMWARE)+= firmware-uclass.o
>  obj-$(CONFIG_$(SPL_)ARM_PSCI_FW) += psci.o
>  obj-$(CONFIG_TI_SCI_PROTOCOL)+= ti_sci.o
>  obj-$(CONFIG_SANDBOX)+= firmware-sandbox.o
> +obj-$(CONFIG_SCMI_FIRMWARE)  += scmi.o
>  obj-$(CONFIG_ZYNQMP_FIRMWARE)+= firmware-zynqmp.o
> diff --git a/drivers/firmware/scmi.c b/drivers/firmware/scmi.c new file mode
> 100644 index 000..fa8a91c3f3d
> --- /dev/null
> +++ b/drivers/firmware/scmi.c
> @@ -0,0 +1,439 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2015-2019, Arm Limited and Contributors. All rights
> reserved.
> + * Copyright (C) 2019-2020 Linaro Limited.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TIMEOUT_US_10MS  1
> +
> +struct error_code {
> + int scmi;
> + int errno;
> +};
> +
> +static const struct error_code scmi_linux_errmap[] = {
> + { .scmi = SCMI_NOT_SUPPORTED, .errno = -EOPNOTSUPP, },
> + { .scmi = SCMI_INVALID_PARAMETERS, .errno = -EINVAL, },
> + { .scmi = SCMI_DENIED, .errno = -EACCES, },
> + { .scmi = SCMI_NOT_FOUND, .errno = -ENOENT, },
> + { .scmi = SCMI_OUT_OF_RANGE, .errno = -ERANGE, },
> + { .scmi = SCMI_BUSY, .errno = -EBUSY, },
> + { .scmi = SCMI_COMMS_ERROR, .errno = -ECOMM, },
> + { .scmi = SCMI_GENERIC_ERROR, .errno = -EIO, },
> + { .scmi = SCMI_HARDWARE_ERROR, .errno = -EREMOTEIO, },
> + { .scmi = SCMI_PROTOCOL_ERROR, .errno = -EPROTO, }, };
> +
> +int scmi_to_linux_errno(s32 scmi_code)
> +{
> + int n;
> +
> + if (scmi_code == 0)

!scmi_code

> + return 0;
> +
> +

RE: [PATCH 2/2] imx8m: soc: Remove unneeded space

2020-07-19 Thread Peng Fan
> Subject: [PATCH 2/2] imx8m: soc: Remove unneeded space
> 
> Checkpatch reports the following issue:
> 
> ERROR: space prohibited before that ',' (ctx:WxW)
> #936: FILE: arch/arm/mach-imx/imx8m/soc.c:936:
> +   0, 0 , 0, 0, 0, 0, &res);
> 
> Remove the unneeded space.
>  ^
> Reported-by: Tom Rini 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/mach-imx/imx8m/soc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/imx8m/soc.c
> b/arch/arm/mach-imx/imx8m/soc.c index b3c08271e6..75e1877e20 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -933,7 +933,7 @@ static void acquire_buildinfo(void)
> 
>   /* Get ARM Trusted Firmware commit id */
>   arm_smccc_smc(IMX_SIP_BUILDINFO,
> IMX_SIP_BUILDINFO_GET_COMMITHASH,
> -   0, 0 , 0, 0, 0, 0, &res);
> +   0, 0, 0, 0, 0, 0, &res);
>   atf_commit = res.a0;
>   if (atf_commit == 0x) {
>   debug("ATF does not support build info\n");

Reviewed-by: Peng Fan 

> --
> 2.17.1



RE: [PATCH 1/2] imx8m: ddrphy_utils: Improve coding style

2020-07-19 Thread Peng Fan
> Subject: [PATCH 1/2] imx8m: ddrphy_utils: Improve coding style
> 
> Currently checkpatch is not happy about this file:
> 
> total: 14 errors, 2 warnings, 7 checks, 359 lines checked
> 
> Improve the coding style so that it can now report:
> 
> total: 0 errors, 0 warnings, 6 checks, 360 lines checked
> 
> Reported-by: Tom Rini 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/ddr/imx/imx8m/ddrphy_utils.c | 29 ++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> index 20ae47bfb5..0f8baefb1f 100644
> --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> -* Copyright 2018 NXP
> -*/
> + * Copyright 2018 NXP
> + */
> 
>  #include 
>  #include 
> @@ -201,7 +201,7 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank,
> unsigned int mr_addr)  }
> 
>  unsigned int look_for_max(unsigned int data[],
> -  unsigned int addr_start, unsigned int addr_end)
> +   unsigned int addr_start, unsigned int addr_end)
>  {
>   unsigned int i, imax = 0;
> 
> @@ -233,9 +233,9 @@ void get_trained_CDD(u32 fsp)
>   if (i == 0) {
>   cdd_cha[0] = (tmp >> 8) & 0xff;
>   } else if (i == 6) {
> - cdd_cha[11]=tmp & 0xff;
> + cdd_cha[11] = tmp & 0xff;
>   } else {
> - cdd_chb[ i * 2 - 1] = tmp & 0xff;
> + cdd_chb[i * 2 - 1] = tmp & 0xff;
>   cdd_chb[i * 2] = (tmp >> 8) & 0xff;
>   }
>   }
> @@ -254,7 +254,8 @@ void get_trained_CDD(u32 fsp)
>   g_cdd_ww_max[fsp] =  cdd_cha_ww_max > cdd_chb_ww_max ?
> cdd_cha_ww_max : cdd_chb_ww_max;
>   } else {
>   unsigned int ddr4_cdd[64];
> - for( i = 0; i < 29; i++) {
> +
> + for (i = 0; i < 29; i++) {
>   tmp = reg32_read(IP2APB_DDRPHY_IPS_BASE_ADDR(0) +
> (0x54012 + i) * 4);
>   ddr4_cdd[i * 2] = tmp & 0xff;
>   ddr4_cdd[i * 2 + 1] = (tmp >> 8) & 0xff; @@ -269,18 
> +270,18
> @@ void get_trained_CDD(u32 fsp)
> 
>  void update_umctl2_rank_space_setting(unsigned int pstat_num)  {
> - unsigned int i,ddr_type;
> + unsigned int i, ddr_type;
>   unsigned int addr_slot, rdata, tmp, tmp_t;
> - unsigned int ddrc_w2r,ddrc_r2w,ddrc_wr_gap,ddrc_rd_gap;
> + unsigned int ddrc_w2r, ddrc_r2w, ddrc_wr_gap, ddrc_rd_gap;
> 
>   ddr_type = reg32_read(DDRC_MSTR(0)) & 0x3f;
>   for (i = 0; i < pstat_num; i++) {
>   addr_slot = i ? (i + 1) * 0x1000 : 0;
>   if (ddr_type == 0x20) {
>   /* update r2w:[13:8], w2r:[5:0] */
> - rdata=reg32_read(DDRC_DRAMTMG2(0) + addr_slot);
> + rdata = reg32_read(DDRC_DRAMTMG2(0) + addr_slot);
>   ddrc_w2r = rdata & 0x3f;
> - if(is_imx8mp())
> + if (is_imx8mp())
>   tmp = ddrc_w2r + (g_cdd_wr_max[i] >> 1);
>   else
>   tmp = ddrc_w2r + (g_cdd_wr_max[i] >> 1) + 1; @@ 
> -297,7
> +298,7 @@ void update_umctl2_rank_space_setting(unsigned int pstat_num)
>   reg32_write((DDRC_DRAMTMG2(0) + addr_slot), tmp_t);
>   } else {
>   /* update w2r:[5:0] */
> - rdata=reg32_read(DDRC_DRAMTMG9(0) + addr_slot);
> + rdata = reg32_read(DDRC_DRAMTMG9(0) + addr_slot);
>   ddrc_w2r = rdata & 0x3f;
>   if (is_imx8mp())
>   tmp = ddrc_w2r + (g_cdd_wr_max[i] >> 1); @@ 
> -310,7
> +311,7 @@ void update_umctl2_rank_space_setting(unsigned int pstat_num)
>   /* update r2w:[13:8] */
>   rdata = reg32_read(DDRC_DRAMTMG2(0) + addr_slot);
>   ddrc_r2w = (rdata >> 8) & 0x3f;
> - if(is_imx8mp())
> + if (is_imx8mp())
>   tmp = ddrc_r2w + (g_cdd_rw_max[i] >> 1);
>   else
>   tmp = ddrc_r2w + (g_cdd_rw_max[i] >> 1) + 1; @@ 
> -324,7
> +325,7 @@ void update_umctl2_rank_space_setting(unsigned int pstat_num)
>   /* update rankctl: wr_gap:11:8; rd:gap:7:4; 
> quasi-dymic, doc
> wrong(static) */
>   rdata = reg32_read(DDRC_RANKCTL(0) + addr_slot);
>   ddrc_wr_gap = (rdata >> 8) & 0xf;
> - if(is_imx8mp())
> + if (is_imx8mp())
>   tmp = ddrc_wr_gap + (g_cdd_ww_max[i] >> 1);
>   else
>

Re: [PATCH v2 1/4] usb: xhci: Add missing endian conversions (cpu_to_leXX / leXX_to_cpu)

2020-07-19 Thread Bin Meng
Hi Stefan,

On Sat, Jul 18, 2020 at 2:22 AM Stefan Roese  wrote:
>
> Hi Bin,
>
> On 17.07.20 16:14, Bin Meng wrote:
> > Hi Stefan,
> >
> > On Fri, Jul 17, 2020 at 10:04 PM Stefan Roese  wrote:
> >>
> >> While trying to use the U-Boot xHCI driver on the MIPS Octeon platform,
> >> which is big endian, I noticed that the driver is missing a few endian
> >> conversion calls. This patch adds these missing endian conversion
> >> calls.
> >>
> >> Signed-off-by: Stefan Roese 
> >> Reviewed-by: Bin Meng 
> >> Cc: Bin Meng 
> >> Cc: Marek Vasut 
> >> ---
> >> v2:
> >> - Add missing (uintptr_t) cast to remove compile time warning
> >>
> >>   drivers/usb/host/xhci-mem.c | 9 +
> >>   1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > Tested-by: Bin Meng 
> >
> > Only this patch is sent as v2?
>
> Yes. I didn't want to pollute the list with unneeded patches. If you
> prefer a complete patchset in the new version, then I can of course
> do as as well.

IMHO it would be good for maintainers to apply this whole series from
patchwork in a batch if we send the complete series.

Regards,
Bin


Re: [PATCH v6 00/25] x86: Enhance MTRR functionality to support multiple CPUs

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:48 PM Simon Glass  wrote:
>
> At present MTRRs are mirrored to the secondary CPUs only once, as those
> CPUs are started up. But U-Boot may add more MTRRs later, e.g. if it
> decides that a video console must be set up.
>
> This series enhances the x86 multi-processor support to allow MTRRs to
> be updated at any time. It also updates the 'mtrr' command to support
> setting the MTRRs on CPUs other than the boot CPU.
>
> Changes in v6:
> - Rebase to x86/master
>
> Changes in v5:
> - Drop timing in mp_park_aps()
>

series applied to u-boot-x86, thanks!


Re: [PATCH] dm: core: Don't show an ACPI warning if there is no ordering

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 11:03 PM Bin Meng  wrote:
>
> On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
> >
> > Some boards don't care about the ordering of ACPI code fragments. Change
> > the warning to a debug message.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/core/acpi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


RE: [v2, 10/11] arm: dts: lx2160ardb: support eMMC HS400 mode

2020-07-19 Thread Peng Fan
> Subject: [v2, 10/11] arm: dts: lx2160ardb: support eMMC HS400 mode
> 
> Add properties related to eMMC HS400 mode.
> 
> mmc-hs400-1_8v;
> bus-width = <8>;
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> ---
>  arch/arm/dts/fsl-lx2160a-rdb.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/dts/fsl-lx2160a-rdb.dts
> b/arch/arm/dts/fsl-lx2160a-rdb.dts
> index d787778..5fbdd90 100644
> --- a/arch/arm/dts/fsl-lx2160a-rdb.dts
> +++ b/arch/arm/dts/fsl-lx2160a-rdb.dts
> @@ -80,6 +80,8 @@
>  &esdhc1 {
>   status = "okay";
>   mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + bus-width = <8>;

If kernel already has this, please add kernel commit.
If not, please use fsl-lx2160a-rdb-u-boot.dtsi to include.

Regards,
Peng.

>  };
> 
>  &fspi {
> --
> 2.7.4



RE: [v2, 07/11] mmc: fsl_esdhc: support eMMC HS400 mode

2020-07-19 Thread Peng Fan
> Subject: [v2, 07/11] mmc: fsl_esdhc: support eMMC HS400 mode
> 
> The process for eMMC HS400 mode for eSDHC is,
> 
> 1. Perform the Tuning Process at the HS400 target operating frequency.
>Latched the clock division value.
> 2. if read transaction, then set the SDTIMNGCTL[FLW_CTL_BG].
> 3. Switch to High Speed mode and then set the card clock frequency to
>a value not greater than 52Mhz
> 4. Clear TBCTL[TB_EN],tuning block enable bit.
> 5. Change to 8 bit DDR Mode
> 6. Switch the card to HS400 mode.
> 7. Set TBCTL[TB_EN], tuning block enable bit.
> 8. Clear SYSCTL[SDCLKEN]
> 9. Wait for PRSSTAT[SDSTB] to be set
> 10. Change the clock division to latched value.Set TBCTL[HS 400 mode]
> and Set SDCLKCTL[CMD_CLK_CTRL]
> 11. Set SYSCTL[SDCLKEN]
> 12. Wait for PRSSTAT[SDSTB] to be set
> 13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
> 14. Wait for delay chain to lock.
> 15. Set TBCTL[HS400_WNDW_ADJUST]
> 16. Again clear SYSCTL[SDCLKEN]
> 17. Wait for PRSSTAT[SDSTB] to be set
> 18. Set ESDHCCTL[FAF]
> 19. Wait for ESDHCCTL[FAF] to be cleared 20. Set SYSCTL[SDCLKEN] 21. Wait
> for PRSSTAT[SDSTB] to be set.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> ---
>  drivers/mmc/fsl_esdhc.c | 98
> -
>  include/fsl_esdhc.h | 12 ++
>  2 files changed, 76 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> 607b420..c1a127c 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -62,7 +62,12 @@ struct fsl_esdhc {
>   uinthostcapblt2;/* Host controller capabilities register 2 */
>   charreserved6[8];   /* reserved */
>   uinttbctl;  /* Tuning block control register */
> - charreserved7[744]; /* reserved */
> + charreserved7[32];  /* reserved */
> + uintsdclkctl;   /* SD clock control register */
> + uintsdtimingctl;/* SD timing control register */
> + charreserved8[20];  /* reserved */
> + uintdllcfg0;/* DLL config 0 register */
> + charreserved9[680]; /* reserved */
>   uintesdhcctl;   /* eSDHC control register */
>  };
> 
> @@ -568,6 +573,38 @@ static void esdhc_clock_control(struct
> fsl_esdhc_priv *priv, bool enable)
>   }
>  }
> 
> +static void esdhc_flush_async_fifo(struct fsl_esdhc_priv *priv) {
> + struct fsl_esdhc *regs = priv->esdhc_regs;
> + u32 time_out;
> +
> + esdhc_setbits32(®s->esdhcctl, ESDHCCTL_FAF);
> +
> + time_out = 20;
> + while (esdhc_read32(®s->esdhcctl) & ESDHCCTL_FAF) {
> + if (time_out == 0) {
> + printf("fsl_esdhc: Flush asynchronous FIFO timeout.\n");
> + break;
> + }
> + time_out--;
> + mdelay(1);
> + }
> +}
> +
> +static void esdhc_tuning_block_enable(struct fsl_esdhc_priv *priv,
> +   bool en)
> +{
> + struct fsl_esdhc *regs = priv->esdhc_regs;
> +
> + esdhc_clock_control(priv, false);
> + esdhc_flush_async_fifo(priv);
> + if (en)
> + esdhc_setbits32(®s->tbctl, TBCTL_TB_EN);
> + else
> + esdhc_clrbits32(®s->tbctl, TBCTL_TB_EN);
> + esdhc_clock_control(priv, true);
> +}
> +
>  static void esdhc_set_timing(struct fsl_esdhc_priv *priv, enum bus_mode
> mode)  {
>   struct fsl_esdhc *regs = priv->esdhc_regs; @@ -577,7 +614,17 @@
> static void esdhc_set_timing(struct fsl_esdhc_priv *priv, enum bus_mode
> mode)
>   if (mode == MMC_HS_200)
>   esdhc_clrsetbits32(®s->autoc12err, UHSM_MASK,
>  UHSM_SDR104_HS200);
> + if (mode == MMC_HS_400) {
> + esdhc_setbits32(®s->tbctl, HS400_MODE);
> + esdhc_setbits32(®s->sdclkctl, CMD_CLK_CTL);
> + esdhc_clock_control(priv, true);
> 
> + esdhc_setbits32(®s->dllcfg0, DLL_ENABLE | DLL_FREQ_SEL);
> + esdhc_setbits32(®s->tbctl, HS400_WNDW_ADJUST);
> +
> + esdhc_clock_control(priv, false);
> + esdhc_flush_async_fifo(priv);
> + }
>   esdhc_clock_control(priv, true);
>  }
> 
> @@ -592,6 +639,9 @@ static int esdhc_set_ios_common(struct
> fsl_esdhc_priv *priv, struct mmc *mmc)
>   esdhc_clock_control(priv, true);
>   }
> 
> + if (mmc->selected_mode == MMC_HS_400)
> + esdhc_tuning_block_enable(priv, true);
> +
>   /* Set the clock speed */
>   if (priv->clock != mmc->clock)
>   set_sysctl(priv, mmc, mmc->clock);
> @@ -987,38 +1037,6 @@ static int fsl_esdhc_reinit(struct udevice *dev)  }
> 
>  #ifdef MMC_SUPPORTS_TUNING
> -static void esdhc_flush_async_fifo(struct fsl_esdhc_priv *priv) -{
> - struct fsl_esdhc *regs = priv->esdhc_regs;
> - u32 time_out;
> -
> - esdhc_setbits32(®s->esdhcctl, ESDHCCTL_FAF);
> -
> - time_out = 20;
> - while (esdhc_read32(®s->esdhcctl) & ESDHCCTL_F

RE: [v2, 06/11] mmc: add a mmc_hs400_prepare_ddr() interface

2020-07-19 Thread Peng Fan
> Subject: [v2, 06/11] mmc: add a mmc_hs400_prepare_ddr() interface
> 
> Add a mmc_hs400_prepare_ddr() interface for controllers which needs
> preparation before switching to DDR mode for
> HS400 mode.

This is LSx specific? If yes, could this be done in fsl_esdhc.c?

Thanks,
Peng.

> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> ---
>  drivers/mmc/mmc-uclass.c | 15 +++
>  drivers/mmc/mmc.c|  2 ++
>  include/mmc.h| 15 ++-
>  3 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index
> b9f0880..240b205 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -141,6 +141,21 @@ int mmc_set_enhanced_strobe(struct mmc
> *mmc)  }  #endif
> 
> +int dm_mmc_hs400_prepare_ddr(struct udevice *dev) {
> + struct dm_mmc_ops *ops = mmc_get_ops(dev);
> +
> + if (ops->hs400_prepare_ddr)
> + return ops->hs400_prepare_ddr(dev);
> +
> + return 0;
> +}
> +
> +int mmc_hs400_prepare_ddr(struct mmc *mmc) {
> + return dm_mmc_hs400_prepare_ddr(mmc->dev);
> +}
> +
>  int dm_mmc_host_power_cycle(struct udevice *dev)  {
>   struct dm_mmc_ops *ops = mmc_get_ops(dev); diff --git
> a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index a18e75d..e396207
> 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1987,6 +1987,8 @@ static int mmc_select_hs400(struct mmc *mmc)
>   /* Set back to HS */
>   mmc_set_card_speed(mmc, MMC_HS, true);
> 
> + mmc_hs400_prepare_ddr(mmc);
> +
>   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_BUS_WIDTH,
>EXT_CSD_BUS_WIDTH_8 | EXT_CSD_DDR_FLAG);
>   if (err)
> diff --git a/include/mmc.h b/include/mmc.h index 2399cc2..659df75 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -513,6 +513,14 @@ struct dm_mmc_ops {
>* @return maximum number of blocks for this transfer
>*/
>   int (*get_b_max)(struct udevice *dev, void *dst, lbaint_t blkcnt);
> +
> + /**
> +  * hs400_prepare_ddr - prepare to switch to DDR mode
> +  *
> +  * @dev:Device to check
> +  * @return 0 if success, -ve on error
> +  */
> + int (*hs400_prepare_ddr)(struct udevice *dev);
>  };
> 
>  #define mmc_get_ops(dev)((struct dm_mmc_ops
> *)(dev)->driver->ops)
> @@ -540,7 +548,7 @@ int mmc_host_power_cycle(struct mmc *mmc);  int
> mmc_deferred_probe(struct mmc *mmc);  int mmc_reinit(struct mmc
> *mmc);  int mmc_get_b_max(struct mmc *mmc, void *dst, lbaint_t blkcnt);
> -
> +int mmc_hs400_prepare_ddr(struct mmc *mmc);
>  #else
>  struct mmc_ops {
>   int (*send_cmd)(struct mmc *mmc,
> @@ -552,6 +560,11 @@ struct mmc_ops {
>   int (*host_power_cycle)(struct mmc *mmc);
>   int (*get_b_max)(struct mmc *mmc, void *dst, lbaint_t blkcnt);  };
> +
> +static inline int mmc_hs400_prepare_ddr(struct mmc *mmc) {
> + return 0;
> +}
>  #endif
> 
>  struct mmc_config {
> --
> 2.7.4



RE: [v2, 05/11] mmc: add a hs400_tuning flag

2020-07-19 Thread Peng Fan
> Subject: [v2, 05/11] mmc: add a hs400_tuning flag
> 
> Add a hs400_tuning flag to identify the tuning for HS400 mode.

Why? Please explain a bit more.

Thanks,
Peng.

> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> ---
>  drivers/mmc/mmc.c | 2 ++
>  include/mmc.h | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> a53f93a..a18e75d 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1976,7 +1976,9 @@ static int mmc_select_hs400(struct mmc *mmc)
>   mmc_set_clock(mmc, mmc->tran_speed, false);
> 
>   /* execute tuning if needed */
> + mmc->hs400_tuning = 1;
>   err = mmc_execute_tuning(mmc,
> MMC_CMD_SEND_TUNING_BLOCK_HS200);
> + mmc->hs400_tuning = 0;
>   if (err) {
>   debug("tuning failed\n");
>   return err;
> diff --git a/include/mmc.h b/include/mmc.h index 161b8bc..2399cc2 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -707,6 +707,7 @@ struct mmc {
> * accessing the boot partitions
> */
>   u32 quirks;
> + u8 hs400_tuning;
>  };
> 
>  struct mmc_hwpart_conf {
> --
> 2.7.4



RE: [v2, 01/11] mmc: add a reinit() API

2020-07-19 Thread Peng Fan
> Subject: [v2, 01/11] mmc: add a reinit() API
> 
> For DM_MMC, the controller re-initialization is needed to clear old
> configuration for mmc rescan.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> ---
>  drivers/mmc/mmc-uclass.c | 15 +++
>  drivers/mmc/mmc.c|  8 ++--
>  include/mmc.h| 10 ++
>  3 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index
> c5b7872..b9f0880 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -170,6 +170,21 @@ int mmc_deferred_probe(struct mmc *mmc)
>   return dm_mmc_deferred_probe(mmc->dev);  }
> 
> +int dm_mmc_reinit(struct udevice *dev)
> +{
> + struct dm_mmc_ops *ops = mmc_get_ops(dev);
> +
> + if (ops->reinit)
> + return ops->reinit(dev);
> +
> + return 0;
> +}
> +
> +int mmc_reinit(struct mmc *mmc)
> +{
> + return dm_mmc_reinit(mmc->dev);
> +}
> +
>  int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg)  {
>   int val;
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> 50f47d4..a53f93a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2813,13 +2813,17 @@ int mmc_get_op_cond(struct mmc *mmc)
>   return err;
> 
>  #if CONFIG_IS_ENABLED(DM_MMC)
> - /* The device has already been probed ready for use */
> + /*
> +  * Re-initialization is needed to clear old configuration for
> +  * mmc rescan.

You mean cmd "mmc rescan" ?

> +  */
> + err = mmc_reinit(mmc);

Probe could not provide what you need? You need a different settings?

Regards,
Peng.

>  #else
>   /* made sure it's not NULL earlier */
>   err = mmc->cfg->ops->init(mmc);
> +#endif
>   if (err)
>   return err;
> -#endif
>   mmc->ddr_mode = 0;
> 
>  retry:
> diff --git a/include/mmc.h b/include/mmc.h index 8256219..161b8bc 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -422,6 +422,14 @@ struct dm_mmc_ops {
>*/
>   int (*deferred_probe)(struct udevice *dev);
>   /**
> +  * reinit() - Re-initialization to clear old configuration for
> +  * mmc rescan.
> +  *
> +  * @dev:Device to reinit
> +  * @return 0 if Ok, -ve if error
> +  */
> + int (*reinit)(struct udevice *dev);
> + /**
>* send_cmd() - Send a command to the MMC device
>*
>* @dev:Device to receive the command
> @@ -518,6 +526,7 @@ int dm_mmc_execute_tuning(struct udevice *dev,
> uint opcode);  int dm_mmc_wait_dat0(struct udevice *dev, int state, int
> timeout_us);  int dm_mmc_host_power_cycle(struct udevice *dev);  int
> dm_mmc_deferred_probe(struct udevice *dev);
> +int dm_mmc_reinit(struct udevice *dev);
>  int dm_mmc_get_b_max(struct udevice *dev, void *dst, lbaint_t blkcnt);
> 
>  /* Transition functions for compatibility */ @@ -529,6 +538,7 @@ int
> mmc_wait_dat0(struct mmc *mmc, int state, int timeout_us);  int
> mmc_set_enhanced_strobe(struct mmc *mmc);  int
> mmc_host_power_cycle(struct mmc *mmc);  int
> mmc_deferred_probe(struct mmc *mmc);
> +int mmc_reinit(struct mmc *mmc);
>  int mmc_get_b_max(struct mmc *mmc, void *dst, lbaint_t blkcnt);
> 
>  #else
> --
> 2.7.4



Re: [PATCH v6 25/25] x86: mtrr: Enhance 'mtrr' command to list MTRRs on any CPU

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
>
> Update this command so it can list the MTRRs on a selected CPU. If
> '-c all' is used, then all CPUs are listed.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Wolfgang Wallner 
> ---
>
> Changes in v6:
> - Rebase to x86/master
>
>  cmd/x86/mtrr.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 


Re: [PATCH v6 19/25] x86: mtrr: Update MTRRs on all CPUs

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
>
> When the boot CPU MTRRs are updated, perform the same update on all other
> CPUs so they are kept in sync.
>
> This avoids kernel warnings about mismatched MTRRs.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Wolfgang Wallner 
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Rename function to mtrr_write_all()
>
>  arch/x86/cpu/mtrr.c | 57 +
>  1 file changed, 57 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v6 15/25] x86: mp: Add iterators for CPUs

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
>
> It is convenient to iterate through the CPUs performing work on each one
> and processing the result. Add a few iterator functions which handle this.
> These can be used by any client code. It can call mp_run_on_cpus() on
> each CPU that is returned, handling them one at a time.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Wolfgang Wallner 
> ---
>
> (no changes since v4)
>
> Changes in v4:
> - Update mp_next_cpu() to stop if CONFIG_SMP_AP_WORK is not enabled
>
> Changes in v3:
> - Add more comments on how the iterators work
>
>  arch/x86/cpu/mp_init.c| 63 +++
>  arch/x86/include/asm/mp.h | 42 ++
>  2 files changed, 105 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v6 13/25] x86: mp: Allow running functions on multiple CPUs

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
>
> Add a way to run a function on a selection of CPUs. This supports either
> a single CPU, all CPUs, just the main CPU or just the 'APs', in Intel
> terminology.
>
> It works by writing into a mailbox and then waiting for the CPUs to notice
> it, take action and indicate they are done.
>
> When SMP is not yet enabled, this just calls the function on the main CPU.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Wolfgang Wallner 
> ---
>
> (no changes since v4)
>
> Changes in v4:
> - Only enable this feature of CONFIG_SMP_AP_WORK is enabled
> - Allow running on the BSP if SMP is not enabled
>
> Changes in v3:
> - Add a comment to run_ap_work()
> - Rename flag to GD_FLG_SMP_READY
> - Update the comment for run_ap_work() to explain logical_cpu_number
> - Clarify meaning of @cpu_select in mp_run_on_cpus() comment
>
>  arch/x86/cpu/mp_init.c| 107 +++---
>  arch/x86/include/asm/mp.h |  33 
>  2 files changed, 134 insertions(+), 6 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v6 14/25] x86: mp: Park CPUs before running the OS

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
>
> With the new MP features the CPUs are no-longer parked when the OS is run.
> Fix this by calling a special function to park them, just before the OS is
> started.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Wolfgang Wallner 
> ---
>
> (no changes since v5)
>
> Changes in v5:
> - Drop timing in mp_park_aps()
>
> Changes in v3:
> - Update the comment for mp_park_aps()
>
>  arch/x86/cpu/cpu.c|  5 +
>  arch/x86/cpu/mp_init.c| 16 
>  arch/x86/include/asm/mp.h | 17 +
>  3 files changed, 38 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v6 11/25] global_data: Add a generic global_data flag for SMP state

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
>
> Allow keeping track of whether all CPUs have been enabled yet. This allows
> us to know whether other CPUs need to be considered when updating
> CPU-specific settings such as MTRRs on x86.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Wolfgang Wallner 
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rename flag to GD_FLG_SMP_READY
>
>  include/asm-generic/global_data.h | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v6 10/25] x86: mp: Support APs waiting for instructions

2020-07-19 Thread Bin Meng
On Fri, Jul 17, 2020 at 10:49 PM Simon Glass  wrote:
>
> At present the APs (non-boot CPUs) are inited once and then parked ready
> for the OS to use them. However in some cases we want to send new requests
> through, such as to change MTRRs and keep them consistent across CPUs.
>
> Change the last state of the flight plan to go into a wait loop, accepting
> instructions from the main CPU.
>
> Drop cpu_map since it is not used.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Wolfgang Wallner 
> ---
>
> (no changes since v4)
>
> Changes in v4:
> - Add a Kconfig to control this feature, enabled only on APL
>
> Changes in v3:
> - s/slow/slot/
> - Use C code instead of assembler to read/write callback pointers
> - Update commit message to mention dropping of cpu_map
>
> Changes in v2:
> - Add more comments
>
>  arch/x86/Kconfig|   7 ++
>  arch/x86/cpu/apollolake/Kconfig |   1 +
>  arch/x86/cpu/mp_init.c  | 123 +---
>  arch/x86/include/asm/mp.h   |  11 +++
>  4 files changed, 134 insertions(+), 8 deletions(-)
>

Reviewed-by: Bin Meng 


RE: am654_sdhci: mmc fail to send stop cmd

2020-07-19 Thread Peng Fan
Hi Jan,

> Subject: am654_sdhci: mmc fail to send stop cmd
> 
> Hi all,
> 
> on one device with one specific SD-card (possibly an aging one), I'm seeing
> frequent "mmc fail to send stop cmd" messages, followed by read errors
> when loading kernel and dtb. -ETIMEDOUT is returned by mmd_send_cmd.
> However, I can always resolve this by simply retrying the stop command like
> this:
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> f36d11ddc8..9019d9f2ed 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -406,7 +406,11 @@ static int mmc_read_blocks(struct mmc *mmc, void
> *dst, lbaint_t start,  #if !defined(CONFIG_SPL_BUILD) ||
> defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
>   pr_err("mmc fail to send stop cmd\n");  #endif
> - return 0;
> + pr_err("retrying...\n");
> + if (mmc_send_cmd(mmc, &cmd, NULL)) {
> + pr_err("failed again\n");
> + return 0;
> + }
>   }
>   }
> 
> 
> Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
> board-enabling and a bunch of patches from your tree [1]. However, already
> 4d6da10ce611 exposes the problem.
> 
> What could cause this?

Where the timeout happen in driver?

Did you try enlarge the timeout value? 

Regards,
Peng.

> 
> Jan
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fsiemens%2Fu-boot%2Fcommits%2Fjan%2Fiot2050&data=02%7
> C01%7CPeng.Fan%40nxp.com%7Cda088100ee5a46cdc37008d82b29779f%7
> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63730680439552710
> 6&sdata=oiS6nOxxAQykjMyTecz%2FTJY4OW8WiZ2CbszR2mBrXuI%3D&
> amp;reserved=0


Re: [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman

2020-07-19 Thread Bin Meng
Hi Simon,

On Mon, Jul 20, 2020 at 3:56 AM Simon Glass  wrote:
>
> Rockchip-based Chromebooks support booting from SPI flash. It is annoying
> to have to manually build the SPI image when the SD image is built
> automatically.
>
> This feature is already available for x86 devices, so the existing
> mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
> to be provided to indicate that any required binary blobs are present and
> it is safe to build the ROM.
>
> A new 'mkimage' type is added to binman to support building binaries
> containing mkimagem using a binman definition to configure it. This avoids
> Makefile/shell/Python code to do the same thing.
>
> This series also migrates some rockchip boards to use binman to produce
> their FIT as well, resulting in removing the fit_spl_optee.sh script.
>
> Other archs and the rest of rockchip could be migrated too.
>
> This series uses binman to produce a ROM image on two selected
> Chromebooks, Bob (RK3399) and Jerry (RK3388).
>
> Changes in v4:
> - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> - Update for changes to arch/arm/mach-k3/config.mk
> - Move the .itb output to a separate rockchip-optee.dtsi file
> - Add a check for CONFIG_FIT before building the .its
>
> Changes in v3:
> - Add a comment about CONFIG_SPL_FRAMEWORK
> - Drop rockchip changes which should not be in this patch
> - Move in the rockchip changes mistakenly in the earlier x86 patch
> - Drop use of rk322x.dtsi
> - Add changes to rk3288-u-boot.dtsi instead
> - Drop leftover debugging

It looks you have applied part of the v3 in u-boot-dm, and sent the
remaining patches as v4?

I re-assigned this series to you in patchwork.

Regards,
Bin


Re: [PATCH v2 8/8] test: dm: add a test for class button

2020-07-19 Thread Simon Glass
Hi Philippe,

On Fri, 17 Jul 2020 at 06:22, Philippe Reynes
 wrote:
>
> Add a test to confirm that we can read button state
> using the button-gpio driver.
>
> Signed-off-by: Philippe Reynes 
> ---
> Changelog:
> v2:
> - new commit in the serie
>
>  test/dm/Makefile |  1 +
>  test/dm/button.c | 74 
> 
>  2 files changed, 75 insertions(+)
>  create mode 100644 test/dm/button.c

This seems to fail with 'make qcheck'. Can you please take a look?
I've left it unapplied for now.

Regards,
Simon


Re: [RFC PATCH 03/16] patman: Add a test that uses gitpython

2020-07-19 Thread Simon Glass
It is convenient to use gitpython to create a real git repo for testing
patman's operation. Add a test for this. So far it just checks that patman
produces the right number of patches for a branch.

Signed-off-by: Simon Glass 
---

 tools/patman/func_test.py | 151 +-
 tools/patman/tools.py |   4 +-
 2 files changed, 152 insertions(+), 3 deletions(-)

Applied to u-boot-dm


Re: [RFC PATCH 06/16] patman: Convert to ArgumentParser

2020-07-19 Thread Simon Glass
Convert from OptionParser to ArgumentParser to match binman. With this we
can easily add sub-commands.

Signed-off-by: Simon Glass 
---

 tools/patman/control.py  | 22 -
 tools/patman/main.py | 97 
 tools/patman/settings.py | 10 +++--
 3 files changed, 65 insertions(+), 64 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 02/49] .gitignore: Ignore Python 3 cache directories

2020-07-19 Thread Simon Glass
These can appear when moving between branches that have different tools
in the tree. Ignore them.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 .gitignore | 3 +++
 1 file changed, 3 insertions(+)

Applied to u-boot-dm


Re: [PATCH v3 05/49] binman: Correct the search patch for pylibfdt

2020-07-19 Thread Simon Glass
Now that binman uses tools/ as its base directory for importing modules,
the path to the pylibfdt build by U-Boot is incorrect. Fix it with a new
path.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v2)

Changes in v2:
- Leave the old (object-directory) path in place

 tools/binman/main.py | 1 +
 1 file changed, 1 insertion(+)

Applied to u-boot-dm


Re: [RFC PATCH 09/16] patman: Allow disabling 'bright' mode with Print output

2020-07-19 Thread Simon Glass
At present all text is marked bright, which makes it stand out on the
terminal. Add a way to disable that, as is done with the Color class.

Signed-off-by: Simon Glass 
---

 tools/patman/terminal.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 01/49] dm: core Fix long line in device_bind_common()

2020-07-19 Thread Simon Glass
Fix an over-length line in this function.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 drivers/core/device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Applied to u-boot-dm


Re: [PATCH v3 08/49] binman: Add support for calling mkimage

2020-07-19 Thread Simon Glass
As a first step to integrating mkimage into binman, add a new entry type
that feeds data into mkimage for processing and incorporates that output
into the image.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 tools/binman/README.entries   | 23 
 tools/binman/etype/_testing.py|  5 +++
 tools/binman/etype/mkimage.py | 62 +++
 tools/binman/ftest.py |  7 
 tools/binman/test/156_mkimage.dts | 23 
 5 files changed, 120 insertions(+)
 create mode 100644 tools/binman/etype/mkimage.py
 create mode 100644 tools/binman/test/156_mkimage.dts

Applied to u-boot-dm


Re: [PATCH v3 04/49] binman: cbfs: Fix IFWI typo

2020-07-19 Thread Simon Glass
This comment references the wrong thing. Fix it.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 tools/binman/etype/cbfs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm


Re: [PATCH v3 03/49] binman: Output errors to stderr

2020-07-19 Thread Simon Glass
At present binman outputs errors to stdout which means that fails are
effectively silent when printed by buildman, for example. Fix this by
outputing errors to stderr.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v2)

Changes in v2:
- Add new binman patch to output errors to stderr

 tools/binman/main.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm


Re: [RFC PATCH 10/16] patman: Support collecting response tags in Patchstream

2020-07-19 Thread Simon Glass
Collect response tags such as 'Reviewed-by' while parsing the stream.
This allows us to see what tags are present.

Add a new 'Fixes' tag also, since this is now quite common.

Signed-off-by: Simon Glass 
---

 tools/patman/commit.py  | 14 ++
 tools/patman/patchstream.py | 21 -
 2 files changed, 30 insertions(+), 5 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 17/49] binman: Detect when valid images are not produced

2020-07-19 Thread Simon Glass
When external blobs are missing, show a message indicating that the images
are not functional.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Move the SetAllowMissing() function into an earlier patch

 tools/binman/control.py   | 16 +++--
 tools/binman/entry.py | 12 ++
 tools/binman/etype/blob_ext.py|  1 +
 tools/binman/etype/section.py | 12 ++
 tools/binman/ftest.py | 14 ++-
 .../binman/test/159_blob_ext_missing_sect.dts | 23 +++
 tools/patman/tout.py  |  1 +
 7 files changed, 76 insertions(+), 3 deletions(-)
 create mode 100644 tools/binman/test/159_blob_ext_missing_sect.dts

Applied to u-boot-dm


Re: [PATCH v3 15/49] binman: Allow external binaries to be missing

2020-07-19 Thread Simon Glass
Sometimes it is useful to build an image even though external binaries are
not present. This allows the build system to continue to function without
these files, albeit not producing valid images.

U-Boot does with with ATF (ARM Trusted Firmware) today.

Add a new flag to binman to request this behaviour.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v3:
- Move the SetAllowMissing() function into this patch
- Keep the _allow_missing property to sections only

 tools/binman/README.entries|  3 +++
 tools/binman/cmdline.py|  2 ++
 tools/binman/control.py|  7 +--
 tools/binman/entry.py  |  9 +
 tools/binman/etype/blob_ext.py | 13 ++---
 tools/binman/etype/section.py  | 24 
 tools/binman/ftest.py  |  8 +++-
 tools/patman/tools.py  |  8 ++--
 8 files changed, 66 insertions(+), 8 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 18/49] binman: Allow missing Intel blobs

2020-07-19 Thread Simon Glass
Update the Intel blob entries to support missing binaries.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 tools/binman/etype/intel_descriptor.py |  7 -
 tools/binman/etype/intel_ifwi.py   | 17 ---
 tools/binman/etype/section.py  |  4 +--
 tools/binman/ftest.py  | 41 +-
 4 files changed, 55 insertions(+), 14 deletions(-)

Applied to u-boot-dm


Re: [RFC PATCH 04/16] patman: Allow creating patches for another branch

2020-07-19 Thread Simon Glass
Add a -b option to allow patches to be created from a branch other than
the current one.

Signed-off-by: Simon Glass 
---

 tools/patman/control.py | 13 -
 tools/patman/func_test.py   | 13 +++--
 tools/patman/gitutil.py | 19 ++-
 tools/patman/main.py|  2 ++
 tools/patman/patchstream.py |  8 +---
 5 files changed, 40 insertions(+), 15 deletions(-)

Applied to u-boot-dm


Re: [RFC PATCH 07/16] patman: Allow different commands

2020-07-19 Thread Simon Glass
At present patman only does one thing so does not have any comments. We
want to add a few more command, so create a sub-parser for the default
command ('send').

Signed-off-by: Simon Glass 
---

 tools/patman/main.py | 77 +++-
 1 file changed, 41 insertions(+), 36 deletions(-)

Applied to u-boot-dm


Re: [RFC PATCH 08/16] patman: Add a 'test' subcommand

2020-07-19 Thread Simon Glass
At present we use --test to indicate that tests should be run. It is
better to use a subcommand for list, like binman. Change it and adjust
the existing code to fit under a 'send' subcommand, the default.

Give this subcommand the same default arguments as the others.

Signed-off-by: Simon Glass 
---

 .azure-pipelines.yml  |  2 +-
 .gitlab-ci.yml|  2 +-
 .travis.yml   |  2 +-
 test/run  |  2 +-
 tools/patman/main.py  | 75 +--
 tools/patman/test_util.py |  2 +-
 6 files changed, 45 insertions(+), 40 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 14/49] binman: Convert existing binary blobs to blob_ext

2020-07-19 Thread Simon Glass
Many of the existing blobs rely on external binaries which may not be
available. Move them over to use blob_ext to indicate this.

Unfortunately cros-ec-rw cannot use this class because it inherits
another. So set the 'external' value for that class.

While we are here, drop the import of Entry since it is not used (and
pylint3 complains).

Signed-off-by: Simon Glass 
---

Changes in v3:
- Update commit message to explain cros_ec_rw and mention dropping Entry

 tools/binman/etype/cros_ec_rw.py  | 1 +
 tools/binman/etype/intel_cmc.py   | 5 ++---
 tools/binman/etype/intel_descriptor.py| 4 ++--
 tools/binman/etype/intel_fit.py   | 4 ++--
 tools/binman/etype/intel_fit_ptr.py   | 4 ++--
 tools/binman/etype/intel_fsp.py   | 5 ++---
 tools/binman/etype/intel_fsp_m.py | 5 ++---
 tools/binman/etype/intel_fsp_s.py | 5 ++---
 tools/binman/etype/intel_fsp_t.py | 5 ++---
 tools/binman/etype/intel_ifwi.py  | 4 ++--
 tools/binman/etype/intel_me.py| 5 ++---
 tools/binman/etype/intel_mrc.py   | 5 ++---
 tools/binman/etype/intel_refcode.py   | 5 ++---
 tools/binman/etype/intel_vbt.py   | 5 ++---
 tools/binman/etype/intel_vga.py   | 5 ++---
 tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py | 1 -
 16 files changed, 29 insertions(+), 39 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 07/49] binman: Set a default toolpath

2020-07-19 Thread Simon Glass
When binman is run from 'make check' it is given a toolpath so that the
latest tools (e.g. mkimage) are used. When run manually with no toolpath,
it relies on the system mkimage. But this may be missing or old.

Make some effort to find the built-from-soruce version by looking in the
current directory and in the builds created by 'make check'.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Set a default toolpath for ease of use

 tools/binman/main.py | 5 +
 1 file changed, 5 insertions(+)

Applied to u-boot-dm


Re: [PATCH v3 06/49] binman: Specify the toolpath when running test coverage

2020-07-19 Thread Simon Glass
At present binman's test coverage runs without a toolpath set. This means
that the system tools will be used. That may not be correct if they are
out of date or missing and this can result in a reduction in test coverage
below 100%.

Provide the toolpath to binman in this case.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 tools/binman/main.py  | 10 +++---
 tools/patman/test_util.py |  9 ++---
 2 files changed, 13 insertions(+), 6 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 09/49] binman: Fix a few typos in the entry docs

2020-07-19 Thread Simon Glass
Some typos have been fixed in the generated entry docs but the code was
not updated. Fix this.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Fix the code rather than breaking the README

 tools/binman/etype/intel_me.py| 2 +-
 tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 20/49] mkimage: Allow updating the FIT timestamp

2020-07-19 Thread Simon Glass
Normally the FIT timestamp is created the first time mkimage is run on a
FIT, when converting the source .its to the binary .fit file. This
corresponds to using the -f flag. But if the original input to mkimage is
a binary file (already compiled) then the timestamp is assumed to have
been set previously.

Add a -t flag to allow setting the timestamp in this case.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 doc/mkimage.1 | 9 +
 tools/fit_image.c | 2 +-
 tools/imagetool.h | 1 +
 tools/mkimage.c   | 5 -
 4 files changed, 15 insertions(+), 2 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 19/49] binman: Allow zero-length entries to overlap

2020-07-19 Thread Simon Glass
Some binary blobs unfortunately obtain their position in the image from
other binary blobs, such as Intel's 'descriptor'. In this case we cannot
rely on packing to work. It is not possible to produce a valid image in
any case, due to the missing blobs.

Allow zero-length overlaps so that this does not cause any problems.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 tools/binman/etype/section.py   |  2 +-
 tools/binman/ftest.py   |  4 
 tools/binman/test/160_pack_overlap_zero.dts | 18 ++
 3 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 tools/binman/test/160_pack_overlap_zero.dts

Applied to u-boot-dm


Re: [PATCH v3 22/49] binman: Add support for generating a FIT

2020-07-19 Thread Simon Glass
FIT (Flat Image Tree) is the main image format used by U-Boot. In some
cases scripts are used to create FITs within the U-Boot build system. This
is not ideal for various reasons:

- Each architecture has its own slightly different script
- There are no tests
- Some are written in shell, some in Python

To help address this, add support for FIT generation to binman. This works
by putting the FIT source directly in the binman definition, with the
ability to adjust parameters, etc. The contents of each FIT image come
from sub-entries of the image, as is normal with binman.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 tools/binman/README.entries|  40 ++
 tools/binman/etype/fit.py  | 164 +
 tools/binman/ftest.py  |  54 
 tools/binman/test/161_fit.dts  |  62 ++
 tools/binman/test/162_fit_external.dts |  64 ++
 5 files changed, 384 insertions(+)
 create mode 100644 tools/binman/etype/fit.py
 create mode 100644 tools/binman/test/161_fit.dts
 create mode 100644 tools/binman/test/162_fit_external.dts

Applied to u-boot-dm


Re: [RFC PATCH 05/16] patman: Allow skipping patches at the end

2020-07-19 Thread Simon Glass
The -s option allows skipping patches at the top of the branch. Sometimes
there are commits at the bottom that need to be skipped. At present it is
necessary to count the number of commits and then use -c to tell patman
how many to process.

Add a -e option to easily skip a number of commits at the bottom of the
branch.

Signed-off-by: Simon Glass 
---

 tools/patman/control.py   |  8 +---
 tools/patman/func_test.py | 13 +++--
 tools/patman/main.py  |  2 ++
 3 files changed, 18 insertions(+), 5 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 16/49] patman: Update errors and warnings to use stderr

2020-07-19 Thread Simon Glass
When warnings and errors are produced by tools they should be written to
stderr. Update the tout implementation to handle this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 tools/binman/ftest.py | 2 +-
 tools/patman/tout.py  | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

Applied to u-boot-dm


Re: [RFC PATCH 02/16] patman: Move main code out to a control module

2020-07-19 Thread Simon Glass
To make testing easier, move the code out from main into a separate
'control' module and split it into four parts: setup, preparing patches,
checking patches and emailing patches.

Add comments and fix a few code-style issues while we are here.

Signed-off-by: Simon Glass 
---

 tools/patman/checkpatch.py |   6 ++
 tools/patman/control.py| 170 +
 tools/patman/gitutil.py|   4 +-
 tools/patman/main.py   |  57 +
 tools/patman/series.py |   2 +-
 5 files changed, 182 insertions(+), 57 deletions(-)
 create mode 100644 tools/patman/control.py

Applied to u-boot-dm


Re: [RFC PATCH 01/16] patman: Use test_util to show test results

2020-07-19 Thread Simon Glass
On Tue, 2020-07-07 at 11:09 +1000, Daniel Axtens wrote:
> Simon Glass  writes:
>
> > Hi Daniel,
> >
> > On Sun, 5 Jul 2020 at 22:50, Daniel Axtens  wrote:
> > > Daniel Axtens  writes:
> > >
> > > > Hi Simon,
> > > >
> > > > I can't see a cover letter so apologies if I've misunderstood something
> > > > basic, but this doesn't appear to apply to the patchwork tree - I'm
> > > > guessing the patchwork relevance is with regards to the last few patches
> > > > that (AFAICT) parse the patchwork web interface for information?
> > >
> > > Ah, nevermind, the cover letter got caught in moderation. I've released 
> > > it.
> > >
> > > pwclient speaks the old, less documented XML-RPC API. We have a new
> > > REST API which is much better documented, and is explorable
> > > (e.g. https://patchwork.ozlabs.org/api/ and
> > > https://patchwork.readthedocs.io/en/latest/api/rest/ )
> > >
> > > > I haven't fully digested the patches (and I lack a lot of context) but
> > > > is there a reason the patchwork API isn't able to meet your needs here?
> > > > (And if so, could we extend it rather than having you parse the 
> > > > frontend?)
> > >
> > > So these questions still stand but for the REST API.
> >
> > So use the REST API instead of the web page? That sounds fine to me.
> > Is it generally enabled on patchwork servers?
>
> I mean patman is your code so it's ultimately not my call :P But yes,
> I'd strongly prefer you used the REST API! It is enabled on ozlabs.org
> and kernel.org and has been for a while (~a couple of years).
>
> > What is the status of pwclient? Is it dead? Is there a replacement?
> > I'd love to use a Python library if one exists.
>
> Stephen F is the expert on the client stuff, so I'm not going to make a
> call on the status of pwclient. All I am confident to say is that I have
> migrated to using 'git-pw' and I recommend others do so to too.

pwclient is alive and won't be going anywhere, but it's still using the
now-deprecated XML-RPC API. Eventually this will move to the REST API,
but I just haven't found the time to do so yet.

> I'm not sure if a dedicated Python client library exists: the last time
> I wanted to write a Python client app I found it simple enough to just
> use the JSON that the API provides directly. But the place I'd start
> with is git-pw.

There's no patchwork SDK yet and git-pw is intended for use as a tool
rather than a library (the internal API isn't stable). However, the
Patchwork API itself is very trivial so requests should get you what
you want very easily.

Stephen

> Regards,
> Daniel
>
> > Regards,
> > SImon


Applied to u-boot-dm


Re: [PATCH v3 10/49] binman: Adjust pylibfdt for incremental build

2020-07-19 Thread Simon Glass
If the pylibfdt shared-object file is detected, then Python assumes that
the libfdt.py file exists also.

Sometimes when an incremental build aborts, the shared-object file is
built but the libfdt.py is not. The only way out at this point is to use
'make mkproper', or similar.

Fix this by removing the .so file before it is built. This seems to make
Python rebuild everything.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 scripts/dtc/pylibfdt/Makefile | 3 +++
 1 file changed, 3 insertions(+)

Applied to u-boot-dm


Re: [PATCH v3 11/49] binman: Re-enable concurrent tests

2020-07-19 Thread Simon Glass
With the change to absolute imports the concurrent tests feature
unfortunately broke. Fix it.

We cannot easy add a warning, since the output messes up tests which check
the output.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 tools/patman/test_util.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Applied to u-boot-dm


Re: [PATCH v3 12/49] binman: Use super() instead of specifying parent type

2020-07-19 Thread Simon Glass
It is easier and less error-prone to use super() when the parent type is
needed. Update binman to remove the type names.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 tools/binman/etype/_testing.py   |  4 ++--
 tools/binman/etype/blob.py   |  2 +-
 tools/binman/etype/blob_dtb.py   |  6 +++---
 tools/binman/etype/blob_named_by_arg.py  |  2 +-
 tools/binman/etype/cbfs.py   | 14 +++---
 tools/binman/etype/cros_ec_rw.py |  3 +--
 tools/binman/etype/fdtmap.py |  2 +-
 tools/binman/etype/files.py  |  2 +-
 tools/binman/etype/fill.py   |  4 ++--
 tools/binman/etype/fmap.py   |  2 +-
 tools/binman/etype/gbb.py|  2 +-
 tools/binman/etype/image_header.py   |  4 ++--
 tools/binman/etype/intel_cmc.py  |  2 +-
 tools/binman/etype/intel_descriptor.py   |  4 ++--
 tools/binman/etype/intel_fit.py  |  4 ++--
 tools/binman/etype/intel_fit_ptr.py  |  4 ++--
 tools/binman/etype/intel_fsp.py  |  2 +-
 tools/binman/etype/intel_fsp_m.py|  2 +-
 tools/binman/etype/intel_fsp_s.py|  2 +-
 tools/binman/etype/intel_fsp_t.py|  2 +-
 tools/binman/etype/intel_ifwi.py |  4 ++--
 tools/binman/etype/intel_me.py   |  2 +-
 tools/binman/etype/intel_mrc.py  |  2 +-
 tools/binman/etype/intel_refcode.py  |  2 +-
 tools/binman/etype/intel_vbt.py  |  2 +-
 tools/binman/etype/intel_vga.py  |  2 +-
 tools/binman/etype/mkimage.py|  2 +-
 .../etype/powerpc_mpc85xx_bootpg_resetvec.py |  2 +-
 tools/binman/etype/section.py| 16 
 tools/binman/etype/text.py   |  2 +-
 tools/binman/etype/u_boot.py |  2 +-
 tools/binman/etype/u_boot_dtb.py |  2 +-
 tools/binman/etype/u_boot_dtb_with_ucode.py  |  4 ++--
 tools/binman/etype/u_boot_elf.py |  4 ++--
 tools/binman/etype/u_boot_img.py |  2 +-
 tools/binman/etype/u_boot_nodtb.py   |  2 +-
 tools/binman/etype/u_boot_spl.py |  2 +-
 tools/binman/etype/u_boot_spl_bss_pad.py |  2 +-
 tools/binman/etype/u_boot_spl_dtb.py |  2 +-
 tools/binman/etype/u_boot_spl_elf.py |  2 +-
 tools/binman/etype/u_boot_spl_nodtb.py   |  2 +-
 tools/binman/etype/u_boot_spl_with_ucode_ptr.py  |  2 +-
 tools/binman/etype/u_boot_tpl.py |  2 +-
 tools/binman/etype/u_boot_tpl_dtb.py |  2 +-
 tools/binman/etype/u_boot_tpl_dtb_with_ucode.py  |  2 +-
 tools/binman/etype/u_boot_tpl_elf.py |  2 +-
 tools/binman/etype/u_boot_tpl_with_ucode_ptr.py  |  2 +-
 tools/binman/etype/u_boot_ucode.py   |  2 +-
 tools/binman/etype/u_boot_with_ucode_ptr.py  |  2 +-
 tools/binman/etype/vblock.py |  2 +-
 tools/binman/etype/x86_reset16.py|  2 +-
 tools/binman/etype/x86_reset16_spl.py|  2 +-
 tools/binman/etype/x86_reset16_tpl.py|  2 +-
 tools/binman/etype/x86_start16.py|  2 +-
 tools/binman/etype/x86_start16_spl.py|  2 +-
 tools/binman/etype/x86_start16_tpl.py|  2 +-
 tools/binman/image.py| 12 ++--
 57 files changed, 86 insertions(+), 87 deletions(-)

Applied to u-boot-dm


Re: [PATCH v3 13/49] binman: Add an etype for external binary blobs

2020-07-19 Thread Simon Glass
It is useful to be able to distinguish between ordinary blobs such as
u-boot.bin and external blobs that cannot be build by the U-Boot build
system. If the external blobs are not available for some reason, then we
know that a value image cannot be built.

Introduce a new 'blob-ext' entry type for that.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 tools/binman/README.entries| 10 +++
 tools/binman/etype/blob_ext.py | 31 ++
 tools/binman/ftest.py  | 12 +
 tools/binman/test/157_blob_ext.dts | 14 ++
 tools/binman/test/158_blob_ext_missing.dts | 16 +++
 5 files changed, 83 insertions(+)
 create mode 100644 tools/binman/etype/blob_ext.py
 create mode 100644 tools/binman/test/157_blob_ext.dts
 create mode 100644 tools/binman/test/158_blob_ext_missing.dts

Applied to u-boot-dm


Re: [PATCH v3 21/49] dtoc: Allow adding variable-sized data to a dtb

2020-07-19 Thread Simon Glass
Add a method for adding a property containing arbitrary bytes. Make sure
that the tree can expand as needed in this case.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 tools/dtoc/fdt.py  | 17 +++--
 tools/dtoc/test_fdt.py |  4 
 2 files changed, 19 insertions(+), 2 deletions(-)

Applied to u-boot-dm


[PATCH v4 25/27] x86: chromebook_link64: Correct the image layout

2020-07-19 Thread Simon Glass
At present the image layout is not correct, since it uses the SDRAM
address of the 64-bit U-Boot as the ROM address. Fix this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 configs/chromebook_link64_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/chromebook_link64_defconfig 
b/configs/chromebook_link64_defconfig
index 7828e2dc34..772a75a8e7 100644
--- a/configs/chromebook_link64_defconfig
+++ b/configs/chromebook_link64_defconfig
@@ -17,8 +17,10 @@ CONFIG_HAVE_MRC=y
 CONFIG_SMP=y
 CONFIG_HAVE_VGA_BIOS=y
 CONFIG_DEFAULT_DEVICE_TREE="chromebook_link"
+CONFIG_X86_OFFSET_U_BOOT=0xffa0
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SHOW_BOOT_PROGRESS=y
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script

2020-07-19 Thread Simon Glass
Now that all board use binman instead of this script, drop it.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 arch/arm/mach-rockchip/fit_spl_optee.sh | 84 -
 1 file changed, 84 deletions(-)
 delete mode 100755 arch/arm/mach-rockchip/fit_spl_optee.sh

diff --git a/arch/arm/mach-rockchip/fit_spl_optee.sh 
b/arch/arm/mach-rockchip/fit_spl_optee.sh
deleted file mode 100755
index 4118472d9f..00
--- a/arch/arm/mach-rockchip/fit_spl_optee.sh
+++ /dev/null
@@ -1,84 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier:  GPL-2.0+
-#
-# Copyright (C) 2019 Rockchip Electronic Co.,Ltd
-#
-# Script to generate FIT image source for 32-bit Rockchip SoCs with
-# U-Boot proper, OPTEE, and devicetree.
-#
-# usage: $0 
-
-[ -z "$TEE" ] && TEE="tee.bin"
-
-if [ ! -f $TEE ]; then
-   echo "WARNING: TEE file $TEE NOT found, U-Boot.itb is non-functional" 
>&2
-   echo "Please export path for TEE or copy tee.bin to U-Boot folder" >&2
-   TEE=/dev/null
-fi
-
-dtname=$1
-text_base=`sed -n "/SYS_TEXT_BASE=/s/CONFIG_SYS_TEXT_BASE=//p" .config \
-  |tr -d '\r'`
-dram_base=`sed -n "/SYS_SDRAM_BASE=/s/CONFIG_SYS_SDRAM_BASE=//p" \
-  include/autoconf.mk|tr -d '\r'`
-tee_base=`echo "obase=16;$(($dram_base+0x840))"|bc`
-tee_base='0x'$tee_base
-
-cat << __HEADER_EOF
-/*
- * Copyright (C) 2017-2019 Rockchip Electronic Co.,Ltd
- *
- * Simple U-boot FIT source file containing U-Boot, dtb and optee
- */
-
-/dts-v1/;
-
-/ {
-   description = "FIT image with OP-TEE support";
-   #address-cells = <1>;
-
-   images {
-   uboot {
-   description = "U-Boot";
-   data = /incbin/("u-boot-nodtb.bin");
-   type = "standalone";
-   os = "U-Boot";
-   arch = "arm";
-   compression = "none";
-   load = <$text_base>;
-   };
-   optee {
-   description = "OP-TEE";
-   data = /incbin/("$TEE");
-   type = "firmware";
-   arch = "arm";
-   os = "tee";
-   compression = "none";
-   load = <$tee_base>;
-   entry = <$tee_base>;
-   };
-   fdt {
-   description = "$(basename $dtname .dtb)";
-   data = /incbin/("$dtname");
-   type = "flat_dt";
-   compression = "none";
-   };
-__HEADER_EOF
-
-cat << __CONF_HEADER_EOF
-   };
-
-   configurations {
-   default = "conf";
-   conf {
-   description = "$(basename $dtname .dtb)";
-   firmware = "optee";
-   loadables = "uboot";
-   fdt = "fdt";
-   };
-__CONF_HEADER_EOF
-
-cat << __ITS_EOF
-   };
-};
-__ITS_EOF
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 18/27] Makefile: Fix a long line in cmd_mkfitimage

2020-07-19 Thread Simon Glass
Fix this line which is over the limit.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index fced33e777..163dc0b8b9 100644
--- a/Makefile
+++ b/Makefile
@@ -999,7 +999,8 @@ cmd_mkimage = $(objtree)/tools/mkimage 
$(MKIMAGEFLAGS_$(@F)) -d $< $@ \
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_mkfitimage = MKIMAGE $@
-cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f 
$(U_BOOT_ITS) -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@\
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) \
+   -f $(U_BOOT_ITS) -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@ \
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_cat = CAT $@
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 26/27] x86: chromebook_panther: Correct the image layout

2020-07-19 Thread Simon Glass
This board does not have microcode but at present that is not supported
by Kconfig nor the binman image layout. Fix both of these.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 arch/x86/Kconfig| 7 ++-
 arch/x86/dts/u-boot.dtsi| 6 +-
 configs/chromebox_panther_defconfig | 2 ++
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f51b7c9f41..e3ba38cefd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -594,8 +594,13 @@ config HAVE_REFCODE
   Various peripherals may fail to work.
 
 config HAVE_MICROCODE
-   bool
+   bool "Board requires a microcode binary"
default y if !FSP_VERSION2
+   help
+ Enable this if the board requires microcode to be loaded on boot.
+ Typically this is handed by the FSP for modern boards, but for
+ some older boards, it must be programmed by U-Boot, and that form
+ part of the image.
 
 config SMP
bool "Enable Symmetric Multiprocessing"
diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index 1e0a985b43..fa8106c8b8 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -75,11 +75,15 @@
u-boot {
offset = ;
};
-# else
+# elif defined(CONFIG_HAVE_MICROCODE)
/* If there is no SPL then we need to put microcode in U-Boot */
u-boot-with-ucode-ptr {
offset = ;
};
+# else
+   u-boot-nodtb {
+   offset = ;
+   };
 # endif
 #endif
 #ifdef CONFIG_HAVE_MICROCODE
diff --git a/configs/chromebox_panther_defconfig 
b/configs/chromebox_panther_defconfig
index fd87ab262b..35ec3e912b 100644
--- a/configs/chromebox_panther_defconfig
+++ b/configs/chromebox_panther_defconfig
@@ -7,7 +7,9 @@ CONFIG_NR_DRAM_BANKS=8
 CONFIG_VENDOR_GOOGLE=y
 CONFIG_TARGET_CHROMEBOX_PANTHER=y
 CONFIG_HAVE_MRC=y
+# CONFIG_HAVE_MICROCODE is not set
 CONFIG_HAVE_VGA_BIOS=y
+CONFIG_X86_OFFSET_U_BOOT=0xffa0
 CONFIG_FIT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 21/27] rockchip: Convert evb-rk3288 over to use binman

2020-07-19 Thread Simon Glass
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Move the .itb output to a separate rockchip-optee.dtsi file
- Add a check for CONFIG_FIT before building the .its

Changes in v3:
- Drop use of rk322x.dtsi
- Add changes to rk3288-u-boot.dtsi instead

 Kconfig   |  2 +-
 arch/arm/dts/rk3288-u-boot.dtsi   |  1 +
 arch/arm/dts/rockchip-optee.dtsi  | 64 +++
 arch/arm/mach-rockchip/rk3288/Kconfig |  1 +
 configs/evb-rk3288_defconfig  |  2 +-
 5 files changed, 68 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/rockchip-optee.dtsi

diff --git a/Kconfig b/Kconfig
index 1dc5273c68..11c71141db 100644
--- a/Kconfig
+++ b/Kconfig
@@ -321,7 +321,7 @@ config BUILD_TARGET
default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_GEN5
default "u-boot-spl.kwb" if ARCH_MVEBU && SPL
default "u-boot-elf.srec" if RCAR_GEN3
-   default "u-boot.itb" if SPL_LOAD_FIT && (ARCH_ROCKCHIP || \
+   default "u-boot.itb" if !BINMAN && SPL_LOAD_FIT && (ARCH_ROCKCHIP || \
ARCH_SUNXI || RISCV || ARCH_ZYNQMP)
default "u-boot.kwb" if ARCH_KIRKWOOD
default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index c87f00141f..e3c6c10f13 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -4,6 +4,7 @@
  */
 
 #include "rockchip-u-boot.dtsi"
+#include "rockchip-optee.dtsi"
 
 / {
chosen {
diff --git a/arch/arm/dts/rockchip-optee.dtsi b/arch/arm/dts/rockchip-optee.dtsi
new file mode 100644
index 00..cde9b81b26
--- /dev/null
+++ b/arch/arm/dts/rockchip-optee.dtsi
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Google LLC
+ */
+
+#include 
+
+#if defined(CONFIG_HAS_ROM) && defined(CONFIG_FIT)
+&binman {
+   itb {
+   filename = "u-boot.itb";
+   fit {
+   fit,external-offset = ;
+   description = "FIT image with OP-TEE support";
+   #address-cells = <1>;
+
+   images {
+   uboot {
+   description = "U-Boot";
+   type = "standalone";
+   os = "U-Boot";
+   arch = "arm";
+   compression = "none";
+   load = ;
+
+   u-boot-nodtb {
+   };
+   };
+   optee {
+   description = "OP-TEE";
+   type = "firmware";
+   arch = "arm";
+   os = "tee";
+   compression = "none";
+   load = <(CONFIG_SYS_SDRAM_BASE + 
0x840)>;
+   entry = <(CONFIG_SYS_SDRAM_BASE + 
0x840)>;
+
+   blob-ext {
+   filename = "tee.bin";
+   };
+   };
+   fdt {
+   description = CONFIG_SYS_BOARD;
+   type = "flat_dt";
+   compression = "none";
+
+   u-boot-dtb {
+   };
+   };
+   };
+
+   configurations {
+   default = "conf";
+   conf {
+   description = CONFIG_SYS_BOARD;
+   firmware = "optee";
+   loadables = "uboot";
+   fdt = "fdt";
+   };
+   };
+   };
+   };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig 
b/arch/arm/mach-rockchip/rk3288/Kconfig
index bb715e9d0e..20a00c5be7 100644
--- a/arch/arm/mach-rockchip/rk3288/Kconfig
+++ b/arch/arm/mach-rockchip/rk3288/Kconfig
@@ -48,6 +48,7 @@ config TARGET_CHROMEBOOK_SPEEDY
 
 config TARGET_EVB_RK3288
bool "Evb-RK3288"
+   select HAS_ROM
select BOARD_LATE_INIT
select TPL
help
diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 350189fc63..cd03767bd5 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-

[PATCH v4 24/27] x86: Move the fdtmap away from the binary blobs

2020-07-19 Thread Simon Glass
This causes conflicts on chromebook_link64. Move it to after U-Boot where
there should be plenty of space.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 arch/x86/dts/u-boot.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index f0f8c71761..1e0a985b43 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -92,6 +92,8 @@
u-boot-dtb {
};
 #endif
+   fdtmap {
+   };
 #ifdef CONFIG_HAVE_X86_FIT
intel-fit {
};
@@ -139,8 +141,6 @@
filename = CONFIG_FSP_FILE_S;
};
 #endif
-   fdtmap {
-   };
 #ifdef CONFIG_HAVE_CMC
intel-cmc {
filename = CONFIG_CMC_FILE;
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 27/27] x86: chromebook_samus_tpl: Correct the image layout

2020-07-19 Thread Simon Glass
At present there is not enough space for U-Boot due to the EFI loader.
Correct this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v2)

Changes in v2:
- Add patches to partially migrate rockchip to use binman

 configs/chromebook_samus_tpl_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/chromebook_samus_tpl_defconfig 
b/configs/chromebook_samus_tpl_defconfig
index e54a4ff6a6..43622f4182 100644
--- a/configs/chromebook_samus_tpl_defconfig
+++ b/configs/chromebook_samus_tpl_defconfig
@@ -17,8 +17,8 @@ CONFIG_HAVE_MRC=y
 CONFIG_HAVE_REFCODE=y
 CONFIG_SMP=y
 CONFIG_HAVE_VGA_BIOS=y
-CONFIG_X86_OFFSET_U_BOOT=0xfff0
 CONFIG_DEFAULT_DEVICE_TREE="chromebook_samus"
+CONFIG_X86_OFFSET_U_BOOT=0xffee
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_SHOW_BOOT_PROGRESS=y
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 17/27] Makefile: Move CONFIG_TOOLS_DEBUG check to later

2020-07-19 Thread Simon Glass
At present this is checked before the config has been loaded by the
Makefile, so it doesn't work.

Move the check to later.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index e4b1c01de1..fced33e777 100644
--- a/Makefile
+++ b/Makefile
@@ -278,7 +278,7 @@ HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)
 HOSTCC   = cc
 HOSTCXX  = c++
 KBUILD_HOSTCFLAGS   := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer \
-   $(if $(CONFIG_TOOLS_DEBUG),-g) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
+   $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
 KBUILD_HOSTCXXFLAGS := -O2 $(HOST_LFS_CFLAGS) $(HOSTCXXFLAGS)
 KBUILD_HOSTLDFLAGS  := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
 KBUILD_HOSTLDLIBS   := $(HOST_LFS_LIBS) $(HOSTLDLIBS)
@@ -735,6 +735,8 @@ KBUILD_CPPFLAGS += $(KCPPFLAGS)
 KBUILD_AFLAGS += $(KAFLAGS)
 KBUILD_CFLAGS += $(KCFLAGS)
 
+KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
+
 # Use UBOOTINCLUDE when you must reference the include/ directory.
 # Needed to be compatible with the O= option
 UBOOTINCLUDE:= \
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 22/27] rockchip: Convert evb-rk3229 over to use binman

2020-07-19 Thread Simon Glass
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.

Signed-off-by: Simon Glass 
---

(no changes since v3)

Changes in v3:
- Drop leftover debugging

 configs/evb-rk3229_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig
index 1d0fe3332b..406437d1d9 100644
--- a/configs/evb-rk3229_defconfig
+++ b/configs/evb-rk3229_defconfig
@@ -15,7 +15,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/fit_spl_optee.sh"
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_USE_PREBOOT=y
 CONFIG_DEFAULT_FDT_FILE="rk3229-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 11/27] powerpc: mpc85xx: Only enable binman when it is needed

2020-07-19 Thread Simon Glass
Quite a few boards using this SoC family don't use binman, yet
CONFIG_BINMAN is enabled for all of them. But the option should only be
enabled if we expect binman to produce an image. Calling binman when the
device tree is missing, etc. will cause failer.

Add a condition so that CONFIG_BINMAN is only enabled as needed.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 arch/powerpc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c2c577f60c..6a2e88fed2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -20,7 +20,7 @@ config MPC85xx
select CREATE_ARCH_SYMLINK
select SYS_FSL_DDR
select SYS_FSL_DDR_BE
-   select BINMAN
+   select BINMAN if OF_SEPARATE
imply CMD_HASH
imply CMD_IRQ
imply USB_EHCI_HCD if USB
-- 
2.28.0.rc0.105.gf9edc3c819-goog



[PATCH v4 13/27] x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM

2020-07-19 Thread Simon Glass
This Kconfig is not needed anymore since U-Boot will build the ROM if the
required binary blobs exist.

The BUILD_ROM environment variable used to request that the ROM be built.
Now this always happens if the required binary blobs are available. Update
it to mean that U-Boot should fail if the ROM cannot be built. This
behaviour should be compatible with how it used to work.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

(no changes since v1)

 Kconfig   | 7 +--
 Makefile  | 3 ++-
 configs/qemu-x86_64_defconfig | 1 -
 configs/qemu-x86_defconfig| 1 -
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Kconfig b/Kconfig
index b3b8532d2c..182f5d6f18 100644
--- a/Kconfig
+++ b/Kconfig
@@ -288,8 +288,11 @@ config ROM_NEEDS_BLOBS
depends on HAS_ROM
help
  Enable this if building the u-boot.rom target needs binary blobs, and
- so cannot be done normally. In this case, pass BUILD_ROM=1 to make
- to tell U-Boot to build the ROM.
+ so cannot be done normally. In this case, U-Boot will only build the
+ ROM if the required blobs exist. If not, you will see an warning like:
+
+   Image 'main-section' is missing external blobs and is 
non-functional:
+ intel-descriptor intel-me intel-refcode intel-vga intel-mrc
 
 config BUILD_ROM
bool "Build U-Boot as BIOS replacement"
diff --git a/Makefile b/Makefile
index b4b5b10813..03590de0ef 100644
--- a/Makefile
+++ b/Makefile
@@ -1312,7 +1312,8 @@ quiet_cmd_binman = BINMAN  $@
 cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \
 --toolpath $(objtree)/tools \
$(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
-   build -u -d u-boot.dtb -O . -m --allow-missing \
+   build -u -d u-boot.dtb -O . \
+   $(if $(BUILD_ROM),,-m --allow-missing) \
-I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
$(BINMAN_$(@F))
 
diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index dd4ae62a30..4d156bc7fc 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -18,7 +18,6 @@ CONFIG_GENERATE_ACPI_TABLE=y
 CONFIG_X86_OFFSET_U_BOOT=0xfff0
 CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BUILD_ROM=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_BOOTSTAGE=y
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 4309c2352d..f0e8e7d967 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -8,7 +8,6 @@ CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
 CONFIG_GENERATE_ACPI_TABLE=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BUILD_ROM=y
 CONFIG_FIT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
-- 
2.28.0.rc0.105.gf9edc3c819-goog



  1   2   >