Re: [U-Boot] [PATCH 05/16] efi_loader: add signature verification functions

2019-11-17 Thread AKASHI Takahiro
Heinrich,

I will address other comments in a separate e-mail, but
it is worth mentioning that Patrick deserves credit for initial
implementation of efi secure boot, which the main logic of my current
patch set heavily relies on;

On Sat, Nov 16, 2019 at 09:00:12PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:52 AM, AKASHI Takahiro wrote:
>
> >diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c
> >new file mode 100644
> >index ..04f43e47d1a3
> >--- /dev/null
> >+++ b/lib/efi_loader/efi_signature.c
> >@@ -0,0 +1,600 @@
> >+// SPDX-License-Identifier: GPL-2.0+
> >+/*
> >+ * Copyright (c) 2018 Patrick Wildt 
> 
> From which upstream did you take the code?

The original code has never been upstreamed, and I took over
his patch directly from him.

Thanks,
-Takahiro Akashi

> >+ * Copyright (c) 2019 Linaro Limited, Author: AKASHI Takahiro
> >+ */
> >+
> 
> debug() checks the value of _DEBUG.
> Please, include common.h as first include.
> 
> Use the sequence of includes as defined in
> https://www.denx.de/wiki/U-Boot/CodingStyle
> 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> 
> Shouldn't we move all cryptography stuff into a directory crypto/?
> 
> >+#include 
> >+/*
> >+ * avoid duplicated inclusion:
> >+ * #include "../lib/crypto/x509_parser.h"
> >+ */
> >+#include "../lib/crypto/pkcs7_parser.h"
> >+
> >+const efi_guid_t efi_guid_image_security_database =
> >+EFI_IMAGE_SECURITY_DATABASE_GUID;
> >+const efi_guid_t efi_guid_sha256 = EFI_CERT_SHA256_GUID;
> >+const efi_guid_t efi_guid_cert_rsa2048 = EFI_CERT_RSA2048_GUID;
> >+const efi_guid_t efi_guid_cert_x509 = EFI_CERT_X509_GUID;
> >+const efi_guid_t efi_guid_cert_x509_sha256 = EFI_CERT_X509_SHA256_GUID;
> >+
> >+#ifdef CONFIG_EFI_SECURE_BOOT
> >+static const unsigned char WinIndirectSha256[] = {
> 
> We don't use camel case.
> 
> >+0x30, 0x33, 0x06, 0x0a, 0x2b, 0x06, 0x01, 0x04, 0x01, 0x82, 0x37, 0x02,
> >+0x01, 0x0f, 0x30, 0x25, 0x03, 0x01, 0x00, 0xa0, 0x20, 0xa2, 0x1e, 0x80,
> >+0x1c, 0x00, 0x3c, 0x00, 0x3c, 0x00, 0x3c, 0x00, 0x4f, 0x00, 0x62, 0x00,
> >+0x73, 0x00, 0x6f, 0x00, 0x6c, 0x00, 0x65, 0x00, 0x74, 0x00, 0x65, 0x00,
> >+0x3e, 0x00, 0x3e, 0x00, 0x3e, 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60,
> >+0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20
> >+};
> 
> What secret sauce is this? - Please, add comments where applicable. Add
> references where needed for verification of correctness.
> 
> Below you describe it as DER wrapper. So why call the variable Sha256?
> 
> >+
> >+/**
> >+ * efi_hash_regions - calculate a hash value
> >+ * @regs:   List of regions
> >+ * @hash:   Pointer to a pointer to buffer holding a hash value
> >+ * @size:   Size of buffer to be returned
> >+ *
> >+ * Calculate a sha256 value of @regs and return a value in @hash.
> 
> Is this a hash of the concatenation of all regions - or is this a list
> of hashes one for each regions?
> 
> >+ *
> >+ * Return:  true on success, false on error
> >+ */
> >+static bool efi_hash_regions(struct efi_image_regions *regs, void **hash,
> >+ size_t *size)
> 
> Why use void** for hash? There should be a structure for SHA256 hashes.
> 
> >+{
> >+*size = 0;
> >+*hash = calloc(1, SHA256_SUM_LEN);
> >+if (!*hash) {
> >+debug("Out of memory\n");
> >+return false;
> >+}
> >+*size = SHA256_SUM_LEN;
> >+
> >+hash_calculate("sha256", regs->reg, regs->num, *hash);
> >+#ifdef DEBUG
> >+debug("hash calculated:\n");
> 
> debug checks the value of _DEBUG not of DEBUG. So wouldn't you use
> #ifdef _DEBUG to be consistent?
> 
> >+print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 1,
> >+   *hash, SHA256_SUM_LEN, false);
> 
> This will fail to compile if CONFIG_HEXDUMP is not defined?
> 
> >+#endif
> >+
> >+return true;
> >+}
> >+
> >+/**
> >+ * efi_hash_regions_in_der - calculate a hash value
> >+ * @regs:   List of regions
> >+ * @hash:   Pointer to a pointer to buffer holding a hash value
> >+ * @size:   Size of buffer to be returned
> >+ *
> >+ * Calculate a sha256 value of @regs and return a value in @hash.
> >+ * This function is a variant of efi_hash_regions(), and the data will
> >+ * be wrapped with some header in DER format before hash calculation.
> >+ * Message digest in signature of PE format will be calculated this way.
> >+ *
> >+ * Return:  true on success, false on error
> >+ */
> >+static bool efi_hash_regions_in_der(struct efi_image_regions *regs, void 
> >**hash,
> >+size_t *size)
> >+{
> >+void *msg;
> >+size_t msg_size;
> >+struct image_region regtmp[2];
> >+
> >+if (!efi_hash_regions(regs, , _size)) {
> >+debug("Hash calculation failed\n");
> >+return false;
> >+;
> >+}
> >+
> >+*size = 0;
> >+*hash = calloc(1, 

Re: [U-Boot] [U-Boot-Board-Maintainers] Please pull u-boot-fdt

2019-11-17 Thread Bin Meng
Hi Simon,

On Sun, Nov 17, 2019 at 11:46 PM Simon Glass  wrote:
>
> Hi Bin,
>
> On Sun, 17 Nov 2019 at 07:07, Bin Meng  wrote:
> >
> > Hi Simon,
> >
> > On Wed, Nov 6, 2019 at 7:12 AM Tom Rini  wrote:
> > >
> > > On Tue, Nov 05, 2019 at 05:23:51AM -0700, Simon Glass wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > Passing run here:
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1210
> > > >
> > > >
> > > > The following changes since commit 
> > > > 73b6e6ad254b36763419cdd3fdf406c0094517b7:
> > > >
> > > >   Merge tag 'u-boot-imx-20191104' of
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-11-04
> > > > 12:57:41 -0500)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   git://git.denx.de/u-boot-fdt.git tags/fdt-pull-5nov19
> > > >
> > > > for you to fetch changes up to 388560134b99dc4cc752627d3a7e9f8c8c2a89a7:
> > > >
> > > >   binman: Move to use Python 3 (2019-11-04 18:15:32 -0700)
> > > >
> > >
> > > Now first,
> > > Applied to u-boot/master, thanks!
> > >
> > > And second, which is why I've included the board maintainers list and
> > > custodian lists, this causes a bit of size growth everywhere just about
> > > (tbs2910 being the exception) because by default upstream now has
> > > various input validation routines.  It doesn't catch "tell the hardware
> > > to overvolt something" but does catch "pass garbage in the property so
> > > we can overwrite the stack and ..." type problems.  And it's
> > > configurable.  If you turn off all of the validation stuff, which we do
> > > in SPL/TPL by default (size concerns!), in the main U-Boot we go from a
> > > size growth to a size shrink.  An arbitrary PowerPC board I picked to
> > > confirm this on grows by 985 bytes now, but if I turned everything off
> > > it would shrink by 1100 bytes.  There's an inbetween setting that would
> > > probably result in neutral size change.
> > >
> > > The default is all of the input validation we can do because I believe
> > > it's important to validate inputs when we can validate them.  I also
> > > firmly believe board maintainers know their requirements best and can
> > > provide a different value for their board(s).
> >
> > I found the following commits breaks SiFive FU540 board, that U-Boot
> > no longer boots:
> >
> > commit f0921f5098d8d98ac38121837aaf7c4b4cb13bb4
> > Author: Simon Glass 
> > Date:   Sun Oct 27 09:47:42 2019 -0600
> >
> > fdt: Sync up to the latest libfdt
> >
> > Reverting this commit makes U-Boot boot again.
> >
> > The failure is serial_find_console_or_panic() no longer finds the
> > serial port with the latest libfdt. Any ideas?
>
> I wonder if it is relying on a feature that never made it upstream?
>
> There was a change to fdt_path_next_separator() which got dropped -
> perhaps that is it? I had assumed it was incorporated but perhaps no
> action was taken? If so, the thread is here:
>
> http://patchwork.ozlabs.org/patch/462756/

Thanks for the pointers.

I simply applied similar changes to fdt_ro.c but it did not make any
difference. I will need have a further debug.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

2019-11-17 Thread Qu Wenruo


On 2019/11/18 上午10:51, Kever Yang wrote:
> Hi Qu Wenruo,
> 
> 
>     Please try with latest u-boot-rockchip with dram and board fix merged:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git master branch

Compiled and installed, and still the same SError trying "memtest 3584M"
on my RockPi4 (4G RAM variant)

I guess now it's time to blame the rkbin I used?

The rkbin files I'm using is:
rk3399_ddr_800MHz_v1.23.bin
rk3399_miniloader_v1.19.bin

And for the trust.ini, it's
---
[VERSION]
MAJOR=1
MINOR=0
[BL30_OPTION]
SEC=0
[BL31_OPTION]
SEC=1
PATH=../rkbin/bin/rk33/rk3399_bl31_v1.29.elf
ADDR=0x0001
[BL32_OPTION]
SEC=1
PATH=../rkbin/bin/rk33/rk3399_bl32_v1.20.bin
ADDR=0x0840
[BL33_OPTION]
SEC=0
[OUTPUT]
PATH=trust.img
---

Since I'm completely new to the rk3399 boot sequence, would it be
possible that above binary files caused the problem?

Thanks,
Qu
> 
> 
>     Did you try with rkbin ddr.bin instead of TPL and keep other
> firmware(SPL, U-Boot, ATF),
> 
> this can confirm if there is something wrong in TPL dram driver or not.
> 
> 
> Thanks,
> 
> - Kever
> 
> On 2019/11/16 下午1:39, Qu Wenruo wrote:
>> On 2019/11/16 下午1:16, Qu Wenruo wrote:
>>> On 2019/11/15 下午10:59, Anand Moon wrote:
 Hi Qu Wenruo,

 On Fri, 15 Nov 2019 at 17:27, Qu Wenruo  wrote:
>
> On 2019/11/15 下午6:37, Qu Wenruo wrote:
>> A small update to this bug.
>>
>> I'm using mem=3584M kernel cmdline, to sacrifice 512M memory.
>>
>> And then surprise, memtest 3G works. (Originally it's 4G physical ram
>> and 3584M memtest.
>>
>> Hopes this could provide some clue.
> Oh no, with 3187M, it still crashes with SError.
>
> So still no luck.
>
> Thanks,
> Qu
 Please this following series of patches for fix this error.
 It fixed issue of SError on my board.
>>> Would you mind to share which commit it is based?
>>>
>>> For v2019.10 tag, it fails at the 13th patch.
>>> The same happened for current master.
>> Well, manually solved the conflicts.
>>
>> If anyone is interested in using that, I have uploaded it to github,
>> which is based on v2019.10 tag:
>>
>> https://github.com/adam900710/u-boot/tree/serror_fixes
>>
>> Unfortunately, still crashed for memtester 3584M.
>>
>> Thanks,
>> Qu
>>
>>> Thanks,
>>> Qu
 [0] https://patchwork.ozlabs.org/cover/1195284/

 Best Regards
 -Anand

>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/5] T1042RDB_PI_NAND_SECURE_BOOT: SECURE_BOOT means environment is nowhere

2019-11-17 Thread Priyanka Jain


>-Original Message-
>From: Tom Rini 
>Sent: Friday, November 15, 2019 6:51 PM
>To: Priyanka Jain 
>Cc: u-boot@lists.denx.de
>Subject: Re: [U-Boot] [PATCH 4/5] T1042RDB_PI_NAND_SECURE_BOOT:
>SECURE_BOOT means environment is nowhere
>
>On Fri, Nov 15, 2019 at 12:43:48PM +, Priyanka Jain wrote:
>>
>>
>> >-Original Message-
>> >From: U-Boot  On Behalf Of Tom Rini
>> >Sent: Thursday, November 14, 2019 8:24 PM
>> >To: u-boot@lists.denx.de
>> >Subject: [U-Boot] [PATCH 4/5] T1042RDB_PI_NAND_SECURE_BOOT:
>> >SECURE_BOOT means environment is nowhere
>> >
>> >Signed-off-by: Tom Rini 
>> >---
>> > board/freescale/t104xrdb/spl.c | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> >diff --git a/board/freescale/t104xrdb/spl.c
>> >b/board/freescale/t104xrdb/spl.c index 7b0eb8edf51d..76b5160cf903
>> >100644
>> >--- a/board/freescale/t104xrdb/spl.c
>> >+++ b/board/freescale/t104xrdb/spl.c
>> >@@ -106,6 +106,7 @@ void board_init_r(gd_t *gd, ulong dest_addr)
>> >#endif
>> >
>> >/* relocate environment function pointers etc. */
>> >+#ifndef CONFIG_NXP_ESBC
>> Can we use some ENV related config instead of this?
>
>We could but I think that's more fragile / complex:
>

>> > #ifdef CONFIG_SPL_NAND_BOOT
>> >nand_spl_load_image(CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
>> >(uchar *)CONFIG_ENV_ADDR);
>> >@@ -120,6 +121,7 @@ void board_init_r(gd_t *gd, ulong dest_addr)
>#endif
>> >gd->env_addr  = (ulong)(CONFIG_ENV_ADDR);
>> >gd->env_valid = ENV_VALID;
>> >+#endif
>
>The endif goes here since we have cases on NAND / MMC / SPI loading the
>environment and then we say it's now valid (and where it is).  We could
>do:
>#if defined(CONFIG_ENV_IS_IN_NAND) || defined(CONFIG_ENV_IS_IN_MMC)
>|| \
>   defined(CONFIG_ENV_IS_IN__SPI_FLASH)
>
This looks better as this is env related code. 
>if you prefer instead of CONFIG_NXP_ESBC
>
>--
>Tom 
-priyankajain

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] arm: socfpga: Enable Stratix10 SMMU access

2019-11-17 Thread Marek Vasut
On 11/18/19 3:46 AM, Tan, Ley Foon wrote:
[...]

>>
>> On 11/15/19 6:20 PM, Thor Thayer wrote:
>>>
>>> Enable TCU access through the Stratix10 CCU so that the SMMU can
>>> access the SDRAM.
>>>
>>
>> [...]
>>
>> Looks good to me. Ley, can you take a look?
>> Thanks!
> Looks good to me too. 
> But, if this patch plan to apply after Agilex patch series, then need to 
> rebase on top of it.

Is this a fix or a feature ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

2019-11-17 Thread Chris Packham
On Sun, Nov 17, 2019 at 8:50 PM Stefan Roese  wrote:
>
> Hi Heinrich,
>
> (+Chris)
>
> On 16.11.19 11:11, Heinrich Schuchardt wrote:
> > Hello Stefan,
> >
> > Gray reporting this bug unfortunately did not provide enough information
> > to analyze his issue.
> >
> > Are you aware of any restrictions of the Kirkwood 88F6281 SoC concerning
> > unaligned access after enabling the unaligned flag?
> >
> > Do you have access to a device with a Kirkwood processor (e.g. Sheevaplug)?
>
> No, unfortunately I don't have have a Kirkwood based board. Chris has
> access to some boards though. Chris, do you have a chance to comment
> on this?
>

I have got a few different Kirkwood boards. But unfortunately none
have anything that I could get a fatfs on.

I can confirm that unaligned access is just not possible (which I
think is an ARMv5TE thing). The Linux kernel does have some logic to
fix up unaligned userspace accesses by emulating the read/write[1] but
I believe kernel-space accesses are still fatal. I don't know if
intercepting these accesses by UEFI apps is something u-boot should be
concerned with.

[1] - 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mm/alignment.c#n800

> > One possible solution would be to let CONFIG_EFI_LOADER depend on
> > CONFIG_KIRKWOOD=n. This would concern 36 devices.
>
> That would be very unfortunate.
>
> Thanks,
> Stefan
>
> > Best regards
> >
> > Heinrich
> >
> > On 11/13/19 8:07 AM, Heinrich Schuchardt wrote:
> >> On 11/12/19 11:55 PM, Gray Remlin wrote:
> >>>
> >>>
> >>> On Tue, 12 Nov 2019 at 19:50, Heinrich Schuchardt  >>> > wrote:
> >>>
> >>>  On 11/11/19 6:14 PM, Gray Remlin wrote:
> >>>   >
> >>>   > This content is getting very convoluted, if appropriate feel
> >>> free to
> >>>   > crop it.
> >>>   > New point raised at very bottom.
> >>>   >
> >>>   > On Sun, 10 Nov 2019 at 08:41, Heinrich Schuchardt
> >>>  mailto:xypron.g...@gmx.de>
> >>>   > >> wrote:
> >>>   >
> >>>   > On 11/9/19 10:31 PM, Gray Remlin wrote:
> >>>   >  > On Sat, 9 Nov 2019 at 20:50, Heinrich Schuchardt
> >>>   > mailto:xypron.g...@gmx.de>
> >>>  >
> >>>   >  > 
> >>>   >>>   >  >
> >>>   >  > On 11/9/19 8:42 PM, Gray Remlin wrote:
> >>>   >  >  > On Sat, 9 Nov 2019 at 18:40, Heinrich Schuchardt
> >>>   >  > mailto:xypron.g...@gmx.de>
> >>>  >
> >>>   > 
> >>>  >>
> >>>   >  >  >  >>>    >>>  >
> >>>   > 
> >>>   wrote:
> >>>   >  >  >
> >>>   >  >  > On 11/9/19 6:08 PM, Heinrich Schuchardt wrote:
> >>>   >  >  >  > On 11/9/19 4:11 PM, Gray Remlin wrote:
> >>>   >  >  >  >> On Fri, 8 Nov 2019 at 20:08, Heinrich
> >>>  Schuchardt
> >>>   >  >  > mailto:xypron.g...@gmx.de>
> >>>  >
> >>>   > 
> >>>  >>
> >>>   >  > 
> >>>  >
> >>>   > 
> >>>   >>>   >  >  >  >>  >>>  
> >>>   > >
> >>>  
> >>>   > >>
> >>>   >  > 
> >>>  >
> >>>   > 
> >>>  > wrote:
> >>>   >  >  >  >>
> >>>   >  >  >  >> On 11/8/19 7:32 PM, Gray Remlin wrote:
> >>>   >  >  >  >>  > Please excuse the noise. I would
> >>>  like to file a
> >>>   >  > bug report
> >>>   >  >  >  >> against the
> >>>   >  >  >  >>   

Re: [U-Boot] [PATCH v2 3/4] dm: spi: Check cs number before accessing slaves

2019-11-17 Thread Bin Meng
Hi Jagan,

On Tue, Oct 29, 2019 at 6:15 PM Bin Meng  wrote:
>
> Hi Jagan,
>
> On Wed, Oct 16, 2019 at 11:21 PM Jagan Teki  
> wrote:
> >
> > Hi Bin,
> >
> > On Mon, Sep 9, 2019 at 6:30 PM Bin Meng  wrote:
> > >
> > > Add chip select number check in spi_find_chip_select().
> > >
> > > Signed-off-by: Bin Meng 
> > >
> > > ---
> > >
> > > Changes in v2:
> > > - move the chip select number check to spi_find_chip_select()
> > >
> > >  drivers/spi/spi-uclass.c | 45 
> > > ++---
> > >  include/spi.h|  3 ++-
> > >  2 files changed, 28 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> > > index 24de0b5..cdeceb5 100644
> > > --- a/drivers/spi/spi-uclass.c
> > > +++ b/drivers/spi/spi-uclass.c
> > > @@ -179,7 +179,32 @@ int spi_chip_select(struct udevice *dev)
> > >
> > >  int spi_find_chip_select(struct udevice *bus, int cs, struct udevice 
> > > **devp)
> > >  {
> > > +   struct dm_spi_ops *ops;
> > > +   struct spi_cs_info info;
> > > struct udevice *dev;
> > > +   int ret;
> > > +
> > > +   /*
> > > +* Ask the driver. For the moment we don't have CS info.
> > > +* When we do we could provide the driver with a helper function
> > > +* to figure out what chip selects are valid, or just handle the
> > > +* request.
> > > +*/
> > > +   ops = spi_get_ops(bus);
> > > +   if (ops->cs_info) {
> > > +   ret = ops->cs_info(bus, cs, );
> > > +   } else {
> > > +   /*
> > > +* We could assume there is at least one valid chip 
> > > select.
> > > +* The driver didn't care enough to tell us.
> > > +*/
> > > +   ret = 0;
> > > +   }
> > > +
> > > +   if (ret) {
> > > +   printf("Invalid cs %d (err=%d)\n", cs, ret);
> > > +   return ret;
> > > +   }
> > >
> >
> > This is breaking 'sf probe' with associated bus and cs on SiFive.
>
> No this does not break anything on SiFive. It enforces the 'sf probe'
> to use the correct CS number on SiFive. And something is wrong when CS
> is 0 on SiFive.

As discussed in another thread, this patch does not break SiFive.
Could you please merge the remaining 2 patches in this series? thanks!

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 07/16] efi_loader: variable: support variable authentication

2019-11-17 Thread AKASHI Takahiro
On Sat, Nov 16, 2019 at 09:02:45PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:52 AM, AKASHI Takahiro wrote:
> >With this commit, EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
> >is supported for authenticated variables and the system secure state
> >will transfer between setup mode and user mode as UEFI specification
> >section 32.3 describes.
> >
> >Internally, authentication data is stored as part of authenticated
> >variable's value. It is nothing but a pkcs7 message (but we need some
> >wrapper, see efi_variable_parse_signature()) and will be validated by
> >efi_variable_authenticate(), hence efi_signature_verify_with_db().
> >
> >Associated time value will be encoded in "{...,time=...}" along with
> >other UEFI variable's attributes.
> 
> Please, provide a unit test testing this single feature.

My test_efi_secboot/test_authvar.py provides various test cases.
Pytest is much better solution than "ut" command in terms of
flexible test scenario (and due to complexed setup).

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  include/efi_loader.h  |   3 +
> >  lib/efi_loader/efi_variable.c | 664 --
> >  2 files changed, 563 insertions(+), 104 deletions(-)
> >
> >diff --git a/include/efi_loader.h b/include/efi_loader.h
> >index 92b683b7653a..2922ee5089a8 100644
> >--- a/include/efi_loader.h
> >+++ b/include/efi_loader.h
> >@@ -175,6 +175,7 @@ extern const efi_guid_t efi_guid_image_security_database;
> >  extern const efi_guid_t efi_guid_sha256;
> >  extern const efi_guid_t efi_guid_cert_x509;
> >  extern const efi_guid_t efi_guid_cert_x509_sha256;
> >+extern const efi_guid_t efi_guid_cert_type_pkcs7;
> >
> >  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
> >  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
> >@@ -697,6 +698,8 @@ efi_status_t efi_image_region_add(struct 
> >efi_image_regions *regs,
> >
> >  void efi_sigstore_free(struct efi_signature_store *sigstore);
> >  struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name);
> >+
> >+bool efi_secure_boot_enabled(void);
> >  #endif /* CONFIG_EFI_SECURE_BOOT */
> >
> >  #else /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> >index 46f35bc60ba0..7e7db8e4a10d 100644
> >--- a/lib/efi_loader/efi_variable.c
> >+++ b/lib/efi_loader/efi_variable.c
> >@@ -10,7 +10,13 @@
> >  #include 
> >  #include 
> >  #include 
> >+#include 
> >  #include 
> >+#include 
> >+#include "../lib/crypto/pkcs7_parser.h"
> >+
> >+const efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> >+static bool efi_secure_boot;
> >
> >  #define READ_ONLY BIT(31)
> >
> >@@ -107,7 +113,7 @@ static const char *prefix(const char *str, const char 
> >*prefix)
> >   * @attrp: pointer to UEFI attributes
> >   * Return: pointer to remainder of U-Boot variable value
> >   */
> >-static const char *parse_attr(const char *str, u32 *attrp)
> >+static const char *parse_attr(const char *str, u32 *attrp, u64 *timep)
> >  {
> > u32 attr = 0;
> > char sep = '{';
> >@@ -130,6 +136,12 @@ static const char *parse_attr(const char *str, u32 
> >*attrp)
> > attr |= EFI_VARIABLE_BOOTSERVICE_ACCESS;
> > } else if ((s = prefix(str, "run"))) {
> > attr |= EFI_VARIABLE_RUNTIME_ACCESS;
> >+} else if ((s = prefix(str, "time="))) {
> >+attr |= 
> >EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS;
> >+hex2bin((u8 *)timep, s, sizeof(*timep));
> >+s += sizeof(*timep) * 2;
> >+} else if (*str == '}') {
> >+break;
> > } else {
> > printf("invalid attribute: %s\n", str);
> > break;
> >@@ -147,48 +159,290 @@ static const char *parse_attr(const char *str, u32 
> >*attrp)
> >  }
> >
> >  /**
> >- * efi_get_variable() - retrieve value of a UEFI variable
> >+ * efi_secure_boot_enabled - return if secure boot is enabled or not
> >   *
> >- * This function implements the GetVariable runtime service.
> >+ * Return:  true if enabled, false if disabled
> >+ */
> >+bool efi_secure_boot_enabled(void)
> >+{
> >+return efi_secure_boot;
> >+}
> >+
> >+#ifdef CONFIG_EFI_SECURE_BOOT
> >+static u8 pkcs7_hdr[] = {
> >+/* SEQUENCE */
> >+0x30, 0x82, 0x05, 0xc7,
> >+/* OID: pkcs7-signedData */
> >+0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x07, 0x02,
> >+/* Context Structured? */
> >+0xa0, 0x82, 0x05, 0xb8,
> >+};
> >+
> >+/**
> >+ * efi_variable_parse_signature - parse a signature in variable
> >+ * @buf:Pointer to variable's value
> >+ * @buflen: Length of @buf
> >   *
> >- * See the Unified Extensible Firmware Interface (UEFI) specification for
> >- * details.
> >+ * Parse a signature embedded in variable's value and instantiate
> >+ * a pkcs7_message structure. Since 

Re: [U-Boot] [PATCH 01/16] include: pe.h: add signature-related definitions

2019-11-17 Thread AKASHI Takahiro
On Mon, Nov 18, 2019 at 07:26:55AM +0100, Heinrich Schuchardt wrote:
> On 11/18/19 6:44 AM, AKASHI Takahiro wrote:
> >Heinrich,
> >
> >On Sat, Nov 16, 2019 at 06:42:11PM +0100, Heinrich Schuchardt wrote:
> >>On 11/13/19 1:52 AM, AKASHI Takahiro wrote:
> >>>The index (IMAGE_DIRECTORY_ENTRY_CERTTABLE) in a table points to
> >>>a region containing authentication information (image's signature)
> >>>in PE format.
> >>>
> >>>WIN_CERTIFICATE structure defines an embedded signature format.
> >>>
> >>>Those definitions will be used in my UEFI secure boot patch.
> >>>
> >>>Signed-off-by: AKASHI Takahiro 
> >>>---
> >>>  include/pe.h | 16 
> >>>  1 file changed, 16 insertions(+)
> >>>
> >>>diff --git a/include/pe.h b/include/pe.h
> >>>index bff3b0aa7a6c..650478ca78af 100644
> >>>--- a/include/pe.h
> >>>+++ b/include/pe.h
> >>>@@ -155,6 +155,7 @@ typedef struct _IMAGE_SECTION_HEADER {
> >>>   uint32_t Characteristics;
> >>>  } IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
> >>>
> >>
> >>Please, add a comment here:
> >>
> >>/* Indices for Optional Header Data Directories */
> >
> >Okay.
> >
> >>>+#define IMAGE_DIRECTORY_ENTRY_CERTTABLE 4
> >>
> >>Yes, 4 is the index of the certificate table. But EDK II calls this
> >>EFI_IMAGE_DIRECTORY_ENTRY_SECURITY. Should we use the same name to avoid
> >>confusion?
> >
> >No. Because the naming is consistent with
> >
> >>>  #define IMAGE_DIRECTORY_ENTRY_BASERELOC 5
> >
> >this existing one.
> 
> IMAGE_DIRECTORY_ENTRY_BASERELOC is a constant name used by EDK2 in
> MdePkg/Include/IndustryStandard/PeImage.h. Why do you want to deviate
> for EFI_IMAGE_DIRECTORY_ENTRY_SECURITY?

Okay, but not due to EDK2, but because Windows uses it:
https://docs.microsoft.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-imagedirectoryentrytodata


> >
> >>>
> >>>  typedef struct _IMAGE_BASE_RELOCATION
> >>>@@ -252,4 +253,19 @@ typedef struct _IMAGE_RELOCATION
> >>>  #define IMAGE_REL_AMD64_PAIR0x000F
> >>>  #define IMAGE_REL_AMD64_SSPAN32 0x0010
> >>>
> >>>+/* certificate appended to PE image */
> >>>+typedef struct _WIN_CERTIFICATE {
> >>
> >>We do not capitalize structs. Please use 'win_certificate' (like Linux
> >>does).
> >>
> >>>+  uint32_t dwLength;
> >>>+  uint16_t wRevision;
> >>>+  uint16_t wCertificateType;
> >>>+  uint8_t bCertificate[];
> >>
> >>We do not use camelcase and type prefixes. Please, use the same
> >>component names as Linux (plus 'certificate' for your extra field).
> >
> >nak.
> >Have you looked at 'pe.h' at all?
> >There are already bunch of use of camelcase's and capital names
> >since this file was first introduced by Alex.
> 
> This shouldn't have happened in the first place.

For consistency, we should keep the style in the *existing* files.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> >
> >>>+} WIN_CERTIFICATE, *LPWIN_CERTIFICATE;
> >>
> >>Please, always make use of scripts/checkpatch.pl before submitting
> >>patches. It says 'WARNING: do not add new typedefs'.
> >
> >ditto.
> >I have run scripts/cehckpatch.pl and dare to leave them unchanged.
> >
> >>Please, avoid the typedefs.
> >
> >No. this is also consistent with other typedef's.
> >
> >
> >>>+
> >>
> >>The following defines are verbatim copies from Linux. Please, also copy
> >>the comment:
> >>
> >>/* Definitions for the contents of the certs data block */
> >
> >Okay.
> >
> >>>+#define WIN_CERT_TYPE_PKCS_SIGNED_DATA0x0002
> >>>+#define WIN_CERT_TYPE_EFI_OKCS115 0x0EF0
> >>>+#define WIN_CERT_TYPE_EFI_GUID0x0EF1
> >>>+
> >>>+#define WIN_CERT_REVISION_1_0 0x0100
> >>>+#define WIN_CERT_REVISION_2_0 0x0200
> >>>+
> >>>  #endif /* _PE_H */
> >>>
> >>
> >>Except for the style issues this looks ok.
> >
> >Thank you for your comments.
> >-Takahiro Akashi
> >
> >>Best regards
> >>
> >>Heinrich
> >>
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] board: rpi4: fix instantiating PL011 driver

2019-11-17 Thread Mark Dapoz

> On 19-Nov-8, at 12:23 PM, Matthias Brugger  wrote:
> 
> On 27/09/2019 07:39, Mark Dapoz wrote:
>> The bcm283x PL011 serial driver is hard coded to allow connections only
>> for UART0.  This prevents using any of the other UARTs as the U-boot
>> console.
>> 
>> The bcm283x serial driver is updated to allow connections to any of the
>> PL011 devices.  The initialization logic has been updated as follows:
>> 
>> - a GPIO pinlist is extracted from the device tree for the device
>> - each pin is compared against a function assignment table
>> - if the pin is found in the table and the currently assigned GPIO
>>   function doesn't match, the device is unavailable
>> - if the function matches the table entry or the pin is not listed
>>   the table, the device is available
>> 
>> The function assignment table contains entries for UART0 to ensure it
>> is multiplexed to GPIO pins 14 and 15.
>> 
> 
> Which is what we already check right now, correct?

Yes, the existing behaviour is maintained.

> 
>> This logic allows GPIO 14 and 15 to be multiplexed between the miniUART
>> and the PL011 UART by the board's loader.
>> 
> 
> Maybe I'm too tired, but I don't see where this is done. I can just see that 
> you
> changed the function to check if PL011 uses GPIO15 as ALT0 to a different
> function which checks the same. Can you please explain.

The pin list for GPIO14 and GPIO15 is checked if they are using ALT0 before
indicating that PL011 is available since that’s the only PL011 device that is
multiplexed with another serial port.  All other PL011 devices are assumed to be
available and the function returns true.   The DTS will determine which PL011’s
are enabled by setting the “status” property.

> 
>> An error in the default clock rate has also been fixed.  If the device
>> tree entry for the serial device doesn't specify a "clocks" property,
>> the default frequency of 1Hz was used.  The default has been changed
>> to 48MHz.
> 
> If doesn't that mean that we don't have a valid DTS?
> If this still makes sense then please split this out into a separate patch.

The generic PL011 driver in drivers/serial/serial_pl01x.c is looking for the
“clock” property but the DTS for the Pi has a “clocks” property instead.
When the driver can’t find the “clock” property, it uses a default value of 1Hz.
The PL011 driver wrapper for the Pi just changes it to 48MHz.

-mark
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Build warnings in libfdt

2019-11-17 Thread Heinrich Schuchardt

On 11/17/19 4:39 PM, Simon Glass wrote:

Hi,

On Sun, 17 Nov 2019 at 06:14, Tom Rini  wrote:


On Sun, Nov 17, 2019 at 11:11:43AM +0100, Heinrich Schuchardt wrote:

Hello Simon,

when building U-Boot HEAD with GCC 9.2.1 I get a bunch of build warnings
which I did not see before your recent libfdt update.

scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’:
scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer
expressions of different signedness: ‘unsigned int’ and ‘int’
[-Wsign-compare]
   137 |   if ((absoffset < offset)
   |  ^
scripts/dtc/libfdt/fdt.c:143:23: warning: comparison of integer
expressions of different signedness: ‘unsigned int’ and ‘int’
[-Wsign-compare]
   143 |   if (((offset + len) < offset)
   |   ^
scripts/dtc/libfdt/fdt.c: In function ‘fdt_move’:
scripts/dtc/libfdt/fdt.c:307:25: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int’ [-Wsign-compare]
   307 |  if (fdt_totalsize(fdt) > bufsize)
   | ^
scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_get_string’:
scripts/dtc/libfdt/fdt_ro.c:56:16: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int32_t’ {aka ‘int’} [-Wsign-compare]
56 |  if (absoffset >= totalsize)
   |^~
scripts/dtc/libfdt/fdt_ro.c:64:18: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
64 |if (stroffset >= fdt_size_dt_strings(fdt))
   |  ^~
scripts/dtc/libfdt/fdt_ro.c:71:21: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
71 |   || (stroffset < -fdt_size_dt_strings(fdt)))
   | ^
scripts/dtc/libfdt/fdt_ro.c:73:20: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
unsigned int’} [-Wsign-compare]
73 |   if ((-stroffset) < len)
   |^
scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_mem_rsv’:
scripts/dtc/libfdt/fdt_ro.c:164:17: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
   164 |   if (absoffset < fdt_off_mem_rsvmap(fdt))
   | ^
scripts/dtc/libfdt/fdt_ro.c:166:17: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘long unsigned int’
[-Wsign-compare]
   166 |   if (absoffset > fdt_totalsize(fdt) -
   | ^
scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_node_offset_by_phandle’:
scripts/dtc/libfdt/fdt_ro.c:682:33: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int’ [-Wsign-compare]
   682 |  if ((phandle == 0) || (phandle == -1))
   | ^~
scripts/dtc/libfdt/fdt_wip.c: In function
‘fdt_setprop_inplace_namelen_partial’:
scripts/dtc/libfdt/fdt_wip.c:26:14: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
26 |  if (proplen < (len + idx))
   |  ^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_grab_space_’:
scripts/dtc/libfdt/fdt_sw.c:105:20: warning: comparison of integer
expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
and ‘int’ [-Wsign-compare]
   105 |  if ((offset + len < offset) || (offset + len > spaceleft))
   |^
scripts/dtc/libfdt/fdt_sw.c:105:47: warning: comparison of integer
expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
and ‘int’ [-Wsign-compare]
   105 |  if ((offset + len < offset) || (offset + len > spaceleft))
   |   ^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_create_with_flags’:
scripts/dtc/libfdt/fdt_sw.c:118:14: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘long unsigned int’
[-Wsign-compare]
   118 |  if (bufsize < hdrsize)
   |  ^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_resize’:
scripts/dtc/libfdt/fdt_sw.c:164:28: warning: comparison of integer
expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
and ‘int’ [-Wsign-compare]
   164 |  if ((headsize + tailsize) > bufsize)
   |^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_add_string_’:
scripts/dtc/libfdt/fdt_sw.c:258:34: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int’ [-Wsign-compare]
   258 |  if (fdt_totalsize(fdt) + offset < struct_top)
   |  ^
scripts/dtc/libfdt/fdt_strerror.c: In function ‘fdt_strerror’:
scripts/dtc/libfdt/fdt_strerror.c:51:18: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘long unsigned int’

Re: [U-Boot] [PATCH 12/16] cmd: env: use appropriate guid for authenticated UEFI variable

2019-11-17 Thread AKASHI Takahiro
Heinrich,

On Sat, Nov 16, 2019 at 09:10:35PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:53 AM, AKASHI Takahiro wrote:
> >A signature database variable is associated with a specific guid.
> >For convenience, if user doesn't supply any guid info, "env set|print -e"
> >should complement it.
> 
> If secure boot is enforced, users should not be able to change any
> security relevant variables.

I disagree. In fact, UEFI specification allows users to modify
security database variables if their signatures are verified.
For example, "db" must be signed by one of certificates in PK or KEK,
and updating its value will should be authenticated in SetVariable API.
That is what my patch#7 exactly does.

Thanks,
-Takahiro Akashi

> Instead we need a way to compile the
> security relevant data into the U-Boot binary and add a signature to the
> U-Boot binary which can be checked by the primary boot loader.
> 
> Best regards
> 
> Heinrich
> 
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  cmd/nvedit_efi.c | 18 ++
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> >
> >diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
> >index 8ea0da01283f..579cf430593c 100644
> >--- a/cmd/nvedit_efi.c
> >+++ b/cmd/nvedit_efi.c
> >@@ -41,6 +41,11 @@ static const struct {
> >  } efi_guid_text[] = {
> > /* signature database */
> > {EFI_GLOBAL_VARIABLE_GUID, "EFI_GLOBAL_VARIABLE_GUID"},
> >+{EFI_IMAGE_SECURITY_DATABASE_GUID, "EFI_IMAGE_SECURITY_DATABASE_GUID"},
> >+/* certificate type */
> >+{EFI_CERT_SHA256_GUID, "EFI_CERT_SHA256_GUID"},
> >+{EFI_CERT_X509_GUID, "EFI_CERT_X509_GUID"},
> >+{EFI_CERT_TYPE_PKCS7_GUID, "EFI_CERT_TYPE_PKCS7_GUID"},
> >  };
> >
> >  /* "----" */
> >@@ -525,9 +530,9 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int argc, 
> >char * const argv[])
> > if (*ep != ',')
> > return CMD_RET_USAGE;
> >
> >+/* 0 should be allowed for delete */
> > size = simple_strtoul(++ep, NULL, 16);
> >-if (!size)
> >-return CMD_RET_FAILURE;
> >+
> > value_on_memory = true;
> > } else if (!strcmp(argv[0], "-v")) {
> > verbose = true;
> >@@ -539,8 +544,13 @@ int do_env_set_efi(cmd_tbl_t *cmdtp, int flag, int 
> >argc, char * const argv[])
> > return CMD_RET_USAGE;
> >
> > var_name = argv[0];
> >-if (default_guid)
> >-guid = efi_global_variable_guid;
> >+if (default_guid) {
> >+if (!strcmp(var_name, "db") || !strcmp(var_name, "dbx") ||
> >+!strcmp(var_name, "dbt"))
> >+guid = efi_guid_image_security_database;
> >+else
> >+guid = efi_global_variable_guid;
> >+}
> >
> > if (verbose) {
> > printf("GUID: %s\n", efi_guid_to_str((const efi_guid_t *)
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 01/16] include: pe.h: add signature-related definitions

2019-11-17 Thread Heinrich Schuchardt

On 11/18/19 6:44 AM, AKASHI Takahiro wrote:

Heinrich,

On Sat, Nov 16, 2019 at 06:42:11PM +0100, Heinrich Schuchardt wrote:

On 11/13/19 1:52 AM, AKASHI Takahiro wrote:

The index (IMAGE_DIRECTORY_ENTRY_CERTTABLE) in a table points to
a region containing authentication information (image's signature)
in PE format.

WIN_CERTIFICATE structure defines an embedded signature format.

Those definitions will be used in my UEFI secure boot patch.

Signed-off-by: AKASHI Takahiro 
---
  include/pe.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/include/pe.h b/include/pe.h
index bff3b0aa7a6c..650478ca78af 100644
--- a/include/pe.h
+++ b/include/pe.h
@@ -155,6 +155,7 @@ typedef struct _IMAGE_SECTION_HEADER {
uint32_t Characteristics;
  } IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;



Please, add a comment here:

/* Indices for Optional Header Data Directories */


Okay.


+#define IMAGE_DIRECTORY_ENTRY_CERTTABLE 4


Yes, 4 is the index of the certificate table. But EDK II calls this
EFI_IMAGE_DIRECTORY_ENTRY_SECURITY. Should we use the same name to avoid
confusion?


No. Because the naming is consistent with


  #define IMAGE_DIRECTORY_ENTRY_BASERELOC 5


this existing one.


IMAGE_DIRECTORY_ENTRY_BASERELOC is a constant name used by EDK2 in
MdePkg/Include/IndustryStandard/PeImage.h. Why do you want to deviate
for EFI_IMAGE_DIRECTORY_ENTRY_SECURITY?





  typedef struct _IMAGE_BASE_RELOCATION
@@ -252,4 +253,19 @@ typedef struct _IMAGE_RELOCATION
  #define IMAGE_REL_AMD64_PAIR0x000F
  #define IMAGE_REL_AMD64_SSPAN32 0x0010

+/* certificate appended to PE image */
+typedef struct _WIN_CERTIFICATE {


We do not capitalize structs. Please use 'win_certificate' (like Linux
does).


+   uint32_t dwLength;
+   uint16_t wRevision;
+   uint16_t wCertificateType;
+   uint8_t bCertificate[];


We do not use camelcase and type prefixes. Please, use the same
component names as Linux (plus 'certificate' for your extra field).


nak.
Have you looked at 'pe.h' at all?
There are already bunch of use of camelcase's and capital names
since this file was first introduced by Alex.


This shouldn't have happened in the first place.

Best regards

Heinrich




+} WIN_CERTIFICATE, *LPWIN_CERTIFICATE;


Please, always make use of scripts/checkpatch.pl before submitting
patches. It says 'WARNING: do not add new typedefs'.


ditto.
I have run scripts/cehckpatch.pl and dare to leave them unchanged.


Please, avoid the typedefs.


No. this is also consistent with other typedef's.



+


The following defines are verbatim copies from Linux. Please, also copy
the comment:

/* Definitions for the contents of the certs data block */


Okay.


+#define WIN_CERT_TYPE_PKCS_SIGNED_DATA 0x0002
+#define WIN_CERT_TYPE_EFI_OKCS115  0x0EF0
+#define WIN_CERT_TYPE_EFI_GUID 0x0EF1
+
+#define WIN_CERT_REVISION_1_0  0x0100
+#define WIN_CERT_REVISION_2_0  0x0200
+
  #endif /* _PE_H */



Except for the style issues this looks ok.


Thank you for your comments.
-Takahiro Akashi


Best regards

Heinrich





___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 02/16] include: image.h: export hash algorithm helper functions

2019-11-17 Thread AKASHI Takahiro
Heinrich,

On Sat, Nov 16, 2019 at 06:59:31PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:52 AM, AKASHI Takahiro wrote:
> >This commit allows us to use common/image-sig.c even if CONFIG_FIT
> >is disabled but CONFIG_EFI_LOADER is enabled.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  include/image.h | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> >diff --git a/include/image.h b/include/image.h
> >index bff87f51f01b..b79424a39c22 100644
> >--- a/include/image.h
> >+++ b/include/image.h
> >@@ -53,7 +53,7 @@ struct fdt_region;
> >
> >  #endif /* USE_HOSTCC */
> >
> >-#if IMAGE_ENABLE_FIT
> >+#if IMAGE_ENABLE_FIT || defined(CONFIG_EFI_SECURE_BOOT)
> 
> Is this #if needed at all?
> 
> Did you run Travis to check that defining CONFIG_EFI_SECURE_BOOT does
> not lead to build failures if IMAGE_ENABLE_FIT is not defined?

Before posting, I have confirmed that the following combination of
config options did not cause any build error, at least, on qemu_arm64:
1. CONFIG_EFI_SECURE_BOOT only
2. CONFIG_FIT (with/without CONFIG_FIT_SIGNATURE) only
3. CONFIG_EFI_SECURE_BOOT and CONFIG_FIT (with/without CONFIG_FIT_SIGNATURE)

I also successfully ran Travis although CONFI_EFI_SECURE_BOOT is not
enabled by default.

> >  #include 
> >  #include 
> >  #include 
> >@@ -86,13 +86,14 @@ struct fdt_region;
> >  #endif
> >
> >  #if defined(CONFIG_FIT_ENABLE_SHA256_SUPPORT) || \
> >-defined(CONFIG_SPL_SHA256_SUPPORT)
> >+defined(CONFIG_SPL_SHA256_SUPPORT) || \
> >+defined(CONFIG_EFI_SECURE_BOOT)
> 
> IMAGE_ENABLE_SHA256 is only used in common/image-fit.c. So why would you
> change anything here?

Okay, I have forgot to remove it.
At some point, I used to use both calculate_hash() and hash_calculate(),
then dropped the former.

> >  #define IMAGE_ENABLE_SHA2561
> >  #else
> >  #define IMAGE_ENABLE_SHA2560
> >  #endif
> >
> >-#endif /* IMAGE_ENABLE_FIT */
> >+#endif /* IMAGE_ENABLE_FIT || defined(CONFIG_EFI_SECURE_BOOT) */
> >
> >  #ifdef CONFIG_SYS_BOOT_GET_CMDLINE
> >  # define IMAGE_BOOT_GET_CMDLINE1
> >@@ -1261,7 +1262,6 @@ struct crypto_algo *image_get_crypto_algo(const char 
> >*full_name);
> >  struct padding_algo *image_get_padding_algo(const char *name);
> >
> >  #if IMAGE_ENABLE_FIT
> >-
> 
> This change is unrelated. It should be in a separate patch. Or at least
> mention in the commit message that you cleaned up other parts of the code.

I don't want to get bothered with minor clean-up patches,
and will drop this hunk.

-Takahiro Akashi

> >  /**
> >   * fit_image_verify_required_sigs() - Verify signatures marked as 
> > 'required'
> >   *
> >@@ -1337,7 +1337,7 @@ static inline int fit_image_check_target_arch(const 
> >void *fdt, int node)
> >  #define fit_unsupported(msg)
> >  #define fit_unsupported_reset(msg)
> >  #endif /* CONFIG_FIT_VERBOSE */
> >-#endif /* CONFIG_FIT */
> >+#endif /* IMAGE_ENABLE_FIT */
> 
> Same here.
> 
> Best regards
> 
> Heinrich
> 
> >
> >  #if defined(CONFIG_ANDROID_BOOT_IMAGE)
> >  struct andr_img_hdr;
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 16/16] efi_loader, pytest: add UEFI secure boot tests (image)

2019-11-17 Thread AKASHI Takahiro
Heinrich,

On Sat, Nov 16, 2019 at 09:31:04PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:53 AM, AKASHI Takahiro wrote:
> >Provide test cases for
> >  * image authentication for signed images
> >(test_efi_secboot/test_signed.py)
> >  * image authentication for unsigned images
> >(test_efi_secboot/test_unsigned.py)
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  test/py/tests/test_efi_secboot/test_signed.py |  97 +
> >  .../tests/test_efi_secboot/test_unsigned.py   | 100 ++
> >  2 files changed, 197 insertions(+)
> >  create mode 100644 test/py/tests/test_efi_secboot/test_signed.py
> >  create mode 100644 test/py/tests/test_efi_secboot/test_unsigned.py
> >
> >diff --git a/test/py/tests/test_efi_secboot/test_signed.py 
> >b/test/py/tests/test_efi_secboot/test_signed.py
> >new file mode 100644
> >index ..00f539462eb8
> >--- /dev/null
> >+++ b/test/py/tests/test_efi_secboot/test_signed.py
> >@@ -0,0 +1,97 @@
> >+# SPDX-License-Identifier:  GPL-2.0+
> >+# Copyright (c) 2019, Linaro Limited
> >+# Author: AKASHI Takahiro 
> >+#
> >+# U-Boot UEFI: Signed Image Authentication Test
> >+
> >+"""
> >+This test verifies image authentication for signed images.
> >+"""
> >+
> >+import pytest
> >+import re
> >+from defs import *
> >+
> >+@pytest.mark.boardspec('sandbox')
> 
> Why would we only test on the sandbox? This leaves 32bit untested.

I commented on this issue on patch#15.

> >+@pytest.mark.buildconfigspec('efi_secure_boot')
> >+@pytest.mark.buildconfigspec('cmd_efidebug')
> >+@pytest.mark.buildconfigspec('cmd_fat')
> >+@pytest.mark.buildconfigspec('cmd_nvedit_efi')
> >+@pytest.mark.slow
> >+class TestEfiSignedImage(object):
> >+def test_efi_signed_image_auth1(self, u_boot_console, efi_boot_env):
> >+"""
> >+Test Case 1 - authenticated by db
> >+"""
> >+disk_img = efi_boot_env
> >+with u_boot_console.log.section('Test Case 1a'):
> >+# Test Case 1a, run signed image if no db/dbx
> >+output = u_boot_console.run_command_list([
> >+'host bind 0 %s' % disk_img,
> >+'efidebug boot add 1 HELLO1 host 0:1 /helloworld.efi.signed 
> >""',
> >+'efidebug boot next 1',
> >+'bootefi bootmgr'])
> >+assert(re.search('Hello, world!', ''.join(output)))
> >+
> >+with u_boot_console.log.section('Test Case 1b'):
> >+# Test Case 1b, run unsigned image if no db/dbx
> >+output = u_boot_console.run_command_list([
> >+'efidebug boot add 2 HELLO2 host 0:1 /helloworld.efi ""',
> >+'efidebug boot next 2',
> >+'bootefi bootmgr'])
> >+assert(re.search('Hello, world!', ''.join(output)))
> >+
> >+with u_boot_console.log.section('Test Case 1c'):
> >+# Test Case 1c, not authenticated by db
> >+output = u_boot_console.run_command_list([
> >+'fatload host 0:1 400 db.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize db',
> >+'fatload host 0:1 400 KEK.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize KEK',
> >+'fatload host 0:1 400 PK.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize PK'])
> >+assert(not re.search('Failed to set EFI variable', 
> >''.join(output)))
> >+output = u_boot_console.run_command_list([
> >+'efidebug boot next 2',
> >+'bootefi bootmgr'])
> >+assert(re.search('\'HELLO2\' failed', ''.join(output)))
> >+
> >+with u_boot_console.log.section('Test Case 1d'):
> >+# Test Case 1d, authenticated by db
> >+output = u_boot_console.run_command_list([
> >+'efidebug boot next 1',
> >+'bootefi bootmgr'])
> >+assert(re.search('Hello, world!', ''.join(output)))
> >+
> >+def test_efi_signed_image_auth2(self, u_boot_console, efi_boot_env):
> >+"""
> >+Test Case 2 - rejected by dbx
> >+"""
> >+disk_img = efi_boot_env
> >+with u_boot_console.log.section('Test Case 2a'):
> >+# Test Case 2a, rejected by dbx
> >+output = u_boot_console.run_command_list([
> >+'host bind 0 %s' % disk_img,
> >+'fatload host 0:1 400 db.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize dbx',
> >+'fatload host 0:1 400 KEK.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize KEK',
> >+'fatload host 0:1 400 PK.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize PK'])
> >+assert(not re.search('Failed to set EFI variable', 
> >''.join(output)))
> >+output = u_boot_console.run_command_list([
> >+'efidebug boot add 1 HELLO host 

Re: [U-Boot] [PATCH 15/16] efi_loader, pytest: add UEFI secure boot tests (authenticated variables)

2019-11-17 Thread AKASHI Takahiro
On Sat, Nov 16, 2019 at 09:28:56PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:53 AM, AKASHI Takahiro wrote:
> >Provide a couple of test cases for variable authentication.
> 
> Please, tell us more in the commit message.

About what?
I have lots of 'text case' descriptions in *.py files.

> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  .../py/tests/test_efi_secboot/test_authvar.py | 289 ++
> >  1 file changed, 289 insertions(+)
> >  create mode 100644 test/py/tests/test_efi_secboot/test_authvar.py
> >
> >diff --git a/test/py/tests/test_efi_secboot/test_authvar.py 
> >b/test/py/tests/test_efi_secboot/test_authvar.py
> >new file mode 100644
> >index ..ed18b80084d6
> >--- /dev/null
> >+++ b/test/py/tests/test_efi_secboot/test_authvar.py
> >@@ -0,0 +1,289 @@
> >+# SPDX-License-Identifier:  GPL-2.0+
> >+# Copyright (c) 2019, Linaro Limited
> >+# Author: AKASHI Takahiro 
> >+#
> >+# U-Boot UEFI: Variable Authentication Test
> >+
> >+"""
> >+This test verifies variable authentication
> >+"""
> >+
> >+import pytest
> >+import re
> >+from defs import *
> >+
> >+@pytest.mark.boardspec('sandbox')
> 
> Why can't we run this on other architectures?

As you see, we need some data files, most of which contain data for
signature database variables, to run test cases. Using sandbox
is the easiest way to minimize hardware requirements.

> The sandbox currently only runs in 64bit mode. This way we might miss
> errors that only occur on 32bit systems.

Right, but this is not my patch-specific issue.

> >+@pytest.mark.buildconfigspec('efi_secure_boot')
> >+@pytest.mark.buildconfigspec('cmd_fat')
> >+@pytest.mark.buildconfigspec('cmd_nvedit_efi')
> >+@pytest.mark.slow
> >+class TestEfiAuthVar(object):
> >+def test_efi_var_auth1(self, u_boot_console, efi_boot_env):
> >+"""
> >+Test Case 1 - Install signature database
> >+"""
> >+disk_img = efi_boot_env
> >+with u_boot_console.log.section('Test Case 1a'):
> >+# Test Case 1a, Initial secure state
> >+output = u_boot_console.run_command_list([
> >+'host bind 0 %s' % disk_img,
> >+'printenv -e SecureBoot'])
> >+assert(re.search(': 00', ''.join(output)))
> >+
> >+output = u_boot_console.run_command(
> >+'printenv -e SecureBoot')
> >+assert(': 00' in output)
> >+output = u_boot_console.run_command(
> >+'printenv -e SetupMode')
> >+assert(': 01' in output)
> >+
> >+with u_boot_console.log.section('Test Case 1b'):
> >+# Test Case 1b, PK without AUTHENTICATED_WRITE_ACCESS
> >+output = u_boot_console.run_command_list([
> >+'host bind 0 %s' % disk_img,
> >+'fatload host 0:1 400 PK.auth',
> >+'setenv -e -nv -bs -rt -i 400,$filesize PK'])
> >+assert(re.search('Failed to set EFI variable', ''.join(output)))
> >+
> >+with u_boot_console.log.section('Test Case 1c'):
> >+# Test Case 1c, install PK
> >+output = u_boot_console.run_command_list([
> >+'fatload host 0:1 400 PK.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize PK',
> >+'printenv -e PK'])
> >+assert(re.search('PK:', ''.join(output)))
> >+
> >+output = u_boot_console.run_command(
> >+'printenv -e SecureBoot')
> >+assert(': 01' in output)
> >+output = u_boot_console.run_command(
> >+'printenv -e SetupMode')
> >+assert(': 00' in output)
> >+
> >+with u_boot_console.log.section('Test Case 1d'):
> >+# Test Case 1d, db/dbx without KEK
> >+output = u_boot_console.run_command_list([
> >+'fatload host 0:1 400 db.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize db'])
> >+assert(re.search('Failed to set EFI variable', ''.join(output)))
> >+
> >+output = u_boot_console.run_command_list([
> >+'fatload host 0:1 400 db.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize dbx'])
> >+assert(re.search('Failed to set EFI variable', ''.join(output)))
> >+
> >+with u_boot_console.log.section('Test Case 1e'):
> >+# Test Case 1e, install KEK
> >+output = u_boot_console.run_command_list([
> >+'fatload host 0:1 400 KEK.auth',
> >+'setenv -e -nv -bs -rt -i 400,$filesize KEK'])
> >+assert(re.search('Failed to set EFI variable', ''.join(output)))
> >+
> >+output = u_boot_console.run_command_list([
> >+'fatload host 0:1 400 KEK.auth',
> >+'setenv -e -nv -bs -rt -at -i 400,$filesize KEK',
> >+'printenv -e KEK'])
> 

Re: [U-Boot] [PATCH 14/16] efi_loader, pytest: set up secure boot environment

2019-11-17 Thread AKASHI Takahiro
Heinrich,

On Sat, Nov 16, 2019 at 09:19:33PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:53 AM, AKASHI Takahiro wrote:
> >A fixture for UEFI secure boot tests (image authentication and variable
> >authentication) is defined. A small file system with test data in a single
> >partition formatted in fat is created.
> 
> Why do we need a file system? That seems overly complicated.

I disagree. As UEFI requires a support for file system, fat, assuming
that we can access a file system is fair enough.

> Can't we use tFTP to download the file you want to check like we do for
> helloworld.efi and grub.efi.

Let me ask the same question as you did.
Why do we need a network device?

> >
> >This test requires efitools v1.5.2 or later. If the system's efitools
> >is older, you have to build it on your own and define EFITOOLS_PATH.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  .travis.yml|   4 +
> >  test/py/README.md  |   4 +
> >  test/py/tests/test_efi_secboot/conftest.py | 128 +
> >  test/py/tests/test_efi_secboot/defs.py |  21 
> >  4 files changed, 157 insertions(+)
> >  create mode 100644 test/py/tests/test_efi_secboot/conftest.py
> >  create mode 100644 test/py/tests/test_efi_secboot/defs.py
> >
> >diff --git a/.travis.yml b/.travis.yml
> >index 1e9837869508..edb87fc6396d 100644
> >--- a/.travis.yml
> >+++ b/.travis.yml
> >@@ -38,6 +38,10 @@ addons:
> >  - libisl15
> >  - clang-7
> >  - srecord
> >+- coreutils
> >+- dosfstools
> >+- efitools
> >+- udisks2
> >
> >  install:
> >   # Clone uboot-test-hooks
> >diff --git a/test/py/README.md b/test/py/README.md
> >index 3cbe01b73e28..bb8d6c9d21dd 100644
> >--- a/test/py/README.md
> >+++ b/test/py/README.md
> >@@ -38,6 +38,10 @@ will be required.  The following is an incomplete list:
> >  | sudo OR guestmount |
> >  | e2fsprogs  |
> >  | dosfstools |
> >+| coreutils  |
> >+| efitools   |
> >+| sbsigntools|
> >+| udisks2|
> >
> >  Please use the apporirate commands for your distribution to match these 
> > tools
> >  up with the package that provides them.
> >diff --git a/test/py/tests/test_efi_secboot/conftest.py 
> >b/test/py/tests/test_efi_secboot/conftest.py
> >new file mode 100644
> >index ..e50f749ad1a6
> >--- /dev/null
> >+++ b/test/py/tests/test_efi_secboot/conftest.py
> >@@ -0,0 +1,128 @@
> >+# SPDX-License-Identifier:  GPL-2.0+
> >+# Copyright (c) 2019, Linaro Limited
> >+# Author: AKASHI Takahiro 
> >+
> >+import os
> >+import os.path
> >+import pytest
> >+import re
> >+from subprocess import call, check_call, check_output, CalledProcessError
> >+from defs import *
> >+
> >+#
> >+# Fixture for UEFI secure boot test
> >+#
> >+# NOTE: yield_fixture was deprecated since pytest-3.0
> >+@pytest.yield_fixture()
> 
> If it is deprecated, don't use it.

Okay, I have forgot to fix it.

-Takahiro Akashi

> https://docs.pytest.org/en/latest/yieldfixture.html
> 
> Best regards
> 
> Heinrich
> 
> >+def efi_boot_env(request, u_boot_config):
> >+"""Set up a file system to be used in UEFI secure boot test.
> >+
> >+Args:
> >+request: Pytest request object.
> >+u_boot_config: U-boot configuration.
> >+
> >+Return:
> >+A path to disk image to be used for testing
> >+"""
> >+global HELLO_PATH
> >+
> >+image_path = u_boot_config.persistent_data_dir
> >+image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME
> >+image_size = EFI_SECBOOT_IMAGE_SIZE
> >+part_size = EFI_SECBOOT_PART_SIZE
> >+fs_type = EFI_SECBOOT_FS_TYPE
> >+
> >+if HELLO_PATH == '':
> >+HELLO_PATH = u_boot_config.build_dir + 
> >'/lib/efi_loader/helloworld.efi'
> >+
> >+try:
> >+# create a disk/partition
> >+check_call('dd if=/dev/zero of=%s bs=1MiB count=%d'
> >+% (image_path, image_size), shell=True)
> >+check_call('sgdisk %s -n 1:0:+%dMiB'
> >+% (image_path, part_size), shell=True)
> >+# create a file system
> >+check_call('dd if=/dev/zero of=%s.tmp bs=1MiB count=%d'
> >+% (image_path, part_size), shell=True)
> >+check_call('mkfs -t %s %s.tmp' % (fs_type, image_path), shell=True)
> >+check_call('dd if=%s.tmp of=%s bs=1MiB seek=1 count=%d conv=notrunc'
> >+% (image_path, image_path, 1), shell=True)
> >+check_call('rm %s.tmp' % image_path, shell=True)
> >+out_data = check_output('udisksctl loop-setup -f %s -o %d'
> >+% (image_path, 1048576), shell=True).decode()
> >+m = re.search('(?<= as )(.*)\.', out_data)
> >+loop_dev = m.group(1)
> >+# print 'loop device is: %s' % loop_dev
> >+out_data = check_output('udisksctl info -b %s' % loop_dev, 
> >shell=True).decode()
> >+m = re.search('MountPoints:[ \t]+(.*)', out_data)
> >+   

Re: [U-Boot] flashing and testing u-boot on chromebook_bob

2019-11-17 Thread Simon Glass
Hi Sahaj,

On Sun, 17 Nov 2019 at 21:33, Sahaj Sarup  wrote:
>
> Hi All,
>
> I was wondering if you could answer a few questions regarding u-boot
> on Asus CP101 gru/bob ?
>
> - To test the u-boot image following README.chromium-chainload,
> should I expect output on the display or do I need
> CDD/SuzyQable Cable for serial?

The display should work OK. I don't think that device supports CCD.

>
> - The CONFIG_SYS_TEXT_BASE is currently 0x0020 but
> shouldn't it be CONFIG_SYS_TEXT_BASE=0x2100
> since its supposed to match CONFIG_KERNEL_START
> from /chromiumos/platform/depthcharge/board/gru/defconfig

Yes it is a bit annoying because the in-house bootloader doesn't
support FIT properly. As I recall you have to set it to the exact
address that it appears in the FIT.

>
> - In order to flash to spi, what's the procedure?

The chain load option doesn't use SPI flash. You actually sign the
image and put it into the kernel partition.

Not much help for you, but there is a new feature on more recent
Chromebooks called 'altfw' (alternative firmware) and if enabled, it
lets you press 1 to boot U-Boot (only in dev mode). It only works on
x86 devices so far and even then the device support is pretty basic if
it boots at all. But the good thing is that you can put things into
the altfw partition in SPI flash and they will boot without affecting
the device.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 01/16] include: pe.h: add signature-related definitions

2019-11-17 Thread AKASHI Takahiro
Heinrich,

On Sat, Nov 16, 2019 at 06:42:11PM +0100, Heinrich Schuchardt wrote:
> On 11/13/19 1:52 AM, AKASHI Takahiro wrote:
> >The index (IMAGE_DIRECTORY_ENTRY_CERTTABLE) in a table points to
> >a region containing authentication information (image's signature)
> >in PE format.
> >
> >WIN_CERTIFICATE structure defines an embedded signature format.
> >
> >Those definitions will be used in my UEFI secure boot patch.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  include/pe.h | 16 
> >  1 file changed, 16 insertions(+)
> >
> >diff --git a/include/pe.h b/include/pe.h
> >index bff3b0aa7a6c..650478ca78af 100644
> >--- a/include/pe.h
> >+++ b/include/pe.h
> >@@ -155,6 +155,7 @@ typedef struct _IMAGE_SECTION_HEADER {
> > uint32_t Characteristics;
> >  } IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
> >
> 
> Please, add a comment here:
> 
> /* Indices for Optional Header Data Directories */

Okay.

> >+#define IMAGE_DIRECTORY_ENTRY_CERTTABLE 4
> 
> Yes, 4 is the index of the certificate table. But EDK II calls this
> EFI_IMAGE_DIRECTORY_ENTRY_SECURITY. Should we use the same name to avoid
> confusion?

No. Because the naming is consistent with

> >  #define IMAGE_DIRECTORY_ENTRY_BASERELOC 5

this existing one.

> >
> >  typedef struct _IMAGE_BASE_RELOCATION
> >@@ -252,4 +253,19 @@ typedef struct _IMAGE_RELOCATION
> >  #define IMAGE_REL_AMD64_PAIR0x000F
> >  #define IMAGE_REL_AMD64_SSPAN32 0x0010
> >
> >+/* certificate appended to PE image */
> >+typedef struct _WIN_CERTIFICATE {
> 
> We do not capitalize structs. Please use 'win_certificate' (like Linux
> does).
> 
> >+uint32_t dwLength;
> >+uint16_t wRevision;
> >+uint16_t wCertificateType;
> >+uint8_t bCertificate[];
> 
> We do not use camelcase and type prefixes. Please, use the same
> component names as Linux (plus 'certificate' for your extra field).

nak.
Have you looked at 'pe.h' at all?
There are already bunch of use of camelcase's and capital names
since this file was first introduced by Alex.

> >+} WIN_CERTIFICATE, *LPWIN_CERTIFICATE;
> 
> Please, always make use of scripts/checkpatch.pl before submitting
> patches. It says 'WARNING: do not add new typedefs'.

ditto.
I have run scripts/cehckpatch.pl and dare to leave them unchanged.

> Please, avoid the typedefs.

No. this is also consistent with other typedef's.


> >+
> 
> The following defines are verbatim copies from Linux. Please, also copy
> the comment:
> 
> /* Definitions for the contents of the certs data block */

Okay.

> >+#define WIN_CERT_TYPE_PKCS_SIGNED_DATA  0x0002
> >+#define WIN_CERT_TYPE_EFI_OKCS115   0x0EF0
> >+#define WIN_CERT_TYPE_EFI_GUID  0x0EF1
> >+
> >+#define WIN_CERT_REVISION_1_0   0x0100
> >+#define WIN_CERT_REVISION_2_0   0x0200
> >+
> >  #endif /* _PE_H */
> >
> 
> Except for the style issues this looks ok.

Thank you for your comments.
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] rockchip: i2c: don't sent stop bit after each message

2019-11-17 Thread Vasily Khoruzhick
On Sun, Nov 17, 2019 at 7:26 PM David.Wu  wrote:
>
> Hi Vasily,
>
> 在 2019/11/17 3:32, Vasily Khoruzhick 写道:
> > + rk_i2c_send_stop_bit(i2c);
> > + rk_i2c_disable(i2c);
>
> I think it is better to also stop i2c if i2c xfer failed, how do you
> feel about it?

I'm not sure if it's a good idea to continue communication if we've
got a failure and sending a stop bit is continuing communication.

But I'm not an expert in i2c and I don't have any strong opinion on
that, so I can send v2 with change you proposed.

> @@ -356,11 +356,16 @@ static int rockchip_i2c_xfer(struct udevice *bus,
> struct i2c_msg *msg,
>  }
>  if (ret) {
>  debug("i2c_write: error sending\n");
> -   return -EREMOTEIO;
> +   ret = -EREMOTEIO;
> +   goto exit;
>  }
>  }
>
> -   return 0;
> +exit:
> +   rk_i2c_send_stop_bit(i2c);
> +   rk_i2c_disable(i2c);
> +
> +   return ret;
>   }
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [v5] armv8: ls1028ardb: enable DisplayPort Power support

2019-11-17 Thread Wen He
Enable DP_PWR signal to power the DP to HDMI converter cable.

Signed-off-by: Wen He 
---
 board/freescale/ls1028a/ls1028a.c | 12 
 include/configs/ls1028a_common.h  |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/board/freescale/ls1028a/ls1028a.c 
b/board/freescale/ls1028a/ls1028a.c
index 095971448f..9281717264 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -82,7 +82,19 @@ int board_init(void)
if (!i2c_get_chip_for_busnum(0, I2C_MUX_PCA_ADDR_PRI, 1, ))
dm_i2c_write(dev, 0x0b, , 1);
 #endif
+#endif
 
+#if defined(CONFIG_TARGET_LS1028ARDB)
+   u8 reg;
+
+   reg = QIXIS_READ(brdcfg[4]);
+   /*
+* Field | Function
+* 3 | DisplayPort Power Enable (net DP_PWR_EN):
+* DPPWR | 0= DP_PWR is enabled.
+*/
+   reg &= ~(DP_PWD_EN_DEFAULT_MASK);
+   QIXIS_WRITE(brdcfg[4], reg);
 #endif
return 0;
 }
diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h
index 40fcd22582..99f5c21689 100644
--- a/include/configs/ls1028a_common.h
+++ b/include/configs/ls1028a_common.h
@@ -192,6 +192,9 @@
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  3
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
 
+/* DisplayPort */
+#define DP_PWD_EN_DEFAULT_MASK  0x8
+
 #ifdef CONFIG_SECURE_BOOT
 #include 
 #endif
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [u-boot] [v4] armv8: ls1028ardb: enable DisplayPort Power support

2019-11-17 Thread Wen He


> -Original Message-
> From: Jagdish Gediya 
> Sent: 2019年11月18日 12:50
> To: Wen He ; u-boot@lists.denx.de;
> u-b...@linux.nxdi.nxp.com
> Cc: Wen He 
> Subject: RE: [u-boot] [v4] armv8: ls1028ardb: enable DisplayPort Power
> support
> 
> Hi Wen,
> 
> > -Original Message-
> > From: u-boot-boun...@linux.nxdi.nxp.com  > boun...@linux.nxdi.nxp.com> On Behalf Of Wen He
> > Sent: Wednesday, November 6, 2019 1:20 PM
> > To: u-boot@lists.denx.de; u-b...@linux.nxdi.nxp.com
> > Cc: Wen He 
> > Subject: [u-boot] [v4] armv8: ls1028ardb: enable DisplayPort Power
> > support
> >
> > Enable DP_PWR signal to power the DP to HDMI converter cable.
> >
> > Signed-off-by: Wen He 
> > ---
> >  board/freescale/ls1028a/ls1028a.c | 14 ++
> > include/configs/ls1028a_common.h  |  3 +++
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/board/freescale/ls1028a/ls1028a.c
> > b/board/freescale/ls1028a/ls1028a.c
> > index 095971448f..c71ed21e9f 100644
> > --- a/board/freescale/ls1028a/ls1028a.c
> > +++ b/board/freescale/ls1028a/ls1028a.c
> > @@ -83,6 +83,20 @@ int board_init(void)
> > dm_i2c_write(dev, 0x0b, , 1);
> >  #endif
> >
> Remove above unnecessary blank line.
> > +#endif
> > +
> > +#if defined(CONFIG_TARGET_LS1028ARDB)
> > +   u8 reg;
> > +
> > +   reg = QIXIS_READ(brdcfg[4]);
> > +   /*
> > +* Field | Function
> > +* 3 | DisplayPort Power Enable (net DP_PWR_EN):
> > +* DPPWR | 0= DP_PWR is enabled.
> > +*/
> > +   reg &= ~(DP_PWD_EN_DEFAULT_MASK);
> > +   QIXIS_WRITE(brdcfg[4], reg);
> > +
> Remove above unnecessary blank line too.

Understand, thanks.

Best Regards,
Wen
> >  #endif
> 
> --Jagdish
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [u-boot] [v4] armv8: ls1028ardb: enable DisplayPort Power support

2019-11-17 Thread Jagdish Gediya
Hi Wen,

> -Original Message-
> From: u-boot-boun...@linux.nxdi.nxp.com  boun...@linux.nxdi.nxp.com> On Behalf Of Wen He
> Sent: Wednesday, November 6, 2019 1:20 PM
> To: u-boot@lists.denx.de; u-b...@linux.nxdi.nxp.com
> Cc: Wen He 
> Subject: [u-boot] [v4] armv8: ls1028ardb: enable DisplayPort Power support
> 
> Enable DP_PWR signal to power the DP to HDMI converter cable.
> 
> Signed-off-by: Wen He 
> ---
>  board/freescale/ls1028a/ls1028a.c | 14 ++
> include/configs/ls1028a_common.h  |  3 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/board/freescale/ls1028a/ls1028a.c
> b/board/freescale/ls1028a/ls1028a.c
> index 095971448f..c71ed21e9f 100644
> --- a/board/freescale/ls1028a/ls1028a.c
> +++ b/board/freescale/ls1028a/ls1028a.c
> @@ -83,6 +83,20 @@ int board_init(void)
>   dm_i2c_write(dev, 0x0b, , 1);
>  #endif
> 
Remove above unnecessary blank line.
> +#endif
> +
> +#if defined(CONFIG_TARGET_LS1028ARDB)
> + u8 reg;
> +
> + reg = QIXIS_READ(brdcfg[4]);
> + /*
> +  * Field | Function
> +  * 3 | DisplayPort Power Enable (net DP_PWR_EN):
> +  * DPPWR | 0= DP_PWR is enabled.
> +  */
> + reg &= ~(DP_PWD_EN_DEFAULT_MASK);
> + QIXIS_WRITE(brdcfg[4], reg);
> +
Remove above unnecessary blank line too.
>  #endif

--Jagdish
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

2019-11-17 Thread Qu Wenruo


On 2019/11/18 上午10:51, Kever Yang wrote:
> Hi Qu Wenruo,
> 
> 
>     Please try with latest u-boot-rockchip with dram and board fix merged:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git master branch

Thanks, I'll take a try if it can compile on Arch, (as dtc include
changed on Arch, and that's the reason I'm sticking to upstream U-boot)

> 
> 
>     Did you try with rkbin ddr.bin instead of TPL and keep other
> firmware(SPL, U-Boot, ATF),

Always using rkbin + miniloader version.
Never tried the other boot flow, due to the need to compile using M0
toolchain (I'm doing native compile, and Archlinuxarm doesn't provide M0
toolchain for aarch64 platform).

Thanks,
Qu

> 
> this can confirm if there is something wrong in TPL dram driver or not.
> 
> 
> Thanks,
> 
> - Kever
> 
> On 2019/11/16 下午1:39, Qu Wenruo wrote:
>> On 2019/11/16 下午1:16, Qu Wenruo wrote:
>>> On 2019/11/15 下午10:59, Anand Moon wrote:
 Hi Qu Wenruo,

 On Fri, 15 Nov 2019 at 17:27, Qu Wenruo  wrote:
>
> On 2019/11/15 下午6:37, Qu Wenruo wrote:
>> A small update to this bug.
>>
>> I'm using mem=3584M kernel cmdline, to sacrifice 512M memory.
>>
>> And then surprise, memtest 3G works. (Originally it's 4G physical ram
>> and 3584M memtest.
>>
>> Hopes this could provide some clue.
> Oh no, with 3187M, it still crashes with SError.
>
> So still no luck.
>
> Thanks,
> Qu
 Please this following series of patches for fix this error.
 It fixed issue of SError on my board.
>>> Would you mind to share which commit it is based?
>>>
>>> For v2019.10 tag, it fails at the 13th patch.
>>> The same happened for current master.
>> Well, manually solved the conflicts.
>>
>> If anyone is interested in using that, I have uploaded it to github,
>> which is based on v2019.10 tag:
>>
>> https://github.com/adam900710/u-boot/tree/serror_fixes
>>
>> Unfortunately, still crashed for memtester 3584M.
>>
>> Thanks,
>> Qu
>>
>>> Thanks,
>>> Qu
 [0] https://patchwork.ozlabs.org/cover/1195284/

 Best Regards
 -Anand

>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] rockchip: i2c: don't sent stop bit after each message

2019-11-17 Thread David.Wu

Hi Vasily,

在 2019/11/17 3:32, Vasily Khoruzhick 写道:

+   rk_i2c_send_stop_bit(i2c);
+   rk_i2c_disable(i2c);


I think it is better to also stop i2c if i2c xfer failed, how do you 
feel about it?


@@ -356,11 +356,16 @@ static int rockchip_i2c_xfer(struct udevice *bus, 
struct i2c_msg *msg,

    }
    if (ret) {
    debug("i2c_write: error sending\n");
-   return -EREMOTEIO;
+   ret = -EREMOTEIO;
+   goto exit;
    }
    }

-   return 0;
+exit:
+   rk_i2c_send_stop_bit(i2c);
+   rk_i2c_disable(i2c);
+
+   return ret;
 }



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V4 1/2] rockchip: dts: tinker: Move u-boot dmc initialization to specific section【请注意,邮件由u-boot-boun...@lists.denx.de代发】

2019-11-17 Thread Kever Yang


On 2019/11/17 下午5:12, Kever Yang wrote:


On 2019/11/16 上午5:07, Michael Trimarchi wrote:

dmc is used to initialize the memory controller. It's needed by
u-boot. Move it in the specific section

Signed-off-by: Michael Trimarchi 

Reviewed-by: Kever Yang 


Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever

---
Changes:
nothing
---
  arch/arm/dts/rk3288-tinker-u-boot.dtsi | 12 
  arch/arm/dts/rk3288-tinker.dts | 12 
  2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/dts/rk3288-tinker-u-boot.dtsi 
b/arch/arm/dts/rk3288-tinker-u-boot.dtsi

index f7f9d6dc72..732aa4f91f 100644
--- a/arch/arm/dts/rk3288-tinker-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-tinker-u-boot.dtsi
@@ -5,6 +5,18 @@
    #include "rk3288-u-boot.dtsi"
  + {
+    u-boot,dm-pre-reloc;
+    rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+    0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+    0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+    0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+    0x8 0x1f4>;
+    rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+    0x0 0xc3 0x6 0x2>;
+    rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
   {
  u-boot,dm-pre-reloc;
  };
diff --git a/arch/arm/dts/rk3288-tinker.dts 
b/arch/arm/dts/rk3288-tinker.dts

index 94c3afe860..4b8405fd82 100644
--- a/arch/arm/dts/rk3288-tinker.dts
+++ b/arch/arm/dts/rk3288-tinker.dts
@@ -15,18 +15,6 @@
  };
  };
  - {
-    rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
-    0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
-    0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
-    0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
-    0x8 0x1f4>;
-    rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
-    0x0 0xc3 0x6 0x2>;
-    rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
-};
-
-
   {
  usb {
  host_vbus_drv: host-vbus-drv {



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V4 2/2] rockchip: dts: tinker: Add tinker-s board support【请注意,邮件由u-boot-boun...@lists.denx.de代发】 board support

2019-11-17 Thread Kever Yang


On 2019/11/17 下午5:12, Kever Yang wrote:


On 2019/11/16 上午5:07, Michael Trimarchi wrote:

Support tinker-s board. The board is equivalent of tinker board
except of emmc.

TODO:
- support of usb current burst when the board is powered from pc

Signed-off-by: Michael Trimarchi 

Reviewed-by: Kever Yang 


Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever

---
Changes:
v3->v4: Add mantainer and boot from to save the enviroment
v2->v3: drop dmc section
v1->v2: Add boot configuration for emmc
---
  arch/arm/dts/Makefile    |  1 +
  arch/arm/dts/rk3288-tinker-s-u-boot.dtsi | 34 +++
  arch/arm/dts/rk3288-tinker-s.dts | 29 ++
  board/rockchip/tinker_rk3288/MAINTAINERS |  7 ++
  board/rockchip/tinker_rk3288/tinker-rk3288.c | 12 +++
  configs/tinker-s-rk3288_defconfig    | 99 
  include/configs/tinker_rk3288.h  |  1 +
  7 files changed, 183 insertions(+)
  create mode 100644 arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3288-tinker-s.dts
  create mode 100644 configs/tinker-s-rk3288_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85ef00a2bd..dfaeea4a25 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
  rk3288-popmetal.dtb \
  rk3288-rock2-square.dtb \
  rk3288-tinker.dtb \
+    rk3288-tinker-s.dtb \
  rk3288-veyron-jerry.dtb \
  rk3288-veyron-mickey.dtb \
  rk3288-veyron-minnie.dtb \
diff --git a/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi 
b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi

new file mode 100644
index 00..a177fca73a
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Amarula Solutions SRO
+ */
+
+#include "rk3288-u-boot.dtsi"
+#include "rk3288-tinker-u-boot.dtsi"
+
+/ {
+    chosen {
+    u-boot,spl-boot-order = \
+    "same-as-spl", , 
+    };
+};
+
+ {
+    u-boot,dm-spl;
+};
+
+_clk {
+    u-boot,dm-spl;
+};
+
+_cmd {
+    u-boot,dm-spl;
+};
+
+_pwr {
+    u-boot,dm-spl;
+};
+
+_bus8 {
+    u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3288-tinker-s.dts 
b/arch/arm/dts/rk3288-tinker-s.dts

new file mode 100644
index 00..cc7ac5f881
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "rk3288-tinker.dtsi"
+
+/ {
+    model = "Rockchip RK3288 Asus Tinker Board S";
+    compatible = "asus,rk3288-tinker-s", "rockchip,rk3288";
+
+    chosen {
+    stdout-path = 
+    };
+};
+
+ {
+    bus-width = <8>;
+    cap-mmc-highspeed;
+    non-removable;
+    pinctrl-names = "default";
+    pinctrl-0 = <_clk _cmd _pwr _bus8>;
+    max-frequency = <15000>;
+    mmc-hs200-1_8v;
+    mmc-ddr-1_8v;
+    status = "okay";
+};
diff --git a/board/rockchip/tinker_rk3288/MAINTAINERS 
b/board/rockchip/tinker_rk3288/MAINTAINERS

index cddceafb6e..ed5de682c9 100644
--- a/board/rockchip/tinker_rk3288/MAINTAINERS
+++ b/board/rockchip/tinker_rk3288/MAINTAINERS
@@ -4,3 +4,10 @@ S:    Maintained
  F:    board/rockchip/tinker_rk3288
  F:    include/configs/tinker_rk3288.h
  F:    configs/tinker-rk3288_defconfig
+
+TINKER-S-RK3288
+M:    Michael Trimarchi 
+S:    Maintained
+F:    board/rockchip/tinker_rk3288
+F:    include/configs/tinker_rk3288.h
+F:    configs/tinker-s-rk3288_defconfig
diff --git a/board/rockchip/tinker_rk3288/tinker-rk3288.c 
b/board/rockchip/tinker_rk3288/tinker-rk3288.c

index 6c76c3c25c..7a0c3c997d 100644
--- a/board/rockchip/tinker_rk3288/tinker-rk3288.c
+++ b/board/rockchip/tinker_rk3288/tinker-rk3288.c
@@ -8,6 +8,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
    static int get_ethaddr_from_eeprom(u8 *addr)
  {
@@ -33,3 +35,13 @@ int rk3288_board_late_init(void)
    return 0;
  }
+
+int mmc_get_env_dev(void)
+{
+    u32 bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+
+    if (bootdevice_brom_id == BROM_BOOTSOURCE_EMMC)
+    return 0;
+
+    return 1;
+}
diff --git a/configs/tinker-s-rk3288_defconfig 
b/configs/tinker-s-rk3288_defconfig

new file mode 100644
index 00..c851a93f31
--- /dev/null
+++ b/configs/tinker-s-rk3288_defconfig
@@ -0,0 +1,99 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ROCKCHIP_RK3288=y
+CONFIG_TARGET_TINKER_RK3288=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_SIZE_LIMIT=307200
+CONFIG_SPL_STACK_R_ADDR=0x80
+CONFIG_DEBUG_UART_BASE=0xff69
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART=y
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SILENT_CONSOLE=y
+CONFIG_CONSOLE_MUX=y
+CONFIG_DEFAULT_FDT_FILE="rk3288-tinker-s.dtb"

Re: [U-Boot] [PATCH v3 00/22] rockchip: ram: add common code for sdram driver【请注意,邮件由kever.y...@gmail.com代发】

2019-11-17 Thread Kever Yang


On 2019/11/15 上午11:04, Kever Yang wrote:

The sdram drivers for Rockchip SoCs was all separate, some of the SoCs
has similar hardware controller and phy, so we have a change to share
the flow and some of the functions between different SoCs.
This patch set implement a first version common code based on PX30,
other SoCs has similar hardware can migrate to this common code, eg.
rk3328 and rk3399 can use this common code.

This patch set also fix some bug for rk3399 by sync code from latest
rockchip vendor code.

V3 split the patch in more detail, and also fix support for px30.


Changes in v3:
- add dm based driver for non-TPL and update commit message
- split code other than migration to separate patches.
- update commit message

Changes in v2:
- Split the patches into multi smaller patches for easy to maintain,
review and test;
- Keep the DRAM_ROCKCHIP_DEBUG macro and enable it by default;
- Update the rockchip_sdram_size to support sys_reg3;

Kever Yang (14):
   ram: rockchip: rename sdram.h to sdram_rk3288.h
   ram: rockchip: rename sdram_common.c/h to sdram.c
   rockchip: sdram: move cap structure and debug function to
 sdram_common.h
   rockchip: sdram: extend to use sys_reg3 for capacity info
   rockchip: sdram: update the sys_reg to sys_reg2
   ram: rockchip: add common code for sdram driver
   ram: rockchip: move sdram_debug function into sdram_common
   ram: rockchip: Default enable DRAM debug info
   ram: rockchip: add controller code for PX30
   ram: rockchip: add phy driver code for PX30
   ram: rockchip: add common msch reg definition
   ram: rockchip: update lpddr4 timing for rk3399
   ram: rk3399: Sync the io setting from Rockchip vendor code
   ram: rk3399: update calculate_stride

YouMin Chen (8):
   ram: px30: add sdram driver
   ram: rk3328: use common sdram driver
   ram: rk3399: migrate to use common code
   ram: rk3399: Clean up code
   ram: rk3399: fix error about get_ddrc0_con reg addr
   ram: rk3399: update the function of sdram_init
   ram: rk3399: add support detect capacity
   ram: rk3399: Fix dram setting to make dram more stable


Applied to u-boot-rockchip master.

Thanks,
- Kever


  arch/arm/dts/rk3328-sdram-ddr3-666.dtsi   |4 +
  arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi|4 +
  arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi |4 +
  arch/arm/dts/rk3399-sdram-ddr3-1333.dtsi  |4 +
  arch/arm/dts/rk3399-sdram-ddr3-1600.dtsi  |4 +
  arch/arm/dts/rk3399-sdram-ddr3-1866.dtsi  |4 +
  .../arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi |4 +
  .../arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi |4 +
  .../rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi |4 +
  arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi |4 +
  arch/arm/include/asm/arch-rockchip/sdram.h|  168 ++-
  .../include/asm/arch-rockchip/sdram_common.h  |  116 +-
  .../include/asm/arch-rockchip/sdram_msch.h|   85 ++
  .../asm/arch-rockchip/sdram_pctl_px30.h   |  139 ++
  .../asm/arch-rockchip/sdram_phy_px30.h|   62 +
  .../arch-rockchip/sdram_phy_ron_rtt_px30.h|   59 +
  .../include/asm/arch-rockchip/sdram_px30.h|  134 ++
  .../include/asm/arch-rockchip/sdram_rk3288.h  |  102 ++
  .../include/asm/arch-rockchip/sdram_rk3328.h  |  420 ++
  .../include/asm/arch-rockchip/sdram_rk3399.h  |   98 +-
  arch/arm/mach-rockchip/Kconfig|2 +
  arch/arm/mach-rockchip/Makefile   |2 +-
  arch/arm/mach-rockchip/rk3036/rk3036.c|2 +-
  arch/arm/mach-rockchip/rk3288/rk3288.c|2 +-
  .../mach-rockchip/{sdram_common.c => sdram.c} |   85 +-
  arch/arm/mach-rockchip/spl.c  |1 -
  configs/evb-rk3328_defconfig  |2 +-
  configs/rock64-rk3328_defconfig   |2 +-
  drivers/ram/Kconfig   |2 +-
  drivers/ram/rockchip/Kconfig  |   17 +-
  drivers/ram/rockchip/Makefile |7 +-
  drivers/ram/rockchip/dmc-rk3368.c |2 +-
  .../rockchip/sdram-px30-ddr3-detect-333.inc   |   72 +
  .../rockchip/sdram-px30-ddr4-detect-333.inc   |   75 +
  drivers/ram/rockchip/sdram-px30-ddr_skew.inc  |  121 ++
  .../rockchip/sdram-px30-lpddr2-detect-333.inc |   73 +
  .../rockchip/sdram-px30-lpddr3-detect-333.inc |   74 +
  .../ram/rockchip/sdram-rk3399-lpddr4-400.inc  |   28 +-
  .../ram/rockchip/sdram-rk3399-lpddr4-800.inc  |   28 +-
  drivers/ram/rockchip/sdram_common.c   |  429 ++
  drivers/ram/rockchip/sdram_debug.c|  147 --
  drivers/ram/rockchip/sdram_pctl_px30.c|  205 +++
  drivers/ram/rockchip/sdram_phy_px30.c |  205 +++
  drivers/ram/rockchip/sdram_px30.c |  751 +++
  drivers/ram/rockchip/sdram_rk3128.c   |2 +-
  drivers/ram/rockchip/sdram_rk3188.c   |2 +-
  drivers/ram/rockchip/sdram_rk322x.c   |2 +-
  drivers/ram/rockchip/sdram_rk3288.c   |2 +-
  drivers/ram/rockchip/sdram_rk3328.c   |  765 

Re: [U-Boot] rockchip: rk3399: TPL: rockpro64: Wrong memory size detected【请注意,邮件由lists.intric...@gmail.com代发】

2019-11-17 Thread Kever Yang

Hi Kurt,

On 2019/11/14 上午2:44, Kurt Miller wrote:

On Tue, 2019-09-17 at 12:02 -0400, Kurt Miller wrote:

On Tue, 2019-09-17 at 10:57 +0800, Kever Yang wrote:

Hi Kurt,

  Could you try with below update:


diff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
index 4a4414a960..dc9db047cb 100644
--- a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
+++ b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
@@ -13,8 +13,8 @@
                  0x2
                  0x1
                  0x0
-               0xf
-               0xf
+               0x10
+               0x10
                  1
                  0x80241d22
                  0x15050f08
@@ -28,8 +28,8 @@
                  0x2
                  0x1
                  0x0
-               0xf
-               0xf
+               0x10
+               0x10
                  1
                  0x80241d22
                  0x15050f08

Thanks,
- Kever

Hi Kever,

Yes, that diff does correct the memory size detection
for my board:

U-Boot TPL 2019.10-rc3-00332-ga314ec1bfd-dirty (Sep 17 2019 - 11:55:26)
con reg
cru , cic , grf , sgrf , pmucru , pmu
Starting SDRAM initialization...
sdram_init: data trained for rank 1, ch 0
sdram_init: data trained for rank 1, ch 1
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
256B stride
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 400 mhz 0, 1
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 800 mhz 1, 0
Finish SDRAM initialization...
Trying to boot from BOOTROM
Returning to boot ROM...

Hi Kever,

Following up on this issue. I retested 2020.01-rc2 to see if
memory size detection has been fixed yet. Without your diff above
applied, 2020.01-rc2 still detects 2G memory instead of 4G:



Could you try with latest u-boot-rockchip?

https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git


Thanks,

- Kever



U-Boot TPL 2020.01-rc2-dirty (Nov 13 2019 - 13:18:40)
con reg ffa8 ffa80800 ffa82000 ffa84000 ffa88000 ffa88800 ffa8a000 ffa8c000
cru ff76, cic ff62, grf ff32, sgrf ff33, pmucru ff75, pmu 
ff31
Starting SDRAM initialization...
sdram_init: data trained for rank 1, ch 0
sdram_init: data trained for rank 1, ch 1
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 400 mhz 0, 1
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 800 mhz 1, 0
Finish SDRAM initialization...
Trying to boot from BOOTROM
Returning to boot ROM...

With your diff above applied I get 4G correctly:

U-Boot TPL 2020.01-rc2-dirty (Nov 13 2019 - 13:23:22)
con reg ffa8 ffa80800 ffa82000 ffa84000 ffa88000 ffa88800 ffa8a000 ffa8c000
cru ff76, cic ff62, grf ff32, sgrf ff33, pmucru ff75, pmu 
ff31
Starting SDRAM initialization...
sdram_init: data trained for rank 1, ch 0
sdram_init: data trained for rank 1, ch 1
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
256B stride
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 400 mhz 0, 1
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 800 mhz 1, 0
Finish SDRAM initialization...
Trying to boot from BOOTROM
Returning to boot ROM...

Regards,
-Kurt




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] rockchip: clk: fix wrong CONFIG_IS_ENABLED handling

2019-11-17 Thread Kever Yang


On 2019/11/9 上午7:06, Heiko Stuebner wrote:

CONFIG_IS_ENABLED() needs the config name like used in Kconfig, so
without the leading CONFIG_. The clock drivers all wrongly check for
CONFIG_RESET_ROCKCHIP, fix that

Signed-off-by: Heiko Stuebner 
Reviewed-by: Kever Yang 

Applied to u-boot-rockchip master.

Thanks,
- Kever

---
  drivers/clk/rockchip/clk_rk3036.c | 2 +-
  drivers/clk/rockchip/clk_rk3188.c | 2 +-
  drivers/clk/rockchip/clk_rk322x.c | 2 +-
  drivers/clk/rockchip/clk_rk3288.c | 2 +-
  drivers/clk/rockchip/clk_rk3328.c | 2 +-
  drivers/clk/rockchip/clk_rk3368.c | 2 +-
  drivers/clk/rockchip/clk_rk3399.c | 2 +-
  drivers/clk/rockchip/clk_rv1108.c | 2 +-
  8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3036.c 
b/drivers/clk/rockchip/clk_rk3036.c
index 9bf9cedaf8..6d5ae3d003 100644
--- a/drivers/clk/rockchip/clk_rk3036.c
+++ b/drivers/clk/rockchip/clk_rk3036.c
@@ -352,7 +352,7 @@ static int rk3036_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3036_cru, cru_softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 9);
if (ret)
diff --git a/drivers/clk/rockchip/clk_rk3188.c 
b/drivers/clk/rockchip/clk_rk3188.c
index dda686cfb3..3ea9a81b32 100644
--- a/drivers/clk/rockchip/clk_rk3188.c
+++ b/drivers/clk/rockchip/clk_rk3188.c
@@ -590,7 +590,7 @@ static int rk3188_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3188_cru, cru_softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 9);
if (ret)
diff --git a/drivers/clk/rockchip/clk_rk322x.c 
b/drivers/clk/rockchip/clk_rk322x.c
index f09730c91b..6e8a164d62 100644
--- a/drivers/clk/rockchip/clk_rk322x.c
+++ b/drivers/clk/rockchip/clk_rk322x.c
@@ -508,7 +508,7 @@ static int rk322x_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk322x_cru, cru_softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 9);
if (ret)
diff --git a/drivers/clk/rockchip/clk_rk3288.c 
b/drivers/clk/rockchip/clk_rk3288.c
index 0122381633..85d1b67e43 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -1015,7 +1015,7 @@ static int rk3288_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3288_cru, cru_softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 12);
if (ret)
diff --git a/drivers/clk/rockchip/clk_rk3328.c 
b/drivers/clk/rockchip/clk_rk3328.c
index 4331048a87..e700a1bc25 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -791,7 +791,7 @@ static int rk3328_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3328_cru, softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 12);
if (ret)
diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index c1a867b2ed..b51d529ade 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -620,7 +620,7 @@ static int rk3368_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3368_cru, softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 15);
if (ret)
diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index a273bd1beb..9020a9f202 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -1195,7 +1195,7 @@ static int rk3399_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3399_cru, softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 21);
if (ret)
diff --git a/drivers/clk/rockchip/clk_rv1108.c 
b/drivers/clk/rockchip/clk_rv1108.c
index b1e8208d54..6019bfc6ce 100644
--- a/drivers/clk/rockchip/clk_rv1108.c
+++ b/drivers/clk/rockchip/clk_rv1108.c
@@ -696,7 +696,7 @@ static int rv1108_clk_bind(struct udevice *dev)
sys_child->priv = priv;
}
  
-#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)

+#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rv1108_cru, softrst_con[0]);
ret = rockchip_reset_bind(dev, ret, 13);
if (ret)


Re: [U-Boot] [PATCH] configs: Rename roc-rk3399-pc -> roc-pc-rk3399 defconfig【请注意,邮件由linux-rockchip-bounces+kever.yang=rock-chips....@lists.infradead.org代发】

2019-11-17 Thread Kever Yang


On 2019/11/13 下午5:13, Kever Yang wrote:


On 2019/11/2 下午12:49, Jagan Teki wrote:

roc-rk3399-pc_defconfig is committed in below

commit <8a681f4c5aa15db51ad0209734859c9fe7c29cfd> ("rockchip: rk3399:
Add ROC-RK3399-PC support")

which doesn't follow the existing defconfigs on rk3399.

So, rename as followed with other rk3399 defconfigs.

Cc: Levin Du 
Signed-off-by: Jagan Teki 



The board name is roc-rk3399-pc, but we do update this in dts as 
{soc}-{board}.dts


and {board}-{soc}_defconfig  for all boards already have, so


Reviewed-by: Kever Yang 

Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever

---
  board/rockchip/evb_rk3399/MAINTAINERS    | 2 +-
  configs/{roc-rk3399-pc_defconfig => roc-pc-rk3399_defconfig} | 0
  2 files changed, 1 insertion(+), 1 deletion(-)
  rename configs/{roc-rk3399-pc_defconfig => roc-pc-rk3399_defconfig} 
(100%)


diff --git a/board/rockchip/evb_rk3399/MAINTAINERS 
b/board/rockchip/evb_rk3399/MAINTAINERS

index f8299d9460..17dfafb743 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -52,7 +52,7 @@ F:    arch/arm/dts/rk3399-orangepi-u-boot.dtsi
  ROC-RK3399-PC
  M:    Levin Du 
  S:    Maintained
-F:    configs/roc-rk3399-pc_defconfig
+F:    configs/roc-pc-rk3399_defconfig
  F:    arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
    ROCK-PI-4
diff --git a/configs/roc-rk3399-pc_defconfig 
b/configs/roc-pc-rk3399_defconfig

similarity index 100%
rename from configs/roc-rk3399-pc_defconfig
rename to configs/roc-pc-rk3399_defconfig




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] rockchip: clk: rv1108: remove duplicate reset init【请注意,邮件由u-boot-boun...@lists.denx.de代发】 reset init

2019-11-17 Thread Kever Yang


On 2019/11/13 下午5:08, Kever Yang wrote:


On 2019/11/9 上午7:06, Heiko Stuebner wrote:

rockchip_reset_bind() already does the needed init for the reset
registers, only referenced the wrong cru structure.

So we can get rid of the open-coded reset init and just fix
the correct cru reference.

Signed-off-by: Heiko Stuebner 


Reviewed-by: Kever Yang 

Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever

---
changes in v2:
- drop the now unused old softreset_reg struct
   softresets are only used inside the softreset driver and
   have their own separate struct

  arch/arm/include/asm/arch-rockchip/clock.h |  6 --
  drivers/clk/rockchip/clk_rv1108.c  | 14 +-
  2 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/clock.h 
b/arch/arm/include/asm/arch-rockchip/clock.h

index 0eb19ca86f..1d5b3a07d0 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -43,12 +43,6 @@ struct sysreset_reg {
  unsigned int glb_srst_snd_value;
  };
  -struct softreset_reg {
-    void __iomem *base;
-    unsigned int sf_reset_offset;
-    unsigned int sf_reset_num;
-};
-
  /**
   * clk_get_divisor() - Calculate the required clock divisior
   *
diff --git a/drivers/clk/rockchip/clk_rv1108.c 
b/drivers/clk/rockchip/clk_rv1108.c

index 3ebb007fab..b1e8208d54 100644
--- a/drivers/clk/rockchip/clk_rv1108.c
+++ b/drivers/clk/rockchip/clk_rv1108.c
@@ -681,7 +681,6 @@ static int rv1108_clk_bind(struct udevice *dev)
  int ret;
  struct udevice *sys_child, *sf_child;
  struct sysreset_reg *priv;
-    struct softreset_reg *sf_priv;
    /* The reset driver does not have a device node, so bind it 
here */

  ret = device_bind_driver(dev, "rockchip_sysreset", "sysreset",
@@ -698,22 +697,11 @@ static int rv1108_clk_bind(struct udevice *dev)
  }
    #if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)
-    ret = offsetof(struct rk3368_cru, softrst_con[0]);
+    ret = offsetof(struct rv1108_cru, softrst_con[0]);
  ret = rockchip_reset_bind(dev, ret, 13);
  if (ret)
  debug("Warning: software reset driver bind faile\n");
  #endif
-    ret = device_bind_driver_to_node(dev, "rockchip_reset", "reset",
- dev_ofnode(dev), _child);
-    if (ret) {
-    debug("Warning: No rockchip reset driver: ret=%d\n", ret);
-    } else {
-    sf_priv = malloc(sizeof(struct softreset_reg));
-    sf_priv->sf_reset_offset = offsetof(struct rv1108_cru,
-    softrst_con[0]);
-    sf_priv->sf_reset_num = 13;
-    sf_child->priv = sf_priv;
-    }
    return 0;
  }



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] rockchip: dts: rk3399-firefly: move u-boot, spl-boot-order to to the u-boot.dtsi【请注意,邮件由u-boot-boun...@lists.denx.de代发】

2019-11-17 Thread Kever Yang


On 2019/11/10 下午10:35, Kever Yang wrote:


On 2019/11/10 上午4:30, Peter Robinson wrote:

The u-boot specific device tree directives should be in u-boot.dtsi

Signed-off-by: Peter Robinson 


Reviewed-by: Kever Yang 

Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever

---
  arch/arm/dts/rk3399-firefly-u-boot.dtsi | 6 ++
  arch/arm/dts/rk3399-firefly.dts | 1 -
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3399-firefly-u-boot.dtsi 
b/arch/arm/dts/rk3399-firefly-u-boot.dtsi

index 67b63a8352..38e0897db9 100644
--- a/arch/arm/dts/rk3399-firefly-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
@@ -5,3 +5,9 @@
    #include "rk3399-u-boot.dtsi"
  #include "rk3399-sdram-ddr3-1600.dtsi"
+
+/ {
+    chosen {
+    u-boot,spl-boot-order = "same-as-spl", , 
+    };
+};
diff --git a/arch/arm/dts/rk3399-firefly.dts 
b/arch/arm/dts/rk3399-firefly.dts

index a4cb64f8bd..89c67fd24c 100644
--- a/arch/arm/dts/rk3399-firefly.dts
+++ b/arch/arm/dts/rk3399-firefly.dts
@@ -14,7 +14,6 @@
    chosen {
  stdout-path = 
-    u-boot,spl-boot-order = "same-as-spl", , 
  };
    backlight: backlight {



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] rockchip: dts: rk3399-evb: move u-boot, spl-boot-order to to the u-boot.dtsi【请注意,邮件由u-boot-boun...@lists.denx.de代发】

2019-11-17 Thread Kever Yang


On 2019/11/10 下午10:35, Kever Yang wrote:


On 2019/11/10 上午4:30, Peter Robinson wrote:

The u-boot specific device tree directives should be in u-boot.dtsi

Signed-off-by: Peter Robinson 


Reviewed-by: Kever Yang 

Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever

---
  arch/arm/dts/rk3399-evb-u-boot.dtsi | 6 ++
  arch/arm/dts/rk3399-evb.dts | 2 --
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi 
b/arch/arm/dts/rk3399-evb-u-boot.dtsi

index 20910e744b..ccb33d34d1 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -5,3 +5,9 @@
    #include "rk3399-u-boot.dtsi"
  #include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
+
+/ {
+    chosen {
+    u-boot,spl-boot-order = , 
+    };
+};
diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index a506e8da37..8e887f3a17 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -15,8 +15,6 @@
    chosen {
  stdout-path = 
-    u-boot,spl-boot-order = \
-    , 
  };
    vdd_center: vdd-center {



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] rockchip: dts: rk3399: move the u-boot, dm-pre-reloc to the u-boot.dtsi

2019-11-17 Thread Kever Yang


On 2019/11/10 下午10:52, Peter Robinson wrote:

On Sun, Nov 10, 2019 at 2:35 PM Kever Yang  wrote:


On 2019/11/10 上午4:30, Peter Robinson wrote:

The u-boot specific pieces in the dts files should be in u-boot.dtsi
not the main files, this allows easier sync with upstream. The
rk3399.dtsi has a mix of both so move them all for consistency.

Signed-off-by: Peter Robinson 

Reviewed-by: Kever Yang 

This has a typo in it, it's a simple fix (see below), do you want me
to send another version or can you fix it up inline?

Applied to u-boot-rockchip master with typo fix.

Thanks,
- Kever



Thanks,
- Kever

---
   arch/arm/dts/rk3399-u-boot.dtsi | 44 +
   arch/arm/dts/rk3399.dtsi| 11 -
   2 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 2738a3889e..3ec66c6fc3 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -3,10 +3,46 @@
* Copyright (C) 2019 Jagan Teki 
*/

+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
   u-boot,dm-pre-reloc;
   };

+ {

The above should be  not crc. Basically s/pmucrc/pmucru/


+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
   u-boot,dm-pre-reloc;
   };
@@ -22,3 +58,11 @@
{
   u-boot,dm-pre-reloc;
   };
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index b73442ee34..3f773b10f4 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -275,7 +275,6 @@
   };

   sdhci: sdhci@fe33 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
   reg = <0x0 0xfe33 0x0 0x1>;
   interrupts = ;
@@ -1072,7 +1071,6 @@
   };

   pmugrf: syscon@ff32 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
   reg = <0x0 0xff32 0x0 0x1000>;

@@ -1083,7 +1081,6 @@
   };

   pmusgrf: syscon@ff33 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-pmusgrf", "syscon";
   reg = <0x0 0xff33 0x0 0xe3d4>;
   };
@@ -1204,7 +1201,6 @@
   };

   cic: syscon@ff62 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-cic", "syscon";
   reg = <0x0 0xff62 0x0 0x100>;
   };
@@ -1219,7 +1215,6 @@
   };

   dmc: dmc {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-dmc";
   devfreq-events = <>;
   interrupts = ;
@@ -1268,7 +1263,6 @@
   };

   pmucru: pmu-clock-controller@ff75 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-pmucru";
   reg = <0x0 0xff75 0x0 0x1000>;
   rockchip,grf = <>;
@@ -1279,7 +1273,6 @@
   };

   cru: clock-controller@ff76 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-cru";
   reg = <0x0 0xff76 0x0 0x1000>;
   rockchip,grf = <>;
@@ -1310,7 +1303,6 @@
   };

   grf: syscon@ff77 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
   reg = <0x0 0xff77 0x0 0x1>;
   #address-cells = <1>;
@@ -1520,7 +1512,6 @@
   };

   vopl: vop@ff8f {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-vop-lit";
   reg = <0x0 0xff8f 0x0 0x3efc>;
   interrupts = ;
@@ -1578,7 +1569,6 @@
   };

   vopb: vop@ff90 {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-vop-big";
   reg = <0x0 0xff90 0x0 0x3efc>;
   interrupts = ;
@@ -1818,7 +1808,6 @@
   };

   pinctrl: pinctrl {
- u-boot,dm-pre-reloc;
   compatible = "rockchip,rk3399-pinctrl";
   rockchip,grf = <>;
   rockchip,pmu = <>;





___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] rockchip: clk: pll: add common pll setting funcs【请注意,邮件由u-boot-boun...@lists.denx.de代发】 funcs

2019-11-17 Thread Kever Yang


On 2019/11/10 下午10:31, Kever Yang wrote:


On 2019/10/25 上午9:42, Elaine Zhang wrote:

Common PLL setup function, compatible with different SOC.
Mainly for the subsequent new SOC use.

Signed-off-by: Elaine Zhang 


Reviewed-by: Kever Yang 


Applied to u-boot-rockchip master .

Thanks,
- Kever

Thanks,
- Kever

---
  arch/arm/include/asm/arch-rockchip/clock.h |  76 +
  drivers/clk/rockchip/Makefile  |   1 +
  drivers/clk/rockchip/clk_pll.c | 361 +
  3 files changed, 438 insertions(+)
  create mode 100644 drivers/clk/rockchip/clk_pll.c

diff --git a/arch/arm/include/asm/arch-rockchip/clock.h 
b/arch/arm/include/asm/arch-rockchip/clock.h

index 0eb19ca86f29..a79c904a3e14 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -9,6 +9,7 @@
  /* define pll mode */
  #define RKCLK_PLL_MODE_SLOW    0
  #define RKCLK_PLL_MODE_NORMAL    1
+#define RKCLK_PLL_MODE_DEEP    2
    enum {
  ROCKCHIP_SYSCON_NOC,
@@ -33,6 +34,81 @@ enum rk_clk_id {
  CLK_COUNT,
  };
  +#define PLL(_type, _id, _con, _mode, _mshift,    \
+ _lshift, _pflags, _rtable)    \
+    {    \
+    .id    = _id,    \
+    .type    = _type,    \
+    .con_offset    = _con,    \
+    .mode_offset    = _mode,    \
+    .mode_shift    = _mshift,    \
+    .lock_shift    = _lshift,    \
+    .pll_flags    = _pflags,    \
+    .rate_table    = _rtable,    \
+    }
+
+#define RK3036_PLL_RATE(_rate, _refdiv, _fbdiv, _postdiv1,    \
+    _postdiv2, _dsmpd, _frac)    \
+{    \
+    .rate    = _rate##U,    \
+    .fbdiv = _fbdiv,    \
+    .postdiv1 = _postdiv1,    \
+    .refdiv = _refdiv,    \
+    .postdiv2 = _postdiv2,    \
+    .dsmpd = _dsmpd,    \
+    .frac = _frac,    \
+}
+
+struct rockchip_pll_rate_table {
+    unsigned long rate;
+    unsigned int nr;
+    unsigned int nf;
+    unsigned int no;
+    unsigned int nb;
+    /* for RK3036/RK3399 */
+    unsigned int fbdiv;
+    unsigned int postdiv1;
+    unsigned int refdiv;
+    unsigned int postdiv2;
+    unsigned int dsmpd;
+    unsigned int frac;
+};
+
+enum rockchip_pll_type {
+    pll_rk3036,
+    pll_rk3066,
+    pll_rk3328,
+    pll_rk3366,
+    pll_rk3399,
+};
+
+struct rockchip_pll_clock {
+    unsigned int    id;
+    unsigned int    con_offset;
+    unsigned int    mode_offset;
+    unsigned int    mode_shift;
+    unsigned int    lock_shift;
+    enum rockchip_pll_type    type;
+    unsigned int    pll_flags;
+    struct rockchip_pll_rate_table *rate_table;
+    unsigned int    mode_mask;
+};
+
+struct rockchip_cpu_rate_table {
+    unsigned long rate;
+    unsigned int aclk_div;
+    unsigned int pclk_div;
+};
+
+int rockchip_pll_set_rate(struct rockchip_pll_clock *pll,
+  void __iomem *base, ulong clk_id,
+  ulong drate);
+ulong rockchip_pll_get_rate(struct rockchip_pll_clock *pll,
+    void __iomem *base, ulong clk_id);
+const struct rockchip_cpu_rate_table *
+rockchip_get_cpu_settings(struct rockchip_cpu_rate_table *cpu_table,
+  ulong rate);
+
  static inline int rk_pll_id(enum rk_clk_id clk_id)
  {
  return clk_id - 1;
diff --git a/drivers/clk/rockchip/Makefile 
b/drivers/clk/rockchip/Makefile

index 41cfb7ad3fd6..03a9fa77babc 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -3,6 +3,7 @@
  # Copyright (c) 2017 Rockchip Electronics Co., Ltd
  #
  +obj-y += clk_pll.o
  obj-$(CONFIG_ROCKCHIP_RK3036) += clk_rk3036.o
  obj-$(CONFIG_ROCKCHIP_RK3128) += clk_rk3128.o
  obj-$(CONFIG_ROCKCHIP_RK3188) += clk_rk3188.o
diff --git a/drivers/clk/rockchip/clk_pll.c 
b/drivers/clk/rockchip/clk_pll.c

new file mode 100644
index ..be0f1245e870
--- /dev/null
+++ b/drivers/clk/rockchip/clk_pll.c
@@ -0,0 +1,361 @@
+/*
+ * (C) Copyright 2018 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier:    GPL-2.0
+ */
+ #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct rockchip_pll_rate_table rockchip_auto_table;
+
+#define PLL_MODE_MASK    0x3
+#define PLL_RK3328_MODE_MASK    0x1
+
+#define RK3036_PLLCON0_FBDIV_MASK    0xfff
+#define RK3036_PLLCON0_FBDIV_SHIFT    0
+#define RK3036_PLLCON0_POSTDIV1_MASK    0x7 << 12
+#define RK3036_PLLCON0_POSTDIV1_SHIFT    12
+#define RK3036_PLLCON1_REFDIV_MASK    0x3f
+#define RK3036_PLLCON1_REFDIV_SHIFT    0
+#define RK3036_PLLCON1_POSTDIV2_MASK    0x7 << 6
+#define RK3036_PLLCON1_POSTDIV2_SHIFT    6
+#define RK3036_PLLCON1_DSMPD_MASK    0x1 << 12
+#define 

Re: [U-Boot] [PATCH 00/12] rockchip: add support for px30

2019-11-17 Thread Kever Yang


On 2019/10/25 上午7:27, Heiko Stuebner wrote:

From: Heiko Stuebner 

This series adds support for the px30 soc and its evaluation board.
The most interesting aspect is the sram size which is only 10kb,
so the TPL doing the DDR init needs to be really tiny, while the
SPL then should use devicemanager and all other newer features.

I'm not yet sure if there is a better solution for the first patch
but right now without it there is no way to build SPL with Framework
and TPL without.

David Wu (1):
   pinctrl: rockchip: add px30 pinctrl driver

Finley Xiao (1):
   misc: add driver for the Rockchip otp controller

Heiko Stuebner (8):
   spl: separate SPL_FRAMEWORK config for spl and tpl
   rockchip: add core px30 headers
   net: gmac_rockchip: add support for px30
   rockchip: misc: read cpuid either from efuse or otp
   rockchip: ram: add dm-based sdram driver
   rockchip: add px30 devicetrees
   rockchip: add px30-evb board

Kever Yang (2):
   rockchip: clk: add px30 clock driver
   rockchip: mkimage: add support for px30
   rockchip: add px30 architecture core
Applied to u-boot-rockchip master with rebase on  TOF and some 
checkpatch warning fix.


Thanks,
- Kever


  arch/arm/dts/Makefile |3 +
  arch/arm/dts/px30-evb-u-boot.dtsi |   81 +
  arch/arm/dts/px30-evb.dts |  527 +
  arch/arm/dts/px30.dtsi| 2068 +
  arch/arm/include/asm/arch-px30/boot0.h|   11 +
  arch/arm/include/asm/arch-px30/gpio.h |   11 +
  arch/arm/include/asm/arch-rockchip/cru_px30.h |  432 
  arch/arm/include/asm/arch-rockchip/grf_px30.h |  144 ++
  .../include/asm/arch-rockchip/sdram_px30.h|  359 +++
  arch/arm/lib/Makefile |2 +-
  arch/arm/lib/crt0.S   |2 +-
  arch/arm/lib/crt0_64.S|2 +
  arch/arm/mach-rockchip/Kconfig|   23 +
  arch/arm/mach-rockchip/Makefile   |2 +
  arch/arm/mach-rockchip/misc.c |7 +-
  arch/arm/mach-rockchip/px30-board-tpl.c   |   59 +
  arch/arm/mach-rockchip/px30/Kconfig   |   48 +
  arch/arm/mach-rockchip/px30/Makefile  |   14 +
  arch/arm/mach-rockchip/px30/clk_px30.c|   31 +
  arch/arm/mach-rockchip/px30/px30.c|  248 ++
  .../px30/sdram-px30-ddr3-detect-333.inc   |   70 +
  .../px30/sdram-px30-ddr4-detect-333.inc   |   73 +
  .../px30/sdram-px30-ddr_skew.inc  |  121 +
  .../px30/sdram-px30-lpddr2-detect-333.inc |   71 +
  .../px30/sdram-px30-lpddr3-detect-333.inc |   72 +
  arch/arm/mach-rockchip/px30/sdram_px30.c  | 1405 +++
  arch/arm/mach-rockchip/px30/syscon_px30.c |   53 +
  arch/powerpc/lib/Makefile |2 +-
  board/rockchip/evb_px30/Kconfig   |   15 +
  board/rockchip/evb_px30/MAINTAINERS   |6 +
  board/rockchip/evb_px30/Makefile  |7 +
  board/rockchip/evb_px30/evb_px30.c|4 +
  common/spl/Kconfig|8 +
  common/spl/Makefile   |2 +-
  configs/evb-px30_defconfig|  113 +
  drivers/clk/rockchip/Makefile |1 +
  drivers/clk/rockchip/clk_px30.c   | 1630 +
  drivers/misc/Kconfig  |9 +
  drivers/misc/Makefile |1 +
  drivers/misc/rockchip-otp.c   |  176 ++
  drivers/net/gmac_rockchip.c   |   69 +
  drivers/pinctrl/rockchip/Makefile |1 +
  drivers/pinctrl/rockchip/pinctrl-px30.c   |  368 +++
  drivers/ram/rockchip/Makefile |1 +
  drivers/ram/rockchip/sdram_px30.c |   57 +
  include/configs/evb_px30.h|   19 +
  include/configs/px30_common.h |   62 +
  include/dt-bindings/clock/px30-cru.h  |  389 
  include/dt-bindings/power/px30-power.h|   27 +
  include/dt-bindings/soc/rockchip,boot-mode.h  |   16 +
  scripts/Makefile.spl  |4 +
  tools/rkcommon.c  |1 +
  52 files changed, 8922 insertions(+), 5 deletions(-)
  create mode 100644 arch/arm/dts/px30-evb-u-boot.dtsi
  create mode 100644 arch/arm/dts/px30-evb.dts
  create mode 100644 arch/arm/dts/px30.dtsi
  create mode 100644 arch/arm/include/asm/arch-px30/boot0.h
  create mode 100644 arch/arm/include/asm/arch-px30/gpio.h
  create mode 100644 arch/arm/include/asm/arch-rockchip/cru_px30.h
  create mode 100644 arch/arm/include/asm/arch-rockchip/grf_px30.h
  create mode 100644 arch/arm/include/asm/arch-rockchip/sdram_px30.h
  create mode 100644 arch/arm/mach-rockchip/px30-board-tpl.c
  create mode 100644 arch/arm/mach-rockchip/px30/Kconfig
  create mode 100644 arch/arm/mach-rockchip/px30/Makefile
  create mode 100644 arch/arm/mach-rockchip/px30/clk_px30.c
  create mode 100644 

Re: [U-Boot] [PATCH 1/2] arm: dts: rk3399-rockpro64: sync dts from linux kernel【请注意,邮件由u-boot-boun...@lists.denx.de代发】

2019-11-17 Thread Kever Yang


On 2019/11/8 上午11:22, Kever Yang wrote:


On 2019/11/7 下午7:11, Soeren Moch wrote:

The most important change for u-boot is the fix for the vdd-log pwm
voltage regulator to avoid overvoltage for the VD_LOGIC power domain.

Signed-off-by: Soeren Moch 
=2D--
Cc: Kever Yang 
Cc: u-boot@lists.denx.de
=2D--


Why  is the "=2D- -" here?

Otherwise looks good to me.


Reviewed-by: Kever Yang

Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever


  arch/arm/dts/rk3399-rockpro64.dts | 57 ++-
  1 file changed, 49 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/rk3399-rockpro64.dts 
b/arch/arm/dts/rk3399-rockp=

ro64.dts
index 1f2394e058..e544deb61d 100644
=2D-- a/arch/arm/dts/rk3399-rockpro64.dts
+++ b/arch/arm/dts/rk3399-rockpro64.dts
@@ -58,6 +58,13 @@
  };
  };

+    fan: pwm-fan {
+    compatible =3D "pwm-fan";
+    #cooling-cells =3D <2>;
+    fan-supply =3D <_dcin>;
+    pwms =3D < 0 5 0>;
+    };
+
  sdio_pwrseq: sdio-pwrseq {
  compatible =3D "mmc-pwrseq-simple";
  clocks =3D < 1>;
@@ -166,7 +173,7 @@
  regulator-always-on;
  regulator-boot-on;
  regulator-min-microvolt =3D <80>;
-    regulator-max-microvolt =3D <140>;
+    regulator-max-microvolt =3D <170>;
  vin-supply =3D <_sys>;
  };
  };
@@ -222,6 +229,10 @@
  status =3D "okay";
  };

+_sound {
+    status =3D "okay";
+};
+
   {
  mali-supply =3D <_gpu>;
  status =3D "okay";
@@ -236,8 +247,8 @@
  rk808: pmic@1b {
  compatible =3D "rockchip,rk808";
  reg =3D <0x1b>;
-    interrupt-parent =3D <>;
-    interrupts =3D <21 IRQ_TYPE_LEVEL_LOW>;
+    interrupt-parent =3D <>;
+    interrupts =3D <10 IRQ_TYPE_LEVEL_LOW>;
  #clock-cells =3D <1>;
  clock-output-names =3D "xin32k", "rk808-clkout2";
  pinctrl-names =3D "default";
@@ -504,11 +515,25 @@
  status =3D "okay";

  bt656-supply =3D <_dvp>;
-    audio-supply =3D <_codec>;
+    audio-supply =3D <_3v0>;
  sdmmc-supply =3D <_sdio>;
  gpio1830-supply =3D <_3v0>;
  };

+ {
+    ep-gpios =3D < RK_PD4 GPIO_ACTIVE_HIGH>;
+    num-lanes =3D <4>;
+    pinctrl-names =3D "default";
+    pinctrl-0 =3D <_perst>;
+    vpcie12v-supply =3D <_dcin>;
+    vpcie3v3-supply =3D <_pcie>;
+    status =3D "okay";
+};
+
+_phy {
+    status =3D "okay";
+};
+
  _io_domains {
  pmu1830-supply =3D <_3v0>;
  status =3D "okay";
@@ -538,6 +563,10 @@
  };

  pcie {
+    pcie_perst: pcie-perst {
+    rockchip,pins =3D <2 RK_PD4 RK_FUNC_GPIO _pull_none>;
+    };
+
  pcie_pwr_en: pcie-pwr-en {
  rockchip,pins =3D <1 RK_PD0 RK_FUNC_GPIO _pull_none>;
  };
@@ -545,7 +574,7 @@

  pmic {
  pmic_int_l: pmic-int-l {
-    rockchip,pins =3D <1 RK_PC5 RK_FUNC_GPIO _pull_up>;
+    rockchip,pins =3D <3 RK_PB2 RK_FUNC_GPIO _pull_up>;
  };

  vsel1_gpio: vsel1-gpio {
@@ -580,6 +609,10 @@
  status =3D "okay";
  };

+ {
+    status =3D "okay";
+};
+
   {
  status =3D "okay";
  };
@@ -591,7 +624,6 @@

   {
  bus-width =3D <4>;
-    cap-mmc-highspeed;
  cap-sd-highspeed;
  cd-gpios =3D < 7 GPIO_ACTIVE_LOW>;
  disable-wp;
@@ -603,12 +635,21 @@

   {
  bus-width =3D <8>;
-    mmc-hs400-1_8v;
-    mmc-hs400-enhanced-strobe;
+    mmc-hs200-1_8v;
  non-removable;
  status =3D "okay";
  };

+ {
+    status =3D "okay";
+
+    flash@0 {
+    compatible =3D "jedec,spi-nor";
+    reg =3D <0>;
+    spi-max-frequency =3D <1000>;
+    };
+};
+
   {
  status =3D "okay";
  };
=2D-
2.17.1





___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] arm: dts: rk3399-rockpro64: slightly increase center voltage【请注意,邮件由u-boot-boun...@lists.denx.de代发】

2019-11-17 Thread Kever Yang


On 2019/11/8 上午11:23, Kever Yang wrote:


On 2019/11/7 下午7:11, Soeren Moch wrote:

The rk3399 VD_CENTER voltage domain is not subject to dynamic voltage
scaling. So the regulator reset voltage of 0.9V is used on this board.
Let u-boot initialize the center voltage to 0.95V as it is done for the
VD_LOGIC domain. This avoids instability and occasional linux kernel
Opses on this board.

Signed-off-by: Soeren Moch 
=2D--
Cc: Kever Yang 
Cc: u-boot@lists.denx.de
=2D--
  arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 5 +


Reviewed-by: Kever Yang


Applied to u-boot-rockchip master .

Thanks,
- Kever

Thanks,
- Kever

  1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi 
b/arch/arm/dts/rk33=

99-rockpro64-u-boot.dtsi
index a073ea25f5..4648513ea9 100644
=2D-- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -11,6 +11,11 @@
  };
  };

+_center {
+    regulator-min-microvolt =3D <95>;
+    regulator-max-microvolt =3D <95>;
+};
+
  _log {
  regulator-init-microvolt =3D <95>;
  };
=2D-
2.17.1





___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 0/9] Add support for RK3308 SOC

2019-11-17 Thread Kever Yang


On 2019/10/30 下午4:11, Andy Yan wrote:

RK3308 is a quad Cortex A35 based SOC with rich audio
interfaces(I2S/PCM/TDM/PDM/SPDIF/VAD/HDMI ARC), which
designed for intelligent voice interaction and audio
input/output processing.

This path set add basic support for it, test with a
emmc board.

More boards support such as Firefly ROC-RK3308-CC will coming soon.

Changes in v2:
- Add board ROC-rk3308-CC
- Update doc/README.rockchip

Andy Yan (8):
   arm: rockchip: Add RK3308 SOC support
   arm: dts: rockchip: Add dts for rk3308 evb
   board: rockchip: Add rk3308 evb support
   rockchip: rk3308: Add sdram driver
   rockchip: mkimage: add support for RK3308
   rockchip: rk3308: Add dts for ROC-RK3308-CC
   rockchip: rk3308: Add support for ROC-RK3308-CC board
   doc: rockchip: Add documentation for rk3308 based boards

Finley Xiao (1):
   rockchip: clk: Add clk driver for rk3308
Applied to u-boot-rockchip master with rebase on  TOF and some 
checkpatch warning fix.


Thanks,
- Kever


  arch/arm/dts/Makefile |4 +
  arch/arm/dts/rk3308-evb-u-boot.dtsi   |   17 +
  arch/arm/dts/rk3308-evb.dts   |  230 +++
  arch/arm/dts/rk3308-roc-cc-u-boot.dtsi|   17 +
  arch/arm/dts/rk3308-roc-cc.dts|  190 ++
  arch/arm/dts/rk3308-u-boot.dtsi   |   25 +
  arch/arm/dts/rk3308.dtsi  | 1829 +
  arch/arm/include/asm/arch-rk3308/boot0.h  |   11 +
  arch/arm/include/asm/arch-rk3308/cru_rk3308.h |  290 +++
  arch/arm/include/asm/arch-rk3308/gpio.h   |   11 +
  arch/arm/include/asm/arch-rk3308/grf_rk3308.h |  197 ++
  arch/arm/mach-rockchip/Kconfig|   24 +
  arch/arm/mach-rockchip/Makefile   |1 +
  arch/arm/mach-rockchip/rk3308/Kconfig |   27 +
  arch/arm/mach-rockchip/rk3308/Makefile|9 +
  arch/arm/mach-rockchip/rk3308/clk_rk3308.c|   31 +
  arch/arm/mach-rockchip/rk3308/rk3308.c|  175 ++
  arch/arm/mach-rockchip/rk3308/syscon_rk3308.c |   20 +
  board/firefly/firefly-rk3308/Kconfig  |   15 +
  board/firefly/firefly-rk3308/MAINTAINERS  |5 +
  board/firefly/firefly-rk3308/Makefile |7 +
  board/firefly/firefly-rk3308/roc_rk3308_cc.c  |   82 +
  board/rockchip/evb_rk3308/Kconfig |   15 +
  board/rockchip/evb_rk3308/MAINTAINERS |6 +
  board/rockchip/evb_rk3308/Makefile|7 +
  board/rockchip/evb_rk3308/evb_rk3308.c|   44 +
  configs/evb-rk3308_defconfig  |   77 +
  configs/roc-rk3308-cc_defconfig   |   77 +
  doc/README.rockchip   |   20 +-
  drivers/clk/rockchip/Makefile |1 +
  drivers/clk/rockchip/clk_rk3308.c | 1078 ++
  drivers/ram/rockchip/Makefile |1 +
  drivers/ram/rockchip/sdram_rk3308.c   |   55 +
  include/configs/evb_rk3308.h  |   20 +
  include/configs/rk3308_common.h   |   58 +
  include/dt-bindings/clock/rk3308-cru.h|  387 
  tools/rkcommon.c  |1 +
  37 files changed, 5063 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/rk3308-evb-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3308-evb.dts
  create mode 100644 arch/arm/dts/rk3308-roc-cc-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3308-roc-cc.dts
  create mode 100644 arch/arm/dts/rk3308-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3308.dtsi
  create mode 100644 arch/arm/include/asm/arch-rk3308/boot0.h
  create mode 100644 arch/arm/include/asm/arch-rk3308/cru_rk3308.h
  create mode 100644 arch/arm/include/asm/arch-rk3308/gpio.h
  create mode 100644 arch/arm/include/asm/arch-rk3308/grf_rk3308.h
  create mode 100644 arch/arm/mach-rockchip/rk3308/Kconfig
  create mode 100644 arch/arm/mach-rockchip/rk3308/Makefile
  create mode 100644 arch/arm/mach-rockchip/rk3308/clk_rk3308.c
  create mode 100644 arch/arm/mach-rockchip/rk3308/rk3308.c
  create mode 100644 arch/arm/mach-rockchip/rk3308/syscon_rk3308.c
  create mode 100644 board/firefly/firefly-rk3308/Kconfig
  create mode 100644 board/firefly/firefly-rk3308/MAINTAINERS
  create mode 100644 board/firefly/firefly-rk3308/Makefile
  create mode 100644 board/firefly/firefly-rk3308/roc_rk3308_cc.c
  create mode 100644 board/rockchip/evb_rk3308/Kconfig
  create mode 100644 board/rockchip/evb_rk3308/MAINTAINERS
  create mode 100644 board/rockchip/evb_rk3308/Makefile
  create mode 100644 board/rockchip/evb_rk3308/evb_rk3308.c
  create mode 100644 configs/evb-rk3308_defconfig
  create mode 100644 configs/roc-rk3308-cc_defconfig
  create mode 100644 drivers/clk/rockchip/clk_rk3308.c
  create mode 100644 drivers/ram/rockchip/sdram_rk3308.c
  create mode 100644 include/configs/evb_rk3308.h
  create mode 100644 include/configs/rk3308_common.h
  create mode 100644 include/dt-bindings/clock/rk3308-cru.h




___
U-Boot mailing 

Re: [U-Boot] [PATCH] arm: dts: rk3399-roc-pc: Sync latest dts changes from Linux【请注意,邮件由u-boot-boun...@lists.denx.de代发】

2019-11-17 Thread Kever Yang


On 2019/11/7 下午5:57, Kever Yang wrote:


On 2019/10/16 下午11:19, Jagan Teki wrote:

Few important regulator power rails fixes are available in
linux-next, so sync them same.

Here is the last commit details:
commit <9f7f9b610e1b7d2dc86c543ab0dfcf781bd42326> ("arm64: dts:
rockchip: Fix roc-rk3399-pc regulator input rails")

Cc: Kever Yang 
Cc: Levin Du 
Signed-off-by: Jagan Teki 



Reviewed-by: Kever Yang 

Applied to u-boot-rockchip master.

Thanks,
- Kever



Thanks,

-Kever


---
  arch/arm/dts/rk3399-roc-pc.dts | 32 
  1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/rk3399-roc-pc.dts 
b/arch/arm/dts/rk3399-roc-pc.dts

index 19f7732d72..257543d069 100644
--- a/arch/arm/dts/rk3399-roc-pc.dts
+++ b/arch/arm/dts/rk3399-roc-pc.dts
@@ -57,9 +57,9 @@
   * should be placed inside mp8859, but not until mp8859 has
   * its own dt-binding.
   */
-    vcc12v_sys: mp8859-dcdc1 {
+    dc_12v: mp8859-dcdc1 {
  compatible = "regulator-fixed";
-    regulator-name = "vcc12v_sys";
+    regulator-name = "dc_12v";
  regulator-always-on;
  regulator-boot-on;
  regulator-min-microvolt = <1200>;
@@ -85,7 +85,7 @@
  regulator-boot-on;
  regulator-min-microvolt = <330>;
  regulator-max-microvolt = <330>;
-    vin-supply = <_sys>;
+    vin-supply = <_sys>;
  };
    /* Actually 3 regulators (host0, 1, 2) controlled by the same 
gpio */

@@ -118,7 +118,7 @@
  regulator-boot-on;
  regulator-min-microvolt = <500>;
  regulator-max-microvolt = <500>;
-    vin-supply = <_sys>;
+    vin-supply = <_12v>;
  };
    vdd_log: vdd-log {
@@ -129,7 +129,7 @@
  regulator-boot-on;
  regulator-min-microvolt = <80>;
  regulator-max-microvolt = <140>;
-    vin-supply = <_sys>;
+    vin-supply = <_sys>;
  };
  };
  @@ -202,16 +202,16 @@
  rockchip,system-power-controller;
  wakeup-source;
  -    vcc1-supply = <_sys>;
-    vcc2-supply = <_sys>;
-    vcc3-supply = <_sys>;
-    vcc4-supply = <_sys>;
-    vcc6-supply = <_sys>;
-    vcc7-supply = <_sys>;
+    vcc1-supply = <_sys>;
+    vcc2-supply = <_sys>;
+    vcc3-supply = <_sys>;
+    vcc4-supply = <_sys>;
+    vcc6-supply = <_sys>;
+    vcc7-supply = <_sys>;
  vcc8-supply = <_sys>;
-    vcc9-supply = <_sys>;
-    vcc10-supply = <_sys>;
-    vcc11-supply = <_sys>;
+    vcc9-supply = <_sys>;
+    vcc10-supply = <_sys>;
+    vcc11-supply = <_sys>;
  vcc12-supply = <_sys>;
  vddio-supply = <_pmu>;
  @@ -385,7 +385,7 @@
  regulator-ramp-delay = <1000>;
  regulator-always-on;
  regulator-boot-on;
-    vin-supply = <_sys>;
+    vin-supply = <_sys>;
    regulator-state-mem {
  regulator-off-in-suspend;
@@ -404,7 +404,7 @@
  regulator-ramp-delay = <1000>;
  regulator-always-on;
  regulator-boot-on;
-    vin-supply = <_sys>;
+    vin-supply = <_sys>;
    regulator-state-mem {
  regulator-off-in-suspend;



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 0/6] Add support for RK3308 SOC

2019-11-17 Thread Kever Yang


On 2019/10/25 下午6:16, Andy Yan wrote:

RK3308 is a quad Cortex A35 based SOC with rich audio
interfaces(I2S/PCM/TDM/PDM/SPDIF/VAD/HDMI ARC), which
designed for intelligent voice interaction and audio
input/output processing.

This path set add basic support for it, test with a
emmc board.

More boards support such as Firefly ROC-RK3308-CC will coming soon.


Andy Yan (5):
   arm: rockchip: Add RK3308 SOC support
   arm: dts: rockchip: Add dts for rk3308 evb
   board: rockchip: Add rk3308 evb support
   rockchip: rk3308: Add sdram driver
   rockchip: mkimage: add support for RK3308

Finley Xiao (1):
   rockchip: clk: Add clk driver for rk3308


Applied to u-boot-rockchip master with rebase on  TOF and some 
checkpatch warning fix.


Thanks,
- Kever


  arch/arm/dts/Makefile |3 +
  arch/arm/dts/rk3308-evb-u-boot.dtsi   |   17 +
  arch/arm/dts/rk3308-evb.dts   |  230 +++
  arch/arm/dts/rk3308-u-boot.dtsi   |   25 +
  arch/arm/dts/rk3308.dtsi  | 1832 +
  arch/arm/include/asm/arch-rk3308/boot0.h  |   11 +
  arch/arm/include/asm/arch-rk3308/cru_rk3308.h |  290 +++
  arch/arm/include/asm/arch-rk3308/gpio.h   |   11 +
  arch/arm/include/asm/arch-rk3308/grf_rk3308.h |  197 ++
  arch/arm/mach-rockchip/Kconfig|   24 +
  arch/arm/mach-rockchip/Makefile   |1 +
  arch/arm/mach-rockchip/rk3308/Kconfig |   22 +
  arch/arm/mach-rockchip/rk3308/Makefile|9 +
  arch/arm/mach-rockchip/rk3308/clk_rk3308.c|   31 +
  arch/arm/mach-rockchip/rk3308/rk3308.c|  175 ++
  arch/arm/mach-rockchip/rk3308/syscon_rk3308.c |   20 +
  board/rockchip/evb_rk3308/Kconfig |   15 +
  board/rockchip/evb_rk3308/MAINTAINERS |6 +
  board/rockchip/evb_rk3308/Makefile|7 +
  board/rockchip/evb_rk3308/evb_rk3308.c|   44 +
  configs/evb-rk3308_defconfig  |   77 +
  drivers/clk/rockchip/Makefile |1 +
  drivers/clk/rockchip/clk_rk3308.c | 1078 ++
  drivers/ram/rockchip/Makefile |1 +
  drivers/ram/rockchip/sdram_rk3308.c   |   55 +
  include/configs/evb_rk3308.h  |   20 +
  include/configs/rk3308_common.h   |   58 +
  include/dt-bindings/clock/rk3308-cru.h|  387 
  tools/rkcommon.c  |1 +
  29 files changed, 4648 insertions(+)
  create mode 100644 arch/arm/dts/rk3308-evb-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3308-evb.dts
  create mode 100644 arch/arm/dts/rk3308-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3308.dtsi
  create mode 100644 arch/arm/include/asm/arch-rk3308/boot0.h
  create mode 100644 arch/arm/include/asm/arch-rk3308/cru_rk3308.h
  create mode 100644 arch/arm/include/asm/arch-rk3308/gpio.h
  create mode 100644 arch/arm/include/asm/arch-rk3308/grf_rk3308.h
  create mode 100644 arch/arm/mach-rockchip/rk3308/Kconfig
  create mode 100644 arch/arm/mach-rockchip/rk3308/Makefile
  create mode 100644 arch/arm/mach-rockchip/rk3308/clk_rk3308.c
  create mode 100644 arch/arm/mach-rockchip/rk3308/rk3308.c
  create mode 100644 arch/arm/mach-rockchip/rk3308/syscon_rk3308.c
  create mode 100644 board/rockchip/evb_rk3308/Kconfig
  create mode 100644 board/rockchip/evb_rk3308/MAINTAINERS
  create mode 100644 board/rockchip/evb_rk3308/Makefile
  create mode 100644 board/rockchip/evb_rk3308/evb_rk3308.c
  create mode 100644 configs/evb-rk3308_defconfig
  create mode 100644 drivers/clk/rockchip/clk_rk3308.c
  create mode 100644 drivers/ram/rockchip/sdram_rk3308.c
  create mode 100644 include/configs/evb_rk3308.h
  create mode 100644 include/configs/rk3308_common.h
  create mode 100644 include/dt-bindings/clock/rk3308-cru.h




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

2019-11-17 Thread Kever Yang

Hi Qu Wenruo,


    Please try with latest u-boot-rockchip with dram and board fix merged:

https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git master branch


    Did you try with rkbin ddr.bin instead of TPL and keep other 
firmware(SPL, U-Boot, ATF),


this can confirm if there is something wrong in TPL dram driver or not.


Thanks,

- Kever

On 2019/11/16 下午1:39, Qu Wenruo wrote:


On 2019/11/16 下午1:16, Qu Wenruo wrote:


On 2019/11/15 下午10:59, Anand Moon wrote:

Hi Qu Wenruo,

On Fri, 15 Nov 2019 at 17:27, Qu Wenruo  wrote:



On 2019/11/15 下午6:37, Qu Wenruo wrote:

A small update to this bug.

I'm using mem=3584M kernel cmdline, to sacrifice 512M memory.

And then surprise, memtest 3G works. (Originally it's 4G physical ram
and 3584M memtest.

Hopes this could provide some clue.

Oh no, with 3187M, it still crashes with SError.

So still no luck.

Thanks,
Qu

Please this following series of patches for fix this error.
It fixed issue of SError on my board.

Would you mind to share which commit it is based?

For v2019.10 tag, it fails at the 13th patch.
The same happened for current master.

Well, manually solved the conflicts.

If anyone is interested in using that, I have uploaded it to github,
which is based on v2019.10 tag:

https://github.com/adam900710/u-boot/tree/serror_fixes

Unfortunately, still crashed for memtester 3584M.

Thanks,
Qu


Thanks,
Qu

[0] https://patchwork.ozlabs.org/cover/1195284/

Best Regards
-Anand



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support

2019-11-17 Thread Bin Meng
Hi Segar Kadam,

On Mon, Nov 18, 2019 at 4:59 AM Sagar Kadam  wrote:
>
>
> Hello Jagan/Bin,
>
> > -Original Message-
> > From: U-Boot  On Behalf Of Bin Meng
> > Sent: Monday, November 11, 2019 8:02 PM
> > To: Jagan Teki 
> > Cc: Palmer Dabbelt ( Sifive) ; U-Boot Mailing List  > b...@lists.denx.de>; linux-amarula 
> > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash
> > support
> >
> > Hi Jagan,
> >
> > On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki 
> > wrote:
> > >
> > > Hi Bin,
> > >
> > > On Tue, Oct 29, 2019 at 3:50 PM Bin Meng  wrote:
> > > >
> > > > Hi Jagan,
> > > >
> > > > On Tue, Oct 29, 2019 at 5:38 PM Bin Meng 
> > wrote:
> > > > >
> > > > > Hi Jagan,
> > > > >
> > > > > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki
> >  wrote:
> > > > > >
> > > > > > HiFive Unleashed A00 support is25wp256 spi-nor flash,
> > > > > > So enable the same and add test result log for future
> > > > > > reference.
> > > > > >
> > > > > > Tested on SiFive FU540 board.
> > > > > >
> > > > > > Signed-off-by: Jagan Teki 
> > > > > > Reviewed-by: Bin Meng 
> > > > > > Tested-by: Bin Meng 
> > > > > > ---
> > > > > >  .../dts/hifive-unleashed-a00-u-boot.dtsi  |  1 +
> > > > > >  board/sifive/fu540/Kconfig|  3 +++
> > > > > >  doc/board/sifive/fu540.rst| 19 
> > > > > > +++
> > > > > >  3 files changed, 23 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > index 25ec8265a5..d7a64134db 100644
> > > > > > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > @@ -5,6 +5,7 @@
> > > > > >
> > > > > >  / {
> > > > > > aliases {
> > > > > > +   spi0 = 
> > > > > > spi2 = 
> > > > > > };
> > > > > >  };
> > > > > > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> > > > > > index 5d65080429..c5a1bca03c 100644
> > > > > > --- a/board/sifive/fu540/Kconfig
> > > > > > +++ b/board/sifive/fu540/Kconfig
> > > > > > @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > > imply CMD_FS_GENERIC
> > > > > > imply CMD_NET
> > > > > > imply CMD_PING
> > > > > > +   imply CMD_SF
> > > > > > imply CLK_SIFIVE
> > > > > > imply CLK_SIFIVE_FU540_PRCI
> > > > > > imply DOS_PARTITION
> > > > > > @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > > imply SIFIVE_SERIAL
> > > > > > imply SPI
> > > > > > imply SPI_SIFIVE
> > > > > > +   imply SPI_FLASH
> > > > > > +   imply SPI_FLASH_ISSI
> > > > > > imply MMC
> > > > > > imply MMC_SPI
> > > > > > imply MMC_BROKEN_CD
> > > > > > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
> > > > > > index 91b94ee06f..2e70cad02e 100644
> > > > > > --- a/doc/board/sifive/fu540.rst
> > > > > > +++ b/doc/board/sifive/fu540.rst
> > > > > > @@ -366,3 +366,22 @@ load uImage.
> > > > > >
> > > > > > Please press Enter to activate this console.
> > > > > > / #
> > > > > > +
> > > > > > +Sample spi nor flash test
> > > > > > +-
> > > > > > +
> > > > > > +.. code-block:: none
> > > > > > +
> > > > > > +   => sf probe 0:2
> > > > >
> > > > > The cs number can't be 2. It should be zero.
> > > >
> > > > With this patch series, we got crazy duplicated flash devices created,
> > > > see below:
> > > >
> > > > => sf probe
> > > > unrecognized JEDEC id bytes: ff, ff, ff
> > > > Failed to initialize SPI flash at 0:0 (error -2)
> > > > => sf probe 0:2
> > > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, 
> > > > total 32
> > MiB
> > > > => sf probe 0:4
> > > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, 
> > > > total 32
> > MiB
> > > > => sf probe 0:6
> > > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, 
> > > > total 32
> > MiB
> > > > => dm tree
> > > >  Class Index  Probed  DriverName
> > > > ---
> > > >  root  0  [ + ]   root_driver   root_driver
> > > >  simple_bus0  [ + ]   generic_simple_bus|-- soc
> > > >  clk   0  [ + ]   sifive-fu540-prci |   |--
> > > > clock-controller@1000
> > > >  serial0  [ + ]   serial_sifive |   |-- serial@1001
> > > >  serial1  [   ]   serial_sifive |   |-- serial@10011000
> > > >  spi   0  [ + ]   sifive_spi|   |-- spi@1004
> > > >  spi_flash 0  [   ]   spi_flash_std |   |   |-- flash@0
> > > >  spi_flash 1  [ + ]   spi_flash_std |   |   |-- 
> > > > spi_flash@0:2
> > > >  spi_flash 2  [ + ]   spi_flash_std |   |   |-- 
> > > > spi_flash@0:4
> > > >  spi_flash 3  [ + ]   spi_flash_std |   |   

Re: [U-Boot] [PATCH v1] arm: socfpga: Enable Stratix10 SMMU access

2019-11-17 Thread Tan, Ley Foon


> -Original Message-
> From: Marek Vasut 
> Sent: Saturday, November 16, 2019 7:10 PM
> To: thor.tha...@linux.intel.com; Simon Goldschmidt
> 
> Cc: u-boot@lists.denx.de; Albert Aribaud ; Tan,
> Ley Foon ; Dinh Nguyen ;
> Tom Rini ; Westergreen, Dalon
> 
> Subject: Re: [PATCH v1] arm: socfpga: Enable Stratix10 SMMU access
> 
> On 11/15/19 6:20 PM, Thor Thayer wrote:
> >
> > Enable TCU access through the Stratix10 CCU so that the SMMU can
> > access the SDRAM.
> >
> 
> [...]
> 
> Looks good to me. Ley, can you take a look?
> Thanks!
Looks good to me too. 
But, if this patch plan to apply after Agilex patch series, then need to rebase 
on top of it.

Reviewed-by: Ley Foon Tan 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Please pull u-boot-marvell/master

2019-11-17 Thread Tom Rini
On Thu, Nov 14, 2019 at 08:39:42AM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following MVEBU related fixes:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Pull request for UEFI sub-system for efi-2020-01-rc3

2019-11-17 Thread Tom Rini
On Thu, Nov 14, 2019 at 04:02:32AM +0100, Heinrich Schuchardt wrote:

> The following changes since commit 3ff1ff3ff76c15efe0451309af084ee6c096c583:
> 
>   Merge branch '2019-11-12-migrate-SYS_REDUNDAND_ENVIRONMENT'
> (2019-11-12 13:40:58 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2020-01-rc3
> 
> for you to fetch changes up to 2e716b8e299309139daa9513707951c622fc2bdf:
> 
>   efi_selftest: enable all UEFI unit tests on the sandbox (2019-11-12
> 23:13:54 +0100)
> 
> Gitlab CI showed no problems:
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/1288
> 
> Primary key fingerprint:
> 6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Pull request: u-boot-rockchip-20191026

2019-11-17 Thread Kever Yang
Hi Tom,

Please pull the rockchip update:
- Add support for rockchip SoC: PX30, RK3308
- Add and migrate to use common dram driver: PX30, RK3328, RK3399
- Add rk3399 board Tinker-s support
- Board config update for Rock960, Rockpro64

These patches are send during merge window, and reviewed for weeks before
they are ready, most of the feature update for Rockchip has been merged in
this PR.

Travis:
https://travis-ci.org/keveryang/u-boot/builds/613058035

Thanks,
- Kever

The following changes since commit 3ff1ff3ff76c15efe0451309af084ee6c096c583:

  Merge branch '2019-11-12-migrate-SYS_REDUNDAND_ENVIRONMENT' (2019-11-12 
13:40:58 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
tags/u-boot-rockchip-20191118

for you to fetch changes up to 59b01eb7a17a7c0915fd8aff8f818699b4624137:

  rockchip: dts: tinker: Add tinker-s board support (2019-11-17 18:51:25 +0800)


Andy Yan (8):
  arm: rockchip: Add RK3308 SOC support
  arm: dts: rockchip: Add dts for rk3308 evb
  board: rockchip: Add rk3308 evb support
  rockchip: rk3308: Add sdram driver
  rockchip: mkimage: add support for RK3308
  rockchip: rk3308: Add dts for ROC-RK3308-CC
  rockchip: rk3308: Add support for ROC-RK3308-CC board
  doc: rockchip: Add documentation for rk3308 based boards

David Wu (1):
  pinctrl: rockchip: add px30 pinctrl driver

Elaine Zhang (1):
  rockchip: clk: pll: add common pll setting funcs

Finley Xiao (2):
  misc: add driver for the Rockchip otp controller
  rockchip: clk: Add clk driver for rk3308

Heiko Stuebner (9):
  spl: separate SPL_FRAMEWORK config for spl and tpl
  rockchip: add core px30 headers
  net: gmac_rockchip: add support for px30
  rockchip: misc: read cpuid either from efuse or otp
  rockchip: add px30 devicetrees
  rockchip: add px30 architecture core
  rockchip: add px30-evb board
  rockchip: clk: rv1108: remove duplicate reset init
  rockchip: clk: fix wrong CONFIG_IS_ENABLED handling

Jagan Teki (2):
  arm: dts: rk3399-roc-pc: Sync latest dts changes from Linux
  configs: Rename roc-rk3399-pc -> roc-pc-rk3399 defconfig

Kever Yang (22):
  ram: rockchip: rename sdram.h to sdram_rk3288.h
  ram: rockchip: rename sdram_common.c/h to sdram.c
  rockchip: sdram: move cap structure and debug function to sdram_common.h
  rockchip: sdram: extend to use sys_reg3 for capacity info
  rockchip: sdram: update the sys_reg to sys_reg2
  ram: rockchip: add common code for sdram driver
  ram: rockchip: move sdram_debug function into sdram_common
  ram: rockchip: Default enable DRAM debug info
  ram: rockchip: add controller code for PX30
  ram: rockchip: add phy driver code for PX30
  ram: rockchip: add common msch reg definition
  ram: rockchip: update lpddr4 timing for rk3399
  ram: rk3399: Sync the io setting from Rockchip vendor code
  ram: rk3399: update calculate_stride
  rockchip: clk: add px30 clock driver
  rockchip: mkimage: add support for px30
  rockchip: usb: Migrate to use ofnode
  rockchip: Init driver otg_data for rk3288 usb phy
  arm64: dts: rk3399-rock960: add vdd_log and its init value
  rockchip: rk3399: rock-pi4: Add init value for vdd_log
  rockchip: rk3399: khadas-edge: Add init value for vdd_log
  rockchip: rk3399: orangepi: Add init value for vdd_log

Michael Trimarchi (2):
  rockchip: dts: tinker: Move u-boot dmc initialization to specific section
  rockchip: dts: tinker: Add tinker-s board support

Peter Robinson (4):
  rockchip: rk3399: rock960: Update config for TPL
  rockchip: dts: rk3399: move the u-boot, dm-pre-reloc to the u-boot.dtsi
  rockchip: dts: rk3399-evb: move u-boot, spl-boot-order to to the 
u-boot.dtsi
  rockchip: dts: rk3399-firefly: move u-boot, spl-boot-order to to the 
u-boot.dtsi

Soeren Moch (2):
  arm: dts: rk3399-rockpro64: sync dts from linux kernel
  arm: dts: rk3399-rockpro64: slightly increase center voltage

Thomas Hebb (3):
  rockchip: SPL: fix ordering of DRAM init
  rockchip: allow DRAM init in SPL
  rockchip: imply instead of selecting SPL_SYS_MALLOC_SIMPLE

Vasily Khoruzhick (1):
  rockchip: rk3399: split rockpro64 out of evb_rk3399

YouMin Chen (8):
  ram: px30: add sdram driver
  ram: rk3328: use common sdram driver
  ram: rk3399: migrate to use common code
  ram: rk3399: Clean up code
  ram: rk3399: fix error about get_ddrc0_con reg addr
  ram: rk3399: update the function of sdram_init
  ram: rk3399: add support detect capacity
  ram: rk3399: Fix dram setting to make dram more stable

 arch/arm/Kconfig   |2 +-
 arch/arm/dts/Makefile  |8 +
 arch/arm/dts/px30-evb-u-boot.dtsi  |   81 +
 

Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support

2019-11-17 Thread Sagar Kadam

Hello Jagan/Bin,

> -Original Message-
> From: U-Boot  On Behalf Of Bin Meng
> Sent: Monday, November 11, 2019 8:02 PM
> To: Jagan Teki 
> Cc: Palmer Dabbelt ( Sifive) ; U-Boot Mailing List  b...@lists.denx.de>; linux-amarula 
> Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash
> support
> 
> Hi Jagan,
> 
> On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki 
> wrote:
> >
> > Hi Bin,
> >
> > On Tue, Oct 29, 2019 at 3:50 PM Bin Meng  wrote:
> > >
> > > Hi Jagan,
> > >
> > > On Tue, Oct 29, 2019 at 5:38 PM Bin Meng 
> wrote:
> > > >
> > > > Hi Jagan,
> > > >
> > > > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki
>  wrote:
> > > > >
> > > > > HiFive Unleashed A00 support is25wp256 spi-nor flash,
> > > > > So enable the same and add test result log for future
> > > > > reference.
> > > > >
> > > > > Tested on SiFive FU540 board.
> > > > >
> > > > > Signed-off-by: Jagan Teki 
> > > > > Reviewed-by: Bin Meng 
> > > > > Tested-by: Bin Meng 
> > > > > ---
> > > > >  .../dts/hifive-unleashed-a00-u-boot.dtsi  |  1 +
> > > > >  board/sifive/fu540/Kconfig|  3 +++
> > > > >  doc/board/sifive/fu540.rst| 19 
> > > > > +++
> > > > >  3 files changed, 23 insertions(+)
> > > > >
> > > > > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > index 25ec8265a5..d7a64134db 100644
> > > > > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > @@ -5,6 +5,7 @@
> > > > >
> > > > >  / {
> > > > > aliases {
> > > > > +   spi0 = 
> > > > > spi2 = 
> > > > > };
> > > > >  };
> > > > > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> > > > > index 5d65080429..c5a1bca03c 100644
> > > > > --- a/board/sifive/fu540/Kconfig
> > > > > +++ b/board/sifive/fu540/Kconfig
> > > > > @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > imply CMD_FS_GENERIC
> > > > > imply CMD_NET
> > > > > imply CMD_PING
> > > > > +   imply CMD_SF
> > > > > imply CLK_SIFIVE
> > > > > imply CLK_SIFIVE_FU540_PRCI
> > > > > imply DOS_PARTITION
> > > > > @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > imply SIFIVE_SERIAL
> > > > > imply SPI
> > > > > imply SPI_SIFIVE
> > > > > +   imply SPI_FLASH
> > > > > +   imply SPI_FLASH_ISSI
> > > > > imply MMC
> > > > > imply MMC_SPI
> > > > > imply MMC_BROKEN_CD
> > > > > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
> > > > > index 91b94ee06f..2e70cad02e 100644
> > > > > --- a/doc/board/sifive/fu540.rst
> > > > > +++ b/doc/board/sifive/fu540.rst
> > > > > @@ -366,3 +366,22 @@ load uImage.
> > > > >
> > > > > Please press Enter to activate this console.
> > > > > / #
> > > > > +
> > > > > +Sample spi nor flash test
> > > > > +-
> > > > > +
> > > > > +.. code-block:: none
> > > > > +
> > > > > +   => sf probe 0:2
> > > >
> > > > The cs number can't be 2. It should be zero.
> > >
> > > With this patch series, we got crazy duplicated flash devices created,
> > > see below:
> > >
> > > => sf probe
> > > unrecognized JEDEC id bytes: ff, ff, ff
> > > Failed to initialize SPI flash at 0:0 (error -2)
> > > => sf probe 0:2
> > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 
> > > 32
> MiB
> > > => sf probe 0:4
> > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 
> > > 32
> MiB
> > > => sf probe 0:6
> > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 
> > > 32
> MiB
> > > => dm tree
> > >  Class Index  Probed  DriverName
> > > ---
> > >  root  0  [ + ]   root_driver   root_driver
> > >  simple_bus0  [ + ]   generic_simple_bus|-- soc
> > >  clk   0  [ + ]   sifive-fu540-prci |   |--
> > > clock-controller@1000
> > >  serial0  [ + ]   serial_sifive |   |-- serial@1001
> > >  serial1  [   ]   serial_sifive |   |-- serial@10011000
> > >  spi   0  [ + ]   sifive_spi|   |-- spi@1004
> > >  spi_flash 0  [   ]   spi_flash_std |   |   |-- flash@0
> > >  spi_flash 1  [ + ]   spi_flash_std |   |   |-- spi_flash@0:2
> > >  spi_flash 2  [ + ]   spi_flash_std |   |   |-- spi_flash@0:4
> > >  spi_flash 3  [ + ]   spi_flash_std |   |   `-- spi_flash@0:6
> > >
> > > With my patch series below
> > > http://patchwork.ozlabs.org/project/uboot/list/?series=129736
> > >
> > > the CS number check was added to the SPI flash hence we got:
> > >
> > > => sf probe
> > > unrecognized JEDEC id bytes: ff, ff, ff
> > > Failed to initialize SPI flash at 0:0 (error -2)
> > > => sf probe 2
> > > 

Re: [U-Boot] [PATCH v2] spl: Introduce SPL_DM_GPIO Kconfig define

2019-11-17 Thread Lukasz Majewski
Hi Simon,

> Hi Simon,
> 
> > Hi Lukasz,
> > 
> > On Mon, 14 Oct 2019 at 06:41, Lukasz Majewski 
> > wrote:  
> > >
> > > Hi Simon,
> > >
> > > > Hi Lukasz,
> > > >
> > > > On Wed, 9 Oct 2019 at 03:02, Lukasz Majewski 
> > > > wrote:
> > > > >
> > > > > Dear Tom,
> > > > >
> > > > > > This define indicates if DM_GPIO shall be supported in SPL.
> > > > > > This allows proper operation of DM converted GPIO drivers in
> > > > > > SPL, which use boards.
> > > > > >
> > > > > > Signed-off-by: Lukasz Majewski 
> > > > > > ---
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Add dependency on DM_GPIO
> > > > > >
> > > > >
> > > > > Tom, are there any issues preventing this patch from being
> > > > > applied to -master?
> > > >
> > > > This does not actually define DM_GPIO anywhere though, so this
> > > > is unused.
> > >
> > > The goal of this patch is to introduce in Kconfig a
> > > CONFIG_SPL_DM_GPIO. This define would be needed anyway, no matter
> > > if you perform the changes from [1].
> > >
> > > This Kconfig define is necessary for the XEA board (i.MX28 based
> > > one), which uses OF_PLATDATA in SPL excessively to fit into size
> > > constraints.
> > >
> > > To be more precise the mxs_gpio.c driver uses
> > > #if CONFIG_IS_ENABLED(DM_GPIO) to provide DM GPIO support in SPL
> > > with OF_PLATDATA.
> > >
> > >
> > > >
> > > > As it happens I sent a similar patch[1], but it doesn't work.
> > > > I'll try again.
> > >
> > > It would be great if we could have [1] not causing build breaks.
> > > However, for my used case it would be enough to have the Kconfig
> > > definition of CONFIG_SPL_DM_GPIO (as I'm using OF_PLATDATA) with
> > > it.
> > >
> > > Simon, if you don't have time to do the fix for [1] I would opt
> > > for pulling this patch (to just add proper Kconfig define).
> > 
> > I have had a crack at this here:
> > 
> > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/commit/a6d15bbd9e4e7684dd47d21817df85915f28cbab
> > 
> > I expect to send this series along with this patch at the end of
> > this week.  
> 
> If I may ask - have you made any progress on this?

In fact it blocks some i.MX28 related code (board to be precise) from
sending it upstream as converted drivers expect SPL_DM_GPIO to be
defined in Kconfig.

In fact I do just need following code:
https://patchwork.ozlabs.org/patch/1169013/

If you have some difficulties to solve (on e.g. other archs) then maybe
it would be enough to pull the above patch?

> 
> >   
> > >
> > > >
> > > > >
> > > > > >  common/spl/Kconfig | 6 ++
> > > > > >  1 file changed, 6 insertions(+)
> > > > > >
> > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > index f467eca2be..e3df8efa7e 100644
> > > > > > --- a/common/spl/Kconfig
> > > > > > +++ b/common/spl/Kconfig
> > > > > > @@ -452,6 +452,12 @@ config SPL_DMA_SUPPORT
> > > > > > the CPU moving the data. Enable this option to build
> > > > > > the drivers in drivers/dma as part of an SPL build.
> > > > > >
> > > > > > +config SPL_DM_GPIO
> > > > > > + bool "Support Driver Model GPIO drivers"
> > > > > > + depends on SPL_GPIO_SUPPORT && DM_GPIO
> > > > > > + help
> > > > > > +   Enable support for Driver Model based GPIO drivers
> > > > > > in SPL. +
> > > > > >  config SPL_DRIVERS_MISC_SUPPORT
> > > > > >   bool "Support misc drivers"
> > > > > >   help
> > > > >
> > > >
> > > > Regards,
> > > > SImon
> > > >
> > > > [1] http://patchwork.ozlabs.org/patch/1167276/
> > >
> > 
> > Regards,
> > Simon  
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpmyEiDIf3qx.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] spl: Introduce SPL_DM_GPIO Kconfig define

2019-11-17 Thread Lukasz Majewski
Hi Simon,

> Hi Lukasz,
> 
> On Mon, 14 Oct 2019 at 06:41, Lukasz Majewski  wrote:
> >
> > Hi Simon,
> >  
> > > Hi Lukasz,
> > >
> > > On Wed, 9 Oct 2019 at 03:02, Lukasz Majewski 
> > > wrote:  
> > > >
> > > > Dear Tom,
> > > >  
> > > > > This define indicates if DM_GPIO shall be supported in SPL.
> > > > > This allows proper operation of DM converted GPIO drivers in
> > > > > SPL, which use boards.
> > > > >
> > > > > Signed-off-by: Lukasz Majewski 
> > > > > ---
> > > > >
> > > > > Changes in v2:
> > > > > - Add dependency on DM_GPIO
> > > > >  
> > > >
> > > > Tom, are there any issues preventing this patch from being
> > > > applied to -master?  
> > >
> > > This does not actually define DM_GPIO anywhere though, so this is
> > > unused.  
> >
> > The goal of this patch is to introduce in Kconfig a
> > CONFIG_SPL_DM_GPIO. This define would be needed anyway, no matter
> > if you perform the changes from [1].
> >
> > This Kconfig define is necessary for the XEA board (i.MX28 based
> > one), which uses OF_PLATDATA in SPL excessively to fit into size
> > constraints.
> >
> > To be more precise the mxs_gpio.c driver uses
> > #if CONFIG_IS_ENABLED(DM_GPIO) to provide DM GPIO support in SPL
> > with OF_PLATDATA.
> >
> >  
> > >
> > > As it happens I sent a similar patch[1], but it doesn't work. I'll
> > > try again.  
> >
> > It would be great if we could have [1] not causing build breaks.
> > However, for my used case it would be enough to have the Kconfig
> > definition of CONFIG_SPL_DM_GPIO (as I'm using OF_PLATDATA) with it.
> >
> > Simon, if you don't have time to do the fix for [1] I would opt for
> > pulling this patch (to just add proper Kconfig define).  
> 
> I have had a crack at this here:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/commit/a6d15bbd9e4e7684dd47d21817df85915f28cbab
> 
> I expect to send this series along with this patch at the end of this
> week.

If I may ask - have you made any progress on this?

> 
> >  
> > >  
> > > >  
> > > > >  common/spl/Kconfig | 6 ++
> > > > >  1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > index f467eca2be..e3df8efa7e 100644
> > > > > --- a/common/spl/Kconfig
> > > > > +++ b/common/spl/Kconfig
> > > > > @@ -452,6 +452,12 @@ config SPL_DMA_SUPPORT
> > > > > the CPU moving the data. Enable this option to build
> > > > > the drivers in drivers/dma as part of an SPL build.
> > > > >
> > > > > +config SPL_DM_GPIO
> > > > > + bool "Support Driver Model GPIO drivers"
> > > > > + depends on SPL_GPIO_SUPPORT && DM_GPIO
> > > > > + help
> > > > > +   Enable support for Driver Model based GPIO drivers in
> > > > > SPL. +
> > > > >  config SPL_DRIVERS_MISC_SUPPORT
> > > > >   bool "Support misc drivers"
> > > > >   help  
> > > >  
> > >
> > > Regards,
> > > SImon
> > >
> > > [1] http://patchwork.ozlabs.org/patch/1167276/  
> >  
> 
> Regards,
> Simon

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpbahsxJsFIp.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] power: fan53555: fix fan53555_regulator_set_value

2019-11-17 Thread Vasily Khoruzhick
fan53555_regulator_set_value() passes its own dev to pmic_clrsetbits()
instead of its parent (pmic). As result u-boot crashes when you try to
set voltage on fan53555 regulator

Signed-off-by: Vasily Khoruzhick 
---
 drivers/power/regulator/fan53555.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/regulator/fan53555.c 
b/drivers/power/regulator/fan53555.c
index 9c48b26216..24a9b67586 100644
--- a/drivers/power/regulator/fan53555.c
+++ b/drivers/power/regulator/fan53555.c
@@ -159,7 +159,7 @@ static int fan53555_regulator_set_value(struct udevice 
*dev, int uV)
debug("%s: uV=%d; writing volume %d: %02x\n",
  __func__, uV, pdata->vol_reg, vol);
 
-   return pmic_clrsetbits(dev, pdata->vol_reg, GENMASK(6, 0), vol);
+   return pmic_clrsetbits(dev->parent, pdata->vol_reg, GENMASK(6, 0), vol);
 }
 
 static int fan53555_voltages_setup(struct udevice *dev)
-- 
2.24.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot-Board-Maintainers] Please pull u-boot-fdt

2019-11-17 Thread Simon Glass
Hi Bin,

On Sun, 17 Nov 2019 at 07:07, Bin Meng  wrote:
>
> Hi Simon,
>
> On Wed, Nov 6, 2019 at 7:12 AM Tom Rini  wrote:
> >
> > On Tue, Nov 05, 2019 at 05:23:51AM -0700, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > Passing run here:
> > >
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1210
> > >
> > >
> > > The following changes since commit 
> > > 73b6e6ad254b36763419cdd3fdf406c0094517b7:
> > >
> > >   Merge tag 'u-boot-imx-20191104' of
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-11-04
> > > 12:57:41 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://git.denx.de/u-boot-fdt.git tags/fdt-pull-5nov19
> > >
> > > for you to fetch changes up to 388560134b99dc4cc752627d3a7e9f8c8c2a89a7:
> > >
> > >   binman: Move to use Python 3 (2019-11-04 18:15:32 -0700)
> > >
> >
> > Now first,
> > Applied to u-boot/master, thanks!
> >
> > And second, which is why I've included the board maintainers list and
> > custodian lists, this causes a bit of size growth everywhere just about
> > (tbs2910 being the exception) because by default upstream now has
> > various input validation routines.  It doesn't catch "tell the hardware
> > to overvolt something" but does catch "pass garbage in the property so
> > we can overwrite the stack and ..." type problems.  And it's
> > configurable.  If you turn off all of the validation stuff, which we do
> > in SPL/TPL by default (size concerns!), in the main U-Boot we go from a
> > size growth to a size shrink.  An arbitrary PowerPC board I picked to
> > confirm this on grows by 985 bytes now, but if I turned everything off
> > it would shrink by 1100 bytes.  There's an inbetween setting that would
> > probably result in neutral size change.
> >
> > The default is all of the input validation we can do because I believe
> > it's important to validate inputs when we can validate them.  I also
> > firmly believe board maintainers know their requirements best and can
> > provide a different value for their board(s).
>
> I found the following commits breaks SiFive FU540 board, that U-Boot
> no longer boots:
>
> commit f0921f5098d8d98ac38121837aaf7c4b4cb13bb4
> Author: Simon Glass 
> Date:   Sun Oct 27 09:47:42 2019 -0600
>
> fdt: Sync up to the latest libfdt
>
> Reverting this commit makes U-Boot boot again.
>
> The failure is serial_find_console_or_panic() no longer finds the
> serial port with the latest libfdt. Any ideas?

I wonder if it is relying on a feature that never made it upstream?

There was a change to fdt_path_next_separator() which got dropped -
perhaps that is it? I had assumed it was incorporated but perhaps no
action was taken? If so, the thread is here:

http://patchwork.ozlabs.org/patch/462756/

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Build warnings in libfdt

2019-11-17 Thread Simon Glass
Hi,

On Sun, 17 Nov 2019 at 06:14, Tom Rini  wrote:
>
> On Sun, Nov 17, 2019 at 11:11:43AM +0100, Heinrich Schuchardt wrote:
> > Hello Simon,
> >
> > when building U-Boot HEAD with GCC 9.2.1 I get a bunch of build warnings
> > which I did not see before your recent libfdt update.
> >
> > scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’:
> > scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer
> > expressions of different signedness: ‘unsigned int’ and ‘int’
> > [-Wsign-compare]
> >   137 |   if ((absoffset < offset)
> >   |  ^
> > scripts/dtc/libfdt/fdt.c:143:23: warning: comparison of integer
> > expressions of different signedness: ‘unsigned int’ and ‘int’
> > [-Wsign-compare]
> >   143 |   if (((offset + len) < offset)
> >   |   ^
> > scripts/dtc/libfdt/fdt.c: In function ‘fdt_move’:
> > scripts/dtc/libfdt/fdt.c:307:25: warning: comparison of integer
> > expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> > ‘int’ [-Wsign-compare]
> >   307 |  if (fdt_totalsize(fdt) > bufsize)
> >   | ^
> > scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_get_string’:
> > scripts/dtc/libfdt/fdt_ro.c:56:16: warning: comparison of integer
> > expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> > ‘int32_t’ {aka ‘int’} [-Wsign-compare]
> >56 |  if (absoffset >= totalsize)
> >   |^~
> > scripts/dtc/libfdt/fdt_ro.c:64:18: warning: comparison of integer
> > expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> > int’} [-Wsign-compare]
> >64 |if (stroffset >= fdt_size_dt_strings(fdt))
> >   |  ^~
> > scripts/dtc/libfdt/fdt_ro.c:71:21: warning: comparison of integer
> > expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> > int’} [-Wsign-compare]
> >71 |   || (stroffset < -fdt_size_dt_strings(fdt)))
> >   | ^
> > scripts/dtc/libfdt/fdt_ro.c:73:20: warning: comparison of integer
> > expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
> > unsigned int’} [-Wsign-compare]
> >73 |   if ((-stroffset) < len)
> >   |^
> > scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_mem_rsv’:
> > scripts/dtc/libfdt/fdt_ro.c:164:17: warning: comparison of integer
> > expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> > int’} [-Wsign-compare]
> >   164 |   if (absoffset < fdt_off_mem_rsvmap(fdt))
> >   | ^
> > scripts/dtc/libfdt/fdt_ro.c:166:17: warning: comparison of integer
> > expressions of different signedness: ‘int’ and ‘long unsigned int’
> > [-Wsign-compare]
> >   166 |   if (absoffset > fdt_totalsize(fdt) -
> >   | ^
> > scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_node_offset_by_phandle’:
> > scripts/dtc/libfdt/fdt_ro.c:682:33: warning: comparison of integer
> > expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> > ‘int’ [-Wsign-compare]
> >   682 |  if ((phandle == 0) || (phandle == -1))
> >   | ^~
> > scripts/dtc/libfdt/fdt_wip.c: In function
> > ‘fdt_setprop_inplace_namelen_partial’:
> > scripts/dtc/libfdt/fdt_wip.c:26:14: warning: comparison of integer
> > expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> > int’} [-Wsign-compare]
> >26 |  if (proplen < (len + idx))
> >   |  ^
> > scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_grab_space_’:
> > scripts/dtc/libfdt/fdt_sw.c:105:20: warning: comparison of integer
> > expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
> > and ‘int’ [-Wsign-compare]
> >   105 |  if ((offset + len < offset) || (offset + len > spaceleft))
> >   |^
> > scripts/dtc/libfdt/fdt_sw.c:105:47: warning: comparison of integer
> > expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
> > and ‘int’ [-Wsign-compare]
> >   105 |  if ((offset + len < offset) || (offset + len > spaceleft))
> >   |   ^
> > scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_create_with_flags’:
> > scripts/dtc/libfdt/fdt_sw.c:118:14: warning: comparison of integer
> > expressions of different signedness: ‘int’ and ‘long unsigned int’
> > [-Wsign-compare]
> >   118 |  if (bufsize < hdrsize)
> >   |  ^
> > scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_resize’:
> > scripts/dtc/libfdt/fdt_sw.c:164:28: warning: comparison of integer
> > expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
> > and ‘int’ [-Wsign-compare]
> >   164 |  if ((headsize + tailsize) > bufsize)
> >   |^
> > scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_add_string_’:
> > scripts/dtc/libfdt/fdt_sw.c:258:34: warning: comparison of integer
> > expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> > ‘int’ [-Wsign-compare]
> >   258 |  

Re: [U-Boot] [U-Boot-Board-Maintainers] Please pull u-boot-fdt

2019-11-17 Thread Bin Meng
Hi Simon,

On Wed, Nov 6, 2019 at 7:12 AM Tom Rini  wrote:
>
> On Tue, Nov 05, 2019 at 05:23:51AM -0700, Simon Glass wrote:
>
> > Hi Tom,
> >
> > Passing run here:
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1210
> >
> >
> > The following changes since commit 73b6e6ad254b36763419cdd3fdf406c0094517b7:
> >
> >   Merge tag 'u-boot-imx-20191104' of
> > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-11-04
> > 12:57:41 -0500)
> >
> > are available in the Git repository at:
> >
> >   git://git.denx.de/u-boot-fdt.git tags/fdt-pull-5nov19
> >
> > for you to fetch changes up to 388560134b99dc4cc752627d3a7e9f8c8c2a89a7:
> >
> >   binman: Move to use Python 3 (2019-11-04 18:15:32 -0700)
> >
>
> Now first,
> Applied to u-boot/master, thanks!
>
> And second, which is why I've included the board maintainers list and
> custodian lists, this causes a bit of size growth everywhere just about
> (tbs2910 being the exception) because by default upstream now has
> various input validation routines.  It doesn't catch "tell the hardware
> to overvolt something" but does catch "pass garbage in the property so
> we can overwrite the stack and ..." type problems.  And it's
> configurable.  If you turn off all of the validation stuff, which we do
> in SPL/TPL by default (size concerns!), in the main U-Boot we go from a
> size growth to a size shrink.  An arbitrary PowerPC board I picked to
> confirm this on grows by 985 bytes now, but if I turned everything off
> it would shrink by 1100 bytes.  There's an inbetween setting that would
> probably result in neutral size change.
>
> The default is all of the input validation we can do because I believe
> it's important to validate inputs when we can validate them.  I also
> firmly believe board maintainers know their requirements best and can
> provide a different value for their board(s).

I found the following commits breaks SiFive FU540 board, that U-Boot
no longer boots:

commit f0921f5098d8d98ac38121837aaf7c4b4cb13bb4
Author: Simon Glass 
Date:   Sun Oct 27 09:47:42 2019 -0600

fdt: Sync up to the latest libfdt

Reverting this commit makes U-Boot boot again.

The failure is serial_find_console_or_panic() no longer finds the
serial port with the latest libfdt. Any ideas?

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Build warnings in libfdt

2019-11-17 Thread Tom Rini
On Sun, Nov 17, 2019 at 11:11:43AM +0100, Heinrich Schuchardt wrote:
> Hello Simon,
> 
> when building U-Boot HEAD with GCC 9.2.1 I get a bunch of build warnings
> which I did not see before your recent libfdt update.
> 
> scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’:
> scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer
> expressions of different signedness: ‘unsigned int’ and ‘int’
> [-Wsign-compare]
>   137 |   if ((absoffset < offset)
>   |  ^
> scripts/dtc/libfdt/fdt.c:143:23: warning: comparison of integer
> expressions of different signedness: ‘unsigned int’ and ‘int’
> [-Wsign-compare]
>   143 |   if (((offset + len) < offset)
>   |   ^
> scripts/dtc/libfdt/fdt.c: In function ‘fdt_move’:
> scripts/dtc/libfdt/fdt.c:307:25: warning: comparison of integer
> expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> ‘int’ [-Wsign-compare]
>   307 |  if (fdt_totalsize(fdt) > bufsize)
>   | ^
> scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_get_string’:
> scripts/dtc/libfdt/fdt_ro.c:56:16: warning: comparison of integer
> expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> ‘int32_t’ {aka ‘int’} [-Wsign-compare]
>56 |  if (absoffset >= totalsize)
>   |^~
> scripts/dtc/libfdt/fdt_ro.c:64:18: warning: comparison of integer
> expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> int’} [-Wsign-compare]
>64 |if (stroffset >= fdt_size_dt_strings(fdt))
>   |  ^~
> scripts/dtc/libfdt/fdt_ro.c:71:21: warning: comparison of integer
> expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> int’} [-Wsign-compare]
>71 |   || (stroffset < -fdt_size_dt_strings(fdt)))
>   | ^
> scripts/dtc/libfdt/fdt_ro.c:73:20: warning: comparison of integer
> expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
> unsigned int’} [-Wsign-compare]
>73 |   if ((-stroffset) < len)
>   |^
> scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_mem_rsv’:
> scripts/dtc/libfdt/fdt_ro.c:164:17: warning: comparison of integer
> expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> int’} [-Wsign-compare]
>   164 |   if (absoffset < fdt_off_mem_rsvmap(fdt))
>   | ^
> scripts/dtc/libfdt/fdt_ro.c:166:17: warning: comparison of integer
> expressions of different signedness: ‘int’ and ‘long unsigned int’
> [-Wsign-compare]
>   166 |   if (absoffset > fdt_totalsize(fdt) -
>   | ^
> scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_node_offset_by_phandle’:
> scripts/dtc/libfdt/fdt_ro.c:682:33: warning: comparison of integer
> expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> ‘int’ [-Wsign-compare]
>   682 |  if ((phandle == 0) || (phandle == -1))
>   | ^~
> scripts/dtc/libfdt/fdt_wip.c: In function
> ‘fdt_setprop_inplace_namelen_partial’:
> scripts/dtc/libfdt/fdt_wip.c:26:14: warning: comparison of integer
> expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
> int’} [-Wsign-compare]
>26 |  if (proplen < (len + idx))
>   |  ^
> scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_grab_space_’:
> scripts/dtc/libfdt/fdt_sw.c:105:20: warning: comparison of integer
> expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
> and ‘int’ [-Wsign-compare]
>   105 |  if ((offset + len < offset) || (offset + len > spaceleft))
>   |^
> scripts/dtc/libfdt/fdt_sw.c:105:47: warning: comparison of integer
> expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
> and ‘int’ [-Wsign-compare]
>   105 |  if ((offset + len < offset) || (offset + len > spaceleft))
>   |   ^
> scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_create_with_flags’:
> scripts/dtc/libfdt/fdt_sw.c:118:14: warning: comparison of integer
> expressions of different signedness: ‘int’ and ‘long unsigned int’
> [-Wsign-compare]
>   118 |  if (bufsize < hdrsize)
>   |  ^
> scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_resize’:
> scripts/dtc/libfdt/fdt_sw.c:164:28: warning: comparison of integer
> expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
> and ‘int’ [-Wsign-compare]
>   164 |  if ((headsize + tailsize) > bufsize)
>   |^
> scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_add_string_’:
> scripts/dtc/libfdt/fdt_sw.c:258:34: warning: comparison of integer
> expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
> ‘int’ [-Wsign-compare]
>   258 |  if (fdt_totalsize(fdt) + offset < struct_top)
>   |  ^
> scripts/dtc/libfdt/fdt_strerror.c: In function ‘fdt_strerror’:
> scripts/dtc/libfdt/fdt_strerror.c:51:18: warning: comparison of integer
> expressions 

[U-Boot] [RFC PATCH] rockchip: tinker: Add automatic board discovery

2019-11-17 Thread Michael Trimarchi
Add a way to detect board id and pcb id.

Signed-off-by: Michael Trimarchi 
---
 arch/arm/dts/rk3288-tinker.dtsi  | 33 
 board/rockchip/tinker_rk3288/tinker-rk3288.c | 83 
 2 files changed, 116 insertions(+)

diff --git a/arch/arm/dts/rk3288-tinker.dtsi b/arch/arm/dts/rk3288-tinker.dtsi
index 2f816af47f..67a0374050 100644
--- a/arch/arm/dts/rk3288-tinker.dtsi
+++ b/arch/arm/dts/rk3288-tinker.dtsi
@@ -53,6 +53,21 @@
#clock-cells = <0>;
};
 
+   board_info: board-info {
+   tinker,pcbid0 = < 8 GPIO_ACTIVE_HIGH>;
+   tinker,pcbid1 = < 9 GPIO_ACTIVE_HIGH>;
+   tinker,pcbid2 = < 10 GPIO_ACTIVE_HIGH>;
+   tinker,pid0 = < 1 GPIO_ACTIVE_HIGH>;
+   tinker,pid1 = < 2 GPIO_ACTIVE_HIGH>;
+   tinker,pid2 = < 3 GPIO_ACTIVE_HIGH>;
+   };
+
+   board_control: board-control {
+   tinker,sdp = < 5 GPIO_ACTIVE_HIGH>;
+   tinker,usblimit = < 6 GPIO_ACTIVE_HIGH>;
+   tinker,maskemmc = < 7 GPIO_ACTIVE_HIGH>;
+   };
+
gpio-keys {
compatible = "gpio-keys";
autorepeat;
@@ -461,6 +476,10 @@
 };
 
  {
+   /* Pins that are not explicitely used by any devices */
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_hog>;
+
pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
drive-strength = <8>;
};
@@ -482,6 +501,20 @@
};
};
 
+   hog {
+   tinker_pin_hog: tinker-pin-hog {
+   rockchip,pins = <2 RK_PA1 RK_FUNC_GPIO _pull_up>, 
/* project id 0 */
+   <2 RK_PA2 RK_FUNC_GPIO _pull_up>, 
/* project id 1 */
+   <2 RK_PA3 RK_FUNC_GPIO _pull_up>, 
/* project id 2 */
+   <2 RK_PB0 RK_FUNC_GPIO 
_pull_none>, /* pcb id 0 */
+   <2 RK_PB1 RK_FUNC_GPIO 
_pull_none>, /* pcb id 1 */
+   <2 RK_PB2 RK_FUNC_GPIO 
_pull_none>, /* pcb id 2 */
+   <6 RK_PA5 RK_FUNC_GPIO 
_pull_none>, /* sdp detect */
+   <6 RK_PA6 RK_FUNC_GPIO _pull_up>, 
/* current limit */
+   <6 RK_PA7 RK_FUNC_GPIO 
_pull_none>; /* emmc mask */
+   };
+   };
+
eth_phy {
eth_phy_pwr: eth-phy-pwr {
rockchip,pins = <0 6 RK_FUNC_GPIO _pull_none>;
diff --git a/board/rockchip/tinker_rk3288/tinker-rk3288.c 
b/board/rockchip/tinker_rk3288/tinker-rk3288.c
index 7a0c3c997d..7c65521f55 100644
--- a/board/rockchip/tinker_rk3288/tinker-rk3288.c
+++ b/board/rockchip/tinker_rk3288/tinker-rk3288.c
@@ -5,12 +5,26 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
+enum project_id {
+   tinker_board_s = 0,
+   tinker_board = 7,
+};
+
+enum pcb_id {
+   SR,
+   ER,
+   PR,
+};
+
 static int get_ethaddr_from_eeprom(u8 *addr)
 {
int ret;
@@ -23,10 +37,14 @@ static int get_ethaddr_from_eeprom(u8 *addr)
return i2c_eeprom_read(dev, 0, addr, 6);
 }
 
+int detect_board_init(void);
+
 int rk3288_board_late_init(void)
 {
u8 ethaddr[6];
 
+   detect_board_init();
+
if (get_ethaddr_from_eeprom(ethaddr))
return 0;
 
@@ -45,3 +63,68 @@ int mmc_get_env_dev(void)
 
return 1;
 }
+
+int detect_board_init(void)
+{
+   int ret = 0, i;
+   ofnode node;
+   struct udevice *gpio_dev2 = NULL;
+   struct udevice *gpio_dev6 = NULL;
+   struct gpio_desc pcbid[3];
+   struct gpio_desc pid[3];
+   enum project_id prjid;
+   char gpio_name[64];
+   enum pcb_id pcbversion;
+
+   debug("%s: detect boad\n", __func__);
+
+   if (uclass_get_device_by_name(UCLASS_GPIO, "gpio2@ff79", 
_dev2) ||
+   uclass_get_device_by_name(UCLASS_GPIO, "gpio6@ff7d", 
_dev6)) {
+   printf("Could not get GPIO device.\n");
+   return -EINVAL;
+   }
+
+   ret = device_probe(gpio_dev2);
+   if (ret)
+   pr_err("%s - probe failed: %d\n", gpio_dev2->name, ret);
+
+   ret = device_probe(gpio_dev6);
+   if (ret)
+   pr_err("%s - probe failed: %d\n", gpio_dev6->name, ret);
+
+   node = ofnode_path("/board-info");
+   if (!ofnode_valid(node)) {
+   pr_err("%s: no /board-info node?\n", __func__);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < 3; i++) {
+   snprintf(gpio_name, 64, "tinker,pid%d", i);
+   if (gpio_request_by_name_nodev(node, gpio_name, 0,
+   [i], GPIOD_IS_IN)) {
+   printf("Failed to request %s\n", gpio_name);
+   continue;
+   }
+}
+
+   for (i = 0; i 

[U-Boot] Build warnings in libfdt

2019-11-17 Thread Heinrich Schuchardt

Hello Simon,

when building U-Boot HEAD with GCC 9.2.1 I get a bunch of build warnings
which I did not see before your recent libfdt update.

scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’:
scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer
expressions of different signedness: ‘unsigned int’ and ‘int’
[-Wsign-compare]
  137 |   if ((absoffset < offset)
  |  ^
scripts/dtc/libfdt/fdt.c:143:23: warning: comparison of integer
expressions of different signedness: ‘unsigned int’ and ‘int’
[-Wsign-compare]
  143 |   if (((offset + len) < offset)
  |   ^
scripts/dtc/libfdt/fdt.c: In function ‘fdt_move’:
scripts/dtc/libfdt/fdt.c:307:25: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int’ [-Wsign-compare]
  307 |  if (fdt_totalsize(fdt) > bufsize)
  | ^
scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_get_string’:
scripts/dtc/libfdt/fdt_ro.c:56:16: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int32_t’ {aka ‘int’} [-Wsign-compare]
   56 |  if (absoffset >= totalsize)
  |^~
scripts/dtc/libfdt/fdt_ro.c:64:18: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
   64 |if (stroffset >= fdt_size_dt_strings(fdt))
  |  ^~
scripts/dtc/libfdt/fdt_ro.c:71:21: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
   71 |   || (stroffset < -fdt_size_dt_strings(fdt)))
  | ^
scripts/dtc/libfdt/fdt_ro.c:73:20: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long
unsigned int’} [-Wsign-compare]
   73 |   if ((-stroffset) < len)
  |^
scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_mem_rsv’:
scripts/dtc/libfdt/fdt_ro.c:164:17: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
  164 |   if (absoffset < fdt_off_mem_rsvmap(fdt))
  | ^
scripts/dtc/libfdt/fdt_ro.c:166:17: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘long unsigned int’
[-Wsign-compare]
  166 |   if (absoffset > fdt_totalsize(fdt) -
  | ^
scripts/dtc/libfdt/fdt_ro.c: In function ‘fdt_node_offset_by_phandle’:
scripts/dtc/libfdt/fdt_ro.c:682:33: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int’ [-Wsign-compare]
  682 |  if ((phandle == 0) || (phandle == -1))
  | ^~
scripts/dtc/libfdt/fdt_wip.c: In function
‘fdt_setprop_inplace_namelen_partial’:
scripts/dtc/libfdt/fdt_wip.c:26:14: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘uint32_t’ {aka ‘unsigned
int’} [-Wsign-compare]
   26 |  if (proplen < (len + idx))
  |  ^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_grab_space_’:
scripts/dtc/libfdt/fdt_sw.c:105:20: warning: comparison of integer
expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
and ‘int’ [-Wsign-compare]
  105 |  if ((offset + len < offset) || (offset + len > spaceleft))
  |^
scripts/dtc/libfdt/fdt_sw.c:105:47: warning: comparison of integer
expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
and ‘int’ [-Wsign-compare]
  105 |  if ((offset + len < offset) || (offset + len > spaceleft))
  |   ^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_create_with_flags’:
scripts/dtc/libfdt/fdt_sw.c:118:14: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘long unsigned int’
[-Wsign-compare]
  118 |  if (bufsize < hdrsize)
  |  ^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_resize’:
scripts/dtc/libfdt/fdt_sw.c:164:28: warning: comparison of integer
expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’}
and ‘int’ [-Wsign-compare]
  164 |  if ((headsize + tailsize) > bufsize)
  |^
scripts/dtc/libfdt/fdt_sw.c: In function ‘fdt_add_string_’:
scripts/dtc/libfdt/fdt_sw.c:258:34: warning: comparison of integer
expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and
‘int’ [-Wsign-compare]
  258 |  if (fdt_totalsize(fdt) + offset < struct_top)
  |  ^
scripts/dtc/libfdt/fdt_strerror.c: In function ‘fdt_strerror’:
scripts/dtc/libfdt/fdt_strerror.c:51:18: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘long unsigned int’
[-Wsign-compare]
   51 |  else if (errval > -FDT_ERRTABSIZE) {
  |  ^
scripts/dtc/libfdt/fdt_overlay.c: In function
‘overlay_update_local_node_references’:

[U-Boot] [PATCH 1/1] efi_loader: restrict EFI_LOADER to armv7 and armv8 on ARM

2019-11-17 Thread Heinrich Schuchardt
fatload USB was reported to fail on the Sheevaplug. Debugging showed that
this was caused by an incorrect unaligned write to memory in
path_to_uefi().

UEFI on ARM requires that unaligned memory access is enabled.

* ARMv5 does not support unaligned access at all.
* ARMv6 supports unaligned access when we clear the A flag and set the
  U flag.
* On ARMv7 unaligned access is possible when clearing the aligned flag,
  which we do in function allow_unaligned() (arch/arm/cpu/armv7/sctlr.S).
  For none of the other cpus in arch/arm/cpu/ we have implemented a
  similar function.
* ARMv8 allows unaligned access.

Let EFI_LOADER on ARM depend on SYS_CPU=armv7 or SYS_CPU=armv8.

Once we have implemented allow_unaligned() for other ARM CPUs we can add
these to Kconfig.

Reported-by: Gray Remlin 
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c7027a9676..2f40e485ef 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,6 +1,9 @@
 config EFI_LOADER
bool "Support running UEFI applications"
-   depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT
+   depends on OF_LIBFDT && ( \
+   ARM && (SYS_CPU = armv7 || \
+   SYS_CPU = armv8) || \
+   X86 || RISCV || SANDBOX)
# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
--
2.24.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

2019-11-17 Thread Heinrich Schuchardt

On 11/17/19 8:50 AM, Stefan Roese wrote:

Hi Heinrich,

(+Chris)

On 16.11.19 11:11, Heinrich Schuchardt wrote:

Hello Stefan,

Gray reporting this bug unfortunately did not provide enough information
to analyze his issue.

Are you aware of any restrictions of the Kirkwood 88F6281 SoC concerning
unaligned access after enabling the unaligned flag?

Do you have access to a device with a Kirkwood processor (e.g. 
Sheevaplug)?


No, unfortunately I don't have have a Kirkwood based board. Chris has
access to some boards though. Chris, do you have a chance to comment
on this?


One possible solution would be to let CONFIG_EFI_LOADER depend on
CONFIG_KIRKWOOD=n. This would concern 36 devices.


That would be very unfortunate.

Thanks,
Stefan


Best regards

Heinrich

On 11/13/19 8:07 AM, Heinrich Schuchardt wrote:

On 11/12/19 11:55 PM, Gray Remlin wrote:



On Tue, 12 Nov 2019 at 19:50, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

 On 11/11/19 6:14 PM, Gray Remlin wrote:
  >
  > This content is getting very convoluted, if appropriate feel
free to
  > crop it.
  > New point raised at very bottom.
  >
  > On Sun, 10 Nov 2019 at 08:41, Heinrich Schuchardt
 mailto:xypron.g...@gmx.de>
  > >> wrote:
  >
  >     On 11/9/19 10:31 PM, Gray Remlin wrote:
  >      > On Sat, 9 Nov 2019 at 20:50, Heinrich Schuchardt
  >     mailto:xypron.g...@gmx.de>
 >
  >      > 
       >
  >      >     On 11/9/19 8:42 PM, Gray Remlin wrote:
  >      >      > On Sat, 9 Nov 2019 at 18:40, Heinrich Schuchardt
  >      >     mailto:xypron.g...@gmx.de>
 >
  >     
 >>
  >      >      >  >
  >     
  wrote:
  >      >      >
  >      >      >     On 11/9/19 6:08 PM, Heinrich Schuchardt 
wrote:

  >      >      >      > On 11/9/19 4:11 PM, Gray Remlin wrote:
  >      >      >      >> On Fri, 8 Nov 2019 at 20:08, Heinrich
 Schuchardt
  >      >      >     

 >
  >     
 >>
  >      >     

 >
  >     
       >      >      >> 
  >     >
 
  >     >>
  >      >     

 >
  >     
 > wrote:
  >      >      >      >>
  >      >      >      >>     On 11/8/19 7:32 PM, Gray Remlin 
wrote:

  >      >      >      >>  > Please excuse the noise. I would
 like to file a
  >      >     bug report
  >      >      >      >>     against the
  >      >      >      >>  > above commit, a quick search of
 www.denx.de 
  >     
  >      >     
  >      >      >      
  >      >      >      >>      did not
  >      >      >      >>  > reveal how I should proceed. 
Please

 point me in
  >      >     the right
  >      >      >      >> direction.
  >      >      >      >>  >
  >      >      >      >>  >
  >      >      >      >>  > Issue:
  >      >      >      >>  > U-Boot hangs (i.e. during boot)
whenever
  >     the command
  >      >      >     'fatload' is
  >      >      >      >>     used.
  >      >      >      >>  >
  >      >      >      >>  > Details:
  >      >      >      >>  > U-Boot 2019.10 compiled with 
either

  >      >     dreamplug_defconfig or
  >      >      >      >>  > guruplug_defconfig.
  >      >      >      >>  >

Re: [U-Boot] [PATCH V4 1/2] rockchip: dts: tinker: Move u-boot dmc initialization to specific section

2019-11-17 Thread Kever Yang


On 2019/11/16 上午5:07, Michael Trimarchi wrote:

dmc is used to initialize the memory controller. It's needed by
u-boot. Move it in the specific section

Signed-off-by: Michael Trimarchi 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
Changes:
nothing
---
  arch/arm/dts/rk3288-tinker-u-boot.dtsi | 12 
  arch/arm/dts/rk3288-tinker.dts | 12 
  2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/dts/rk3288-tinker-u-boot.dtsi 
b/arch/arm/dts/rk3288-tinker-u-boot.dtsi
index f7f9d6dc72..732aa4f91f 100644
--- a/arch/arm/dts/rk3288-tinker-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-tinker-u-boot.dtsi
@@ -5,6 +5,18 @@
  
  #include "rk3288-u-boot.dtsi"
  
+ {

+   u-boot,dm-pre-reloc;
+   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+   0x8 0x1f4>;
+   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+   0x0 0xc3 0x6 0x2>;
+   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
   {
u-boot,dm-pre-reloc;
  };
diff --git a/arch/arm/dts/rk3288-tinker.dts b/arch/arm/dts/rk3288-tinker.dts
index 94c3afe860..4b8405fd82 100644
--- a/arch/arm/dts/rk3288-tinker.dts
+++ b/arch/arm/dts/rk3288-tinker.dts
@@ -15,18 +15,6 @@
};
  };
  
- {

-   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
-   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
-   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
-   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
-   0x8 0x1f4>;
-   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
-   0x0 0xc3 0x6 0x2>;
-   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
-};
-
-
   {
usb {
host_vbus_drv: host-vbus-drv {



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V4 2/2] rockchip: dts: tinker: Add tinker-s board support

2019-11-17 Thread Kever Yang


On 2019/11/16 上午5:07, Michael Trimarchi wrote:

Support tinker-s board. The board is equivalent of tinker board
except of emmc.

TODO:
- support of usb current burst when the board is powered from pc

Signed-off-by: Michael Trimarchi 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
Changes:
v3->v4: Add mantainer and boot from to save the enviroment
v2->v3: drop dmc section
v1->v2: Add boot configuration for emmc
---
  arch/arm/dts/Makefile|  1 +
  arch/arm/dts/rk3288-tinker-s-u-boot.dtsi | 34 +++
  arch/arm/dts/rk3288-tinker-s.dts | 29 ++
  board/rockchip/tinker_rk3288/MAINTAINERS |  7 ++
  board/rockchip/tinker_rk3288/tinker-rk3288.c | 12 +++
  configs/tinker-s-rk3288_defconfig| 99 
  include/configs/tinker_rk3288.h  |  1 +
  7 files changed, 183 insertions(+)
  create mode 100644 arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3288-tinker-s.dts
  create mode 100644 configs/tinker-s-rk3288_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85ef00a2bd..dfaeea4a25 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
rk3288-tinker.dtb \
+   rk3288-tinker-s.dtb \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
diff --git a/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi 
b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
new file mode 100644
index 00..a177fca73a
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Amarula Solutions SRO
+ */
+
+#include "rk3288-u-boot.dtsi"
+#include "rk3288-tinker-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = \
+   "same-as-spl", , 
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_clk {
+   u-boot,dm-spl;
+};
+
+_cmd {
+   u-boot,dm-spl;
+};
+
+_pwr {
+   u-boot,dm-spl;
+};
+
+_bus8 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3288-tinker-s.dts b/arch/arm/dts/rk3288-tinker-s.dts
new file mode 100644
index 00..cc7ac5f881
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "rk3288-tinker.dtsi"
+
+/ {
+   model = "Rockchip RK3288 Asus Tinker Board S";
+   compatible = "asus,rk3288-tinker-s", "rockchip,rk3288";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   non-removable;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _pwr _bus8>;
+   max-frequency = <15000>;
+   mmc-hs200-1_8v;
+   mmc-ddr-1_8v;
+   status = "okay";
+};
diff --git a/board/rockchip/tinker_rk3288/MAINTAINERS 
b/board/rockchip/tinker_rk3288/MAINTAINERS
index cddceafb6e..ed5de682c9 100644
--- a/board/rockchip/tinker_rk3288/MAINTAINERS
+++ b/board/rockchip/tinker_rk3288/MAINTAINERS
@@ -4,3 +4,10 @@ S: Maintained
  F:board/rockchip/tinker_rk3288
  F:include/configs/tinker_rk3288.h
  F:configs/tinker-rk3288_defconfig
+
+TINKER-S-RK3288
+M: Michael Trimarchi 
+S: Maintained
+F: board/rockchip/tinker_rk3288
+F: include/configs/tinker_rk3288.h
+F: configs/tinker-s-rk3288_defconfig
diff --git a/board/rockchip/tinker_rk3288/tinker-rk3288.c 
b/board/rockchip/tinker_rk3288/tinker-rk3288.c
index 6c76c3c25c..7a0c3c997d 100644
--- a/board/rockchip/tinker_rk3288/tinker-rk3288.c
+++ b/board/rockchip/tinker_rk3288/tinker-rk3288.c
@@ -8,6 +8,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  
  static int get_ethaddr_from_eeprom(u8 *addr)

  {
@@ -33,3 +35,13 @@ int rk3288_board_late_init(void)
  
  	return 0;

  }
+
+int mmc_get_env_dev(void)
+{
+   u32 bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+
+   if (bootdevice_brom_id == BROM_BOOTSOURCE_EMMC)
+   return 0;
+
+   return 1;
+}
diff --git a/configs/tinker-s-rk3288_defconfig 
b/configs/tinker-s-rk3288_defconfig
new file mode 100644
index 00..c851a93f31
--- /dev/null
+++ b/configs/tinker-s-rk3288_defconfig
@@ -0,0 +1,99 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ROCKCHIP_RK3288=y
+CONFIG_TARGET_TINKER_RK3288=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_SIZE_LIMIT=307200
+CONFIG_SPL_STACK_R_ADDR=0x80
+CONFIG_DEBUG_UART_BASE=0xff69
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART=y
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SILENT_CONSOLE=y
+CONFIG_CONSOLE_MUX=y

Re: [U-Boot] [PATCH v2 2/3] rockchip: allow DRAM init in SPL

2019-11-17 Thread Kever Yang


On 2019/11/16 上午12:48, Thomas Hebb wrote:

b7abef2ecbcc ("rockchip: rk3399: Migrate to use common spl board file")
removed SoC-specific code for RK3399's SPL and in the process caused
the previously-unconditional DRAM initialization in board_init_f() to
only happen when compiling a configuration that does not support TPL,
meaning DRAM never gets initialized if TPL is supported but disabled.

Fix this by omitting the DRAM init in SPL only when we are configured to
also build a TPL. This fixes custom configurations that have disabled
TPL, and it should also unbreak the "ficus-rk3399", "rock960-rk3399",
and "chromebook_bob" defconfigs, although since I don't have any of
those devices I can't confirm they're broken now.

Signed-off-by: Thomas Hebb 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/mach-rockchip/spl.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 5570bb1339..089f0a5258 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -103,7 +103,7 @@ __weak int arch_cpu_init(void)
  void board_init_f(ulong dummy)
  {
int ret;
-#if !defined(CONFIG_SUPPORT_TPL) || defined(CONFIG_SPL_OS_BOOT)
+#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_OS_BOOT)
struct udevice *dev;
  #endif
  
@@ -135,7 +135,7 @@ void board_init_f(ulong dummy)

/* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */
timer_init();
  #endif
-#if !defined(CONFIG_SUPPORT_TPL) || defined(CONFIG_SPL_OS_BOOT)
+#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_OS_BOOT)
debug("\nspl:init dram\n");
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret) {



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/3] rockchip: imply instead of selecting SPL_SYS_MALLOC_SIMPLE

2019-11-17 Thread Kever Yang


On 2019/11/16 上午12:48, Thomas Hebb wrote:

We shouldn't force which allocator the SPL uses, since there's no
platform requirement for one over the other: in fact, we currently allow
selection of the TPL allocator but not the SPL one!

Signed-off-by: Thomas Hebb 


Reviewed-by: Kever Yang 

Thanks,
- Kever

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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7b80630aa1..f96841c777 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1604,7 +1604,6 @@ config ARCH_ROCKCHIP
select OF_CONTROL
select SPI
select SPL_DM if SPL
-   select SPL_SYS_MALLOC_SIMPLE if SPL
select SYS_MALLOC_F
select SYS_THUMB_BUILD if !ARM64
imply ADC
@@ -1614,6 +1613,7 @@ config ARCH_ROCKCHIP
imply FAT_WRITE
imply SARADC_ROCKCHIP
imply SPL_SYSRESET
+   imply SPL_SYS_MALLOC_SIMPLE
imply SYS_NS16550
imply TPL_SYSRESET
imply USB_FUNCTION_FASTBOOT



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/3] rockchip: fix ordering of DRAM init

2019-11-17 Thread Kever Yang


On 2019/11/16 上午12:48, Thomas Hebb wrote:

b7abef2ecbcc ("rockchip: rk3399: Migrate to use common spl board file")
removed SoC-specific code for RK3399's SPL and in the process reordered
the DRAM initialization before rockchip_stimer_init(), which as far as I
can tell causes the RK3399 to lock up completely.

Fix this issue in the common code by putting the DRAM init back after
timer init. I have only tested this on the RK3399, but it wouldn't make
any sense for the timer init to require DRAM be set up on any system.

Signed-off-by: Thomas Hebb 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/mach-rockchip/spl.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 92102b39e7..5570bb1339 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -128,6 +128,13 @@ void board_init_f(ulong dummy)
hang();
}
arch_cpu_init();
+#if !defined(CONFIG_ROCKCHIP_RK3188)
+   rockchip_stimer_init();
+#endif
+#ifdef CONFIG_SYS_ARCH_TIMER
+   /* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */
+   timer_init();
+#endif
  #if !defined(CONFIG_SUPPORT_TPL) || defined(CONFIG_SPL_OS_BOOT)
debug("\nspl:init dram\n");
ret = uclass_get_device(UCLASS_RAM, 0, );
@@ -135,13 +142,6 @@ void board_init_f(ulong dummy)
printf("DRAM init failed: %d\n", ret);
return;
}
-#endif
-#if !defined(CONFIG_ROCKCHIP_RK3188)
-   rockchip_stimer_init();
-#endif
-#ifdef CONFIG_SYS_ARCH_TIMER
-   /* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */
-   timer_init();
  #endif
preloader_console_init();
  }



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot