Re: [U-Boot] error in the make: bad value in the asm-offsets.c file

[Chris Packham]

On Fri, Nov 9, 2018 at 1:16 PM Chris Packham  wrote:
>
>
>
> On Fri, 9 Nov 2018, 2:08 AM Sarah Wicker >
>> Hi Chris, Ian,
>>
>> i tested with downloading and installing the package through the terminal, 
>> changing the CROSS_COMPILE value and redoing the make, it didn#t work.
>>
>> So i tried using the first link https://www.kernel.org/pub/tools/crosstool/ 
>> and later  https://toolchains.bootlin.com/ but still the same result.
>>
>>
>>
>> Each time have added the path tot he binary files to my main path (export 
>> PATH=‘pwd‘$PATH) and changing the CROSS_COMPILER value according the package 
>> i wanted to use but the error stayed the same.
>>
>>
>>
>> In the end I used the package: armv5-eabi--glibc--stable-2018.02-2.tar.gz2 
>> since the error messages is referring to armv5. Unpacked it into another 
>> folder, linked the path tot he binary files and export 
>> CROSS_COMPILE=arm-buildroot-linux-gnueabi-
>>
>> But i still got the same error… Do you have another idea?
>>
>> Thank yuo a lot for your help,
>
>
> I think to get a better idea of what's going on you should post a complete 
> console log starting from a new shell setting PATH & CROSS_COMPILE up to the 
> build error.
>
> Also just as a test to check your compiler run ${CROSS_COMPILE}cc --version

If it helps here's a recipe that worked for me

wget 
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_arm-linux-gnueabi.tar.xz
tar -xf ~/Downloads/x86_64-gcc-7.3.0-nolibc_arm-linux-gnueabi.tar.xz
git clone https://github.com/Xilinx/u-boot-xlnx.git
cd u-boot-xlnx
export PATH="$HOME/gcc-7.3.0-nolibc/arm-linux-gnueabi/bin:$PATH"
export CROSS_COMPILE=arm-linux-gnueabi-
make zynq_zed_defconfig
make
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] am33xx board with no external RTC crystal issue

[Belisko Marek]

Hi Alex,

On Tue, Oct 30, 2018 at 7:12 AM Alex Kiernan  wrote:
>
> On Mon, Oct 29, 2018 at 11:36 PM Belisko Marek  
> wrote:
> >
> > Hi,
> >
> > I'm working on custome am33xx based HW which have no external 32KHz
> > crystal. Anyway I want to use bootcount feature. I was trying to use
> > internal PRCM CLK_32KHZ clock as source for RTCSS but still when want
> > to read RTC registers I get data abort.
> >
> > I adapted this method :
> >
> > static void rtc32k_enable(void)
> >  {
> > struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;
> >
> > /*
> >  * Unlock the RTC's registers.  For more details please see the
> >  * RTC_SS section of the TRM.  In order to unlock we need to
> > @@ -287,9 +288,8 @@ static void rtc32k_enable(void)
> > writel(RTC_KICK1R_WE, &rtc->kick1r);
> >
> > /* Enable the RTC 32K OSC by setting bits 3 and 6. */
> > -   writel((1 << 3) | (1 << 6), &rtc->osc);
> > +   writel((1 << 6), &rtc->osc);
> >  }
> >
> > to not use external crystal 32KHz clock but internal. Anyway when
> > doing that board just hangs and thats it. Any ideas or suggestions?
>
> I've a board exactly like that... check you're driving RTC_PORz
> correctly, if you hold it in reset, that's the behaviour I see.
OK thanks for info. I think it's hold in reset.
>
> > It
> > is even possible to have something like that? I just seen that
> > include/configs/siemens-am33x-common.h (using also am335x cpu without
> > external 32KHz crystal) storing bootcount to env. Thanks a lot for any
> > pointers.
> >
>
> FWIW I gave up trying to use the internal clock as I couldn't get it
> to tick reliably (my suspicion was my hand modified board wasn't
> actually driving the reset correctly) and instead switched to keeping
> the bootcounter in SRAM.
I'm using bootcount stored in env. I'm using 2017.09 and didn't see
option to store bootcount in RAM (maybe overlooked something).
So you mean bootcount is stored in internal cpu SRAM? Thanks.
>
> --
> Alex Kiernan

BR,

marek



-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] spl_spi: Read default speed and mode values from DT

[Simon Goldschmidt]

On Thu, Nov 8, 2018 at 5:58 PM Patrick Delaunay  wrote:
>
> In case of DT boot, don't read default speed and mode for SPI from
> CONFIG_*, instead read from DT node.
>
> Signed-off-by: Christophe Kerello 
> Signed-off-by: Patrick Delaunay 
> ---
>
>  common/spl/spl_spi.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
> index 8cd4830..3cefc9a 100644
> --- a/common/spl/spl_spi.c
> +++ b/common/spl/spl_spi.c
> @@ -78,11 +78,18 @@ static int spl_spi_load_image(struct spl_image_info 
> *spl_image,
> /*
>  * Load U-Boot image from SPI flash into RAM
>  */
> -
> +#ifdef CONFIG_DM_SPI_FLASH
> +   /* In DM mode defaults will be taken from DT */
> +   flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
> +   CONFIG_SF_DEFAULT_CS,
> +   0,
> +   0);

Code duplication is never good. Wouldn't it be nicer to only have an
#if for the two differing parameters (e.g. via local variables)
instead of duplicating the function call?

Simon

> +#else
> flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
> CONFIG_SF_DEFAULT_CS,
> CONFIG_SF_DEFAULT_SPEED,
> CONFIG_SF_DEFAULT_MODE);
> +#endif
> if (!flash) {
> puts("SPI probe failed.\n");
> return -ENODEV;
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] efi_loader: enumerate disk devices every time

[Heinrich Schuchardt]

On 11/9/18 7:22 AM, AKASHI Takahiro wrote:
> Hi Heinrich,
> 
> Thank you for your comments.
> First of all, as I said [1], my essential question is whether my approach
> here is a right way to go. What do think?

The approach that you have chosen is surely an improvement. On the other
hand let's look at the target state:

Simon want's to eliminate all block device drivers that are not device
tree based. So we could say an EFI handle for a disk has to be created
when a device tree node is created for a block device. When the node is
removed the EFI handle should be marked as stale.

The UEFI spec foresees applications, boottime drivers and runtime
drivers as binaries. U-Boot cannot decide if a driver keeps a reference
to a handle. So, please, do not deallocate EFI handles for block devices
 unless an application or driver (like iPXE) removes the last protocol.

Instead return "device not ready" if a stale block device handle is used.

Best regards

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

Re: [U-Boot] [PATCH 2/2] efi_loader: enumerate disk devices every time

[AKASHI Takahiro]

Hi Heinrich,

Thank you for your comments.
First of all, as I said [1], my essential question is whether my approach
here is a right way to go. What do think?

On Wed, Nov 07, 2018 at 08:36:48AM +0100, Heinrich Schuchardt wrote:
> On 11/7/18 1:44 AM, AKASHI Takahiro wrote:
> > Currently, efi_init_obj_list() scan disk devices only once, and never
> > change a list of efi disk devices. This will possibly result in failing
> > to find a removable storage which may be added later on. See [1].
> >
> > In this patch, called is efi_disk_update() which is responsible for
> > re-scanning UCLASS_BLK devices and removing/adding efi disks if necessary.
> >
> > For example,
> >
> > => efishell devices
> > Scanning disk pci_mmc.blk...
> > Found 3 disks
> > Device Name
> > 
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > => usb start
> > starting USB...
> > USB0:   USB EHCI 1.00
> > scanning bus 0 for devices... 3 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > => efishell devices
> > Scanning disk usb_mass_storage.lun0...
> > Device Name
> > 
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
> >
> > Without this patch, the last device, USB mass storage, won't show up.
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/bootefi.c |   8 +-
> >  include/efi_loader.h  |   2 +
> >  lib/efi_loader/efi_disk.c | 150 ++
> >  3 files changed, 159 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 3cefb4d0ecaa..493022a09482 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -57,8 +57,14 @@ efi_status_t efi_init_obj_list(void)
> > efi_save_gd();
> >
> > /* Initialize once only */
> > -   if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
> > +   if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) {
> 
> If efi_obj_list_initialized is neither OBJ_LIST_NOT_INITIALIZED nor
> EFI_SUCCESS, return efi_obj_list_initialized.

Right.

> > +#ifdef CONFIG_PARTITIONS
> > +   ret = efi_disk_update();
> > +   if (ret != EFI_SUCCESS)
> > +   printf("+++ updating disks failed\n");
> > +#endif
> > return efi_obj_list_initialized;
> > +   }
> >
> > /* Initialize system table */
> > ret = efi_initialize_system_table();
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 5cc3bded03fa..e5a080281dba 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -260,6 +260,8 @@ efi_status_t efi_initialize_system_table(void);
> >  efi_status_t efi_console_register(void);
> >  /* Called by bootefi to make all disk storage accessible as EFI objects */
> >  efi_status_t efi_disk_register(void);
> > +/* Called by bootefi to find and update disk storage information */
> > +efi_status_t efi_disk_update(void);
> >  /* Create handles and protocols for the partitions of a block device */
> >  int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
> >const char *if_typename, int diskid,
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index c037526ad2d0..e1d47f34049b 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -14,10 +14,13 @@
> >
> >  const efi_guid_t efi_block_io_guid = BLOCK_IO_GUID;
> >
> > +#define _EFI_DISK_MARK_DELETE 0x1
> 
> Plese, add a comment to the code explaining what this constant is used
> for.

Sure.

> None of our other constants starts with an underscore.

This flag name is totally efi_disk.c internal. So an underscore is
added to prevent any potential name collision with UEFI spec.
(unlikely though)

# The name will be renamed to _EFI_DISK_FLAG_DELETE(D)


> In your coding below you keep handles for deleted drives. What will

No, any handles marked "deleted" will be deleted in this patch.

> happen if a binary tries to access a deleted drive?

See below.

> > +
> >  /**
> >   * struct efi_disk_obj - EFI disk object
> >   *
> >   * @header:EFI object header
> > + * @flags: control flags
> >   * @ops:   EFI disk I/O protocol interface
> >   * @ifname:interface name for block device
> >   * @dev_index: device index of block device
> > @@ -30,6 +33,7 @@ const efi_guid_t efi_block_io_guid = BLOCK_IO_GUID;
> >   */
> >  stru

Re: [U-Boot] [PATCH v3 3/5] Use _AC and UL macros from linux/const.h

[Rick Chen]

> > > Drop the _AC and UL macros from common.h. Linux headers is the
> > > original source of this macro, so keep its definition in the same header.
> > >
> > > Update existing users of these macros to include const.h directly.
> > >
> > > Cc: Daniel Schwierzeck 
> > > Cc: Rick Chen 
> > > Signed-off-by: Baruch Siach 
> >
> > I know you'll need to now drop the MIPS part but otherwise:
> >
> > Reviewed-by: Tom Rini 
> >

Reviewed-by: Rick Chen 

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

Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities

[Simon Goldschmidt]

On Fri, Nov 9, 2018 at 1:37 AM Fabio Estevam  wrote:
>
> Hi Andrea,
>
> On Tue, Nov 6, 2018 at 12:57 PM Andrea Barisani
>  wrote:
>
> > # load large file
> > => ext2load mmc 0 0x6000 fitimage.itb
>
> Does this change work for you?
> http://dark-code.bulix.org/u6gw3b-499924

My understanding was U-Boot text or stack could get overwritten which
leads to the loaded bytes being executed as code.
So you would have to check that the loaded range is within ram but not
within that reserved range of code or stack (or heap).

Getting this reserved range is what 'boot_start_lmb' does (in
bootm.c). Maybe this code can be refactored and reused in fs.c to get
a valid range for loading?

Additionally, your patch checks the loaded file's size without taking
the load address into account. So unless I read that wrong, your check
is only valid for 'addr == 0'.
Plus, the 'bytes' parameter should probably be a restriction to the
file's size when checking for a valid load range.

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

[U-Boot] [PATCH] armv8: Secure Boot: Modify boot_a_script definition

[Vinitha V Pillai]

boot_script_hdr does not exist, it should not continue to
boot. So adding separate validation after loading boot_script

Signed-off-by: Vinitha V Pillai 
---
 include/configs/ls1012afrwy.h| 3 ++-
 include/configs/ls1012ardb.h | 3 ++-
 include/configs/ls1021atwr.h | 3 ++-
 include/configs/ls1043a_common.h | 3 ++-
 include/configs/ls1046a_common.h | 5 +++--
 include/configs/ls1088ardb.h | 3 ++-
 include/configs/ls2080ardb.h | 3 ++-
 7 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h
index ebb1df41c7..12e6437a05 100644
--- a/include/configs/ls1012afrwy.h
+++ b/include/configs/ls1012afrwy.h
@@ -98,7 +98,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
-   "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+   "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+   "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"  \
"installer=load mmc 0:2 $load_addr "\
diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index f149a604cf..f6640fa499 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -98,7 +98,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
-   "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+   "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+   "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"  \
"installer=load mmc 0:2 $load_addr "\
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index ddd024e8c0..70af3ebb8f 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -364,7 +364,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
-   "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+   "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+   "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"  \
"installer=load mmc 0:2 $load_addr "\
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 7875bf4bba..3d6ce2cafb 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -294,7 +294,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
-   "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+   "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+   "env exists secureboot "\
"&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"\
"qspi_bootcmd=echo Trying load from qspi..;"\
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index 6e36c9339b..4ac31c59dd 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -271,8 +271,9 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
-   "${scripthdraddr} ${prefix}${boot_script_hdr} " \
-   "&& esbc_validate ${scripthdraddr};"\
+   "${scripthdraddr} ${prefix}${boot_script_hdr}; " \
+   "env exists secureboot "\
+   "&& esbc_validate ${scripthdraddr};"\
"source ${scriptaddr}\0"  \
"qspi_bootcmd=echo Trying load from qspi..;"  \
"sf probe && sf read $load_addr " \
diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h
index 2391a7cc05..b5a9f68dda 100644
--- a/include/configs/ls1088ardb.h
+++ b/include/configs/ls1088ardb.h
@@ -407,7 +407,8 @@
"${scriptaddr} ${prefix}${script}; "\
"env exists secureboot && load ${devtype} " \
"${devnum}:${distro_bootpart} " \
-   "${scripthdraddr} ${prefix}${b

[U-Boot] [PATCH] armv8: lx2160ardb: Add TFABOOT Secure Boot support

[Vinitha V Pillai]

Signed-off-by: Vinitha V Pillai 
---
 configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 83 
 include/configs/lx2160a_common.h | 12 ++-
 2 files changed, 93 insertions(+), 2 deletions(-)
 create mode 100644 configs/lx2160ardb_tfa_SECURE_BOOT_defconfig

diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
new file mode 100644
index 00..eb1632866b
--- /dev/null
+++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
@@ -0,0 +1,83 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LX2160ARDB=y
+CONFIG_SYS_TEXT_BASE=0x8200
+CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
+CONFIG_SECURE_BOOT=y
+CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-lx2160a-rdb"
+CONFIG_NR_DRAM_BANKS=3
+CONFIG_BOOTDELAY=0
+CONFIG_DM=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_TFABOOT=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyAMA0,115200 root=/dev/ram0 
earlycon=pl011,mmio32,0x21c ramdisk_size=0x200 default_hugepagesz=1024m 
hugepagesz=1024m hugepages=2 pci=pcie_bus_perf"
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_EEPROM=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_CACHE=y
+CONFIG_MP=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM_SERIAL=y
+CONFIG_SERIAL_PROBE_ALL=y
+CONFIG_CONS_INDEX=0
+CONFIG_FSL_CAAM=y
+CONFIG_FSL_ESDHC=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MICRON=y
+CONFIG_SPI_FLASH_USE_4K_SECTORS=n
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_NXP_FSPI=y
+CONFIG_FSPI_AHB_EN_4BYTE=y
+CONFIG_SYS_FSPI_AHB_INIT=y
+CONFIG_PHYLIB=y
+CONFIG_NETDEVICES=y
+CONFIG_PHY_GIGE=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_PXE=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_EXT2=y
+CONFIG_NET=y
+CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=n
+CONFIG_BLK=n
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_SCSI_AHCI=y
+CONFIG_SCSI=y
+# CONFIG_SYS_FSL_DDR_PHY is not set
+CONFIG_SYS_GEN2_DDR_PHY=y
+CONFIG_SYS_MALLOC_F=y
+CONFIG_SYS_MALLOC_F_LEN=0x6000
+CONFIG_PHYLIB_10G=y
+CONFIG_PHY_AQUANTIA=y
+CONFIG_PHY_CORTINA=y
+CONFIG_PHY_ATHEROS=y
+CONFIG_PHY_INPHI=y
+CONFIG_INPHI_25G=y
+CONFIG_HUSH_PARSER=y
+CONFIG_EMC2305=y
+CONFIG_RSA=y
+CONFIG_SPL_RSA=y
+CONFIG_RSA_SOFTWARE_EXP=y
diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h
index 51037d321a..42429ce16b 100644
--- a/include/configs/lx2160a_common.h
+++ b/include/configs/lx2160a_common.h
@@ -194,9 +194,15 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
 /* Initial environment variables */
-#define XSPI_NOR_BOOTCOMMAND   "fsl_mc apply dpl 0x20d0;" \
+#define XSPI_NOR_BOOTCOMMAND   "env exists mcinitcmd && env exists secureboot" 
\
+   "&& esbc_validate 0x207C; " \
+   "env exists mcinitcmd && "  \
+   "fsl_mc apply dpl 0x20d0;" \
"sf probe 0:0;" \
"sf read 0xa000 0x100 0x300;" \
+   "env exists secureboot &&"  \
+   "sf read 0x8020 0x80 0x4000 &&" \
+   "esbc_validate 0x8020;" \
"bootm 0xa000"
 
 #define SD_BOOTCOMMAND "mmc read 0xa000 0x6800 0xA0;" \
@@ -205,11 +211,13 @@ unsigned long get_board_ddr_clk(void);
"bootm 0xb000"
 
 #define XSPI_MC_INIT_CMD   \
+   "echo trying to load mc;env exists secureboot && "  \
+   "esbc_validate 0x2070 && "  \
+   "esbc_validate 0x2078 ;"\
"fsl_mc start mc 0x20a0 0x20e0\0"
 
 #define SD_MC_INIT_CMD \
"mmc read 0x8000 0x5000 0x800;" \
"mmc read 0x8010 0x7000 0x800;" \
"fsl_mc start mc 0x8000 0x8010\0"
-
 #endif /* __LX2_COMMON_H */
-- 
2.17.1

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

Re: [U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2

[Bin Meng]

On Thu, Nov 8, 2018 at 8:47 AM Andy Shevchenko
 wrote:
>
> On Thu, Nov 8, 2018 at 2:28 AM Bin Meng  wrote:
> > On Thu, Nov 8, 2018 at 2:02 AM Andy Shevchenko
> >  wrote:
> > > On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote:
>
> > > > Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793
>
> > > P.S. Btw, I recommend to read a commit message to a proposed fix.
> >
> > Good idea. However I read the fix commit message and have no idea on
> > how to workaround in the U-Boot codes. Do you have any idea?
>
> There is no workaround, just interesting reading in my opinion.
> He explains what happened there and what he did to mitigate it.
>
> Basically for now it means U-Boot can't be built with gcc 8.x for x86.
> Of course, if you have time to try the patch and build a compiler, and try 
> it...
>

A small correction, it's only the efi-x86_app can't be built with gcc
8.x/9.x for x86, not all x86 targets :)

+Simon,

Simon, maybe we can enhance buildman to specify the GCC toolchain
version for a specific target?

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

Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities

[Fabio Estevam]

Hi Andrea,

On Tue, Nov 6, 2018 at 12:57 PM Andrea Barisani
 wrote:

> # load large file
> => ext2load mmc 0 0x6000 fitimage.itb

Does this change work for you?
http://dark-code.bulix.org/u6gw3b-499924
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] error in the make: bad value in the asm-offsets.c file

[Chris Packham]

On Fri, 9 Nov 2018, 2:08 AM Sarah Wicker  Hi Chris, Ian,
>
> i tested with downloading and installing the package through the terminal,
> changing the CROSS_COMPILE value and redoing the make, it didn#t work.
>
> So i tried using the first link
> https://www.kernel.org/pub/tools/crosstool/ and later
> https://toolchains.bootlin.com/ but still the same result.
>
>
>
> Each time have added the path tot he binary files to my main path (export
> PATH=‘pwd‘$PATH) and changing the CROSS_COMPILER value according the
> package i wanted to use but the error stayed the same.
>
>
>
> In the end I used the package: armv5-eabi--glibc--stable-2018.02-2.tar.gz2
> since the error messages is referring to armv5. Unpacked it into another
> folder, linked the path tot he binary files and export
> CROSS_COMPILE=arm-buildroot-linux-gnueabi-
>
> But i still got the same error… Do you have another idea?
>
> Thank yuo a lot for your help,
>

I think to get a better idea of what's going on you should post a complete
console log starting from a new shell setting PATH & CROSS_COMPILE up to
the build error.

Also just as a test to check your compiler run ${CROSS_COMPILE}cc --version

> Sarah
>
>
>
>
>
> *Von:* Chris Packham [mailto:judge.pack...@gmail.com]
> *Gesendet:* Mittwoch, 7. November 2018 23:00
> *An:* Ian Kane 
> *Cc:* Sarah Wicker ; u-boot 
> *Betreff:* Re: [U-Boot] error in the make: bad value in the asm-offsets.c
> file
>
>
>
> Hi Ian, Sarah,
>
> On Thu, 8 Nov 2018, 6:09 AM Ian Kane 
> Sarah,
>
> It looks to me from the attached image that the error is related to an
> expected, but missing value for the -march flag.
> To me, I'd expect to see "-march=ARMv5 switch" instead of "-march=
> switch".  Make note of the empty space in the second.
>
> However I defer to anyone else more knowledgeable on the subject, I'm very
> new user of the project myself.
>
>
>
> Yes you are on the right track.
>
>
> Best regards,
> - Ian
> 
> From: U-Boot  on behalf of Sarah Wicker <
> s.wic...@primes.de>
> Sent: Wednesday, November 7, 2018 11:19 AM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] error in the make: bad value in the asm-offsets.c  file
>
> Good Morning,
> i am trying to compile u-boot on my pc  to use it for a ZedBoard from
> Xilinx.
> I cloned the repository u-boot-xlnx using this link:
> https://github.com/Xilinx/u-boot-xlnx.git
> Made the first make to build the U-boot for a ZedBoard, it works well.
> Asked for the second make and i received the message that in the file
> asm-offsets.c:1:0: error: bad value (armv5) for -march=switch
> I opened the file but couldn't see were was this value
>
> [cid:image001.jpg@01D476BE.1BC339F0]
>
> For information i am trying to compile on a virtual machine using
> Debian9.5.0
>
> I thank you in advance for your help
>
>
>
> The problem is more than likely that you are using the host compiler,
> which is probably x86 and doesn know how to generate output for arm. To
> compile for an embedded target you need a suitable cross compiler. For
> debian i believe there is a packaged arm compiler so it should just be a
> matter of
>
>
>
> sudo apt install gcc-arm-linux-gnueabi
>
> export CROSS_COMPILE=gcc-arm-linux-gnueabi
>
> make ZedBoard_defconfig
>
> make
>
>
>
> The lastest u-boot does require a fairly up to date gcc for arm. I'm not
> sure what debian ship. But if you get errors about the cross compiler being
> too old you might need to grab a more recent compiler from
> https://www.kernel.org/pub/tools/crosstool/ or the excellent
> https://toolchains.bootlin.com/
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Ping failure

[Paul Nader]

Hi,

I tried with x-over cable and the results were practically the same - no
pings.

I increased the tx-delay-ps to 700ps and then I started getting the
occasional arp being responded to. Below that I wouldn't see any. Here is
the relevant potion of my DT (attached):

&emac {
pinctrl-names = "default";
pinctrl-0 = <&rgmii_pins>;
phy-mode = "rgmii";
phy-handle = <&ext_rgmii_phy>;
phy-supply = <®_dcdc1>;
allwinner,tx-delay-ps = <700>;
status = "okay";
};

&mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
};
};

Below is a the trace for a ping (I've added some more code trace statements
myself). Here the first ARP request times out, but the second one is
responded to.
I see the requests and responses in wireshark on the development host
(attached to email).
The host doing the ping is 192.168.0.2 (02:ba:7b:d5:c6:6f), the one suposed
to respond is 192.168.0.1 (94:de:80:7e:84:9c)

DEBUG.none,net/net.c:412-net_loop() --- net_loop Entry
DEBUG.none,net/eth-uclass.c:272-eth_init() Trying ethernet@1c3
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 0
DEBUG.none,net/net.c:438-net_loop() --- net_loop Init
Using ethernet@1c3 device
DEBUG.none,net/net.c:795-net_set_timeout_handler() --- net_loop timeout
handler set (7dfa4ea8)
DEBUG.none,net/ping.c:44-ping_send() sending ARP for 192.168.0.1
DEBUG.none,net/arp.c:58-arp_raw_request() ARP broadcast 1
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/arp.c:109-arp_timeout_check() ARP Timeout expired: 669957
5000
DEBUG.none,net/arp.c:58-arp_raw_request() ARP broadcast 2
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/net.c:1087-net_process_received_packet() packet received
DEBUG.none,net/net.c:1159-net_process_received_packet() Receive from
protocol 0x806
DEBUG.none,net/arp.c:140-arp_receive() Got ARP
DEBUG.none,net/arp.c:196-arp_receive() Got ARP REPLY
DEBUG.none,net/arp.c:212-arp_receive() Got ARP REPLY, set eth addr
(94:de:80:7e:84:9c)
DEBUG.none,net/arp.c:226-arp_receive() Sending tx_packet
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/net.c:622-net_loop() --- net_loop timeout
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 3
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 3
DEBUG.none,net/net.c:759-net_set_udp_handler() --- net_loop UDP handler set
()
DEBUG.none,net/net.c:773-net_set_arp_handler() --- net_loop ARP handler set
()
DEBUG.none,net/net.c:791-net_set_timeout_handler() --- net_loop timeout
handler cancelled
DEBUG.none,net/net.c:659-net_loop() --- net_loop Fail!
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 0
ping failed; host 192.168.0.1 is not alive
DEBUG.none,common/command.c:501-cmd_call() Command failed, result=1
DEBUG.none,net/net.c:412-net_loop() --- net_loop Entry
DEBUG.none,net/eth-uclass.c:272-eth_init() Trying ethernet@1c3
DEBUG.none,include/net.h:655-net_set_state() --- NetState set to 0
DEBUG.none,net/net.c:438-net_loop() --- net_loop Init
Using ethernet@1c3 device
DEBUG.none,net/net.c:795-net_set_timeout_handler() --- net_loop timeout
handler set (7dfa4ea8)
DEBUG.none,net/ping.c:44-ping_send() sending ARP for 192.168.0.1
DEBUG.none,net/arp.c:58-arp_raw_request() ARP broadcast 1
DEBUG.none,net/eth-uclass.c:332-eth_send() uclass_emac_eth_send
DEBUG.none,drivers/net/sun8i_emac.c:572-_sun8i_emac_eth_send()
_sun8i_emac_eth_send
DEBUG.none,net/net.c:759-net_set_udp_handler() --- net_loop UDP handler set
()
DEBUG.none,net/net.c:773-net_set_arp_handler() --- net_loop ARP handler set
()
DEBUG.none,net/net.c:791-net_set_timeout_handler() --- net_loop timeout
handler cancelled

Even though _sun8i_emac_eth_send() is called to send the ICMP ping packet I
never see it arrive at the host. After that net loop times out at
net/net.c:622

Any suggestions on how to proceed next?

Paul

On Tue, Nov 6, 2018 at 10:54 AM Paul Nader  wrote:

> I'll try without the switch using a crossover cable to link the board and
> the host running wireshark directly and let you know.
>
> On Tue, Nov 6, 2018 at 10:19 AM Paul Nader  wrote:
>
>>
>>
>> On Tue, Nov 6, 2018 at 9:45 AM Chris Packham 
>> wrote:
>>
>>>
>>>
>>> On Tue, 6 Nov 2018, 6:09 AM Paul Nader >>
 Hi,

 I'm trying to get an olinuxino-a64 board to boot using bootp but it
 failed
 to send any DHCP packets so I reduced the problem to trying to get it to
 ping another host but that fails as well.

 I tried it both with 2018.09 and then the head of 

[U-Boot] [PATCH] video: add command cls

[Patrick Delaunay]

Implement the existing command cls, for clear screen,
when CONFIG_DM_VIDEO is activated.

This command was defined for old LCD framework (not dm) in
  common/lcd.c:251
  U_BOOT_CMD(cls,   1, 1, do_lcd_clear, "clear screen", "");

This command is useful to clear existing output (vidconsole) before
to display splashscreen with bmp command.

Signed-off-by: Patrick Delaunay 
---
Example of simple splashscreen in DISTRO script: boot.scr.uimg

if load ${devtype} ${devnum}:${distro_bootpart} ${splashimage} splash.bmp
then
   env set stdout "serial"
   env set stderr "serial"
   cls
   bmp display ${splashimage}
fi

 drivers/video/video-uclass.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 44dfa71..5fe49a5 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -300,3 +300,17 @@ UCLASS_DRIVER(video) = {
.per_device_auto_alloc_size = sizeof(struct video_priv),
.per_device_platdata_auto_alloc_size = sizeof(struct video_uc_platdata),
 };
+
+static int do_video_clear(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   struct udevice *dev;
+
+   if (uclass_first_device_err(UCLASS_VIDEO, &dev))
+   return CMD_RET_FAILURE;
+   video_clear(dev);
+
+   return 0;
+}
+
+U_BOOT_CMD(cls,1, 1, do_video_clear, "clear screen", "");
-- 
2.7.4

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

[U-Boot] [PATCH 2/2] splash: sf: Read default speed and mode values from DT

[Patrick Delaunay]

In case of DT boot, don't read default speed and mode for SPI from
CONFIG_*, instead read from DT node.

Signed-off-by: Patrick Delaunay 
---

 common/splash_source.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/common/splash_source.c b/common/splash_source.c
index 62763b9..f0b3407 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -25,10 +25,18 @@ static struct spi_flash *sf;
 static int splash_sf_read_raw(u32 bmp_load_addr, int offset, size_t read_size)
 {
if (!sf) {
+#ifdef CONFIG_DM_SPI_FLASH
+   /* In DM mode defaults will be taken from DT */
+   sf = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
+CONFIG_SF_DEFAULT_CS,
+0,
+0);
+#else
sf = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
 CONFIG_SF_DEFAULT_CS,
 CONFIG_SF_DEFAULT_SPEED,
 CONFIG_SF_DEFAULT_MODE);
+#endif
if (!sf)
return -ENODEV;
}
-- 
2.7.4

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

[U-Boot] [PATCH 1/2] spl_spi: Read default speed and mode values from DT

[Patrick Delaunay]

In case of DT boot, don't read default speed and mode for SPI from
CONFIG_*, instead read from DT node.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrick Delaunay 
---

 common/spl/spl_spi.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
index 8cd4830..3cefc9a 100644
--- a/common/spl/spl_spi.c
+++ b/common/spl/spl_spi.c
@@ -78,11 +78,18 @@ static int spl_spi_load_image(struct spl_image_info 
*spl_image,
/*
 * Load U-Boot image from SPI flash into RAM
 */
-
+#ifdef CONFIG_DM_SPI_FLASH
+   /* In DM mode defaults will be taken from DT */
+   flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
+   CONFIG_SF_DEFAULT_CS,
+   0,
+   0);
+#else
flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
CONFIG_SF_DEFAULT_CS,
CONFIG_SF_DEFAULT_SPEED,
CONFIG_SF_DEFAULT_MODE);
+#endif
if (!flash) {
puts("SPI probe failed.\n");
return -ENODEV;
-- 
2.7.4

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

[U-Boot] [PATCH 0/2] Read default speed and mode values from DT

[Patrick Delaunay]

This serie generalize the commit 96907c0fe50a
("dm: spi: Read default speed and mode values from DT")

In case of DT boot, don't read default speed and mode for SPI from
CONFIG_*, instead read from DT node. This will make sure that boards
with multiple SPI/QSPI controllers can be probed at different
bus frequencies and SPI modes.

Today it is only done in the command sf; this patch do the same
for the other user of the spi_flash_probe(): spl and splash
to avoid probe issue.



Patrick Delaunay (2):
  spl_spi: Read default speed and mode values from DT
  splash: sf: Read default speed and mode values from DT

 common/spl/spl_spi.c   | 9 -
 common/splash_source.c | 8 
 2 files changed, 16 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[U-Boot] [PATCH] MAINTAINERS: Update stm32mp entry

[Patrick Delaunay]

Add mailing list for stm32mp architecture and board.

Signed-off-by: Patrick Delaunay 
---

 MAINTAINERS   | 1 +
 board/st/stm32mp1/MAINTAINERS | 1 +
 2 files changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b39b6fc..abdb6dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -233,6 +233,7 @@ ARM STM STM32MP
 M: Patrick Delaunay 
 M: Christophe Kerello 
 M: Patrice Chotard 
+L: uboot-st...@st-md-mailman.stormreply.com (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-stm32mp
 F: drivers/clk/clk_stm32mp1.c
diff --git a/board/st/stm32mp1/MAINTAINERS b/board/st/stm32mp1/MAINTAINERS
index 65266bc..48d8fd2 100644
--- a/board/st/stm32mp1/MAINTAINERS
+++ b/board/st/stm32mp1/MAINTAINERS
@@ -1,5 +1,6 @@
 STM32MP1 BOARD
 M: Patrick Delaunay 
+L: uboot-st...@st-md-mailman.stormreply.com (moderated for non-subscribers)
 S: Maintained
 F: board/st/stm32mp1
 F: include/configs/stm32mp1.h
-- 
2.7.4

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

[U-Boot] ARM64: armada3720: strange u-boot freeze (how to debug?)

[Marek Behún]

Hello,
during my development for U-Boot on Turris Mox I keep encountering
this strange bug when sometimes U-Boot gets compiled in such a way that
it freezes after printing the first line:

  U-Boot 2018.11-rc3-00065-gfc69da4cb1-dirty (Nov 08 2018 - 15:51:52
  +0100)

This bug disappears if I change something, for example a add a
puts("lol\n"); somewhere, or change the version of the compiler.

It seems like some unaligned access, or maybe the compiler sometimes
generates wrong instruction (but all gcc versions from 6 to 8 do this
sometimes).

How should I find out what the issue is?

Thank you.

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

Re: [U-Boot] [PATCH v3 1/5] MIPS: drop asm/const.h

[Daniel Schwierzeck]

Am Do., 8. Nov. 2018 um 13:29 Uhr schrieb Baruch Siach :
>
> Commit 86f21c96f467368 (mips: Use common _AC macro now.) removed the _AC
> definition from const.h. All other macros defined in const.h are not
> used anywhere. Remove this header.
>
> Cc: Daniel Schwierzeck 
> Signed-off-by: Baruch Siach 
> ---
> v3: New patch in this series
> ---
>  arch/mips/include/asm/const.h   | 27 -
>  arch/mips/include/asm/mach-generic/spaces.h |  2 --
>  2 files changed, 29 deletions(-)
>  delete mode 100644 arch/mips/include/asm/const.h
>
> diff --git a/arch/mips/include/asm/const.h b/arch/mips/include/asm/const.h
> deleted file mode 100644
> index ed43b5d534ac..
> --- a/arch/mips/include/asm/const.h
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -/*
> - * const.h: Macros for dealing with constants.
> - */
> -
> -#ifndef _LINUX_CONST_H
> -#define _LINUX_CONST_H
> -
> -/* Some constant macros are used in both assembler and
> - * C code.  Therefore we cannot annotate them always with
> - * 'UL' and other type specifiers unilaterally.  We
> - * use the following macros to deal with this.
> - *
> - * Similarly, _AT() will cast an expression with a type in C, but
> - * leave it unchanged in asm.
> - */
> -
> -#ifdef __ASSEMBLY__
> -#define _AT(T,X)   X
> -#else
> -#define _AT(T,X)   ((T)(X))
> -#endif
> -
> -#define _BITUL(x)  (_AC(1,UL) << (x))
> -#define _BITULL(x) (_AC(1,ULL) << (x))
> -
> -#endif /* !(_LINUX_CONST_H) */

The removal of arch/mips/include/asm/const.h should be a standalone
patch after patch 3/5 (after switching MIPS to generic linux/const.h,
see comment below).

> diff --git a/arch/mips/include/asm/mach-generic/spaces.h 
> b/arch/mips/include/asm/mach-generic/spaces.h
> index b7eac323cd67..85f5849abfbe 100644
> --- a/arch/mips/include/asm/mach-generic/spaces.h
> +++ b/arch/mips/include/asm/mach-generic/spaces.h
> @@ -7,8 +7,6 @@
>  #ifndef _ASM_MACH_GENERIC_SPACES_H
>  #define _ASM_MACH_GENERIC_SPACES_H
>
> -#include 
> -
>  /*
>   * This gives the physical RAM offset.
>   */

This hunk should be squashed into patch 3/5.

> --
> 2.19.1
>


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

Re: [U-Boot] [PATCH v1 2/2] imx: mkimage: add size check to the u-boot.imx make target

[Stefano Babic]

Hi Marcel,

On 08/11/18 02:55, Fabio Estevam wrote:
> [Adding Stefano]
> 
> On Wed, Nov 7, 2018 at 8:41 PM Marcel Ziswiler  wrote:
>>
>> From: Marcel Ziswiler 
>>
>> The make macro to check if the binary exceeds the board size limit is
>> taken straight from the root Makefile.
>>
>> Without this and e.g. enabled EFI Vybrid fails booting as the regular
>> size limit check does not take the final u-boot.imx binary size into
>> account which is bigger due to alignment as well as IMX header stuff.
>>
>> Signed-off-by: Marcel Ziswiler 
> 
> Reviewed-by: Fabio Estevam 
> 
> Hi Stefano, maybe this could be material for 2018.11?
> 

Added both patches to u-boot-imx, check is effective, now size is too
much and build fails:


Building current source for 1 boards (1 thread, 8 jobs per thread)
   arm:  +   colibri_vf
+u-boot.imx exceeds file size limit:
+  limit:  520192 bytes
+  actual: 526104 bytes
+  excess: 5912 bytes
+make[2]: *** [u-boot.imx] Error 1
+make[1]: *** [u-boot.imx] Error 2
+make: *** [sub-make] Error 2
001 /1  colibri_vf

Can you take a look ?

Best regards,
Stefeano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH usb RFC] usb: Make vbus-supply code common

[Marek Behún]

The code for vbus-supply regulator enabling/disabling is repeated in
several drivers. Create a header file with static inline definitions
of the funtions and use them in some of those drivers.

Signed-off-by: Marek Behún 
---
 drivers/usb/host/dwc2.c | 61 -
 drivers/usb/host/ehci-generic.c | 51 +++
 drivers/usb/host/vbus-supply.h  | 49 ++
 drivers/usb/host/xhci-mvebu.c   | 28 +--
 4 files changed, 76 insertions(+), 113 deletions(-)
 create mode 100644 drivers/usb/host/vbus-supply.h

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index b6f008a400..51a2e21a6b 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -14,9 +14,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
+#include "vbus-supply.h"
 #include "dwc2.h"
 
 /* Use only HC channel 0. */
@@ -168,57 +168,6 @@ static void dwc_otg_core_reset(struct dwc2_core_regs *regs)
mdelay(100);
 }
 
-#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR)
-static int dwc_vbus_supply_init(struct udevice *dev)
-{
-   struct dwc2_priv *priv = dev_get_priv(dev);
-   int ret;
-
-   ret = device_get_supply_regulator(dev, "vbus-supply",
- &priv->vbus_supply);
-   if (ret) {
-   debug("%s: No vbus supply\n", dev->name);
-   return 0;
-   }
-
-   ret = regulator_set_enable(priv->vbus_supply, true);
-   if (ret) {
-   dev_err(dev, "Error enabling vbus supply\n");
-   return ret;
-   }
-
-   return 0;
-}
-
-static int dwc_vbus_supply_exit(struct udevice *dev)
-{
-   struct dwc2_priv *priv = dev_get_priv(dev);
-   int ret;
-
-   if (priv->vbus_supply) {
-   ret = regulator_set_enable(priv->vbus_supply, false);
-   if (ret) {
-   dev_err(dev, "Error disabling vbus supply\n");
-   return ret;
-   }
-   }
-
-   return 0;
-}
-#else
-static int dwc_vbus_supply_init(struct udevice *dev)
-{
-   return 0;
-}
-
-#if defined(CONFIG_DM_USB)
-static int dwc_vbus_supply_exit(struct udevice *dev)
-{
-   return 0;
-}
-#endif
-#endif
-
 /*
  * This function initializes the DWC_otg controller registers for
  * host mode.
@@ -311,8 +260,10 @@ static void dwc_otg_core_host_init(struct udevice *dev,
}
}
 
-   if (dev)
-   dwc_vbus_supply_init(dev);
+   if (dev) {
+   struct dwc2_priv *priv = dev_get_priv(dev);
+   enable_vbus_supply(dev, &priv->vbus_supply);
+   }
 }
 
 /*
@@ -1332,7 +1283,7 @@ static int dwc2_usb_remove(struct udevice *dev)
struct dwc2_priv *priv = dev_get_priv(dev);
int ret;
 
-   ret = dwc_vbus_supply_exit(dev);
+   ret = disable_vbus_supply(priv->vbus_supply);
if (ret)
return ret;
 
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index 0270f3bc95..e47263ba58 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include "ehci.h"
-#include 
+#include "vbus-supply.h"
 
 /*
  * Even though here we don't explicitly use "struct ehci_ctrl"
@@ -30,49 +30,6 @@ struct generic_ehci {
int reset_count;
 };
 
-#ifdef CONFIG_DM_REGULATOR
-static int ehci_enable_vbus_supply(struct udevice *dev)
-{
-   struct generic_ehci *priv = dev_get_priv(dev);
-   int ret;
-
-   ret = device_get_supply_regulator(dev, "vbus-supply",
- &priv->vbus_supply);
-   if (ret && ret != -ENOENT)
-   return ret;
-
-   if (priv->vbus_supply) {
-   ret = regulator_set_enable(priv->vbus_supply, true);
-   if (ret) {
-   dev_err(dev, "Error enabling VBUS supply\n");
-   return ret;
-   }
-   } else {
-   dev_dbg(dev, "No vbus supply\n");
-   }
-
-   return 0;
-}
-
-static int ehci_disable_vbus_supply(struct generic_ehci *priv)
-{
-   if (priv->vbus_supply)
-   return regulator_set_enable(priv->vbus_supply, false);
-   else
-   return 0;
-}
-#else
-static int ehci_enable_vbus_supply(struct udevice *dev)
-{
-   return 0;
-}
-
-static int ehci_disable_vbus_supply(struct generic_ehci *priv)
-{
-   return 0;
-}
-#endif
-
 static int ehci_usb_probe(struct udevice *dev)
 {
struct generic_ehci *priv = dev_get_priv(dev);
@@ -142,7 +99,7 @@ static int ehci_usb_probe(struct udevice *dev)
}
}
 
-   err = ehci_enable_vbus_supply(dev);
+   err = enable_vbus_supply(dev, &priv->vbus_supply);
if (err)
goto reset_err;
 
@@ -166,7 +123,7 @@ phy_err:
dev_err(dev, "failed to shutdown usb phy\n");
 
 regulator_err:
-   ret = ehci_disable_vbus_supply

Re: [U-Boot] error in the make: bad value in the asm-offsets.c file

[Sarah Wicker]

Hi Chris, Ian,
i tested with downloading and installing the package through the terminal, 
changing the CROSS_COMPILE value and redoing the make, it didn#t work.
So i tried using the first link https://www.kernel.org/pub/tools/crosstool/ and 
later  https://toolchains.bootlin.com/ but still the same result.

Each time have added the path tot he binary files to my main path (export 
PATH=‘pwd‘$PATH) and changing the CROSS_COMPILER value according the package i 
wanted to use but the error stayed the same.

In the end I used the package: armv5-eabi--glibc--stable-2018.02-2.tar.gz2 
since the error messages is referring to armv5. Unpacked it into another 
folder, linked the path tot he binary files and export 
CROSS_COMPILE=arm-buildroot-linux-gnueabi-
But i still got the same error… Do you have another idea?
Thank yuo a lot for your help,
Sarah


Von: Chris Packham [mailto:judge.pack...@gmail.com]
Gesendet: Mittwoch, 7. November 2018 23:00
An: Ian Kane 
Cc: Sarah Wicker ; u-boot 
Betreff: Re: [U-Boot] error in the make: bad value in the asm-offsets.c file

Hi Ian, Sarah,
On Thu, 8 Nov 2018, 6:09 AM Ian Kane 
mailto:ik...@codeblue.com> wrote:
Sarah,

It looks to me from the attached image that the error is related to an 
expected, but missing value for the -march flag.
To me, I'd expect to see "-march=ARMv5 switch" instead of "-march= switch".  
Make note of the empty space in the second.

However I defer to anyone else more knowledgeable on the subject, I'm very new 
user of the project myself.

Yes you are on the right track.

Best regards,
- Ian

From: U-Boot 
mailto:u-boot-boun...@lists.denx.de>> on behalf 
of Sarah Wicker mailto:s.wic...@primes.de>>
Sent: Wednesday, November 7, 2018 11:19 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] error in the make: bad value in the asm-offsets.c  file

Good Morning,
i am trying to compile u-boot on my pc  to use it for a ZedBoard from Xilinx.
I cloned the repository u-boot-xlnx using this link: 
https://github.com/Xilinx/u-boot-xlnx.git
Made the first make to build the U-boot for a ZedBoard, it works well. Asked 
for the second make and i received the message that in the file 
asm-offsets.c:1:0: error: bad value (armv5) for -march=switch
I opened the file but couldn't see were was this value

[cid:image001.jpg@01D476BE.1BC339F0]

For information i am trying to compile on a virtual machine using Debian9.5.0

I thank you in advance for your help

The problem is more than likely that you are using the host compiler, which is 
probably x86 and doesn know how to generate output for arm. To compile for an 
embedded target you need a suitable cross compiler. For debian i believe there 
is a packaged arm compiler so it should just be a matter of

sudo apt install gcc-arm-linux-gnueabi
export CROSS_COMPILE=gcc-arm-linux-gnueabi
make ZedBoard_defconfig
make

The lastest u-boot does require a fairly up to date gcc for arm. I'm not sure 
what debian ship. But if you get errors about the cross compiler being too old 
you might need to grab a more recent compiler from 
https://www.kernel.org/pub/tools/crosstool/ or the excellent 
https://toolchains.bootlin.com/

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

Re: [U-Boot] [PATCH v3 3/5] Use _AC and UL macros from linux/const.h

[Tom Rini]

On Thu, Nov 08, 2018 at 02:24:12PM +0200, Baruch Siach wrote:


> Drop the _AC and UL macros from common.h. Linux headers is the original
> source of this macro, so keep its definition in the same header.
> 
> Update existing users of these macros to include const.h directly.
> 
> Cc: Daniel Schwierzeck 
> Cc: Rick Chen 
> Signed-off-by: Baruch Siach 

I know you'll need to now drop the MIPS part but otherwise:

Reviewed-by: Tom Rini 

-- 
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] [PATCH v3 4/5] linux/sizes.h: sync from kernel

[Tom Rini]

On Thu, Nov 08, 2018 at 02:24:13PM +0200, Baruch Siach wrote:

> The kernel added SZ_4G macro in commit f2b9ba871b (arm64/kernel: kaslr:
> reduce module randomization range to 4 GB).
> 
> Include linux/const.h for the _AC macro.
> 
> Drop a local SZ_4G definition in tegra code.
> 
> Cc: Tom Warren 
> Signed-off-by: Baruch Siach 

Reviewed-by: Tom Rini 

-- 
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] [PATCH v3 1/5] MIPS: drop asm/const.h

[Tom Rini]

On Thu, Nov 08, 2018 at 02:24:10PM +0200, Baruch Siach wrote:

> Commit 86f21c96f467368 (mips: Use common _AC macro now.) removed the _AC
> definition from const.h. All other macros defined in const.h are not
> used anywhere. Remove this header.
> 
> Cc: Daniel Schwierzeck 
> Signed-off-by: Baruch Siach 
> ---
> v3: New patch in this series
> ---

This should be patch #2 and switch asm/mach/spaces.h to using
 I think.

-- 
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] [PATCH v3 2/5] linux/const.h: import from kernel

[Tom Rini]

On Thu, Nov 08, 2018 at 02:24:11PM +0200, Baruch Siach wrote:

> Combine the uapi/linux/const.h header into the kernel linux/const.h. The
> next commit will use the _AC macro this header instead of the common.h
> definition.
> 
> Signed-off-by: Baruch Siach 
> ---
> v3: New patch in this series
> ---

This should be patch #1 and mention what kernel release it's from
please, 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] Issue with relocating code to DDR

[Clément Péron]

Hi,

Maybe check the GCC option "-mno-unaligned-access"

$>cat arch/arm/cpu/armv7/config.mk
#
# (C) Copyright 2002
# Gary Jennejohn, DENX Software Engineering, 
#
# SPDX-License-Identifier: GPL-2.0+
#

# On supported platforms we set the bit which causes us to trap on unaligned
# memory access.  This is the opposite of what the compiler expects to be
# the default so we must pass in -mno-unaligned-access so that it is aware
# of our decision.
PF_NO_UNALIGNED := $(call cc-option, -mno-unaligned-access,)
PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)

Regards,
Clement
On Thu, 8 Nov 2018 at 13:16, SHEKHAR SINGH  wrote:
>
> Hi All,
>
> We got the issue, actually our DDR only supports 32bit access, 16bit and 8bit 
> access are not supported.
> Is there any compiler option or any u-boot option, we need to configure so 
> that u-boot use 32 bit access only.
>
> Thanks in advance.
> Regards
> Shekhar Singh
>
> On Thu, Nov 1, 2018 at 7:14 PM SHEKHAR SINGH  wrote:
>>
>>
>> Hi All,
>>
>> I am new to U-boot. Currently, I am working on developing U-boot for a new 
>> SOC. The SOC has arm926ej-s as the core and is implemented on Xilinx FPGA 
>> with SD-card as the boot device. With current setup DDR is already 
>> initialized by FPGA and SD card can be accessed using direct addressing. We 
>> have added board files and SoC related files to the Uboot directory and is 
>> able to successfully compile and get some outputs on UART (debug console). 
>> Currently, we have added only support for GPIO and UART drivers.
>>
>> SD Card : 0x - 0x007F
>> SRAM: 0x9000 - 0x90007FFF
>> DDR   : 0x4000 - 0x43FF
>>
>> We are facing some issue with the uboot booting. We are able to see the 
>> initial uboot prints and debug prints when the stack pointer is in SRAM, but 
>> after we relocate the code from SD card to DDR and change the stack pointer 
>> to DDR we are getting junk prints on the console. Can anyone help me or 
>> suggest me what we are doing wrong here? Thanks in advance for your help.
>>
>> Please see the below UART Log:
>>
>> initcall: 5cdc
>> initcall: 9a84
>> initcall: 5ccc
>> initcall: 5fbc
>> initcall: 60c0
>> initcall: 0418
>> initcall: 6090
>> initcall: 5fb4
>> malloc_simple: size=18, ptr=18, limit=400: 9b30
>> malloc_simple: size=54, ptr=6c, limit=400: 9b48
>> malloc_simple: size=4, ptr=70, limit=400: 9b9c
>> uclass_find_device_by_seq: 0 -1
>> uclass_find_device_by_seq: 0 0
>>- -1 -1 'root_driver'
>>- not found
>> initcall: 6088
>> initcall: 10b0
>> initcall: 04a8
>> initcall: f77c
>> env_init: Environment nowhere init done (ret=0)
>> initcall: 5f88
>> initcall: f0dc
>> initcall: 000147c0
>>
>>
>>  U-Boot 2018.09 (Nov 01 2018 - 18:33:40 +0530)
>>
>>  initcall: 5eac
>>  U-Boot code:  -> 00024604  BSS: -> 00030608
>>  initcall: 0438
>>  CPU: SoC Version 0.01
>>  CPU clock:75MHz
>>  SDRAM clock:  75MHz
>>  initcall: 6470
>>  initcall: 5f70
>>  DRAM:  initcall: 10ec
>>  SDRAM Reg 000 : 
>>  EDAC Reg  004 : 
>>  SDRAM Reg 100 : 
>>  EDAC Reg  104 : 
>>  EMC Reg   : 1ff
>>  initcall: 6178
>>  Monitor len: 00030608
>>  Ram size: 0400
>>  gd->relocaddr : 4400
>>  Ram top: 4400
>>  initcall: 5cfc
>>  initcall: 6098
>>  initcall: 5d14
>>  initcall: 60a0
>>  initcall: 5e44
>>  Reserving 193k for U-Boot at: 43fcf000
>>  initcall: 5e18
>>  Reserving 1152k for malloc() at: 43eaf000
>>  initcall: 5f1c
>>  Reserving 80 Bytes for Board Info at: 43eaefb0
>>  initcall: 60a8
>>  initcall: 5de4
>>  Reserving 200 Bytes for Global Data at: 43eaeee8
>>  initcall: 5d5c
>>  initcall: 60b0
>>  initcall: 60c8
>>  initcall: 61f4
>>  gd->relocaddr : 43FCF000
>>  initcall: 5d1c
>>  initcall: 60dc
>>
>>  RAM Configuration:
>>  Bank #0: 4000 64 MiB
>>
>>  DRAM:  64 MiB
>>  initcall: 5d40
>>  New Stack Pointer is: 43eaeec0
>>  initcall: 5ed8
>>  initcall: 60b8
>>  initcall: 5fd0
>>  __image_copy_start : 
>>  __image_copy_end : 00024604
>>  gd copied successfully to new gd...
>>  Relocation Offset is: 43fcf000
>>  Relocating to Addr 43fcf000, new gd at 43eaeee8, sp at 43eaeec0
>>  Current Stack Pointer 9a60
>>  
>>  
>>ENABLE CACHESWARNING: Caches not enabled
>>  
>> 
>> 
>> 
>>
>>
>>
>>  
>>  
>>
>> 
>>
>>
>>
>>  i

[U-Boot] [PATCH v3 5/5] arm64: mvebu: a8k: autodetect RAM size

[Baruch Siach]

Some Armada 8K boards like Macchiatobin and Clearfog GT-8K use RAM from
external DIMM. Hard coding the RAM size in the device-tree is not
convenient. Fortunately, the ATF that initializes the RAM knows the size
of RAM, and U-Boot can query the ATF using a SMC call.

The ATF maps the lower 3G of RAM starting at address 0. Higher RAM is
mapped at 4G. This leaves a 1G hole between 3G and 4G for IO
peripherals. Use a second bi_dram[] entry to describe the higher RAM
area. As a result, CONFIG_NR_DRAM_BANKS must be set to 2 to use more
than 3GB RAM.

This code in this commit is mostly taken from downstream Marvell U-Boot
code by Grzegorz Jaszczyk.

Cc: Grzegorz Jaszczyk 
Signed-off-by: Baruch Siach 
---
v3:
  No change

v2:
  Expand memory layout description in code comment and the commit log
  (Stefan)
---
 arch/arm/mach-mvebu/arm64-common.c | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/arm64-common.c 
b/arch/arm/mach-mvebu/arm64-common.c
index f47273fde9c6..47bbf69944ec 100644
--- a/arch/arm/mach-mvebu/arm64-common.c
+++ b/arch/arm/mach-mvebu/arm64-common.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -45,15 +46,62 @@ const struct mbus_dram_target_info 
*mvebu_mbus_dram_info(void)
 
 /* DRAM init code ... */
 
+#define MV_SIP_DRAM_SIZE   0x8210
+
+static u64 a8k_dram_scan_ap_sz(void)
+{
+   struct pt_regs pregs;
+
+   pregs.regs[0] = MV_SIP_DRAM_SIZE;
+   pregs.regs[1] = SOC_REGS_PHY_BASE;
+   smc_call(&pregs);
+
+   return pregs.regs[0];
+}
+
+static void a8k_dram_init_banksize(void)
+{
+   /*
+* The firmware (ATF) leaves a 1G whole above the 3G mark for IO
+* devices. Higher RAM is mapped at 4G.
+*
+* Config 2 DRAM banks:
+* Bank 0 - max size 4G - 1G
+* Bank 1 - ram size - 4G + 1G
+*/
+   phys_size_t max_bank0_size = SZ_4G - SZ_1G;
+
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   if (gd->ram_size <= max_bank0_size) {
+   gd->bd->bi_dram[0].size = gd->ram_size;
+   return;
+   }
+
+   gd->bd->bi_dram[0].size = max_bank0_size;
+   if (CONFIG_NR_DRAM_BANKS > 1) {
+   gd->bd->bi_dram[1].start = SZ_4G;
+   gd->bd->bi_dram[1].size = gd->ram_size - max_bank0_size;
+   }
+}
+
 int dram_init_banksize(void)
 {
-   fdtdec_setup_memory_banksize();
+   if (CONFIG_IS_ENABLED(ARMADA_8K))
+   a8k_dram_init_banksize();
+   else
+   fdtdec_setup_memory_banksize();
 
return 0;
 }
 
 int dram_init(void)
 {
+   if (CONFIG_IS_ENABLED(ARMADA_8K)) {
+   gd->ram_size = a8k_dram_scan_ap_sz();
+   if (gd->ram_size != 0)
+   return 0;
+   }
+
if (fdtdec_setup_mem_size_base() != 0)
return -EINVAL;
 
-- 
2.19.1

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

[U-Boot] [PATCH v3 4/5] linux/sizes.h: sync from kernel

[Baruch Siach]

The kernel added SZ_4G macro in commit f2b9ba871b (arm64/kernel: kaslr:
reduce module randomization range to 4 GB).

Include linux/const.h for the _AC macro.

Drop a local SZ_4G definition in tegra code.

Cc: Tom Warren 
Signed-off-by: Baruch Siach 
---
v3: Use linux/const.h

v2: No change
---
 arch/arm/mach-tegra/tegra186/nvtboot_mem.c | 3 +--
 include/linux/sizes.h  | 4 
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-tegra/tegra186/nvtboot_mem.c 
b/arch/arm/mach-tegra/tegra186/nvtboot_mem.c
index 5c9467bfe8be..62142821a595 100644
--- a/arch/arm/mach-tegra/tegra186/nvtboot_mem.c
+++ b/arch/arm/mach-tegra/tegra186/nvtboot_mem.c
@@ -6,11 +6,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#define SZ_4G 0x1ULL
-
 /*
  * Size of a region that's large enough to hold the relocated U-Boot and all
  * other allocations made around it (stack, heap, page tables, etc.)
diff --git a/include/linux/sizes.h b/include/linux/sizes.h
index ce3e8150c174..fbde0bc7e882 100644
--- a/include/linux/sizes.h
+++ b/include/linux/sizes.h
@@ -8,6 +8,8 @@
 #ifndef __LINUX_SIZES_H__
 #define __LINUX_SIZES_H__
 
+#include 
+
 #define SZ_1   0x0001
 #define SZ_2   0x0002
 #define SZ_4   0x0004
@@ -44,4 +46,6 @@
 #define SZ_1G  0x4000
 #define SZ_2G  0x8000
 
+#define SZ_4G  _AC(0x1, ULL)
+
 #endif /* __LINUX_SIZES_H__ */
-- 
2.19.1

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

[U-Boot] [PATCH v3 1/5] MIPS: drop asm/const.h

[Baruch Siach]

Commit 86f21c96f467368 (mips: Use common _AC macro now.) removed the _AC
definition from const.h. All other macros defined in const.h are not
used anywhere. Remove this header.

Cc: Daniel Schwierzeck 
Signed-off-by: Baruch Siach 
---
v3: New patch in this series
---
 arch/mips/include/asm/const.h   | 27 -
 arch/mips/include/asm/mach-generic/spaces.h |  2 --
 2 files changed, 29 deletions(-)
 delete mode 100644 arch/mips/include/asm/const.h

diff --git a/arch/mips/include/asm/const.h b/arch/mips/include/asm/const.h
deleted file mode 100644
index ed43b5d534ac..
--- a/arch/mips/include/asm/const.h
+++ /dev/null
@@ -1,27 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * const.h: Macros for dealing with constants.
- */
-
-#ifndef _LINUX_CONST_H
-#define _LINUX_CONST_H
-
-/* Some constant macros are used in both assembler and
- * C code.  Therefore we cannot annotate them always with
- * 'UL' and other type specifiers unilaterally.  We
- * use the following macros to deal with this.
- *
- * Similarly, _AT() will cast an expression with a type in C, but
- * leave it unchanged in asm.
- */
-
-#ifdef __ASSEMBLY__
-#define _AT(T,X)   X
-#else
-#define _AT(T,X)   ((T)(X))
-#endif
-
-#define _BITUL(x)  (_AC(1,UL) << (x))
-#define _BITULL(x) (_AC(1,ULL) << (x))
-
-#endif /* !(_LINUX_CONST_H) */
diff --git a/arch/mips/include/asm/mach-generic/spaces.h 
b/arch/mips/include/asm/mach-generic/spaces.h
index b7eac323cd67..85f5849abfbe 100644
--- a/arch/mips/include/asm/mach-generic/spaces.h
+++ b/arch/mips/include/asm/mach-generic/spaces.h
@@ -7,8 +7,6 @@
 #ifndef _ASM_MACH_GENERIC_SPACES_H
 #define _ASM_MACH_GENERIC_SPACES_H
 
-#include 
-
 /*
  * This gives the physical RAM offset.
  */
-- 
2.19.1

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

[U-Boot] [PATCH v3 3/5] Use _AC and UL macros from linux/const.h

[Baruch Siach]

Drop the _AC and UL macros from common.h. Linux headers is the original
source of this macro, so keep its definition in the same header.

Update existing users of these macros to include const.h directly.

Cc: Daniel Schwierzeck 
Cc: Rick Chen 
Signed-off-by: Baruch Siach 
---
v3: New patch in this series
---
 arch/arm/include/asm/armv8/mmu.h| 2 ++
 arch/mips/include/asm/mach-generic/spaces.h | 2 ++
 arch/riscv/include/asm/csr.h| 2 ++
 include/common.h| 9 -
 4 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 62d00d15c26d..4a573208dfd0 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -7,6 +7,8 @@
 #ifndef _ASM_ARMV8_MMU_H_
 #define _ASM_ARMV8_MMU_H_
 
+#include 
+
 /*
  * block/section address mask and size definitions.
  */
diff --git a/arch/mips/include/asm/mach-generic/spaces.h 
b/arch/mips/include/asm/mach-generic/spaces.h
index 85f5849abfbe..539d0a566d52 100644
--- a/arch/mips/include/asm/mach-generic/spaces.h
+++ b/arch/mips/include/asm/mach-generic/spaces.h
@@ -7,6 +7,8 @@
 #ifndef _ASM_MACH_GENERIC_SPACES_H
 #define _ASM_MACH_GENERIC_SPACES_H
 
+#include 
+
 /*
  * This gives the physical RAM offset.
  */
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 50fccea5c8f9..29624fdbb555 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -8,6 +8,8 @@
 #ifndef _ASM_RISCV_CSR_H
 #define _ASM_RISCV_CSR_H
 
+#include 
+
 /* Status register flags */
 #define SR_SIE _AC(0x0002, UL) /* Supervisor Interrupt Enable */
 #define SR_SPIE_AC(0x0020, UL) /* Previous Supervisor IE */
diff --git a/include/common.h b/include/common.h
index 83b3bdc58dfa..f3c1de9f1fa2 100644
--- a/include/common.h
+++ b/include/common.h
@@ -14,9 +14,6 @@ typedef volatile unsigned longvu_long;
 typedef volatile unsigned short vu_short;
 typedef volatile unsigned char vu_char;
 
-/* Allow sharing constants with type modifiers between C and assembly. */
-#define _AC(X, Y)   (X##Y)
-
 #include 
 #include 
 #include 
@@ -542,16 +539,10 @@ int cpu_release(u32 nr, int argc, char * const argv[]);
 
 #else  /* __ASSEMBLY__ */
 
-/* Drop a C type modifier (like in 3UL) for constants used in assembly. */
-#define _AC(X, Y)   X
-
 #endif /* __ASSEMBLY__ */
 
 /* Put only stuff here that the assembler can digest */
 
-/* Declare an unsigned long constant digestable both by C and an assembler. */
-#define UL(x)   _AC(x, UL)
-
 #ifdef CONFIG_POST
 #define CONFIG_HAS_POST
 #ifndef CONFIG_POST_ALT_LIST
-- 
2.19.1

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

[U-Boot] [PATCH v3 2/5] linux/const.h: import from kernel

[Baruch Siach]

Combine the uapi/linux/const.h header into the kernel linux/const.h. The
next commit will use the _AC macro this header instead of the common.h
definition.

Signed-off-by: Baruch Siach 
---
v3: New patch in this series
---
 include/linux/const.h | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 include/linux/const.h

diff --git a/include/linux/const.h b/include/linux/const.h
new file mode 100644
index ..379c88923269
--- /dev/null
+++ b/include/linux/const.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _LINUX_CONST_H
+#define _LINUX_CONST_H
+
+/* const.h: Macros for dealing with constants.  */
+
+/* Some constant macros are used in both assembler and
+ * C code.  Therefore we cannot annotate them always with
+ * 'UL' and other type specifiers unilaterally.  We
+ * use the following macros to deal with this.
+ *
+ * Similarly, _AT() will cast an expression with a type in C, but
+ * leave it unchanged in asm.
+ */
+
+#ifdef __ASSEMBLY__
+#define _AC(X,Y)   X
+#define _AT(T,X)   X
+#else
+#define __AC(X,Y)  (X##Y)
+#define _AC(X,Y)   __AC(X,Y)
+#define _AT(T,X)   ((T)(X))
+#endif
+
+#define _UL(x) (_AC(x, UL))
+#define _ULL(x)(_AC(x, ULL))
+
+#define _BITUL(x)  (_UL(1) << (x))
+#define _BITULL(x) (_ULL(1) << (x))
+
+#define UL(x)  (_UL(x))
+#define ULL(x) (_ULL(x))
+
+#endif /* _LINUX_CONST_H */
-- 
2.19.1

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

[U-Boot] Antwort: [PATCH] fs: fat: fix reading non-cluster-aligned root directory

[Bernhard Messerklinger]

Hi Anssi,

I tested your patch because i faced the same problem.
But I need an addition to your patch to get everything to work.

Since for fat12/16 the sect_to_clust() calculation is always a negative 
value
the division through the cluster size with an odd negative value cuts the 
rest.
With the next clust_to_sect() call the now even cluster number is 
multiplied 
by the cluster size and and the data_begin section is added. So after the 
calculation without the rest the negative value is smaller and my 
rootdir_sect
is higher then the actual rootdir_sect.
In my case:
clust_size = 2
rootdir_sect = 113
dara_begin = 132

sect_to_clust: 0xfff1 = (0x113 - 132) / 2
sect_to_clust: 114 = 132 + 0xfff1 * 2

Now my root_cluster is above the root dir but it should be below it (112).
I fixed this with the following patch:

---

 fs/fat/fat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index de5c7210be..695b6323b1 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -587,7 +587,9 @@ static int get_fs_info(fsdata *mydata)
mydata->rootdir_size -
(mydata->clust_size * 2);
mydata->root_cluster =
-   sect_to_clust(mydata, mydata->rootdir_sect);
+   sect_to_clust(mydata, mydata->rootdir_sect -
+ (mydata->rootdir_sect %
+  mydata->clust_size));
}
 
mydata->fatbufnum = -1;


After patch:
sect_to_clust: 0xfff0 = (0x112 - 132) / 2
sect_to_clust: 112 = 132 + 0xfff0 * 2

Can you verify this?
If yes? Is it maybe possible to add this to your patch?

Regards,
Bernhard

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

Re: [U-Boot] Issue with relocating code to DDR

[SHEKHAR SINGH]

Hi All,

We got the issue, actually our DDR only supports 32bit access, 16bit and
8bit access are not supported.
Is there any compiler option or any u-boot option, we need to configure so
that u-boot use 32 bit access only.

Thanks in advance.
Regards
Shekhar Singh

On Thu, Nov 1, 2018 at 7:14 PM SHEKHAR SINGH 
wrote:

>
> Hi All,
>
> I am new to U-boot. Currently, I am working on developing U-boot for a new
> SOC. The SOC has arm926ej-s as the core and is implemented on Xilinx FPGA
> with SD-card as the boot device. With current setup DDR is already
> initialized by FPGA and SD card can be accessed using direct addressing. We
> have added board files and SoC related files to the Uboot directory and is
> able to successfully compile and get some outputs on UART (debug console).
> Currently, we have added only support for GPIO and UART drivers.
>
> SD Card : 0x - 0x007F
> SRAM: 0x9000 - 0x90007FFF
> DDR   : 0x4000 - 0x43FF
>
> We are facing some issue with the uboot booting. We are able to see the
> initial uboot prints and debug prints when the stack pointer is in SRAM,
> but after we relocate the code from SD card to DDR and change the stack
> pointer to DDR we are getting junk prints on the console. Can anyone help
> me or suggest me what we are doing wrong here? Thanks in advance for your
> help.
>
> Please see the below UART Log:
>
> initcall: 5cdc
> initcall: 9a84
> initcall: 5ccc
> initcall: 5fbc
> initcall: 60c0
> initcall: 0418
> initcall: 6090
> initcall: 5fb4
> malloc_simple: size=18, ptr=18, limit=400: 9b30
> malloc_simple: size=54, ptr=6c, limit=400: 9b48
> malloc_simple: size=4, ptr=70, limit=400: 9b9c
> uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 -1 'root_driver'
>- not found
> initcall: 6088
> initcall: 10b0
> initcall: 04a8
> initcall: f77c
> env_init: Environment nowhere init done (ret=0)
> initcall: 5f88
> initcall: f0dc
> initcall: 000147c0
>
>
>  U-Boot 2018.09 (Nov 01 2018 - 18:33:40 +0530)
>
>  initcall: 5eac
>  U-Boot code:  -> 00024604  BSS: -> 00030608
>  initcall: 0438
>  CPU: SoC Version 0.01
>  CPU clock:75MHz
>  SDRAM clock:  75MHz
>  initcall: 6470
>  initcall: 5f70
>  DRAM:  initcall: 10ec
>  SDRAM Reg 000 : 
>  EDAC Reg  004 : 
>  SDRAM Reg 100 : 
>  EDAC Reg  104 : 
>  EMC Reg   : 1ff
>  initcall: 6178
>  Monitor len: 00030608
>  Ram size: 0400
>  gd->relocaddr : 4400
>  Ram top: 4400
>  initcall: 5cfc
>  initcall: 6098
>  initcall: 5d14
>  initcall: 60a0
>  initcall: 5e44
>  Reserving 193k for U-Boot at: 43fcf000
>  initcall: 5e18
>  Reserving 1152k for malloc() at: 43eaf000
>  initcall: 5f1c
>  Reserving 80 Bytes for Board Info at: 43eaefb0
>  initcall: 60a8
>  initcall: 5de4
>  Reserving 200 Bytes for Global Data at: 43eaeee8
>  initcall: 5d5c
>  initcall: 60b0
>  initcall: 60c8
>  initcall: 61f4
>  gd->relocaddr : 43FCF000
>  initcall: 5d1c
>  initcall: 60dc
>
>  RAM Configuration:
>  Bank #0: 4000 64 MiB
>
>  DRAM:  64 MiB
>  initcall: 5d40
>  New Stack Pointer is: 43eaeec0
>  initcall: 5ed8
>  initcall: 60b8
>  initcall: 5fd0
>  __image_copy_start : 
>  __image_copy_end : 00024604
>  gd copied successfully to new gd...
>  Relocation Offset is: 43fcf000
>  Relocating to Addr 43fcf000, new gd at 43eaeee8, sp at 43eaeec0
>  Current Stack Pointer 9a60
>  
> 
> ENABLE CACHESWARNING: Caches not enabled
>  
> 
> 
> 
>
>
>
>  
> 
> 
> 
> 
>
>
>
>  
> 
> 
>
>
>
>  
> 
> 
> MMC:
> 
> 
> 
> 
>
>
>
>  
> 
> 

Re: [U-Boot] Booting i.MX6UL via SPL?

[Martyn Welch]

On Thu, 2018-11-08 at 11:25 +0100, Stefano Babic wrote:
> Hi Martyn,
> 
> On 07/11/18 21:46, Martyn Welch wrote:
> > Hi All,
> > 
> > I've been trying to boot a i.MX6UL based device I have here using
> > SPL.
> > It doesn't seem to want to work for me.
> > 
> > I see there's a number of i.MX6UL ports in U-Boot already, some use
> > a
> > custom DCD to configure the board, others seem to provide both
> > options
> > (DCD and SPL). Interestingly the Freescale i.MX 6UltraLite
> > Evaluation
> > Kit port (via mx6ul_14x14_evk_defconfig) appears to be using the
> > SPL
> > mechanism exclusively.
> > 
> > Can someone confirm that the above device boots using this config
> > from
> > SD card?
> > 
> > I seem to be able to boot from SD card using a custom DCD (which
> > copies
> > U-Boot into RAM), I'm also able to get the SPL to boot via USB
> > (which
> > copies the SPL to OCRAM). However when I try to boot the SPL from
> > SD
> > card it doesn't boot. If I boot the SPL via USB, insert an SD card
> > and
> > reset the device, it seems to boot from the SPL previously loaded
> > from
> > USB (as in it's still in the OCRAM) but carries on like it's booted
> > from the SD card (looking on the SD card rather than USB for the
> > main
> > U-Boot image). The reason I think it's doing this is that if I
> > rebuild
> > U-Boot and flash a copy with an updated build time to the SD card,
> > when
> > I perform a reset I still see the old build time in the U-Boot
> > banner.
> > It looks to me like for some reason it's unable to copy the SPL to
> > OCRAM, but carries on thinking it has.
> > 
> > Anyone got any pointers?
> > 
> 
> I confirm that SPL works for a MX6UL, but I had this issue, too. It
> could depend on the Hardware Revision of your processor.
> 
> There is a bug in revision 1.2 of the processor that makes the first
> part of the OCRAM not available and SPL cannot be copied. This bug
> affects just some production charges, and NXP solved this later
> without
> changing the revision of the processor. That means there are some
> boards
> where everything is fine, some other boards with just a newer
> processor
> that do not boot. I do not know if this is your use case, but it
> makes
> sense to give a try.
> 
> I had just moved CONFIG_SPL_TEXT_BASE to a later offset:
> 
> define CONFIG_SPL_TEXT_BASE0x00909000
> 

Thanks Stefano, this was exactly the issue that I was hitting!

Martyn

> However, there is no chance to know at runtime if a board is affected
> by
> this issue because the revision does not change, and I do not think
> it
> is a good idea to force all MX6UL to restrict their OCRAM due to a
> buggy
> and time constrained production by the manufacturer.
> 
> I hope this helps,
> Stefano
> 

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

[U-Boot] [PATCH 1/1] embestmx6boards: Add SPL support

[Fabien Lahoudere]

In order to boot faster with falcon mode, we need to add SPL
support to riotboard.

Signed-off-by: Fabien Lahoudere 
---
 arch/arm/mach-imx/mx6/Kconfig  |  1 +
 board/embest/mx6boards/mx6boards.c | 48 ++
 configs/riotboard_spl_defconfig| 48 ++
 include/configs/embestmx6boards.h  | 13 
 4 files changed, 110 insertions(+)
 create mode 100644 configs/riotboard_spl_defconfig

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 06c25bae36..e7cce46e03 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -182,6 +182,7 @@ config TARGET_DISPLAY5
 config TARGET_EMBESTMX6BOARDS
bool "embestmx6boards"
select BOARD_LATE_INIT
+   select SUPPORT_SPL
 
 config TARGET_GE_BX50V3
bool "General Electric Bx50v3"
diff --git a/board/embest/mx6boards/mx6boards.c 
b/board/embest/mx6boards/mx6boards.c
index 8930c36fe6..fed92aa88a 100644
--- a/board/embest/mx6boards/mx6boards.c
+++ b/board/embest/mx6boards/mx6boards.c
@@ -608,3 +608,51 @@ int checkboard(void)
 
return 0;
 }
+
+#ifdef CONFIG_SPL_BUILD
+#include 
+
+void board_init_f(ulong dummy)
+{
+   u32 cputype = cpu_type(get_cpu_rev());
+
+   switch (cputype) {
+   case MXC_CPU_MX6SOLO:
+   board_type = BOARD_IS_RIOTBOARD;
+   break;
+   case MXC_CPU_MX6D:
+   board_type = BOARD_IS_MARSBOARD;
+   break;
+   }
+   arch_cpu_init();
+
+   /* setup GP timer */
+   timer_init();
+
+#ifdef CONFIG_SPL_SERIAL_SUPPORT
+   setup_iomux_uart();
+   preloader_console_init();
+#endif
+}
+
+void board_boot_order(u32 *spl_boot_list)
+{
+   spl_boot_list[0] = BOOT_DEVICE_MMC1;
+}
+
+/*
+ * In order to jump to standard u-boot shell, you have to connect pin 5 of J13
+ * to pin 3 (ground).
+ */
+int spl_start_uboot(void)
+{
+   int gpio_key = IMX_GPIO_NR(4, 16);
+
+   gpio_direction_input(gpio_key);
+   if (gpio_get_value(gpio_key) == 0)
+   return 1;
+   else
+   return 0;
+}
+
+#endif
diff --git a/configs/riotboard_spl_defconfig b/configs/riotboard_spl_defconfig
new file mode 100644
index 00..8b5459aa1a
--- /dev/null
+++ b/configs/riotboard_spl_defconfig
@@ -0,0 +1,48 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SYS_TEXT_BASE=0x1780
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_TARGET_EMBESTMX6BOARDS=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,SPL,MX6S,DDR_MB=1024"
+CONFIG_BOOTCOMMAND="run finduuid; run distro_bootcmd"
+# CONFIG_CONSOLE_MUX is not set
+CONFIG_SYS_CONSOLE_IS_IN_ENV=y
+CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_RAW_IMAGE_SUPPORT=y
+CONFIG_SPL_EXT_SUPPORT=y
+CONFIG_SPL_OS_BOOT=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_DM=y
+CONFIG_FSL_ESDHC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_PHYLIB=y
+CONFIG_MII=y
+CONFIG_SPI=y
+CONFIG_MXC_SPI=y
+CONFIG_DM_THERMAL=y
+CONFIG_USB=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_VIDEO=y
+# CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_OF_LIBFDT=y
+CONFIG_SPL_OF_LIBFDT=y
diff --git a/include/configs/embestmx6boards.h 
b/include/configs/embestmx6boards.h
index 71217f07e2..7e7de4dae6 100644
--- a/include/configs/embestmx6boards.h
+++ b/include/configs/embestmx6boards.h
@@ -109,6 +109,19 @@
 
 #include "mx6_common.h"
 
+#ifdef CONFIG_SPL
+#include "imx6_spl.h"
+/* RiOTboard */
+#define CONFIG_SYS_SPL_ARGS_ADDR 0x1300
+#define CONFIG_SPL_FS_LOAD_KERNEL_NAME "uImage"
+#define CONFIG_SPL_FS_LOAD_ARGS_NAME "imx6dl-riotboard.dtb"
+
+#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0 /* offset 69KB */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR  0 /* offset 69KB */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 0 /* offset 69KB */
+
+#endif
+
 /* 256M RAM (minimum), 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
  * 1M script, 1M pxe and the ramdisk at the end */
 #define MEM_LAYOUT_ENV_SETTINGS \
-- 
2.17.2

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

Re: [U-Boot] [PATCH v1 2/2] imx: mkimage: add size check to the u-boot.imx make target

[Tom Rini]

On Thu, Nov 08, 2018 at 09:43:56AM +0100, Stefano Babic wrote:
> On 08/11/18 02:55, Fabio Estevam wrote:
> > [Adding Stefano]
> > 
> > On Wed, Nov 7, 2018 at 8:41 PM Marcel Ziswiler  wrote:
> >>
> >> From: Marcel Ziswiler 
> >>
> >> The make macro to check if the binary exceeds the board size limit is
> >> taken straight from the root Makefile.
> >>
> >> Without this and e.g. enabled EFI Vybrid fails booting as the regular
> >> size limit check does not take the final u-boot.imx binary size into
> >> account which is bigger due to alignment as well as IMX header stuff.
> >>
> >> Signed-off-by: Marcel Ziswiler 
> > 
> > Reviewed-by: Fabio Estevam 
> > 
> > Hi Stefano, maybe this could be material for 2018.11?
> > 
> > Thanks
> > 
> 
> It makes sense - Tom, could you pick this up or do you prefer a formal PR ?

PR please, 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] [PATCH 22/25] misc: Update read() and write() methods to return bytes xfered

[Patrick DELAUNAY]

Hi Simon, 

> From: Simon Glass 
> Sent: mardi 6 novembre 2018 23:22
> Subject: [PATCH 22/25] misc: Update read() and write() methods to return bytes
> 
> At present these functions return 0 on success. For some devices we want to
> know how many bytes were transferred. It seems useful to adjust the API to be
> more like the POSIX read() and write() functions.
> 
> Update these two methods, a test and all users.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  arch/arm/mach-stm32mp/cpu.c|  4 ++--
>  drivers/clk/clk_vexpress_osc.c |  4 ++--
>  drivers/misc/altera_sysid.c|  2 +-
>  drivers/misc/misc_sandbox.c|  4 ++--
>  drivers/misc/rockchip-efuse.c  |  2 +-
>  drivers/misc/stm32mp_fuse.c| 12 
>  include/misc.h |  8 
>  7 files changed, 24 insertions(+), 12 deletions(-)

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

Re: [U-Boot] Booting i.MX6UL via SPL?

[Stefano Babic]

Hi Martyn,

On 07/11/18 21:46, Martyn Welch wrote:
> Hi All,
> 
> I've been trying to boot a i.MX6UL based device I have here using SPL.
> It doesn't seem to want to work for me.
> 
> I see there's a number of i.MX6UL ports in U-Boot already, some use a
> custom DCD to configure the board, others seem to provide both options
> (DCD and SPL). Interestingly the Freescale i.MX 6UltraLite Evaluation
> Kit port (via mx6ul_14x14_evk_defconfig) appears to be using the SPL
> mechanism exclusively.
> 
> Can someone confirm that the above device boots using this config from
> SD card?
> 
> I seem to be able to boot from SD card using a custom DCD (which copies
> U-Boot into RAM), I'm also able to get the SPL to boot via USB (which
> copies the SPL to OCRAM). However when I try to boot the SPL from SD
> card it doesn't boot. If I boot the SPL via USB, insert an SD card and
> reset the device, it seems to boot from the SPL previously loaded from
> USB (as in it's still in the OCRAM) but carries on like it's booted
> from the SD card (looking on the SD card rather than USB for the main
> U-Boot image). The reason I think it's doing this is that if I rebuild
> U-Boot and flash a copy with an updated build time to the SD card, when
> I perform a reset I still see the old build time in the U-Boot banner.
> It looks to me like for some reason it's unable to copy the SPL to
> OCRAM, but carries on thinking it has.
> 
> Anyone got any pointers?
> 

I confirm that SPL works for a MX6UL, but I had this issue, too. It
could depend on the Hardware Revision of your processor.

There is a bug in revision 1.2 of the processor that makes the first
part of the OCRAM not available and SPL cannot be copied. This bug
affects just some production charges, and NXP solved this later without
changing the revision of the processor. That means there are some boards
where everything is fine, some other boards with just a newer processor
that do not boot. I do not know if this is your use case, but it makes
sense to give a try.

I had just moved CONFIG_SPL_TEXT_BASE to a later offset:

define CONFIG_SPL_TEXT_BASE0x00909000

However, there is no chance to know at runtime if a board is affected by
this issue because the revision does not change, and I do not think it
is a good idea to force all MX6UL to restrict their OCRAM due to a buggy
and time constrained production by the manufacturer.

I hope this helps,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Booting i.MX6UL via SPL?

[Heiko Schocher]

Hello Martyn,

Am 07.11.2018 um 21:46 schrieb Martyn Welch:

Hi All,

I've been trying to boot a i.MX6UL based device I have here using SPL.
It doesn't seem to want to work for me.

I see there's a number of i.MX6UL ports in U-Boot already, some use a
custom DCD to configure the board, others seem to provide both options
(DCD and SPL). Interestingly the Freescale i.MX 6UltraLite Evaluation
Kit port (via mx6ul_14x14_evk_defconfig) appears to be using the SPL
mechanism exclusively.

Can someone confirm that the above device boots using this config from
SD card?

I seem to be able to boot from SD card using a custom DCD (which copies
U-Boot into RAM), I'm also able to get the SPL to boot via USB (which
copies the SPL to OCRAM). However when I try to boot the SPL from SD
card it doesn't boot. If I boot the SPL via USB, insert an SD card and
reset the device, it seems to boot from the SPL previously loaded from
USB (as in it's still in the OCRAM) but carries on like it's booted
from the SD card (looking on the SD card rather than USB for the main
U-Boot image). The reason I think it's doing this is that if I rebuild
U-Boot and flash a copy with an updated build time to the SD card, when
I perform a reset I still see the old build time in the U-Boot banner.
It looks to me like for some reason it's unable to copy the SPL to
OCRAM, but carries on thinking it has.

Anyone got any pointers?


Hard to say...

I have running U-Boot wit SPL on a imx6ull based board, booting from
SPI NOR.

If you have a setup with DCD, also SPL should work, but be sure to
setup correct RAM config. But you say, SPL works when loading through
USB

I added for imx6ull:

#undef CONFIG_SPL_STACK
#define CONFIG_SPL_STACK   0x00918000

You use
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"

?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Pull request: u-boot-ubi/master

[Heiko Schocher]

Hello Tom,

please pull from u-boot-ubi-git master

as it is a Bugfix, I think it should go into current release.

The following changes since commit dd610e616cceda16a81dfa6f9a134877f783548c:

  Merge tag 'u-boot-imx-20181106' of git://git.denx.de/u-boot-imx (2018-11-06 
11:12:00 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-ubi.git master

for you to fetch changes up to e4aa10ba5770fc391bf8a4b00c131353901704e7:

  fs: ubifs: Fix UBIFS decompression on 64 bit (2018-11-07 08:49:27 +0100)


Paul Davey (1):
  fs: ubifs: Fix UBIFS decompression on 64 bit

 fs/ubifs/ubifs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

travis builds fine:
https://travis-ci.org/hsdenx/u-boot-ubi/builds/451758575

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1] fs: ubifs: Fix UBIFS decompression on 64 bit

[Heiko Schocher]

Hello Paul,

Am 05.11.2018 um 06:09 schrieb Paul Davey:

Add local size_t variable to crypto_comp_decompress as intermediate
storage for destination length to avoid memory corruption and incorrect
results on 64 bit targets.

This is what linux does for the various lz compression implementations.

Signed-off-by: Paul Davey 
Cc: Heiko Schocher 
---

When attempting to use ubifs on a MIPS64 platform I found that it would fail
decompression for the file I was attempting to load.

Further investigation found that this was due to the pointer cast from unsigned
int * to size_t * in the decompression wrapper.  This will cause any big endian
64 bit platform to fail to load any ubifs file that requires decompression and
at least cause little endian 64 bit platforms to silently write 0 over 4 bytes
of stack memory.

  fs/ubifs/ubifs.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)


Applied to u-boot-ubi.git master

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rpi: Do not use dtb loaded by firmware

[Jun Nie]

Alexander Graf  于2018年11月8日周四 下午4:59写道：
>
> On 11/08/2018 09:36 AM, Jun Nie wrote:
> > Do not use dtb loaded by firmware if fit image signature is enabled.
> > So that u-boot.dtb can be used. The u-boot.dtb contains the pulibc key
> > that is to verify Linux kernel FIT image blob.
> >
> > The u-boot.dtb can be loaded by Arm Trusted Firmware(ATF) together
> > with u-boot.bin to make sure the key is protected by ATF.
>
> I don't think I fully understand what you're trying to do here. If ATF
> loads U-Boot as well as the DT, ATF can pass the DT to U-Boot which then
> ends up as $fdtaddr. If you enable CONFIG_OF_BOARD, it even becomes the
> input DT for U-Boot.

Current usage is that pack u-boot.dtb to u-boot-nodtb.bin so that
u-boot can find
device tree in the end if u-boot binary. This saves separate signing
to u-boot.dtb in
ATF. Do you see any benefit to load u-boot.dtb separately and feed
$fdtaddr to u-boot?

Jun

>
> Hiding the fdtfile variable name doesn't sound like it solves anything
> to me?
>
>
> Alex
>
> >
> > Signed-off-by: Jun Nie 
> > ---
> >   board/raspberrypi/rpi/rpi.c | 6 ++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> > index 649127c..f7041e3 100644
> > --- a/board/raspberrypi/rpi/rpi.c
> > +++ b/board/raspberrypi/rpi/rpi.c
> > @@ -283,6 +283,7 @@ int dram_init(void)
> >   return 0;
> >   }
> >
> > +#ifndef CONFIG_FIT_SIGNATURE
> >   static void set_fdtfile(void)
> >   {
> >   const char *fdtfile;
> > @@ -318,6 +319,7 @@ unsigned long board_get_usable_ram_top(unsigned long 
> > total_size)
> >   return gd->ram_top;
> >   return fw_dtb_pointer & ~0x;
> >   }
> > +#endif
> >
> >   static void set_usbethaddr(void)
> >   {
> > @@ -390,8 +392,10 @@ static void set_serial_number(void)
> >
> >   int misc_init_r(void)
> >   {
> > +#ifndef CONFIG_FIT_SIGNATURE
> >   set_fdt_addr();
> >   set_fdtfile();
> > +#endif
> >   set_usbethaddr();
> >   #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> >   set_board_info();
> > @@ -467,6 +471,7 @@ int board_init(void)
> >   return bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
> >   }
> >
> > +#ifndef CONFIG_FIT_SIGNATURE
> >   /*
> >* If the firmware passed a device tree use it for U-Boot.
> >*/
> > @@ -476,6 +481,7 @@ void *board_fdt_blob_setup(void)
> >   return NULL;
> >   return (void *)fw_dtb_pointer;
> >   }
> > +#endif
> >
> >   int ft_board_setup(void *blob, bd_t *bd)
> >   {
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rpi: Do not use dtb loaded by firmware

[Alexander Graf]

On 11/08/2018 09:36 AM, Jun Nie wrote:

Do not use dtb loaded by firmware if fit image signature is enabled.
So that u-boot.dtb can be used. The u-boot.dtb contains the pulibc key
that is to verify Linux kernel FIT image blob.

The u-boot.dtb can be loaded by Arm Trusted Firmware(ATF) together
with u-boot.bin to make sure the key is protected by ATF.


I don't think I fully understand what you're trying to do here. If ATF 
loads U-Boot as well as the DT, ATF can pass the DT to U-Boot which then 
ends up as $fdtaddr. If you enable CONFIG_OF_BOARD, it even becomes the 
input DT for U-Boot.


Hiding the fdtfile variable name doesn't sound like it solves anything 
to me?



Alex



Signed-off-by: Jun Nie 
---
  board/raspberrypi/rpi/rpi.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 649127c..f7041e3 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -283,6 +283,7 @@ int dram_init(void)
return 0;
  }
  
+#ifndef CONFIG_FIT_SIGNATURE

  static void set_fdtfile(void)
  {
const char *fdtfile;
@@ -318,6 +319,7 @@ unsigned long board_get_usable_ram_top(unsigned long 
total_size)
return gd->ram_top;
return fw_dtb_pointer & ~0x;
  }
+#endif
  
  static void set_usbethaddr(void)

  {
@@ -390,8 +392,10 @@ static void set_serial_number(void)
  
  int misc_init_r(void)

  {
+#ifndef CONFIG_FIT_SIGNATURE
set_fdt_addr();
set_fdtfile();
+#endif
set_usbethaddr();
  #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info();
@@ -467,6 +471,7 @@ int board_init(void)
return bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
  }
  
+#ifndef CONFIG_FIT_SIGNATURE

  /*
   * If the firmware passed a device tree use it for U-Boot.
   */
@@ -476,6 +481,7 @@ void *board_fdt_blob_setup(void)
return NULL;
return (void *)fw_dtb_pointer;
  }
+#endif
  
  int ft_board_setup(void *blob, bd_t *bd)

  {



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

Re: [U-Boot] [PATCH v1 2/2] imx: mkimage: add size check to the u-boot.imx make target

[Stefano Babic]

On 08/11/18 02:55, Fabio Estevam wrote:
> [Adding Stefano]
> 
> On Wed, Nov 7, 2018 at 8:41 PM Marcel Ziswiler  wrote:
>>
>> From: Marcel Ziswiler 
>>
>> The make macro to check if the binary exceeds the board size limit is
>> taken straight from the root Makefile.
>>
>> Without this and e.g. enabled EFI Vybrid fails booting as the regular
>> size limit check does not take the final u-boot.imx binary size into
>> account which is bigger due to alignment as well as IMX header stuff.
>>
>> Signed-off-by: Marcel Ziswiler 
> 
> Reviewed-by: Fabio Estevam 
> 
> Hi Stefano, maybe this could be material for 2018.11?
> 
> Thanks
> 

It makes sense - Tom, could you pick this up or do you prefer a formal PR ?

Regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rpi: Do not use dtb loaded by firmware

[Jun Nie]

Do not use dtb loaded by firmware if fit image signature is enabled.
So that u-boot.dtb can be used. The u-boot.dtb contains the pulibc key
that is to verify Linux kernel FIT image blob.

The u-boot.dtb can be loaded by Arm Trusted Firmware(ATF) together
with u-boot.bin to make sure the key is protected by ATF.

Signed-off-by: Jun Nie 
---
 board/raspberrypi/rpi/rpi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 649127c..f7041e3 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -283,6 +283,7 @@ int dram_init(void)
return 0;
 }
 
+#ifndef CONFIG_FIT_SIGNATURE
 static void set_fdtfile(void)
 {
const char *fdtfile;
@@ -318,6 +319,7 @@ unsigned long board_get_usable_ram_top(unsigned long 
total_size)
return gd->ram_top;
return fw_dtb_pointer & ~0x;
 }
+#endif
 
 static void set_usbethaddr(void)
 {
@@ -390,8 +392,10 @@ static void set_serial_number(void)
 
 int misc_init_r(void)
 {
+#ifndef CONFIG_FIT_SIGNATURE
set_fdt_addr();
set_fdtfile();
+#endif
set_usbethaddr();
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info();
@@ -467,6 +471,7 @@ int board_init(void)
return bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
 }
 
+#ifndef CONFIG_FIT_SIGNATURE
 /*
  * If the firmware passed a device tree use it for U-Boot.
  */
@@ -476,6 +481,7 @@ void *board_fdt_blob_setup(void)
return NULL;
return (void *)fw_dtb_pointer;
 }
+#endif
 
 int ft_board_setup(void *blob, bd_t *bd)
 {
-- 
2.7.4

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