[U-Boot] [PATCH] armv8: ls1088aqds: Enable mdio commands on u-boot prompt
Signed-off-by: Ashish Kumar --- board/freescale/ls1088a/eth_ls1088aqds.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/freescale/ls1088a/eth_ls1088aqds.c b/board/freescale/ls1088a/eth_ls1088aqds.c index 7fe446e..d09e077 100644 --- a/board/freescale/ls1088a/eth_ls1088aqds.c +++ b/board/freescale/ls1088a/eth_ls1088aqds.c @@ -5,12 +5,14 @@ */ #include +#include #include #include #include #include #include #include +#include #include #include #include -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Relocate env drivers if manual reloc is required
Hi,
On 12.4.2018 18:42, Simon Glass wrote:
> Hi Michal,
>
> On 12 April 2018 at 04:26, Michal Simek wrote:
>> From: Siva Durga Prasad Paladugu
>>
>> Relocate env drivers if manual relocation is enabled. This
>> patch fixes the issue of u-boot hang incase if env is
>> present in any of the flash devices.
>>
>> Signed-off-by: Siva Durga Prasad Paladugu
>> Signed-off-by: Michal Simek
>> ---
>>
>> env/common.c | 1 +
>> env/env.c | 21 +
>> include/environment.h | 5 +
>> 3 files changed, 27 insertions(+)
>
> Reviewed-by: Simon Glass
>
> Please see below
>
>>
>> diff --git a/env/common.c b/env/common.c
>> index f21ff7009695..d282868ee51b 100644
>> --- a/env/common.c
>> +++ b/env/common.c
>> @@ -227,6 +227,7 @@ void env_relocate(void)
>> {
>> #if defined(CONFIG_NEEDS_MANUAL_RELOC)
>> env_reloc();
>> + fix_envdriver();
>> env_htab.change_ok += gd->reloc_off;
>> #endif
>> if (gd->env_valid == ENV_INVALID) {
>> diff --git a/env/env.c b/env/env.c
>> index 3795dbc24e2b..15a0597100f4 100644
>> --- a/env/env.c
>> +++ b/env/env.c
>> @@ -10,6 +10,27 @@
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> +#if defined(CONFIG_NEEDS_MANUAL_RELOC)
>> +void fix_envdriver(void)
>
> How about env_fix_drivers() ? The env_ prefix is nice for something in
> the environment code.
>
> [..]
>
v2 sent with name changed.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] env: Relocate env drivers if manual reloc is required
From: Siva Durga Prasad Paladugu
Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
Reviewed-by: Simon Glass
---
Changes in v2:
- 's/fix_envdriver/env_fix_drivers/g' - by Simon
env/common.c | 1 +
env/env.c | 21 +
include/environment.h | 5 +
3 files changed, 27 insertions(+)
diff --git a/env/common.c b/env/common.c
index f21ff7009695..8f602de9d28f 100644
--- a/env/common.c
+++ b/env/common.c
@@ -227,6 +227,7 @@ void env_relocate(void)
{
#if defined(CONFIG_NEEDS_MANUAL_RELOC)
env_reloc();
+ env_fix_drivers();
env_htab.change_ok += gd->reloc_off;
#endif
if (gd->env_valid == ENV_INVALID) {
diff --git a/env/env.c b/env/env.c
index 3795dbc24e2b..90d65974d0c9 100644
--- a/env/env.c
+++ b/env/env.c
@@ -10,6 +10,27 @@
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
+void env_fix_drivers(void)
+{
+ struct env_driver *drv;
+ const int n_ents = ll_entry_count(struct env_driver, env_driver);
+ struct env_driver *entry;
+
+ drv = ll_entry_start(struct env_driver, env_driver);
+ for (entry = drv; entry != drv + n_ents; entry++) {
+ if (entry->name)
+ entry->name += gd->reloc_off;
+ if (entry->load)
+ entry->load += gd->reloc_off;
+ if (entry->save)
+ entry->save += gd->reloc_off;
+ if (entry->init)
+ entry->init += gd->reloc_off;
+ }
+}
+#endif
+
static struct env_driver *_env_driver_lookup(enum env_location loc)
{
struct env_driver *drv;
diff --git a/include/environment.h b/include/environment.h
index 1b52353365ed..2bd0ad12a640 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -314,6 +314,11 @@ int env_load(void);
*/
int env_save(void);
+/**
+ * env_fix_drivers() - Updates envdriver as per relocation
+ */
+void env_fix_drivers(void);
+
void eth_parse_enetaddr(const char *addr, uint8_t *enetaddr);
int eth_env_get_enetaddr(const char *name, uint8_t *enetaddr);
int eth_env_set_enetaddr(const char *name, const uint8_t *enetaddr);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Fwd: Re: Please pull from u-boot-i2c
Hello Tom, Huch ... just saw, that I forgot to add the u-boot ml to cc ... sorry! bye, Heiko Weitergeleitete Nachricht Betreff: Re: [U-Boot] Please pull from u-boot-i2c Datum: Thu, 12 Apr 2018 09:35:30 -0400 Von: Tom Rini An: Heiko Schocher Kopie (CC): Mario Six , Alexander Kochetkov On Wed, Apr 11, 2018 at 06:39:50PM +0200, Heiko Schocher wrote: Hello Tom, please pull from u-boot-i2c master The following changes since commit 2600df4f8ef12ece9cec13030005919e0ba2b0d5: Merge tag 'xilinx-for-v2018.05-rc2' of git://git.denx.de/u-boot-microblaze (2018-04-09 11:06:21 -0400) are available in the Git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to e5c762f5a7dbeaa21870720e8daf656153e1aef9: i2c: fsl: Add option to get clock from DT (2018-04-11 11:34:55 +0200) Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: nitrogen6x: Convert Sabrelite to distro boot support
On Tue, Apr 10, 2018 at 6:50 AM, Gary Bisson
wrote:
> Hi Guillaume,
>
> On Mon, Apr 09, 2018 at 05:17:44PM +0200, Guillaume Gardet wrote:
>>
>>
>> Le 09/04/2018 à 16:40, Gary Bisson a écrit :
>> > Hi Guillaume,
>> >
>> > Thanks for your patch! Switching the upstream nitrogen6x configuration
>> > to distro bootcmd has been in our todo list for some time since we also
>> > use that in our own git repo.
>> >
>> > On Fri, Apr 06, 2018 at 12:05:48PM +0200, Guillaume GARDET wrote:
>> > > Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.
>> > >
>> > > Signed-off-by: Guillaume GARDET
>> > > Cc: Troy Kisky
>> > > Cc: Stefano Babic
>> > > Cc: Fabio Estevam
>> > > ---
>> > > include/configs/nitrogen6x.h | 86
>> > > ++--
>> > > 1 file changed, 18 insertions(+), 68 deletions(-)
>> > >
>> > > diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
>> > > index c73cfb7f7e..2e2c499cb6 100644
>> > > --- a/include/configs/nitrogen6x.h
>> > > +++ b/include/configs/nitrogen6x.h
>> > > @@ -102,82 +102,32 @@
>> > > #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
>> > > #if defined(CONFIG_SABRELITE)
>> > Please also switch nitrogen6x to it, not only sabrelite.
>>
>> Should we keep all the 6x scripts stuff or not?
>
> No, we need to switch to something standard, let's remove it.
>
>> > > +#define BOOT_TARGET_DEVICES(func) \
>> > > + func(MMC, mmc, 0) \
>> > > + func(MMC, mmc, 1) \
>> > > + func(SATA, sata, 0) \
>> > > + func(USB, usb, 0) \
>> > > + func(PXE, pxe, na) \
>> > That currently doesn't build because CMD_PXE isn't selected in the
>> > sabrelite defconfig.
>> > "include/config_distro_bootcmd.h:319:2: error: expected ‘}’ before
>> > ‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’"
>> >
>> > Which brings a good point, all the above should depend on the storage
>> > command being present, like done here [1].
>>
>> No, we just need to update the defconfig, see V2 of this patch sent earlier
>> today.
>
> I know updating the defconfig makes it build. My point is that it would
> be more flexible to do like in the link provided so that someone that
> removes CMD_PXE from the defconfig for any reason can still build.
Agreed. Also, be careful to check for CONFIG_CMD_DHCP and
CONFIG_CMD_PXE for the PXE case.
>> > > + func(DHCP, dhcp, na)
>> > > +
>> > > +#include
>> > > +
>> > > #define CONFIG_EXTRA_ENV_SETTINGS \
>> > > - "script=boot.scr\0" \
>> > > - "uimage=uImage\0" \
>> > > "console=ttymxc1\0" \
>> > > "fdt_high=0x\0" \
>> > > "initrd_high=0x\0" \
>> > > - "fdt_file=imx6q-sabrelite.dtb\0" \
>> > > + "fdtfile=imx6q-sabrelite.dtb\0" \
>> > I wish the default efi_fdtfile would work, Fabio is there any plan to
>> > populate the ${soc} variable like it is done for i.MX7? [2]
>> > Then a small patch in the nitrogen6x.c would set the proper board env
>> > variable.
>> >
>> > That way there would be no difference in this header between sabrelite
>> > vs. nitrogen6x.
>> >
>> > > "fdt_addr=0x1800\0" \
>> > Do we need to keep fdt_addr since we define fdt_addr_r below?
>>
>> It was for backward compatibility, if people had some script using it.
>
> I think it should be dropped.
>
> Regards,
> Gary
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: mvebu: a8k: Add distro boot support
On Fri, Mar 30, 2018 at 9:10 AM, Stefan Roese wrote: > On 17.03.2018 09:34, Mark Kettenis wrote: >> >> The various load address values are taken from the a37xx configuration >> and match the dowstream 'u-boot-2017.03-armada-17.10' release where >> appropriate. >> >> Signed-off-by: Mark Kettenis >> --- >> include/configs/mvebu_armada-8k.h | 19 +++ >> 1 file changed, 19 insertions(+) >> >> diff --git a/include/configs/mvebu_armada-8k.h >> b/include/configs/mvebu_armada-8k.h >> index f288cf5b17..1cd0fa93d3 100644 >> --- a/include/configs/mvebu_armada-8k.h >> +++ b/include/configs/mvebu_armada-8k.h >> @@ -106,4 +106,23 @@ >> #define CONFIG_E1000 >> #endif >> +#define BOOT_TARGET_DEVICES(func) \ >> + func(MMC, mmc, 1) \ >> + func(MMC, mmc, 0) \ >> + func(USB, usb, 0) \ >> + func(SCSI, scsi, 0) \ >> + func(PXE, pxe, na) \ >> + func(DHCP, dhcp, na) Make sure you only add DHCP if CONFIG_CMD_DHCP is set and only add PXE if CONFIG_CMD_DHCP and CONFIG_CMD_PXE are set. >> + >> +#include >> + >> +#define CONFIG_EXTRA_ENV_SETTINGS \ >> + "scriptaddr=0x4d0\0"\ >> + "pxefile_addr_r=0x4e0\0"\ >> + "fdt_addr_r=0x4f0\0"\ >> + "kernel_addr_r=0x500\0" \ >> + "ramdisk_addr_r=0x800\0"\ >> + "fdtfile=marvell/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ >> + BOOTENV >> + >> #endif /* _CONFIG_MVEBU_ARMADA_8K_H */ >> > > Applied to u-boot-marvell/master. > > Thanks, > Stefan > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] libfdt: Safer access to strings section
On Thu, Apr 12, 2018 at 03:00:17PM -0400, Tom Rini wrote: > On Thu, Apr 12, 2018 at 02:01:05PM +1000, David Gibson wrote: > > On Tue, Apr 10, 2018 at 06:36:06PM -0400, Tom Rini wrote: > > > On Tue, Apr 10, 2018 at 10:42:45AM -0400, Simon Glass wrote: > > > > +U-Boot, Tom, Masahiro > > > > > > > > Hi David, > > > > > > > > On 10 April 2018 at 01:22, David Gibson > > > > wrote: > > > > > On Wed, Apr 04, 2018 at 01:21:10AM +0800, Simon Glass wrote: > > > > >> Hi David, > > > > >> > > > > >> On 3 April 2018 at 23:02, David Gibson > > > > >> wrote: > > > > >> > > > > > >> > On Fri, Mar 30, 2018 at 04:42:21PM +0800, Simon Glass wrote: > > > > >> > > Hi David, > > > > >> > > > > > > >> > > On 26 March 2018 at 07:25, David Gibson > > > > >> > > wrote: > > > > >> > > > fdt_string() is used to retrieve strings from a DT blob's > > > > >> > > > strings section. > > > > >> > > > It's rarely used directly, but is widely used internally. > > > > >> > > > > > > > >> > > > However, it doesn't do any bounds checking, which means in the > > > > >> > > > case of a > > > > >> > > > corrupted blob it could access bad memory, which libfdt is > > > > >> > > > supposed to > > > > >> > > > avoid. > > > > >> > > > > > > > >> > > > This write a safe alternative to fdt_string, fdt_get_string(). > > > > >> > > > It checks > > > > >> > > > both that the given offset is within the string section and > > > > >> > > > that the string > > > > >> > > > it points to is properly \0 terminated within the section. It > > > > >> > > > also returns > > > > >> > > > the string's length as a convenience (since it needs to > > > > >> > > > determine to do the > > > > >> > > > checks anyway). > > > > >> > > > > > > > >> > > > fdt_string() is rewritten in terms of fdt_get_string() for > > > > >> > > > compatibility. > > > > >> > > > > > > > >> > > > Most of the diff here is actually testing infrastructure. > > > > >> > > > > > > > >> > > > Signed-off-by: David Gibson > > > > >> > > > --- > > > > >> > > > libfdt/fdt_ro.c | 61 > > > > >> > > > +++-- > > > > >> > > > libfdt/libfdt.h | 18 ++- > > > > >> > > > libfdt/version.lds | 2 +- > > > > >> > > > tests/.gitignore | 1 + > > > > >> > > > tests/Makefile.tests | 2 +- > > > > >> > > > tests/run_tests.sh | 1 + > > > > >> > > > tests/testdata.h | 1 + > > > > >> > > > tests/testutils.c| 11 +-- > > > > >> > > > tests/trees.S| 26 > > > > >> > > > tests/truncated_string.c | 79 > > > > >> > > > > > > > >> > > > 10 files changed, 193 insertions(+), 9 deletions(-) > > > > >> > > > create mode 100644 tests/truncated_string.c > > > > >> > > > > > > >> > > Similar code-size quesiton here. It looks like a lot of checking > > > > >> > > code. > > > > >> > > Can we have an option to remove it? > > > > >> > > > > > >> > Again, I'm disinclined without a concrete example of a problem. > > > > >> > Fwiw > > > > >> > the code size change is +276 bytes on my setup. > > > > >> > > > > >> That might not sound like a lot, but the overhead of DT in U-Boot is > > > > >> about 3KB, so this adds nearly 10%. > > > > > > > > > > Hm. And how much is it compared to the whole U-Boot blob? > > > > > > > > > >> The specific problem is that when U-Boot SPL gets too big boards > > > > >> don't > > > > >> boot. Because we take the upstream libfdt this will affect U-Boot. > > > > >> > > > > >> Do you have any thoughts on how we could avoid this size increase? > > > > > > > > > > So, again, I'm very disinclined to prioritize size over memory safety > > > > > without a *concrete* example. i.e. "We hit this specific problem with > > > > > size on this specific board that we were really using" rather than > > > > > just "it might be a problem". > > > > > > I'm either failing in my Google-fu or is there not an easy way to grab > > > the patches from patchwork/similar? But, if you shoot me the series > > > off-list, I can tell you how much U-Boot targets grow here (we can use > > > the same script as the kernel to re-sync sources back in, so I can give > > > you a before/after). But as Simon notes, we have a number of platforms > > > that need to use (parts of) libfdt and stick to ~30KiB or less in total, > > > sometimes including some memory for stack/etc and we've long been using > > > -ffunction-sections/etc (the latest round of trying to use LTO has me > > > thinking maybe we can see if that's a valid option finally, but that's > > > an aside). Thanks! > > > > We don't have a patchwork for these lists AFAIK, but you can get my > > draft branch from: > > > > https://github.com/dgibson/dtc/tree/safety > > OK, thanks. So, I used scripts/dtc/update-dtc-source.sh to re-sync us > first with current master, and then with the safety branch, and > boy-howdy, are there a lot of warning changes and additions :) For the > record,
Re: [U-Boot] [PATCH v2 10/18] bios: vesa: Guard setting vesa mode with CONFIG_FRAMEBUFFER_SET_VESA_MODE
Hi Simon, On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass wrote: > Hi Bin, > > On 11 April 2018 at 23:02, Bin Meng wrote: >> If CONFIG_FRAMEBUFFER_SET_VESA_MODE is not set, don't switch >> graphics card to VESA mode. This applies to both native mode >> and emulator mode of running the VGA BIOS. >> >> Signed-off-by: Bin Meng >> --- >> >> Changes in v2: None >> >> arch/x86/lib/bios.c | 4 >> drivers/bios_emulator/atibios.c | 4 >> 2 files changed, 8 insertions(+) > > Could this use if() instead of #ifdef ? > Not all of the changes can, so I chose use #ifdef > Reviewed-by: Simon Glass Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/18] elf: Add a very simple ELF64 loader
Hi Simon, On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass wrote: > On 11 April 2018 at 23:02, Bin Meng wrote: >> This adds a very simple ELF64 loader via program headers, similar >> to load_elf_image_phdr() that we already have. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - update the ELF32 and ELF64 loader comments >> >> cmd/elf.c | 44 +++- >> 1 file changed, 43 insertions(+), 1 deletion(-) > > Reviewed-by: Simon Glass > > I wonder if this should be used within the x86 relocate code? No, I don't think so. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] Android A/B Bootloader support
Hi Alex, The Android A/B bootloader patch series looks good. How far along are you to have this work integrated ? Regards, Stan On 04/02/2017 04:49 PM, Alex Deymo wrote: > An "Android Bootloader" has a lot of requirements about how it should > behave which Android partners must implement. In particular, the new > A/B updates [1] added more requirements and flows to the bootloader > which are not common, on top of the existing flows. > > For example, a few uncommon requirements include: > * Lookup in the BCB (boot control block) whether a "recovery" message >is stored. This is used by the recovery environment when applying a >multi-stage update in the legacy update model (recovery reboots to >recovery again) and for interrumpted factory-reset (a reboot during >the factory reset should continue to reboot into factory reset until >it is done). > * A new "repair" mode. In the A/B model, when none of the slots is >bootable, the device would boot into repair mode, which is often the >same as "bootloader" mode (fastboot). > * Recovery as root: In newer version of AOSP, it is possible to mount >the system image as / without an initramfs, which then frees up the >initramfs in the "boot" partition to hold the "recovery" initramfs. >This is the default for new devices and required for the A/B setup. > > This patchset updates the Android-related headers and introduces new > commands to boot a recent Android build. This work is based on the > bootloader used in the Raspberry Pi in Android Things and extensively > tested there. > > [1] https://source.android.com/devices/tech/ota/ab_updates.html > > > Alex Deymo (6): >image: Update include/android_image.h >image: Implement a function to load Android Images. >cmd: Add 'load_android' command to load Android images. >disk: Return the partition number in part_get_info_by_name() >Initial support for the Android Bootloader flow >cmd: Add "boot_android" command. > > README | 25 ++- > cmd/Kconfig | 19 ++ > cmd/Makefile | 2 + > cmd/boot_android.c | 126 + > cmd/load_android.c | 56 ++ > common/Kconfig | 19 ++ > common/Makefile | 1 + > common/android_bootloader.c | 350 > +++ > common/fb_mmc.c | 6 +- > common/image-android.c | 60 ++ > disk/part.c | 2 +- > include/android_bootloader.h | 48 + > include/android_bootloader_message.h | 174 + > include/android_image.h | 24 ++- > include/image.h | 19 ++ > include/part.h | 3 +- > 16 files changed, 920 insertions(+), 14 deletions(-) > create mode 100644 cmd/boot_android.c > create mode 100644 cmd/load_android.c > create mode 100644 common/android_bootloader.c > create mode 100644 include/android_bootloader.h > create mode 100644 include/android_bootloader_message.h > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] rockchip: rk3288: provide ${fdtfile}
All rk3288 default configs define CONFIG_DEFAULT_DEVICE_TREE.
So we can use it to define ${fdtfile} in rk3288_common.h.
This variable is needed by the distro boot command.
Signed-off-by: Heinrich Schuchardt
---
include/configs/rk3288_common.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 78595b86ec..762a206143 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -73,6 +73,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"fdt_high=0x0fff\0" \
"initrd_high=0x0fff\0" \
+ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"partitions=" PARTS_DEFAULT \
ENV_MEM_LAYOUT_SETTINGS \
ROCKCHIP_DEVICE_SETTINGS \
--
2.14.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 1/2] x86: Add TSC-specific timer functions
Coreboot timestamp functions and Quark memory reference code use
get_tbclk() to get TSC frequency. This will not work if another
early timer is selected.
Add tsc_rate_mhz() function and use it in the code that specifically
needs to get TSC rate regardless of currently selected early timer.
Signed-off-by: Ivan Gorinov
---
arch/x86/cpu/coreboot/timestamp.c | 2 +-
arch/x86/cpu/quark/mrc_util.c | 13 ++---
arch/x86/include/asm/u-boot-x86.h | 2 +-
drivers/timer/tsc_timer.c | 33 -
4 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/arch/x86/cpu/coreboot/timestamp.c
b/arch/x86/cpu/coreboot/timestamp.c
index b382795..05bb214 100644
--- a/arch/x86/cpu/coreboot/timestamp.c
+++ b/arch/x86/cpu/coreboot/timestamp.c
@@ -78,7 +78,7 @@ int timestamp_add_to_bootstage(void)
if (name) {
bootstage_add_record(0, name, BOOTSTAGEF_ALLOC,
tse->entry_stamp /
- get_tbclk_mhz());
+ tsc_rate_mhz());
}
}
diff --git a/arch/x86/cpu/quark/mrc_util.c b/arch/x86/cpu/quark/mrc_util.c
index fac2d72..4794395 100644
--- a/arch/x86/cpu/quark/mrc_util.c
+++ b/arch/x86/cpu/quark/mrc_util.c
@@ -57,19 +57,18 @@ void mrc_post_code(uint8_t major, uint8_t minor)
void delay_n(uint32_t ns)
{
/* 1000 MHz clock has 1ns period --> no conversion required */
- uint64_t final_tsc = rdtsc();
+ uint64_t start_tsc = rdtsc();
+ uint64_t ticks;
- final_tsc += ((get_tbclk_mhz() * ns) / 1000);
-
- while (rdtsc() < final_tsc)
- ;
+ ticks = (tsc_rate_mhz() * ns) / 1000;
+ while (rdtsc() - start_tsc < ticks);
}
/* Delay number of microseconds */
-void delay_u(uint32_t ms)
+void delay_u(uint32_t us)
{
/* 64-bit math is not an option, just use loops */
- while (ms--)
+ while (us--)
delay_n(1000);
}
diff --git a/arch/x86/include/asm/u-boot-x86.h
b/arch/x86/include/asm/u-boot-x86.h
index 187fe5f..de68120 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -29,7 +29,7 @@ int cleanup_before_linux(void);
void timer_isr(void *);
typedef void (timer_fnc_t) (void);
int register_timer_isr (timer_fnc_t *isr_func);
-unsigned long get_tbclk_mhz(void);
+unsigned long tsc_rate_mhz(void);
void timer_set_base(uint64_t base);
int i8254_init(void);
diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
index 9296de6..98cbf12 100644
--- a/drivers/timer/tsc_timer.c
+++ b/drivers/timer/tsc_timer.c
@@ -277,15 +277,12 @@ success:
return delta / 1000;
}
-/* Get the speed of the TSC timer in MHz */
-unsigned notrace long get_tbclk_mhz(void)
-{
- return get_tbclk() / 100;
-}
-
static ulong get_ms_timer(void)
{
- return (get_ticks() * 1000) / get_tbclk();
+ if (gd->arch.clock_rate == 0)
+ return 0;
+
+ return (rdtsc() * 1000) / gd->arch.clock_rate;
}
ulong get_timer(ulong base)
@@ -295,7 +292,10 @@ ulong get_timer(ulong base)
ulong notrace timer_get_us(void)
{
- return get_ticks() / get_tbclk_mhz();
+ if (gd->arch.clock_rate == 0)
+ return 0;
+
+ return (rdtsc() * 100) / gd->arch.clock_rate;
}
ulong timer_get_boot_us(void)
@@ -308,7 +308,7 @@ void __udelay(unsigned long usec)
u64 now = get_ticks();
u64 stop;
- stop = now + usec * get_tbclk_mhz();
+ stop = now + ((u64)usec * gd->arch.clock_rate) / 100;
while ((int64_t)(stop - get_ticks()) > 0)
#if defined(CONFIG_QEMU) && defined(CONFIG_SMP)
@@ -355,6 +355,14 @@ static void tsc_timer_ensure_setup(void)
}
}
+/* Get the speed of the TSC timer in MHz */
+unsigned notrace long tsc_rate_mhz(void)
+{
+ tsc_timer_ensure_setup();
+
+ return gd->arch.clock_rate / 100;
+}
+
static int tsc_timer_probe(struct udevice *dev)
{
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
@@ -365,6 +373,13 @@ static int tsc_timer_probe(struct udevice *dev)
return 0;
}
+int timer_init(void)
+{
+ tsc_timer_ensure_setup();
+
+ return 0;
+}
+
unsigned long notrace timer_early_get_rate(void)
{
tsc_timer_ensure_setup();
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 2/2] timer: Add High Precision Event Timers (HPET) support
Add HPET driver as an alternative timer for x86 (default is TSC).
HPET counter has constant frequency and does not need calibration.
New HPET driver can also be selected as the early timer on x86.
HPET can be selected as the tick timer in the Device Tree "chosen" node:
/include/ "hpet.dtsi"
...
chosen {
tick-timer = "/hpet";
};
Signed-off-by: Ivan Gorinov
---
arch/Kconfig | 1 +
arch/x86/Kconfig | 21 +
arch/x86/dts/hpet.dtsi | 7 ++
common/Kconfig | 1 +
drivers/timer/Kconfig | 9 ++
drivers/timer/Makefile | 1 +
drivers/timer/hpet_timer.c | 209 +
drivers/timer/tsc_timer.c | 8 ++
8 files changed, 257 insertions(+)
create mode 100644 arch/x86/dts/hpet.dtsi
create mode 100644 drivers/timer/hpet_timer.c
diff --git a/arch/Kconfig b/arch/Kconfig
index e599e7a..f904fab 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -105,6 +105,7 @@ config X86
select PCI
select TIMER
select X86_TSC_TIMER
+ imply HPET_TIMER
imply BLK
imply DM_ETH
imply DM_GPIO
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5c23b2c..8f64b95 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -119,6 +119,27 @@ source "arch/x86/cpu/tangier/Kconfig"
# architecture-specific options below
+choice
+ prompt "Select which timer to use early"
+ depends on TIMER_EARLY
+ default X86_EARLY_TIMER_TSC
+
+config X86_EARLY_TIMER_TSC
+ bool "TSC"
+ depends on X86_TSC_TIMER
+ help
+ This selects x86 Time Stamp Counter (TSC) as the early timer.
+ See CONFIG_TIMER_EARLY for the early timer description.
+
+config X86_EARLY_TIMER_HPET
+ bool "HPET"
+ depends on HPET_TIMER
+ help
+ This selects High Precision Event Timers as the early timer.
+ Early HPET base address is specified by CONFIG_HPET_ADDRESS.
+
+endchoice
+
config AHCI
default y
diff --git a/arch/x86/dts/hpet.dtsi b/arch/x86/dts/hpet.dtsi
new file mode 100644
index 000..a74f739
--- /dev/null
+++ b/arch/x86/dts/hpet.dtsi
@@ -0,0 +1,7 @@
+/ {
+ hpet: hpet@fed0 {
+ compatible = "hpet-x86";
+ u-boot,dm-pre-reloc;
+ reg = <0xfed0 0x1000>;
+ };
+};
diff --git a/common/Kconfig b/common/Kconfig
index 03eeeb2..b02384c 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -2,6 +2,7 @@ menu "Boot timing"
config BOOTSTAGE
bool "Boot timing and reporting"
+ select TIMER_EARLY
help
Enable recording of boot time while booting. To use it, insert
calls to bootstage_mark() with a suitable BOOTSTAGE_ID from
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 2c96896..26743b7 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -65,6 +65,15 @@ config X86_TSC_TIMER
help
Select this to enable Time-Stamp Counter (TSC) timer for x86.
+config HPET_TIMER
+ bool "High Precision Event Timers (HPET) support"
+ depends on TIMER
+ default y if X86
+ help
+ Select this to enable High Precision Event Timers (HPET) on x86.
+ HPET main counter increments at constant rate and does not need
+ calibration.
+
config OMAP_TIMER
bool "Omap timer support"
depends on TIMER
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index a6e7832..557fecc 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -8,6 +8,7 @@ obj-y += timer-uclass.o
obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o
obj-$(CONFIG_SANDBOX_TIMER)+= sandbox_timer.o
obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
+obj-$(CONFIG_HPET_TIMER) += hpet_timer.o
obj-$(CONFIG_OMAP_TIMER) += omap-timer.o
obj-$(CONFIG_AST_TIMER)+= ast_timer.o
obj-$(CONFIG_STI_TIMER)+= sti-timer.o
diff --git a/drivers/timer/hpet_timer.c b/drivers/timer/hpet_timer.c
new file mode 100644
index 000..0914dd5
--- /dev/null
+++ b/drivers/timer/hpet_timer.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HPET_PERIOD_REG 0x004
+#define HPET_CONFIG_REG 0x010
+#define HPET_MAIN_COUNT 0x0f0
+
+#define ENABLE_CNF 1
+
+#define HPET_MAX_PERIOD 1
+
+struct hpet_timer_priv {
+ void *regs;
+};
+
+/*
+ * Returns HPET clock frequency in HZ
+ * (rounding to the nearest integer),
+ * or 0 if HPET is not available.
+ */
+static inline u32 get_clock_frequency(void *regs)
+{
+ u64 d = 1000ull;
+ u32 period;
+
+ period = readl(regs + HPET_PERIOD_REG);
+ if (period == 0)
+ return 0;
+ if (period > HPET_MAX_PERIOD)
+ return 0;
+
+ d += period / 2;
+
+ return d / period;
+}
+
+/* Reset and start the main co
[U-Boot] [PATCH v6 0/2] timer: Add High Precision Event Timers (HPET) support
Add HPET driver as an alternative timer for x86 (default is TSC). HPET counter has constant frequency and does not need calibration. This change also makes TSC timer driver optional on x86. New HPET driver can also be selected as the early timer on x86. v6: Added TSC-specific timer functions to use instead of early timer in the code that specifically needs TSC. v5: Using readq() and writeq() for main counter access. v3: Added early timer choice in x86 Kconfig. Ivan Gorinov (2): x86: Add TSC-specific timer functions timer: Add High Precision Event Timers (HPET) support arch/Kconfig | 1 + arch/x86/Kconfig | 21 arch/x86/cpu/coreboot/timestamp.c | 2 +- arch/x86/cpu/quark/mrc_util.c | 13 ++- arch/x86/dts/hpet.dtsi| 7 ++ arch/x86/include/asm/u-boot-x86.h | 2 +- common/Kconfig| 1 + drivers/timer/Kconfig | 9 ++ drivers/timer/Makefile| 1 + drivers/timer/hpet_timer.c| 209 ++ drivers/timer/tsc_timer.c | 39 +-- 11 files changed, 288 insertions(+), 17 deletions(-) create mode 100644 arch/x86/dts/hpet.dtsi create mode 100644 drivers/timer/hpet_timer.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] x86: Rename coreboot-x86 to coreboot
We only use coreboot as a target on x86 platforms, since on ARM platforms
U-Boot always runs as the primary boot loader. Rename the coreboot-x86
platform to reflect this.
Signed-off-by: Simon Glass
---
board/coreboot/coreboot/MAINTAINERS| 2 +-
configs/{coreboot-x86_defconfig => coreboot_defconfig} | 0
doc/README.x86 | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename configs/{coreboot-x86_defconfig => coreboot_defconfig} (100%)
diff --git a/board/coreboot/coreboot/MAINTAINERS
b/board/coreboot/coreboot/MAINTAINERS
index 2736aa0282..188906b080 100644
--- a/board/coreboot/coreboot/MAINTAINERS
+++ b/board/coreboot/coreboot/MAINTAINERS
@@ -3,4 +3,4 @@ M: Simon Glass
S: Maintained
F: board/coreboot/coreboot/
F: include/configs/chromebook_link.h
-F: configs/coreboot-x86_defconfig
+F: configs/coreboot_defconfig
diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot_defconfig
similarity index 100%
rename from configs/coreboot-x86_defconfig
rename to configs/coreboot_defconfig
diff --git a/doc/README.x86 b/doc/README.x86
index 772e8d2a86..b1663a4111 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -46,7 +46,7 @@ Build Instructions for U-Boot as coreboot payload
Building U-Boot as a coreboot payload is just like building U-Boot for targets
on other architectures, like below:
-$ make coreboot-x86_defconfig
+$ make coreboot_defconfig
$ make all
Note this default configuration will build a U-Boot payload for the QEMU board.
--
2.17.0.484.g0c8726318c-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: Update H2 Stout
The H2 Stout port was broken since some time. This patch updates
the H2 Stout port to use modern frameworks, DM, DT probing, SPL
and TPL for the preloading and puts it on par with the M2 Porter
board.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/mach-rmobile/Kconfig.32 | 3 +
board/renesas/stout/Makefile | 6 +-
board/renesas/stout/cpld.c | 16 +-
board/renesas/stout/stout.c | 135 ++-
board/renesas/stout/stout_spl.c | 481 +++
configs/stout_defconfig | 70 +-
include/configs/stout.h | 55 ++---
7 files changed, 597 insertions(+), 169 deletions(-)
create mode 100644 board/renesas/stout/stout_spl.c
diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32
index 97260dfefb..37e0cbab79 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -78,6 +78,9 @@ config TARGET_STOUT
bool "Stout board"
select DM
select DM_SERIAL
+ select SUPPORT_TPL
+ select SUPPORT_SPL
+ select SPL_DM if SPL
endchoice
diff --git a/board/renesas/stout/Makefile b/board/renesas/stout/Makefile
index cb7c61d020..b8875bb7b9 100644
--- a/board/renesas/stout/Makefile
+++ b/board/renesas/stout/Makefile
@@ -8,4 +8,8 @@
# SPDX-License-Identifier: GPL-2.0
#
-obj-y := stout.o cpld.o qos.o ../rcar-common/common.o
+ifdef CONFIG_SPL_BUILD
+obj-y := stout_spl.o
+else
+obj-y := stout.o cpld.o qos.o
+endif
diff --git a/board/renesas/stout/cpld.c b/board/renesas/stout/cpld.c
index 5640e1d28e..fc1e30ca57 100644
--- a/board/renesas/stout/cpld.c
+++ b/board/renesas/stout/cpld.c
@@ -13,10 +13,10 @@
#include
#include "cpld.h"
-#define SCLK GPIO_GP_3_24
-#define SSTBZ GPIO_GP_3_25
-#define MOSI GPIO_GP_3_26
-#define MISO GPIO_GP_3_27
+#define SCLK (92 + 24)
+#define SSTBZ (92 + 25)
+#define MOSI (92 + 26)
+#define MISO (92 + 27)
#define CPLD_ADDR_MODE 0x00 /* RW */
#define CPLD_ADDR_MUX 0x01 /* RW */
@@ -91,10 +91,10 @@ void cpld_init(void)
val |= PUPR3_SD3_DAT1;
writel(val, PUPR3);
- gpio_request(SCLK, NULL);
- gpio_request(SSTBZ, NULL);
- gpio_request(MOSI, NULL);
- gpio_request(MISO, NULL);
+ gpio_request(SCLK, "SCLK");
+ gpio_request(SSTBZ, "SSTBZ");
+ gpio_request(MOSI, "MOSI");
+ gpio_request(MISO, "MISO");
gpio_direction_output(SCLK, 0);
gpio_direction_output(SSTBZ, 1);
diff --git a/board/renesas/stout/stout.c b/board/renesas/stout/stout.c
index 3cb16db10f..d7e81292a0 100644
--- a/board/renesas/stout/stout.c
+++ b/board/renesas/stout/stout.c
@@ -59,14 +59,7 @@ void s_init(void)
qos_init();
}
-#define TMU0_MSTP125 (1 << 25)
-#define SCIFA0_MSTP204 (1 << 4)
-#define SDHI0_MSTP314 (1 << 14)
-#define SDHI2_MSTP312 (1 << 12)
-#define ETHER_MSTP813 (1 << 13)
-
-#define MSTPSR30xE6150048
-#define SMSTPCR3 0xE615013C
+#define TMU0_MSTP125 BIT(25)
#define SD2CKCR0xE6150078
#define SD2_97500KHZ 0x7
@@ -75,12 +68,6 @@ int board_early_init_f(void)
{
/* TMU0 */
mstp_clrbits_le32(MSTPSR1, SMSTPCR1, TMU0_MSTP125);
- /* SCIFA0 */
- mstp_clrbits_le32(MSTPSR2, SMSTPCR2, SCIFA0_MSTP204);
- /* ETHER */
- mstp_clrbits_le32(MSTPSR8, SMSTPCR8, ETHER_MSTP813);
- /* SDHI0,2 */
- mstp_clrbits_le32(MSTPSR3, SMSTPCR3, SDHI0_MSTP314 | SDHI2_MSTP312);
/*
* SD0 clock is set to 97.5MHz by default.
@@ -91,66 +78,37 @@ int board_early_init_f(void)
return 0;
}
+#define ETHERNET_PHY_RESET 123 /* GPIO 3 31 */
+
int board_init(void)
{
/* adress of boot parameters */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
- /* Init PFC controller */
- r8a7790_pinmux_init();
-
cpld_init();
-#ifdef CONFIG_SH_ETHER
- /* ETHER Enable */
- gpio_request(GPIO_FN_ETH_CRS_DV, NULL);
- gpio_request(GPIO_FN_ETH_RX_ER, NULL);
- gpio_request(GPIO_FN_ETH_RXD0, NULL);
- gpio_request(GPIO_FN_ETH_RXD1, NULL);
- gpio_request(GPIO_FN_ETH_LINK, NULL);
- gpio_request(GPIO_FN_ETH_REF_CLK, NULL);
- gpio_request(GPIO_FN_ETH_MDIO, NULL);
- gpio_request(GPIO_FN_ETH_TXD1, NULL);
- gpio_request(GPIO_FN_ETH_TX_EN, NULL);
- gpio_request(GPIO_FN_ETH_MAGIC, NULL);
- gpio_request(GPIO_FN_ETH_TXD0, NULL);
- gpio_request(GPIO_FN_ETH_MDC, NULL);
- gpio_request(GPIO_FN_IRQ1, NULL);
-
- gpio_request(GPIO_GP_3_31, NULL); /* PHY_RST */
- gpio_direction_output(GPIO_GP_3_31, 0);
+ /* Force ethernet PHY out of reset */
+ gpio_request(ETHERNET_PHY_RESET, "phy_reset");
+ gpio_direction_output(ETHERNET_PHY_RESET, 0);
mdelay(20);
- gpio_set_value(GPIO_GP_3
[U-Boot] [PATCH] ARM: rmobile: Fix LBSC programming offset on M2 Porter
The offset of CSWCRx starts at 0x30, fix this.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
board/renesas/porter/porter_spl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/renesas/porter/porter_spl.c
b/board/renesas/porter/porter_spl.c
index f711aa9c35..4b4dd4d4aa 100644
--- a/board/renesas/porter/porter_spl.c
+++ b/board/renesas/porter/porter_spl.c
@@ -169,8 +169,8 @@ static void tpl_init_lbsc(void)
static const struct reg_config lbsc_config[] = {
{ 0x00, 0x0020 },
{ 0x08, 0x2020 },
- { 0x10, 0x2a103320 },
- { 0x18, 0xff70ff70 },
+ { 0x30, 0x2a103320 },
+ { 0x38, 0xff70ff70 },
};
static const u16 lbsc_offs[] = {
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: Enable SCIFA0 early on H2 Stout
The H2 Stout uses SCIFA0 for serial console, make sure it is
available very early on when probing from DT.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7790-stout-u-boot.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/r8a7790-stout-u-boot.dts
b/arch/arm/dts/r8a7790-stout-u-boot.dts
index 12092fcf5d..d2b7d371aa 100644
--- a/arch/arm/dts/r8a7790-stout-u-boot.dts
+++ b/arch/arm/dts/r8a7790-stout-u-boot.dts
@@ -8,3 +8,7 @@
#include "r8a7790-stout.dts"
#include "r8a7790-u-boot.dtsi"
+
+&scifa0 {
+ u-boot,dm-pre-reloc;
+};
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] serial: sh: Add SCIFA0 address entry
Add the SCIFA0 address entry so it can be used in TPL if needed
due to size restrictions.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
drivers/serial/serial_sh.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index a17698f90e..5f4ace7848 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -270,6 +270,8 @@ U_BOOT_DRIVER(serial_sh) = {
# define SCIF_BASE SCIF6_BASE
#elif defined(CONFIG_CONS_SCIF7)
# define SCIF_BASE SCIF7_BASE
+#elif defined(CONFIG_CONS_SCIFA0)
+# define SCIF_BASE SCIFA0_BASE
#else
# error "Default SCIF doesn't set."
#endif
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: sh_eth: Add remaining Gen2 DT compatible
Add compatible strings for R8A7790, R8A7793 and R8A7794, since the
contemporary DTs use those don't have a generic match value.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
Cc: Joe Hershberger
---
drivers/net/sh_eth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index e3416f3391..cb3970e051 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -906,7 +906,10 @@ int sh_ether_ofdata_to_platdata(struct udevice *dev)
}
static const struct udevice_id sh_ether_ids[] = {
+ { .compatible = "renesas,ether-r8a7790" },
{ .compatible = "renesas,ether-r8a7791" },
+ { .compatible = "renesas,ether-r8a7793" },
+ { .compatible = "renesas,ether-r8a7794" },
{ }
};
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] clk: renesas: Minor clean up of the R8A7790 clock driver
The initconst is not used in U-Boot, drop it. The r8a7790_crit_mod_clks
is also not used in U-Boot, so drop it too.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
drivers/clk/renesas/r8a7790-cpg-mssr.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/renesas/r8a7790-cpg-mssr.c
b/drivers/clk/renesas/r8a7790-cpg-mssr.c
index 33ab9ad7cc..360c02c5fd 100644
--- a/drivers/clk/renesas/r8a7790-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7790-cpg-mssr.c
@@ -40,7 +40,7 @@ enum clk_ids {
MOD_CLK_BASE
};
-static const struct cpg_core_clk r8a7790_core_clks[] __initconst = {
+static const struct cpg_core_clk r8a7790_core_clks[] = {
/* External Clock Inputs */
DEF_INPUT("extal", CLK_EXTAL),
DEF_INPUT("usb_extal", CLK_USB_EXTAL),
@@ -90,7 +90,7 @@ static const struct cpg_core_clk r8a7790_core_clks[]
__initconst = {
DEF_DIV6P1("ssprs", R8A7790_CLK_SSPRS, CLK_PLL1_DIV2, 0x24c),
};
-static const struct mssr_mod_clk r8a7790_mod_clks[] __initconst = {
+static const struct mssr_mod_clk r8a7790_mod_clks[] = {
DEF_MOD("msiof0", 0, R8A7790_CLK_MP),
DEF_MOD("vcp1", 100, R8A7790_CLK_ZS),
DEF_MOD("vcp0", 101, R8A7790_CLK_ZS),
@@ -209,10 +209,6 @@ static const struct mssr_mod_clk r8a7790_mod_clks[]
__initconst = {
DEF_MOD("scu-src0", 1031, MOD_CLK_ID(1017)),
};
-static const unsigned int r8a7790_crit_mod_clks[] __initconst = {
- MOD_CLK_ID(408),/* INTC-SYS (GIC) */
-};
-
/*
* CPG Clock Data
*/
@@ -235,7 +231,7 @@ static const unsigned int r8a7790_crit_mod_clks[]
__initconst = {
#define CPG_PLL_CONFIG_INDEX(md) md) & BIT(14)) >> 12) | \
(((md) & BIT(13)) >> 12) | \
(((md) & BIT(19)) >> 19))
-static const struct rcar_gen2_cpg_pll_config cpg_pll_configs[8] __initconst = {
+static const struct rcar_gen2_cpg_pll_config cpg_pll_configs[8] = {
{ 1, 208, 106 }, { 1, 208, 88 }, { 1, 156, 80 }, { 1, 156, 66 },
{ 2, 240, 122 }, { 2, 240, 102 }, { 2, 208, 106 }, { 2, 208, 88 },
};
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] libfdt: Safer access to strings section
On Thu, Apr 12, 2018 at 02:01:05PM +1000, David Gibson wrote: > On Tue, Apr 10, 2018 at 06:36:06PM -0400, Tom Rini wrote: > > On Tue, Apr 10, 2018 at 10:42:45AM -0400, Simon Glass wrote: > > > +U-Boot, Tom, Masahiro > > > > > > Hi David, > > > > > > On 10 April 2018 at 01:22, David Gibson > > > wrote: > > > > On Wed, Apr 04, 2018 at 01:21:10AM +0800, Simon Glass wrote: > > > >> Hi David, > > > >> > > > >> On 3 April 2018 at 23:02, David Gibson > > > >> wrote: > > > >> > > > > >> > On Fri, Mar 30, 2018 at 04:42:21PM +0800, Simon Glass wrote: > > > >> > > Hi David, > > > >> > > > > > >> > > On 26 March 2018 at 07:25, David Gibson > > > >> > > wrote: > > > >> > > > fdt_string() is used to retrieve strings from a DT blob's > > > >> > > > strings section. > > > >> > > > It's rarely used directly, but is widely used internally. > > > >> > > > > > > >> > > > However, it doesn't do any bounds checking, which means in the > > > >> > > > case of a > > > >> > > > corrupted blob it could access bad memory, which libfdt is > > > >> > > > supposed to > > > >> > > > avoid. > > > >> > > > > > > >> > > > This write a safe alternative to fdt_string, fdt_get_string(). > > > >> > > > It checks > > > >> > > > both that the given offset is within the string section and that > > > >> > > > the string > > > >> > > > it points to is properly \0 terminated within the section. It > > > >> > > > also returns > > > >> > > > the string's length as a convenience (since it needs to > > > >> > > > determine to do the > > > >> > > > checks anyway). > > > >> > > > > > > >> > > > fdt_string() is rewritten in terms of fdt_get_string() for > > > >> > > > compatibility. > > > >> > > > > > > >> > > > Most of the diff here is actually testing infrastructure. > > > >> > > > > > > >> > > > Signed-off-by: David Gibson > > > >> > > > --- > > > >> > > > libfdt/fdt_ro.c | 61 > > > >> > > > +++-- > > > >> > > > libfdt/libfdt.h | 18 ++- > > > >> > > > libfdt/version.lds | 2 +- > > > >> > > > tests/.gitignore | 1 + > > > >> > > > tests/Makefile.tests | 2 +- > > > >> > > > tests/run_tests.sh | 1 + > > > >> > > > tests/testdata.h | 1 + > > > >> > > > tests/testutils.c| 11 +-- > > > >> > > > tests/trees.S| 26 > > > >> > > > tests/truncated_string.c | 79 > > > >> > > > > > > >> > > > 10 files changed, 193 insertions(+), 9 deletions(-) > > > >> > > > create mode 100644 tests/truncated_string.c > > > >> > > > > > >> > > Similar code-size quesiton here. It looks like a lot of checking > > > >> > > code. > > > >> > > Can we have an option to remove it? > > > >> > > > > >> > Again, I'm disinclined without a concrete example of a problem. Fwiw > > > >> > the code size change is +276 bytes on my setup. > > > >> > > > >> That might not sound like a lot, but the overhead of DT in U-Boot is > > > >> about 3KB, so this adds nearly 10%. > > > > > > > > Hm. And how much is it compared to the whole U-Boot blob? > > > > > > > >> The specific problem is that when U-Boot SPL gets too big boards don't > > > >> boot. Because we take the upstream libfdt this will affect U-Boot. > > > >> > > > >> Do you have any thoughts on how we could avoid this size increase? > > > > > > > > So, again, I'm very disinclined to prioritize size over memory safety > > > > without a *concrete* example. i.e. "We hit this specific problem with > > > > size on this specific board that we were really using" rather than > > > > just "it might be a problem". > > > > I'm either failing in my Google-fu or is there not an easy way to grab > > the patches from patchwork/similar? But, if you shoot me the series > > off-list, I can tell you how much U-Boot targets grow here (we can use > > the same script as the kernel to re-sync sources back in, so I can give > > you a before/after). But as Simon notes, we have a number of platforms > > that need to use (parts of) libfdt and stick to ~30KiB or less in total, > > sometimes including some memory for stack/etc and we've long been using > > -ffunction-sections/etc (the latest round of trying to use LTO has me > > thinking maybe we can see if that's a valid option finally, but that's > > an aside). Thanks! > > We don't have a patchwork for these lists AFAIK, but you can get my > draft branch from: > > https://github.com/dgibson/dtc/tree/safety OK, thanks. So, I used scripts/dtc/update-dtc-source.sh to re-sync us first with current master, and then with the safety branch, and boy-howdy, are there a lot of warning changes and additions :) For the record, in U-Boot you can use the buildman tool (./tools/buildman/buildman) to build a series for a set of targets and get size change for each commit. I did: ./tools/buildman/buildman -o /tmp/libfdt-test -b master -SCdvel \ 'arc|arm|sandbox|x86|aarch64|powerpc|avr32|m68k|nios2|sh4|mips|xtensa|ris
[U-Boot] [PATCH 1/1] sunxi: R40: add support for gigabit ethernet
This patch adds support for the gigabit interface found on the
Allwinner R40/V40 CPU.
It does not support the 100Mbit interface (EMAC).
Fixes:
- add GMAC gating clock and reset control
- GPIO mux settings
- device tree entries
Tested on BananaPi M2 Berry (R40), custom board (V40).
Signed-off-by: Lothar Felten
---
arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts | 14 ++
arch/arm/dts/sun8i-r40.dtsi | 37 +++
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 10 +++-
board/sunxi/gmac.c| 5 +++-
configs/Bananapi_M2_Ultra_defconfig | 4 +++
drivers/net/sun8i_emac.c | 2 ++
6 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
index ab471ab0bf..25f2112fbf 100644
--- a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -67,3 +67,17 @@
pinctrl-0 = <&uart0_pb_pins>;
status = "okay";
};
+
+&gmac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii>;
+ status = "okay";
+ phy-handle = <&rgmii_phy>;
+};
+
+&mdio {
+ rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
diff --git a/arch/arm/dts/sun8i-r40.dtsi b/arch/arm/dts/sun8i-r40.dtsi
index 48ec2e855a..93bf811014 100644
--- a/arch/arm/dts/sun8i-r40.dtsi
+++ b/arch/arm/dts/sun8i-r40.dtsi
@@ -114,6 +114,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon@1c0 {
+ compatible = "allwinner,sun8i-r40-system-controller",
+ "syscon";
+ reg = <0x01c0 0x1000>;
+ };
+
pio: pinctrl@1c20800 {
compatible = "allwinner,sun8i-r40-pinctrl";
reg = <0x01c20800 0x400>;
@@ -126,6 +132,15 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
+ gmac_pins_rgmii: gmac_rgmii {
+ pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA10",
+ "PA11", "PA12", "PA13",
+ "PA15", "PA16";
+ function = "gmac";
+ };
+
i2c0_pins: i2c0_pins {
pins = "PB0", "PB1";
function = "i2c0";
@@ -159,6 +174,28 @@
#size-cells = <0>;
};
+ gmac: ethernet@01c5 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c5 0x2000>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ clocks = <&osc24M>, <&osc24M>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii>;
+ phy-mode = "rgmii";
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index d35aa479f7..5af8c64fa2 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -61,7 +61,11 @@ struct sunxi_ccm_reg {
u32 reserved11;
u32 sata_clk_cfg; /* 0xc8 SATA clock control (R40 only) */
u32 usb_clk_cfg;/* 0xcc USB clock control */
- u32 gmac_clk_cfg; /* 0xd0 GMAC clock control */
+#ifndef CONFIG_MACH_SUN8I_R40
+ u32 gmac_clk_cfg; /* 0xd0 GMAC clock control (not for R40) */
+#else
+ u32 cir0_clk_cfg; /* 0xd0 CIR0 clock control (R40 only) */
+#endif
u32 reserved12[7];
u32 mdfs_clk_cfg; /* 0xf0 MDFS clock control */
u32 dram_clk_cfg; /* 0xf4 DRAM configuration clock control */
@@ -104,7 +108,11 @@ struct sunxi_ccm_reg {
u32 mtc_clk_cfg;/* 0x158 MTC module clock */
u32 mbus0_clk_cfg; /* 0x15c MBUS0 module clock */
Re: [U-Boot] [PATCH] fit: skip signature verification if board request
Hi,
On 11 April 2018 at 09:13, Jun Nie wrote:
> It may be unnecessary to check signature on unlocked board.
> Get the hint from platform specific code to support secure boot
> and non-secure boot with the same binary, so that boot is not
> blocked if board is not locked and has no key for signature
> verification.
>
> Signed-off-by: Jun Nie
> ---
> common/image-sig.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/common/image-sig.c b/common/image-sig.c
> index d9f712f..f3d1252 100644
> --- a/common/image-sig.c
> +++ b/common/image-sig.c
> @@ -151,6 +151,11 @@ struct image_region *fit_region_make_list(const void
> *fit,
> return region;
> }
>
> +int __attribute__((weak)) fit_board_skip_sig_verification(void)
> +{
> + return 0;
> +}
> +
> static int fit_image_setup_verify(struct image_sign_info *info,
> const void *fit, int noffset, int required_keynode,
> char **err_msgp)
> @@ -188,6 +193,12 @@ int fit_image_check_sig(const void *fit, int noffset,
> const void *data,
> uint8_t *fit_value;
> int fit_value_len;
>
> + /* Skip verification if board says that */
> + if (fit_board_skip_sig_verification()) {
> + printf("signature check skipped\n");
> + return 0;
> + }
Instead of a weak function can you please add a parameter to this
function (perhaps a flags word?) and a add test for this case to the
test?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: zynq_gem: Use max-speed property from dt
On Thu, Apr 12, 2018 at 5:22 AM, Michal Simek wrote: > From: Siva Durga Prasad Paladugu > > Add support to use max-speed property from dt for > determining the supported speed. Use 1000Mbps as > default. > > Signed-off-by: Siva Durga Prasad Paladugu > Signed-off-by: Michal Simek Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Relocate env drivers if manual reloc is required
Hi Michal,
On 12 April 2018 at 04:26, Michal Simek wrote:
> From: Siva Durga Prasad Paladugu
>
> Relocate env drivers if manual relocation is enabled. This
> patch fixes the issue of u-boot hang incase if env is
> present in any of the flash devices.
>
> Signed-off-by: Siva Durga Prasad Paladugu
> Signed-off-by: Michal Simek
> ---
>
> env/common.c | 1 +
> env/env.c | 21 +
> include/environment.h | 5 +
> 3 files changed, 27 insertions(+)
Reviewed-by: Simon Glass
Please see below
>
> diff --git a/env/common.c b/env/common.c
> index f21ff7009695..d282868ee51b 100644
> --- a/env/common.c
> +++ b/env/common.c
> @@ -227,6 +227,7 @@ void env_relocate(void)
> {
> #if defined(CONFIG_NEEDS_MANUAL_RELOC)
> env_reloc();
> + fix_envdriver();
> env_htab.change_ok += gd->reloc_off;
> #endif
> if (gd->env_valid == ENV_INVALID) {
> diff --git a/env/env.c b/env/env.c
> index 3795dbc24e2b..15a0597100f4 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -10,6 +10,27 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#if defined(CONFIG_NEEDS_MANUAL_RELOC)
> +void fix_envdriver(void)
How about env_fix_drivers() ? The env_ prefix is nice for something in
the environment code.
[..]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] timer: Add High Precision Event Timers (HPET) support
Hi,
On 8 April 2018 at 19:22, Bin Meng wrote:
> Hi Ivan,
>
> On Sat, Apr 7, 2018 at 3:18 AM, Ivan Gorinov wrote:
>> Add HPET driver as an alternative timer for x86 (default is TSC).
>> HPET counter has constant frequency and does not need calibration.
>> This change also makes TSC timer driver optional on x86.
>> New HPET driver can also be selected as the early timer on x86.
>>
>> HPET can be selected as the tick timer in the Device Tree "chosen" node:
>>
>> /include/ "hpet.dtsi"
>>
>> ...
>>
>> chosen {
>> tick-timer = "/hpet";
>> };
>>
>> Signed-off-by: Ivan Gorinov
>> ---
>> arch/Kconfig | 2 +-
>> arch/x86/Kconfig | 21 ++
>> arch/x86/dts/hpet.dtsi | 7 ++
>> drivers/timer/Kconfig | 9 +++
>> drivers/timer/Makefile | 1 +
>> drivers/timer/hpet_timer.c | 179
>> +
>> drivers/timer/tsc_timer.c | 8 ++
>> 7 files changed, 226 insertions(+), 1 deletion(-)
>> create mode 100644 arch/x86/dts/hpet.dtsi
>> create mode 100644 drivers/timer/hpet_timer.c
>>
[..]
>> diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
>> index 9296de6..bd0e75c 100644
>> --- a/drivers/timer/tsc_timer.c
>> +++ b/drivers/timer/tsc_timer.c
>> @@ -277,6 +277,8 @@ success:
>> return delta / 1000;
>> }
>>
>> +#ifdef CONFIG_X86_EARLY_TIMER_TSC
>
> Why do we surround the following APIs with CONFIG_X86_EARLY_TIMER_TSC?
> These APIs are generic U-Boot timer APIs. If we select
> CONFIG_X86_EARLY_TIMER_HPET, these APIs are not available and will
> cause build error.
>
> Simon, do you think we should fix such in the timer uclass driver?
We should not have arch-specific code in the uclass, or in any generic driver.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/18] bios: vesa: Guard setting vesa mode with CONFIG_FRAMEBUFFER_SET_VESA_MODE
Hi Bin, On 11 April 2018 at 23:02, Bin Meng wrote: > If CONFIG_FRAMEBUFFER_SET_VESA_MODE is not set, don't switch > graphics card to VESA mode. This applies to both native mode > and emulator mode of running the VGA BIOS. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/lib/bios.c | 4 > drivers/bios_emulator/atibios.c | 4 > 2 files changed, 8 insertions(+) Could this use if() instead of #ifdef ? Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] core: Add function to get device for ofnode
Hi Mario,
On 10 April 2018 at 05:34, Mario Six wrote:
> Hi Simon,
>
> On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass wrote:
>> Hi Mario,
>>
>> On 28 March 2018 at 20:37, Mario Six wrote:
>>> It's sometimes useful to get the device associated with a given ofnode.
>>> Implement a function to implement this lookup operation.
>>
>> Where would you use this? Can you not use phandles to find the device?
>> Or uclass_get_device_by_ofnode() ?
>>
>
> The function is used with the dev_{enable,disable}_by_path in the next patch:
> If I used any of the uclass_* functions or similar, the device would be
> probed,
> which is not what I want, since the device may not actually be physically
> present.
So how about using uclass_find_device_by_ofnode() ?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/18] elf: Add a very simple ELF64 loader
On 11 April 2018 at 23:02, Bin Meng wrote: > This adds a very simple ELF64 loader via program headers, similar > to load_elf_image_phdr() that we already have. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - update the ELF32 and ELF64 loader comments > > cmd/elf.c | 44 +++- > 1 file changed, 43 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass I wonder if this should be used within the x86 relocate code? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/18] bootvx: Refactor the bootline copy codes a little bit
On 11 April 2018 at 23:02, Bin Meng wrote: > There is a small duplication in do_bootvx() that does the bootline > copy. Refactor this a little bit to make it simpler. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > cmd/elf.c | 15 +-- > 1 file changed, 5 insertions(+), 10 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/18] bootvx: x86: Make VxWorks EFI console driver happy
On 11 April 2018 at 23:02, Bin Meng wrote: > When booting from EFI BIOS, VxWorks bootloader stores the EFI GOP > framebuffer info at a pre-defined offset @ 0x6100. When VxWorks > kernel boots up, its EFI console driver tries to find such a block > and if the signature matches, the framebuffer information will be > used to initialize the driver. > > However it is not necessary to prepare an EFI environment for > VxWorks's EFI console driver to function (eg: EFI loader in > U-Boot). If U-Boot has already initialized the graphics card and > set it to a VESA mode that is compatible with EFI GOP, we can > simply prepare such a block for VxWorks. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > cmd/elf.c | 19 +++ > include/vxworks.h | 26 ++ > 2 files changed, 45 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/18] x86: Change default FRAMEBUFFER_VESA_MODE of some boards
On 11 April 2018 at 23:02, Bin Meng wrote: > This changes some boards' default FRAMEBUFFER_VESA_MODE to use 32-bit > pixel format for better VxWorks compatibility. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > configs/bayleybay_defconfig | 2 +- > configs/minnowmax_defconfig | 2 +- > configs/qemu-x86_64_defconfig| 2 +- > configs/qemu-x86_defconfig | 2 +- > configs/qemu-x86_efi_payload32_defconfig | 2 +- > configs/qemu-x86_efi_payload64_defconfig | 2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/18] bootvx: x86: Explicitly clear the bootloader image size
On 11 April 2018 at 23:02, Bin Meng wrote: > VxWorks bootloader stores its size at a pre-defined offset @ 0x5004. > Later when VxWorks kernel boots up and system memory information is > retrieved from the E820 table, the bootloader size will be subtracted > from the total system memory size to calculate the size of available > memory for the OS. > > Explicitly clear the bootloader image size otherwise if memory > at this offset happens to contain some garbage data, the final > available memory size for the kernel is insane. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > cmd/elf.c | 7 +++ > include/vxworks.h | 9 + > 2 files changed, 16 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/18] elf: Add ELF64 related structure defines
On 11 April 2018 at 23:02, Bin Meng wrote: > This adds ELF header, program header and section header structure > defines for the 64-bit ELF image. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > include/elf.h | 43 +++ > 1 file changed, 43 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] core: Add functions to set properties in live-tree
Hi Mario,
On 10 April 2018 at 05:23, Mario Six wrote:
> Hi Simon,
>
> On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass wrote:
>> Hi Mario,
>>
>> On 28 March 2018 at 20:37, Mario Six wrote:
>>> Implement a set of functions to manipulate properties in a live device
>>> tree:
>>>
>>> * ofnode_set_property() to set generic properties of a node
>>> * ofnode_write_string() to set string properties of a node
>>> * ofnode_enable() to enable a node
>>> * ofnode_disable() to disable a node
>>>
>>
>> Please add a test for these functions.
>>
>>> Signed-off-by: Mario Six
>>> ---
>>> drivers/core/ofnode.c | 58
>>> +++
>>> include/dm/ofnode.h | 49 +++
>>> 2 files changed, 107 insertions(+)
>>>
>>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
>>> index ca002063b3..90d05aa559 100644
>>> --- a/drivers/core/ofnode.c
>>> +++ b/drivers/core/ofnode.c
>>> @@ -699,3 +699,61 @@ u64 ofnode_translate_address(ofnode node, const
>>> fdt32_t *in_addr)
>>> else
>>> return fdt_translate_address(gd->fdt_blob,
>>> ofnode_to_offset(node), in_addr);
>>> }
>>> +
>>> +#ifdef CONFIG_OF_LIVE
>>
>> Is this needed?
>>
>
> See below, these functions don't make sense if there is no livetree.
Right, but they should still compile?
>
>>> +int ofnode_set_property(ofnode node, const char *propname, int len,
>>> + const void *value)
>>> +{
>>> + const struct device_node *np = ofnode_to_np(node);
>>> + struct property *pp;
>>> + struct property *new;
>>> +
>>> + if (!np)
>>> + return -EINVAL;
>>> +
>>> + for (pp = np->properties; pp; pp = pp->next) {
>>> + if (strcmp(pp->name, propname) == 0) {
>>> + /* Property exists -> change value */
>>> + pp->value = (void *)value;
>>> + pp->length = len;
>>> + return 0;
>>> + }
>>> + }
>>> +
>>> + /* Property does not exist -> append new property */
>>> + new = malloc(sizeof(struct property));
>>> +
>>> + new->name = strdup(propname);
>>> + new->value = malloc(len);
>>> + memcpy(new->value, value, len);
>>> + new->length = len;
>>> + new->next = NULL;
>>> +
>>> + pp->next = new;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +int ofnode_write_string(ofnode node, const char *propname, const char
>>> *value)
>>> +{
>>> + assert(ofnode_valid(node));
>>
>> What does this function do if livetree is not enabled?
>>
>
> The idea was to not make them available if livetree is not enabled (hence the
> #ifdef CONFIG_OF_LIVE).
>
> Making them nops in case livetree is not available would work as well if
> that's preferable.
Yes. Then they could return -ENOSYS, for example. Then we at least
have a consistent API for both live/flat tree, instead of them
splitting away from each other.
>
>>> + debug("%s: %s = %s", __func__, propname, value);
>>> +
>>> + return ofnode_set_property(node, propname, strlen(value) + 1,
>>> value);
>>> +}
>>> +
>>> +int ofnode_enable(ofnode node)
>>> +{
>>> + assert(ofnode_valid(node));
>>> +
>>> + return ofnode_write_string(node, "status", "okay");
>>> +}
>>> +
>>> +int ofnode_disable(ofnode node)
>>> +{
>>> + assert(ofnode_valid(node));
>>> +
>>> + return ofnode_write_string(node, "status", "disable");
>>> +}
>>> +
>>> +#endif
>>> diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
>>> index aec205eb80..e82ebf19c5 100644
>>> --- a/include/dm/ofnode.h
>>> +++ b/include/dm/ofnode.h
>>> @@ -689,4 +689,53 @@ int ofnode_read_resource_byname(ofnode node, const
>>> char *name,
>>> * @return the translated address; OF_BAD_ADDR on error
>>> */
>>> u64 ofnode_translate_address(ofnode node, const fdt32_t *in_addr);
>>> +
>>> +#ifdef CONFIG_OF_LIVE
>>> +
>>> +/**
>>> + * ofnode_set_property() - Set a property of a ofnode
>>> + *
>>> + * @node: The node for whose property should be set
>>> + * @propname: The name of the property to set
>>> + * @len: The length of the new value of the property
>>> + * @value: The new value of the property
>>> + * @return 0 if successful, -ve on error
>>> + */
>>> +int ofnode_set_property(ofnode node, const char *propname, int len,
>>> + const void *value);
>>
>> We should think about consistency here. Maybe
>>
>> ofnode_write_prop()?
Yes
>>
>>> +
>>> +/**
>>> + * ofnode_write_string() - Set a string property of a ofnode
>>> + *
>>> + * @node: The node for whose string property should be set
>>> + * @propname: The name of the string property to set
>>> + * @value: The new value of the string property
>>> + * @return 0 if successful, -ve on error
>>> + */
>>> +int ofnode_write_string(ofnode node, const char *propname, const char
>>> *value);
>>> +
>>> +/**
>>> + * ofnode_enable() - Enable a device tree node given b
Re: [U-Boot] [PATCH v2 11/18] video: vesa: Change default FRAMEBUFFER_VESA_MODE
On 11 April 2018 at 23:02, Bin Meng wrote: > This changes the default FRAMEBUFFER_VESA_MODE to use 32-bit pixel > format for better VxWorks compatibility. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > drivers/video/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/18] pci: video: Only print out when everything is OK
On 11 April 2018 at 23:02, Bin Meng wrote: > If video initialization fails, the "Video:" output message will be > mixed with the next console log. Change to print out such message > only when everything is OK, which improves the boot log readability. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > drivers/pci/pci_rom.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm64: Add SMC and HVC commands
Hi, On 12 April 2018 at 03:20, Michalis Pappas wrote: > Okay, i see. The change is the replacement of the dependency of ARM64 to > ARM_SMCCC in Kconfig. > > If you think it's necessary to issue a v4 and document the changes properly > please let me know and I'll do so. Yes please. > > Michalis > > > On 04/11/2018 03:36 PM, Simon Glass wrote: >> >> On 9 April 2018 at 09:17, Michalis Pappas wrote: >>> >>> This patch adds smc and hvc commands, that allow issuing Secure Monitor >>> Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention. >>> >>> Add Kconfig items to allow each command can be individually enabled. >>> >>> Signed-off-by: Michalis Pappas >>> --- >>> >>> cmd/Kconfig | 14 ++ >>> cmd/Makefile | 2 ++ >>> cmd/smccc.c | 72 >>> 3 files changed, 88 insertions(+) >>> create mode 100644 cmd/smccc.c >>> >> Reviewed-by: Simon Glass >> >> But you need a change list > > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] reset: fix bulk API when DM_RESET is disabled
On 12 April 2018 at 02:03, Neil Armstrong wrote:
> In the commit "reset: Add get/assert/deassert/release for bulk of reset
> signals"
> the disabled reset_release_bulk() and reset_get_bulk() used the wrong
> struct clk_bulk instead of struct reset_ctl_bulk.
>
> Fixes: 0c28233903b5 ("reset: Add get/assert/deassert/release for bulk of
> reset signals")
> Reported-by: Jean-Jacques Hiblot
> Signed-off-by: Neil Armstrong
> ---
> include/reset.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass
We don't have build coverage for this at the moment I suppose. It
would be a bit of pain to add that with sandbox, although I wonder if
it could be done with some horrible #define hackery in a C file that
includes this header?
- Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] video_display: Add Xilinx LogiCore DP TX
Hi Mario, On 11 April 2018 at 01:27, Mario Six wrote: > Hi Simon, > > On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: >> Hi Mario, >> >> On 28 March 2018 at 20:40, Mario Six wrote: >>> Add a driver for the Xilinx LogiCORE DisplayPort IP core. >>> >>> Signed-off-by: Mario Six >>> --- >>> drivers/video/Kconfig|8 + >>> drivers/video/Makefile |1 + >>> drivers/video/logicore_dp_dpcd.h | 342 ++ >>> drivers/video/logicore_dp_tx.c | 1974 >>> ++ >>> drivers/video/logicore_dp_tx.h | 40 + >>> drivers/video/logicore_dp_tx_regif.h | 365 +++ >>> 6 files changed, 2730 insertions(+) >>> create mode 100644 drivers/video/logicore_dp_dpcd.h >>> create mode 100644 drivers/video/logicore_dp_tx.c >>> create mode 100644 drivers/video/logicore_dp_tx.h >>> create mode 100644 drivers/video/logicore_dp_tx_regif.h >> >> Is it possible to have common code with the other DP drivers? >> > > While the DP transmitters, of course, all do similar things (e.g. they all > eventually set a lane count), the implementation details differ greatly, and I > think trying to merge them would only make things more confusing, since the > drivers tend to be pretty elaborate (looking at the exynos driver, for > example). OK. Are they merged in Linux? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Mario, On 11 April 2018 at 00:39, Mario Six wrote: > Hi Simon, > > On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: >> Hi, >> >> On 28 March 2018 at 20:38, Mario Six wrote: >>> Add a cpu_print_info function to the CPU uclass to emulate the behavior >>> of some current non-DM drivers (e.g. MPC83xx) to print CPU information >>> during startup. >>> >>> Signed-off-by: Mario Six >>> --- >>> drivers/cpu/cpu-uclass.c | 10 ++ >>> include/cpu.h| 15 +++ >>> 2 files changed, 25 insertions(+) >>> >> >> I really don't want drivers printing stuff. Can you use the existing >> get_info() method? >> > > I could, but I'm just emulating the behavior of the legacy code here, which > prints some information when the CPU is initialized. I think that's pretty > useful, and I can do that in our board file, but that would mean implementing > the same routine in every MPC83xx board to get the legacy behavior back. Yes, but I don't want the legacy code creeping into the eclass. Can you convert the board to use the CPU eclass instead? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] video_display: Add power_on function
Hi Mario, On 11 April 2018 at 00:35, Mario Six wrote: > Hi Simon, > > On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: >> Hi Mario, >> >> On 28 March 2018 at 20:40, Mario Six wrote: >>> Add a power_on function to the display uclass to allow devices to be >>> probed and powered-on separately. >> >> Is this different from the 'enable' method? >> > > I was thinking that this is more low-level than the enable method, which also > sets display parameters. I could also use the enable method if it's alright to > disregard the panel_bpp and timing parameters. Yes it's fine to ignore those. I'm just trying to use existing API calls where possible (without being silly about it!) > >> Also note that we have a panel uclass that might be useful. >> > > The Logicore driver is probably more low-level than that, but I'll take a > look. OK. Conceptually a panel is just a display panel, so could be of any type, I think. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: mvneta: support setting hardware address
On Thu, Apr 12, 2018 at 5:20 AM, Stefan Roese wrote:
> Hi Matt,
>
> (added Joe as network custodian to Cc)
>
>
> On 27.03.2018 19:18, Matt Pelland wrote:
>>
>> mvneta already supports setting the MAC address but this was only done
>> internally when some other part of U-Boot tries to actually use the
>> interface. This commit exposes this functionality to the ethernet core
>> code so that the MAC addresses of all interfaces are configured
>> correctly even if they are not used before loading Linux.
>>
>> Signed-off-by: Matt Pelland
>> ---
>> drivers/net/mvneta.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
>> index 83e3153768..fdff772178 100644
>> --- a/drivers/net/mvneta.c
>> +++ b/drivers/net/mvneta.c
>> @@ -890,6 +890,16 @@ static void mvneta_mac_addr_set(struct mvneta_port
>> *pp, unsigned char *addr,
>> mvneta_set_ucast_addr(pp, addr[5], queue);
>> }
>> +static int mvneta_write_hwaddr(struct udevice *dev)
>> +{
>> + mvneta_mac_addr_set(
>> + dev_get_priv(dev),
>> + ((struct eth_pdata *)dev_get_platdata(dev))->enetaddr,
>> + rxq_def);
>> +
>> + return 0;
>> +}
>> +
>> /* Handle rx descriptor fill by setting buf_cookie and buf_phys_addr */
>> static void mvneta_rx_desc_fill(struct mvneta_rx_desc *rx_desc,
>> u32 phys_addr, u32 cookie)
>> @@ -1753,6 +1763,7 @@ static const struct eth_ops mvneta_ops = {
>> .send = mvneta_send,
>> .recv = mvneta_recv,
>> .stop = mvneta_stop,
>> + .write_hwaddr = mvneta_write_hwaddr,
>> };
>> static int mvneta_ofdata_to_platdata(struct udevice *dev)
>>
>
> Reviewed-by: Stefan Roese
>
> Joe, will you pick this one up (if you have no objections)? Or should I
> push it via the Marvell repo?
I'll take it.
Cheers,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: mvneta: support setting hardware address
On Tue, Mar 27, 2018 at 12:18 PM, Matt Pelland wrote: > mvneta already supports setting the MAC address but this was only done > internally when some other part of U-Boot tries to actually use the > interface. This commit exposes this functionality to the ethernet core > code so that the MAC addresses of all interfaces are configured > correctly even if they are not used before loading Linux. > > Signed-off-by: Matt Pelland Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] core: Add uclass_{first, next}_device_compat
Hi Mario,
On 11 April 2018 at 01:15, Mario Six wrote:
> Hi Simon,
>
> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote:
>> Hi Mario,
>>
>> On 28 March 2018 at 20:38, Mario Six wrote:
>>> A lot of times one wants to cycle through the devices in a uclass, but
>>> only certain ones, especially ones identified by their compatibility
>>> string, and ignore all others (in the best case this procedure should
>>> not even activate the devices one is not interested in).
>>>
>>> Hence, we add a pair of functions similar to uclass_{first,next}_device,
>>> but taking a compatibility string as an additional argument, which cycle
>>> through the devices of a uclass that conform to this compatibility
>>> string.
>>
>> Can we not use a phandle to find the device? Using raw compatible
>> strings feel bad (and slow to me).
>>
>> If not, a please add a sandbox test.
>>
>
> A phandle would indeed be the cleaner solution, but it won't work if you have
> to get device handles in board files, since there is no device for a board you
> could query for a phandle. And the MPC83xx board this series leads up to needs
> to gather numerous device handles for configuration and querying purposes.
>
> If there was a underlying device for the board functions there would be no
> issue with using a phandle, but as it is, it sadly won't work.
Yes, actually this comes up a lot. Perhaps we should support a 'board'
device which can have phandles pointing to things? It would be easy to
implement. I'm not sure how Linux handles this stuff?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] Kconfig: Enlarge default SYS_MALLOC_F_LEN for AM33XX
Since commit 8e14ba7bd524 ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC
flag") omap GPIO gets bound before relocation. Unfortunately due to
this, on at least the beaglebone black, the pre-relocation memory pool
gets exhausted before probing the serial port. This then causes u-boot
to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...
Resolve this by resizing the default size of the pre-relocation malloc
pool for AM335X platforms.
Signed-off-by: Sjoerd Simons
---
Changes in v2:
- Set the default in the toplevel kConfig file rather then the omap2plus one
Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/Kconfig b/Kconfig
index 6670913799..55dddc844d 100644
--- a/Kconfig
+++ b/Kconfig
@@ -131,6 +131,7 @@ config SYS_MALLOC_F
config SYS_MALLOC_F_LEN
hex "Size of malloc() pool before relocation"
depends on SYS_MALLOC_F
+ default 0x1000 if AM33XX
default 0x400
help
Before relocation, memory is very limited on many platforms. Still,
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mach-omap2: Enlarge SYS_MALLOC_F_LEN
On 04/11/2018 03:58 PM, Tom Rini wrote:
> On Wed, Apr 11, 2018 at 09:26:40PM +0200, Sjoerd Simons wrote:
>
>> Since commit 8e14ba7bd524 ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC
>> flag") omap GPIO gets bound before relocation. Unfortunately due to
>> this, on at least the beaglebone black, the pre-relocation memory pool
>> gets exhausted before probing the serial port. This then causes u-boot
>> to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...
>
> Ah, so, you're using am335x_boneblack_defconfig and not
> am335x_evm_defconfig which is why I didn't see this problem myself.
>
>> Resolve this by doubling the default size of the pre-relocation malloc
>> pool on mach-omap2.
>>
>> Signed-off-by: Sjoerd Simons
>>
>> ---
>>
>> arch/arm/mach-omap2/Kconfig | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> index 3bb1ecb58d..02c5a4c0b8 100644
>> --- a/arch/arm/mach-omap2/Kconfig
>> +++ b/arch/arm/mach-omap2/Kconfig
>> @@ -186,4 +186,7 @@ source "board/compulab/cm_t43/Kconfig"
>> config SPL_LDSCRIPT
>> default "arch/arm/mach-omap2/u-boot-spl.lds"
>>
>> +config SYS_MALLOC_F_LEN
>> +default 0x0800
>
> This isn't the first bad example, ugh, but we shouldn't go this route.
> Ideally we should modify the top-level Kconfig, as that declares
> SYS_MALLOC_F_LEN, to be default 0x800 if ARCH_OMAP2PLUS.
>
> That said, most of the am335x platforms set SYS_MALLOC_F_LEN to either
> 0x1000 or 0x2000. At this point, I would recommend tweaking
> configs/am335x_evm* and configs/am335x_boneblack* to be consistent and
> use 0x1000 as I don't know if the HS variants can safely be pushed up to
> 0x2000 (adding in Andrew). Thanks!
>
Quick test shows they can even be pushed to 0x4000 without obvious
problems. Lets be consistent and push all ARCH_OMAP2PLUS up to 0x2000 so
we don't have to revisit this for awhile. The SPL_ version too.
Andrew
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mach-omap2: Enlarge SYS_MALLOC_F_LEN
On Thu, Apr 12, 2018 at 05:21:27PM +0200, Sjoerd Simons wrote:
> On Wed, 2018-04-11 at 16:58 -0400, Tom Rini wrote:
> > On Wed, Apr 11, 2018 at 09:26:40PM +0200, Sjoerd Simons wrote:
> >
> > > Since commit 8e14ba7bd524 ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC
> > > flag") omap GPIO gets bound before relocation. Unfortunately due
> > > to
> > > this, on at least the beaglebone black, the pre-relocation memory
> > > pool
> > > gets exhausted before probing the serial port. This then causes u-
> > > boot
> > > to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...
> >
> > Ah, so, you're using am335x_boneblack_defconfig and not
> > am335x_evm_defconfig which is why I didn't see this problem myself.
> >
> > > Resolve this by doubling the default size of the pre-relocation
> > > malloc
> > > pool on mach-omap2.
> > >
> > > Signed-off-by: Sjoerd Simons
> > >
> > > ---
> > >
> > > arch/arm/mach-omap2/Kconfig | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-
> > > omap2/Kconfig
> > > index 3bb1ecb58d..02c5a4c0b8 100644
> > > --- a/arch/arm/mach-omap2/Kconfig
> > > +++ b/arch/arm/mach-omap2/Kconfig
> > > @@ -186,4 +186,7 @@ source "board/compulab/cm_t43/Kconfig"
> > > config SPL_LDSCRIPT
> > > default "arch/arm/mach-omap2/u-boot-spl.lds"
> > >
> > > +config SYS_MALLOC_F_LEN
> > > + default 0x0800
> >
> > This isn't the first bad example, ugh, but we shouldn't go this
> > route.
> > Ideally we should modify the top-level Kconfig, as that declares
> > SYS_MALLOC_F_LEN, to be default 0x800 if ARCH_OMAP2PLUS.
>
> Fwiw I proposed it that way around as various machs (tegra, zync,
> bmips, meson, integrator, etc) and the x86 arch seems to doing it like
> that.
Right. Those are bad examples I should migrate :(
> > That said, most of the am335x platforms set SYS_MALLOC_F_LEN to
> > either
> > 0x1000 or 0x2000. At this point, I would recommend tweaking
> > configs/am335x_evm* and configs/am335x_boneblack* to be consistent
> > and
> > use 0x1000 as I don't know if the HS variants can safely be pushed up
> > to
> > 0x2000 (adding in Andrew). Thanks!
>
> Happy to prepare a patch for that; but the one thing that worries me is
> that there are probably more defconfigs broken due to this then just
> those. So changing the default via kconfig is probably more robust.
I'm a little worried too, frankly. We could do default 0x1000 if AM33XX
in the top-level Kconfig file for now, and see about bumping it up to
0x2000 for ARCH_OMAP2PLUS for the next release.
--
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] arm: mach-omap2: Enlarge SYS_MALLOC_F_LEN
On Wed, 2018-04-11 at 16:58 -0400, Tom Rini wrote:
> On Wed, Apr 11, 2018 at 09:26:40PM +0200, Sjoerd Simons wrote:
>
> > Since commit 8e14ba7bd524 ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC
> > flag") omap GPIO gets bound before relocation. Unfortunately due
> > to
> > this, on at least the beaglebone black, the pre-relocation memory
> > pool
> > gets exhausted before probing the serial port. This then causes u-
> > boot
> > to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...
>
> Ah, so, you're using am335x_boneblack_defconfig and not
> am335x_evm_defconfig which is why I didn't see this problem myself.
>
> > Resolve this by doubling the default size of the pre-relocation
> > malloc
> > pool on mach-omap2.
> >
> > Signed-off-by: Sjoerd Simons
> >
> > ---
> >
> > arch/arm/mach-omap2/Kconfig | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-
> > omap2/Kconfig
> > index 3bb1ecb58d..02c5a4c0b8 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -186,4 +186,7 @@ source "board/compulab/cm_t43/Kconfig"
> > config SPL_LDSCRIPT
> > default "arch/arm/mach-omap2/u-boot-spl.lds"
> >
> > +config SYS_MALLOC_F_LEN
> > + default 0x0800
>
> This isn't the first bad example, ugh, but we shouldn't go this
> route.
> Ideally we should modify the top-level Kconfig, as that declares
> SYS_MALLOC_F_LEN, to be default 0x800 if ARCH_OMAP2PLUS.
Fwiw I proposed it that way around as various machs (tegra, zync,
bmips, meson, integrator, etc) and the x86 arch seems to doing it like
that.
> That said, most of the am335x platforms set SYS_MALLOC_F_LEN to
> either
> 0x1000 or 0x2000. At this point, I would recommend tweaking
> configs/am335x_evm* and configs/am335x_boneblack* to be consistent
> and
> use 0x1000 as I don't know if the HS variants can safely be pushed up
> to
> 0x2000 (adding in Andrew). Thanks!
Happy to prepare a patch for that; but the one thing that worries me is
that there are probably more defconfigs broken due to this then just
those. So changing the default via kconfig is probably more robust.
--
Sjoerd Simons
Collabora Ltd.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: socfpga: disable EFI and ISO partition types
On 04/12/2018 04:03 PM, Dinh Nguyen wrote: > None of the SoCFPGA platforms will support EFI/ISO partition types that > is needed for DISTRO_DEFAULTS. SoCFPGA bootroom will only support 0xa2 > partition type. > > This is needed to help limit the size of the SPL to within the 64k limit > that is required for SoCFPGA. > > Signed-off-by: Dinh Nguyen Applied, thanks -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] configs: socfpga: disable EFI and ISO partition types
None of the SoCFPGA platforms will support EFI/ISO partition types that is needed for DISTRO_DEFAULTS. SoCFPGA bootroom will only support 0xa2 partition type. This is needed to help limit the size of the SPL to within the 64k limit that is required for SoCFPGA. Signed-off-by: Dinh Nguyen --- configs/socfpga_arria10_defconfig | 2 ++ configs/socfpga_arria5_defconfig | 2 ++ configs/socfpga_cyclone5_defconfig | 2 ++ configs/socfpga_dbm_soc1_defconfig | 2 ++ configs/socfpga_de0_nano_soc_defconfig | 2 ++ configs/socfpga_de10_nano_defconfig| 2 ++ configs/socfpga_de1_soc_defconfig | 2 ++ configs/socfpga_is1_defconfig | 2 ++ configs/socfpga_mcvevk_defconfig | 2 ++ configs/socfpga_sockit_defconfig | 2 ++ configs/socfpga_socrates_defconfig | 2 ++ configs/socfpga_sr1500_defconfig | 2 ++ configs/socfpga_vining_fpga_defconfig | 2 ++ 13 files changed, 26 insertions(+) diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 1bf3731..3d307d9 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -15,6 +15,8 @@ CONFIG_SPL_FPGA_SUPPORT=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_CACHE=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index 5f80232..03bd1cb 100644 --- a/configs/socfpga_arria5_defconfig +++ b/configs/socfpga_arria5_defconfig @@ -21,6 +21,8 @@ CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig index 5202f47..c68ccac 100644 --- a/configs/socfpga_cyclone5_defconfig +++ b/configs/socfpga_cyclone5_defconfig @@ -21,6 +21,8 @@ CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/socfpga_dbm_soc1_defconfig b/configs/socfpga_dbm_soc1_defconfig index d14fceb..249c38c 100644 --- a/configs/socfpga_dbm_soc1_defconfig +++ b/configs/socfpga_dbm_soc1_defconfig @@ -22,6 +22,8 @@ CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/socfpga_de0_nano_soc_defconfig b/configs/socfpga_de0_nano_soc_defconfig index 4736def..d227b36 100644 --- a/configs/socfpga_de0_nano_soc_defconfig +++ b/configs/socfpga_de0_nano_soc_defconfig @@ -22,6 +22,8 @@ CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/socfpga_de10_nano_defconfig b/configs/socfpga_de10_nano_defconfig index 5a876dd..8eefe2b 100644 --- a/configs/socfpga_de10_nano_defconfig +++ b/configs/socfpga_de10_nano_defconfig @@ -21,6 +21,8 @@ CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/socfpga_de1_soc_defconfig b/configs/socfpga_de1_soc_defconfig index 33381da..a51bc96 100644 --- a/configs/socfpga_de1_soc_defconfig +++ b/configs/socfpga_de1_soc_defconfig @@ -23,6 +23,8 @@ CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/socfpga_is1_defconfig b/configs/socfpga_is1_defconfig index 53b5c34..55895f3 100644 --- a/configs/socfpga_is1_defconfig +++ b/configs/socfpga_is1_defconfig @@ -20,6 +20,8 @@ CONFIG_SPL_STACK_R=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_SF=y diff --git a/configs/socfpga_mcvevk_defconfig b/configs/socfpga_mcvevk_defconfig index c97dcd0..9471c83 100644 --- a/configs/socfpga_mcvevk_defconfig +++ b/configs/socfpga_mcvevk_defconfig @@ -22,6 +22,8 @@ CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig index f421740..57f55de 100644 --- a/configs/socfpga_sockit_defconfig +++ b/configs/socfp
Re: [U-Boot] Re-introducing support for OLD hardware
On Thu, Apr 12, 2018 at 09:04:20AM +0200, Jason Mitchell wrote: > Good day all > > I am currently faced with a task of having to run new software on ageing > hardware. We have currently about 1000 units in the field of a machine that > runs Windows CE using the Samsung S3C6410. > > Because these are considerable assets its not a simple case of replacing > them with new, more modern hardware. > > The goal is to be able to get these existing boards to run Ubuntu so that > we can run GoLang applications, so we need the GUI with just a relatively > recent browser. > > The board in question is a near perfect clone of the SMDK6410, which was > supported fully in U-boot in the past, indeed I can select SMDK6410 and > compile a working U-boot using 1.3.4 sources > > After much effort I managed to get a tailored (tailored as in having > changed the memory configuration to match the hardware) U-boot V1.3.4 > compiled and running for this chip, the problem now, obviously we have a > fairly recent Linux kernel compiled and it won't boot because the Device > Tree Blob doesn't exist on such an old version of U-boot. > > So my questions are: > > - Has anyone perhaps created a branch or fork of the current or nearly > current version of U-boot and patched in this support. I see a lot of > Chinese websites where they seem to have done this but the language barrier > is a big problem. Also a lot of dead links are another problem. > > - If there isn't something out there, would it be possible to run through > the steps with me to add support for this CPU again. I don't mind doing the > work, the main issue is I have no clue how U-boot actually works internally. > > I have FULL JTAG access to this board, with a perfectly functional OpenOCD > setup. This is how we are able to program versions of U-boot into the FLASH. There's two options: 1) You can re-introduce support for the SMDK6410 into mainline U-Boot and be an active maintainer of it. It was removed due to lack of active maintainers. 2) You can, for Linux, use the "appended DTB" work-around to boot a modern kernel from an old bootloader. -- 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] configs: am335x_boneblack: add example debug uart configuration
On Wed, Apr 11, 2018 at 09:23:19PM +0200, Sjoerd Simons wrote: > To make it simpler to enable the debug uart on boneblack add debug > uart configuration as an example in the defconfig but with > CONFIG_DEBUG_UART disabled. Which allows a user to simple enable it when > needing easily without figuring out the right values for memory > base/clock and shift. > > Signed-off-by: Sjoerd Simons > --- > > configs/am335x_boneblack_defconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/configs/am335x_boneblack_defconfig > b/configs/am335x_boneblack_defconfig > index 5688e44c0b..67c16e46d2 100644 > --- a/configs/am335x_boneblack_defconfig > +++ b/configs/am335x_boneblack_defconfig > @@ -48,3 +48,8 @@ CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" > CONFIG_LZO=y > CONFIG_OF_LIBFDT=y > CONFIG_OF_LIBFDT_OVERLAY=y > +# CONFIG_DEBUG_UART is not set > +CONFIG_DEBUG_UART_NS16550=y > +CONFIG_DEBUG_UART_BASE=0x44e09000 > +CONFIG_DEBUG_UART_CLOCK=4800 > +CONFIG_DEBUG_UART_SHIFT=2 This will get overwritten by the next defconfig re-sync. -- 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] fit: skip signature verification if board request
On Wed, Apr 11, 2018 at 11:13:05PM +0800, Jun Nie wrote:
> It may be unnecessary to check signature on unlocked board.
> Get the hint from platform specific code to support secure boot
> and non-secure boot with the same binary, so that boot is not
> blocked if board is not locked and has no key for signature
> verification.
>
> Signed-off-by: Jun Nie
> ---
> common/image-sig.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/common/image-sig.c b/common/image-sig.c
> index d9f712f..f3d1252 100644
> --- a/common/image-sig.c
> +++ b/common/image-sig.c
> @@ -151,6 +151,11 @@ struct image_region *fit_region_make_list(const void
> *fit,
> return region;
> }
>
> +int __attribute__((weak)) fit_board_skip_sig_verification(void)
> +{
> + return 0;
> +}
> +
> static int fit_image_setup_verify(struct image_sign_info *info,
> const void *fit, int noffset, int required_keynode,
> char **err_msgp)
> @@ -188,6 +193,12 @@ int fit_image_check_sig(const void *fit, int noffset,
> const void *data,
> uint8_t *fit_value;
> int fit_value_len;
>
> + /* Skip verification if board says that */
> + if (fit_board_skip_sig_verification()) {
> + printf("signature check skipped\n");
> + return 0;
> + }
> +
> *err_msgp = NULL;
> if (fit_image_setup_verify(&info, fit, noffset, required_keynode,
> err_msgp))
> @@ -438,6 +449,12 @@ int fit_config_verify_required_sigs(const void *fit, int
> conf_noffset,
> int noffset;
> int sig_node;
>
> + /* Skip verification if board says that */
> + if (fit_board_skip_sig_verification()) {
> + printf("signature check skipped\n");
> + return 0;
> + }
> +
> /* Work out what we need to verify */
> sig_node = fdt_subnode_offset(sig_blob, 0, FIT_SIG_NODENAME);
> if (sig_node < 0) {
I'm not sure I like the concept here. Wouldn't this make it easier to
break in to a secure setup with some binary editing? Or is that really
no worse than today? Also, can you please follow up with an
implementation of fit_board_skip_sig_verification? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] tools: zynqmpimage: Add partition read support
The zynqmp image format has support for inline partitions which are
used by FSBL to describe payloads that are loaded by FSBL itself.
While we can't create images that contain partitions (yet), we should
still at least be able to examine them and show the user what's inside
when we analyze an image created by bootgen.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- prettify defines
- fix offset and size outputs
- add u-boot as payload target
- align CPU names with bif
- add shift constants
- add U-Boot as potential partition owner
- mention documentation source
- add HEADER_CPU_SELECT_A53_64BIT define
---
tools/zynqmpimage.c | 174 +++-
1 file changed, 172 insertions(+), 2 deletions(-)
diff --git a/tools/zynqmpimage.c b/tools/zynqmpimage.c
index a61fb17c40..8117913da3 100644
--- a/tools/zynqmpimage.c
+++ b/tools/zynqmpimage.c
@@ -7,6 +7,7 @@
* The following Boot Header format/structures and values are defined in the
* following documents:
* * ug1085 ZynqMP TRM doc v1.4 (Chapter 11, Table 11-4)
+ * * ug1137 ZynqMP Software Developer Guide v6.0 (Chapter 16)
*
* Expected Header Size = 0x9C0
* Forced as 'little' endian, 32-bit words
@@ -63,6 +64,7 @@
#define HEADER_REGINIT_NULL (cpu_to_le32(0x))
#define HEADER_WIDTHDETECTION (cpu_to_le32(0xaa995566))
#define HEADER_IMAGEIDENTIFIER (cpu_to_le32(0x584c4e58))
+#define HEADER_CPU_SELECT_A53_64BIT(0x2 << 10)
enum {
ENCRYPTION_EFUSE = 0xa5c3c5a3,
@@ -80,6 +82,78 @@ struct zynqmp_reginit {
#define HEADER_INTERRUPT_VECTORS 8
#define HEADER_REGINITS256
+struct image_header_table {
+ uint32_t version; /* 0x00 */
+ uint32_t nr_parts;/* 0x04 */
+ uint32_t partition_header_offset; /* 0x08, divided by 4 */
+ uint32_t image_header_offset; /* 0x0c, divided by 4 */
+ uint32_t auth_certificate_offset; /* 0x10 */
+ uint32_t boot_device; /* 0x14 */
+ uint32_t __reserved1[9]; /* 0x18 - 0x38 */
+ uint32_t checksum;/* 0x3c */
+};
+
+#define PART_ATTR_VEC_LOCATION 0x80
+#define PART_ATTR_BS_BLOCK_SIZE_MASK 0x70
+#define PART_ATTR_BS_BLOCK_SIZE_DEFAULT0x00
+#define PART_ATTR_BS_BLOCK_SIZE_8MB0x40
+#define PART_ATTR_BIG_ENDIAN 0x04
+#define PART_ATTR_PART_OWNER_MASK 0x03
+#define PART_ATTR_PART_OWNER_FSBL 0x00
+#define PART_ATTR_PART_OWNER_UBOOT 0x01
+#define PART_ATTR_RSA_SIG 0x008000
+#define PART_ATTR_CHECKSUM_MASK0x007000
+#definePART_ATTR_CHECKSUM_NONE 0x00
+#definePART_ATTR_CHECKSUM_MD5 0x001000
+#definePART_ATTR_CHECKSUM_SHA2 0x002000
+#definePART_ATTR_CHECKSUM_SHA3 0x003000
+#define PART_ATTR_DEST_CPU_SHIFT 8
+#define PART_ATTR_DEST_CPU_MASK0x000f00
+#definePART_ATTR_DEST_CPU_NONE 0x00
+#definePART_ATTR_DEST_CPU_A53_00x000100
+#definePART_ATTR_DEST_CPU_A53_10x000200
+#definePART_ATTR_DEST_CPU_A53_20x000300
+#definePART_ATTR_DEST_CPU_A53_30x000400
+#definePART_ATTR_DEST_CPU_R5_0 0x000500
+#definePART_ATTR_DEST_CPU_R5_1 0x000600
+#definePART_ATTR_DEST_CPU_R5_L 0x000700
+#definePART_ATTR_DEST_CPU_PMU 0x000800
+#define PART_ATTR_ENCRYPTED0x80
+#define PART_ATTR_DEST_DEVICE_SHIFT4
+#define PART_ATTR_DEST_DEVICE_MASK 0x70
+#definePART_ATTR_DEST_DEVICE_NONE 0x00
+#definePART_ATTR_DEST_DEVICE_PS0x10
+#definePART_ATTR_DEST_DEVICE_PL0x20
+#definePART_ATTR_DEST_DEVICE_PMU 0x30
+#definePART_ATTR_DEST_DEVICE_XIP 0x40
+#define PART_ATTR_A53_EXEC_AARCH32 0x08
+#define PART_ATTR_TARGET_EL_SHIFT 1
+#define PART_ATTR_TARGET_EL_MASK 0x06
+#define PART_ATTR_TZ_SECURE0x01
+
+static const char *dest_cpus[0x10] = {
+ "none", "a5x-0", "a5x-1", "a5x-2", "a5x-3", "r5-0", "r5-1",
+ "r5-lockstep", "pmu", "unknown", "unknown", "unknown", "unknown",
+ "unknown", "unknown", "unknown"
+};
+
+struct partition_header {
+ uint32_t len_enc; /* 0x00, divided by 4 */
+ uint32_t len_unenc; /* 0x04, divided by 4 */
+ uint32_t len; /* 0x08, divided by 4 */
+ uint32_t next_partition_offset; /* 0x0c */
+ uint64_t entry_point; /* 0x10 */
+ uint64_t load_address;/* 0x18 */
+ uint32_t offset; /* 0x20, divided by 4 */
+ uint32_t attributes; /* 0x24 */
+ uint32_t __reserved1; /* 0x28 */
+ uint32_t checksum_offset; /* 0x2c, divided by
[U-Boot] [PATCH v3 0/3] tools: zynqmpimage: Support partitions
A good chunk of the booting chain of ZynqMP based systems is open source (depending on your definition of it), except for the image generation flow. This patch set aims to change that, with read and write support for boot.bin partitions which allows us to create boot.bin files using only open source tools. v1 -> v2: - Add bif based generation - Add documentation pointer - Split definitions into separate header v2 -> v3: - zero initialize header - reduce default debug verbosity Alexander Graf (3): tools: zynqmpimage: Add partition read support tools: zynqmpimage: Move defines to header tools: zynqmpimage: Add bif support common/image.c | 1 + include/image.h | 1 + tools/Makefile | 1 + tools/imagetool.h | 1 + tools/mkimage.c | 3 + tools/zynqmpbif.c | 839 tools/zynqmpimage.c | 141 ++--- tools/zynqmpimage.h | 135 + 8 files changed, 1080 insertions(+), 42 deletions(-) create mode 100644 tools/zynqmpbif.c create mode 100644 tools/zynqmpimage.h -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] tools: zynqmpimage: Add bif support
The officially described way to generate boot.bin files for ZynqMP is to
describe the contents of the target binary using a file of the "bif" format.
This file then links to other files that all get packed into a bootable image.
This patch adds support to read such a .bif file and generate a respective
ZynqMP boot.bin file that can include the normal image and pmu files, but also
supports image partitions now. This makes it a handy replacement for the
proprietary "bootgen" utility that is currently used to generate boot.bin
files with FSBL.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- zero initialize header
- reduce default debug verbosity
---
common/image.c | 1 +
include/image.h | 1 +
tools/Makefile | 1 +
tools/imagetool.h | 1 +
tools/mkimage.c | 3 +
tools/zynqmpbif.c | 839
tools/zynqmpimage.c | 4 +-
tools/zynqmpimage.h | 3 +
8 files changed, 851 insertions(+), 2 deletions(-)
create mode 100644 tools/zynqmpbif.c
diff --git a/common/image.c b/common/image.c
index e1c50eb25d..f30dfa229b 100644
--- a/common/image.c
+++ b/common/image.c
@@ -159,6 +159,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_VYBRIDIMAGE, "vybridimage", "Vybrid Boot Image", },
{ IH_TYPE_ZYNQIMAGE, "zynqimage", "Xilinx Zynq Boot Image" },
{ IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image"
},
+ { IH_TYPE_ZYNQMPBIF, "zynqmpbif", "Xilinx ZynqMP Boot Image
(bif)" },
{ IH_TYPE_FPGA, "fpga", "FPGA Image" },
{ IH_TYPE_TEE,"tee","Trusted Execution
Environment Image",},
{ IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 IVT"
},
diff --git a/include/image.h b/include/image.h
index a579c5f509..c5af912aeb 100644
--- a/include/image.h
+++ b/include/image.h
@@ -269,6 +269,7 @@ enum {
IH_TYPE_RKSPI, /* Rockchip SPI image */
IH_TYPE_ZYNQIMAGE, /* Xilinx Zynq Boot Image */
IH_TYPE_ZYNQMPIMAGE,/* Xilinx ZynqMP Boot Image */
+ IH_TYPE_ZYNQMPBIF, /* Xilinx ZynqMP Boot Image (bif) */
IH_TYPE_FPGA, /* FPGA Image */
IH_TYPE_VYBRIDIMAGE,/* VYBRID .vyb Image */
IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
diff --git a/tools/Makefile b/tools/Makefile
index 8143c25666..204685ec9e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -113,6 +113,7 @@ dumpimage-mkimage-objs := aisimage.o \
ublimage.o \
zynqimage.o \
zynqmpimage.o \
+ zynqmpbif.o \
$(LIBFDT_OBJS) \
gpimage.o \
gpimage-common.o \
diff --git a/tools/imagetool.h b/tools/imagetool.h
index e67de9b5ad..d78a9458f4 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -232,6 +232,7 @@ time_t imagetool_get_source_date(
void pbl_load_uboot(int fd, struct image_tool_params *mparams);
+void zynqmpbif_copy_image(int fd, struct image_tool_params *mparams);
#define ___cat(a, b) a ## b
#define __cat(a, b) ___cat(a, b)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 4e561820e7..72183f5f2b 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -514,6 +514,9 @@ int main(int argc, char **argv)
} else if (params.type == IH_TYPE_PBLIMAGE) {
/* PBL has special Image format, implements its' own */
pbl_load_uboot(ifd, ¶ms);
+ } else if (params.type == IH_TYPE_ZYNQMPBIF) {
+ /* Image file is meta, walk through actual targets */
+ zynqmpbif_copy_image(ifd, ¶ms);
} else {
copy_file(ifd, params.datafile, pad_len);
}
diff --git a/tools/zynqmpbif.c b/tools/zynqmpbif.c
new file mode 100644
index 00..d60eff1d8b
--- /dev/null
+++ b/tools/zynqmpbif.c
@@ -0,0 +1,839 @@
+/*
+ * Copyright (C) 2018 Alexander Graf
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "imagetool.h"
+#include "mkimage.h"
+#include "zynqmpimage.h"
+#include
+#include
+
+struct bif_entry {
+ const char *filename;
+ uint64_t flags;
+ uint64_t dest_cpu;
+ uint64_t exp_lvl;
+ uint64_t dest_dev;
+ uint64_t load;
+ uint64_t entry;
+};
+
+enum bif_flag {
+ BIF_FLAG_AESKEYFILE,
+ BIF_FLAG_INIT,
+ BIF_FLAG_UDF_BH,
+ BIF_FLAG_HEADERSIGNATURE,
+ BIF_FLAG_PPKFILE,
+ BIF_FLAG_PSKFILE,
+ BIF_FLAG_SPKFILE,
+ BIF_FLAG_SSKFILE,
+ BIF_FLAG_SPKSIGNATURE,
+ BIF_FLAG_FSBL_CONFIG,
+ BIF_FLAG_AUTH_PARAMS,
+ BIF_FLAG_KEYSRC_ENCRYPTION,
+ BIF_FLAG_PMUFW_IMAGE,
+ BIF_FLAG_BOOTLOADER,
+ BIF_FLAG_TZ,
+ BIF_FLAG_BH_KEY_IV,
+ BIF_FLAG_BH_KE
[U-Boot] [PATCH v3 2/3] tools: zynqmpimage: Move defines to header
We will add support for ZynqMP bif input files later, so let's move
all structure definitions into a header file that can be used by that
one as well.
Signed-off-by: Alexander Graf
---
tools/zynqmpimage.c | 115 +
tools/zynqmpimage.h | 132
2 files changed, 133 insertions(+), 114 deletions(-)
create mode 100644 tools/zynqmpimage.h
diff --git a/tools/zynqmpimage.c b/tools/zynqmpimage.c
index 8117913da3..8f4766f077 100644
--- a/tools/zynqmpimage.c
+++ b/tools/zynqmpimage.c
@@ -58,122 +58,9 @@
#include "imagetool.h"
#include "mkimage.h"
+#include "zynqmpimage.h"
#include
-#define HEADER_INTERRUPT_DEFAULT (cpu_to_le32(0xeafe))
-#define HEADER_REGINIT_NULL (cpu_to_le32(0x))
-#define HEADER_WIDTHDETECTION (cpu_to_le32(0xaa995566))
-#define HEADER_IMAGEIDENTIFIER (cpu_to_le32(0x584c4e58))
-#define HEADER_CPU_SELECT_A53_64BIT(0x2 << 10)
-
-enum {
- ENCRYPTION_EFUSE = 0xa5c3c5a3,
- ENCRYPTION_OEFUSE = 0xa5c3c5a7,
- ENCRYPTION_BBRAM = 0x3a5c3c5a,
- ENCRYPTION_OBBRAM = 0xa35c7ca5,
- ENCRYPTION_NONE = 0x0,
-};
-
-struct zynqmp_reginit {
- uint32_t address;
- uint32_t data;
-};
-
-#define HEADER_INTERRUPT_VECTORS 8
-#define HEADER_REGINITS256
-
-struct image_header_table {
- uint32_t version; /* 0x00 */
- uint32_t nr_parts;/* 0x04 */
- uint32_t partition_header_offset; /* 0x08, divided by 4 */
- uint32_t image_header_offset; /* 0x0c, divided by 4 */
- uint32_t auth_certificate_offset; /* 0x10 */
- uint32_t boot_device; /* 0x14 */
- uint32_t __reserved1[9]; /* 0x18 - 0x38 */
- uint32_t checksum;/* 0x3c */
-};
-
-#define PART_ATTR_VEC_LOCATION 0x80
-#define PART_ATTR_BS_BLOCK_SIZE_MASK 0x70
-#define PART_ATTR_BS_BLOCK_SIZE_DEFAULT0x00
-#define PART_ATTR_BS_BLOCK_SIZE_8MB0x40
-#define PART_ATTR_BIG_ENDIAN 0x04
-#define PART_ATTR_PART_OWNER_MASK 0x03
-#define PART_ATTR_PART_OWNER_FSBL 0x00
-#define PART_ATTR_PART_OWNER_UBOOT 0x01
-#define PART_ATTR_RSA_SIG 0x008000
-#define PART_ATTR_CHECKSUM_MASK0x007000
-#definePART_ATTR_CHECKSUM_NONE 0x00
-#definePART_ATTR_CHECKSUM_MD5 0x001000
-#definePART_ATTR_CHECKSUM_SHA2 0x002000
-#definePART_ATTR_CHECKSUM_SHA3 0x003000
-#define PART_ATTR_DEST_CPU_SHIFT 8
-#define PART_ATTR_DEST_CPU_MASK0x000f00
-#definePART_ATTR_DEST_CPU_NONE 0x00
-#definePART_ATTR_DEST_CPU_A53_00x000100
-#definePART_ATTR_DEST_CPU_A53_10x000200
-#definePART_ATTR_DEST_CPU_A53_20x000300
-#definePART_ATTR_DEST_CPU_A53_30x000400
-#definePART_ATTR_DEST_CPU_R5_0 0x000500
-#definePART_ATTR_DEST_CPU_R5_1 0x000600
-#definePART_ATTR_DEST_CPU_R5_L 0x000700
-#definePART_ATTR_DEST_CPU_PMU 0x000800
-#define PART_ATTR_ENCRYPTED0x80
-#define PART_ATTR_DEST_DEVICE_SHIFT4
-#define PART_ATTR_DEST_DEVICE_MASK 0x70
-#definePART_ATTR_DEST_DEVICE_NONE 0x00
-#definePART_ATTR_DEST_DEVICE_PS0x10
-#definePART_ATTR_DEST_DEVICE_PL0x20
-#definePART_ATTR_DEST_DEVICE_PMU 0x30
-#definePART_ATTR_DEST_DEVICE_XIP 0x40
-#define PART_ATTR_A53_EXEC_AARCH32 0x08
-#define PART_ATTR_TARGET_EL_SHIFT 1
-#define PART_ATTR_TARGET_EL_MASK 0x06
-#define PART_ATTR_TZ_SECURE0x01
-
-static const char *dest_cpus[0x10] = {
- "none", "a5x-0", "a5x-1", "a5x-2", "a5x-3", "r5-0", "r5-1",
- "r5-lockstep", "pmu", "unknown", "unknown", "unknown", "unknown",
- "unknown", "unknown", "unknown"
-};
-
-struct partition_header {
- uint32_t len_enc; /* 0x00, divided by 4 */
- uint32_t len_unenc; /* 0x04, divided by 4 */
- uint32_t len; /* 0x08, divided by 4 */
- uint32_t next_partition_offset; /* 0x0c */
- uint64_t entry_point; /* 0x10 */
- uint64_t load_address;/* 0x18 */
- uint32_t offset; /* 0x20, divided by 4 */
- uint32_t attributes; /* 0x24 */
- uint32_t __reserved1; /* 0x28 */
- uint32_t checksum_offset; /* 0x2c, divided by 4 */
- uint32_t __reserved2; /* 0x30 */
- uint32_t auth_certificate_offset; /* 0x34 */
- uint32_t __reserved3; /* 0x38 */
- uint32_t checksum;/* 0x3c */
-};
-
-struct zynqmp_header {
- uint32_t interrupt_vectors[HEADER_INTERRUPT_VECTORS]; /* 0
[U-Boot] [PATCH v2 3/3] tools: zynqmpimage: Add bif support
The officially described way to generate boot.bin files for ZynqMP is to
describe the contents of the target binary using a file of the "bif" format.
This file then links to other files that all get packed into a bootable image.
This patch adds support to read such a .bif file and generate a respective
ZynqMP boot.bin file that can include the normal image and pmu files, but also
supports image partitions now. This makes it a handy replacement for the
proprietary "bootgen" utility that is currently used to generate boot.bin
files with FSBL.
Signed-off-by: Alexander Graf
---
common/image.c | 1 +
include/image.h | 1 +
tools/Makefile | 1 +
tools/imagetool.h | 1 +
tools/mkimage.c | 3 +
tools/zynqmpbif.c | 839
tools/zynqmpimage.c | 4 +-
tools/zynqmpimage.h | 3 +
8 files changed, 851 insertions(+), 2 deletions(-)
create mode 100644 tools/zynqmpbif.c
diff --git a/common/image.c b/common/image.c
index e1c50eb25d..f30dfa229b 100644
--- a/common/image.c
+++ b/common/image.c
@@ -159,6 +159,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_VYBRIDIMAGE, "vybridimage", "Vybrid Boot Image", },
{ IH_TYPE_ZYNQIMAGE, "zynqimage", "Xilinx Zynq Boot Image" },
{ IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image"
},
+ { IH_TYPE_ZYNQMPBIF, "zynqmpbif", "Xilinx ZynqMP Boot Image
(bif)" },
{ IH_TYPE_FPGA, "fpga", "FPGA Image" },
{ IH_TYPE_TEE,"tee","Trusted Execution
Environment Image",},
{ IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 IVT"
},
diff --git a/include/image.h b/include/image.h
index a579c5f509..c5af912aeb 100644
--- a/include/image.h
+++ b/include/image.h
@@ -269,6 +269,7 @@ enum {
IH_TYPE_RKSPI, /* Rockchip SPI image */
IH_TYPE_ZYNQIMAGE, /* Xilinx Zynq Boot Image */
IH_TYPE_ZYNQMPIMAGE,/* Xilinx ZynqMP Boot Image */
+ IH_TYPE_ZYNQMPBIF, /* Xilinx ZynqMP Boot Image (bif) */
IH_TYPE_FPGA, /* FPGA Image */
IH_TYPE_VYBRIDIMAGE,/* VYBRID .vyb Image */
IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
diff --git a/tools/Makefile b/tools/Makefile
index 8143c25666..204685ec9e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -113,6 +113,7 @@ dumpimage-mkimage-objs := aisimage.o \
ublimage.o \
zynqimage.o \
zynqmpimage.o \
+ zynqmpbif.o \
$(LIBFDT_OBJS) \
gpimage.o \
gpimage-common.o \
diff --git a/tools/imagetool.h b/tools/imagetool.h
index e67de9b5ad..d78a9458f4 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -232,6 +232,7 @@ time_t imagetool_get_source_date(
void pbl_load_uboot(int fd, struct image_tool_params *mparams);
+void zynqmpbif_copy_image(int fd, struct image_tool_params *mparams);
#define ___cat(a, b) a ## b
#define __cat(a, b) ___cat(a, b)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 4e561820e7..72183f5f2b 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -514,6 +514,9 @@ int main(int argc, char **argv)
} else if (params.type == IH_TYPE_PBLIMAGE) {
/* PBL has special Image format, implements its' own */
pbl_load_uboot(ifd, ¶ms);
+ } else if (params.type == IH_TYPE_ZYNQMPBIF) {
+ /* Image file is meta, walk through actual targets */
+ zynqmpbif_copy_image(ifd, ¶ms);
} else {
copy_file(ifd, params.datafile, pad_len);
}
diff --git a/tools/zynqmpbif.c b/tools/zynqmpbif.c
new file mode 100644
index 00..47218873eb
--- /dev/null
+++ b/tools/zynqmpbif.c
@@ -0,0 +1,839 @@
+/*
+ * Copyright (C) 2018 Alexander Graf
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "imagetool.h"
+#include "mkimage.h"
+#include "zynqmpimage.h"
+#include
+#include
+
+struct bif_entry {
+ const char *filename;
+ uint64_t flags;
+ uint64_t dest_cpu;
+ uint64_t exp_lvl;
+ uint64_t dest_dev;
+ uint64_t load;
+ uint64_t entry;
+};
+
+enum bif_flag {
+ BIF_FLAG_AESKEYFILE,
+ BIF_FLAG_INIT,
+ BIF_FLAG_UDF_BH,
+ BIF_FLAG_HEADERSIGNATURE,
+ BIF_FLAG_PPKFILE,
+ BIF_FLAG_PSKFILE,
+ BIF_FLAG_SPKFILE,
+ BIF_FLAG_SSKFILE,
+ BIF_FLAG_SPKSIGNATURE,
+ BIF_FLAG_FSBL_CONFIG,
+ BIF_FLAG_AUTH_PARAMS,
+ BIF_FLAG_KEYSRC_ENCRYPTION,
+ BIF_FLAG_PMUFW_IMAGE,
+ BIF_FLAG_BOOTLOADER,
+ BIF_FLAG_TZ,
+ BIF_FLAG_BH_KEY_IV,
+ BIF_FLAG_BH_KEYFILE,
+ BIF_FLAG_PUF_FILE,
+
+ /* Internal flags */
+ BIF_FL
[U-Boot] [PATCH v2 2/3] tools: zynqmpimage: Move defines to header
We will add support for ZynqMP bif input files later, so let's move
all structure definitions into a header file that can be used by that
one as well.
Signed-off-by: Alexander Graf
---
tools/zynqmpimage.c | 115 +
tools/zynqmpimage.h | 132
2 files changed, 133 insertions(+), 114 deletions(-)
create mode 100644 tools/zynqmpimage.h
diff --git a/tools/zynqmpimage.c b/tools/zynqmpimage.c
index 8117913da3..8f4766f077 100644
--- a/tools/zynqmpimage.c
+++ b/tools/zynqmpimage.c
@@ -58,122 +58,9 @@
#include "imagetool.h"
#include "mkimage.h"
+#include "zynqmpimage.h"
#include
-#define HEADER_INTERRUPT_DEFAULT (cpu_to_le32(0xeafe))
-#define HEADER_REGINIT_NULL (cpu_to_le32(0x))
-#define HEADER_WIDTHDETECTION (cpu_to_le32(0xaa995566))
-#define HEADER_IMAGEIDENTIFIER (cpu_to_le32(0x584c4e58))
-#define HEADER_CPU_SELECT_A53_64BIT(0x2 << 10)
-
-enum {
- ENCRYPTION_EFUSE = 0xa5c3c5a3,
- ENCRYPTION_OEFUSE = 0xa5c3c5a7,
- ENCRYPTION_BBRAM = 0x3a5c3c5a,
- ENCRYPTION_OBBRAM = 0xa35c7ca5,
- ENCRYPTION_NONE = 0x0,
-};
-
-struct zynqmp_reginit {
- uint32_t address;
- uint32_t data;
-};
-
-#define HEADER_INTERRUPT_VECTORS 8
-#define HEADER_REGINITS256
-
-struct image_header_table {
- uint32_t version; /* 0x00 */
- uint32_t nr_parts;/* 0x04 */
- uint32_t partition_header_offset; /* 0x08, divided by 4 */
- uint32_t image_header_offset; /* 0x0c, divided by 4 */
- uint32_t auth_certificate_offset; /* 0x10 */
- uint32_t boot_device; /* 0x14 */
- uint32_t __reserved1[9]; /* 0x18 - 0x38 */
- uint32_t checksum;/* 0x3c */
-};
-
-#define PART_ATTR_VEC_LOCATION 0x80
-#define PART_ATTR_BS_BLOCK_SIZE_MASK 0x70
-#define PART_ATTR_BS_BLOCK_SIZE_DEFAULT0x00
-#define PART_ATTR_BS_BLOCK_SIZE_8MB0x40
-#define PART_ATTR_BIG_ENDIAN 0x04
-#define PART_ATTR_PART_OWNER_MASK 0x03
-#define PART_ATTR_PART_OWNER_FSBL 0x00
-#define PART_ATTR_PART_OWNER_UBOOT 0x01
-#define PART_ATTR_RSA_SIG 0x008000
-#define PART_ATTR_CHECKSUM_MASK0x007000
-#definePART_ATTR_CHECKSUM_NONE 0x00
-#definePART_ATTR_CHECKSUM_MD5 0x001000
-#definePART_ATTR_CHECKSUM_SHA2 0x002000
-#definePART_ATTR_CHECKSUM_SHA3 0x003000
-#define PART_ATTR_DEST_CPU_SHIFT 8
-#define PART_ATTR_DEST_CPU_MASK0x000f00
-#definePART_ATTR_DEST_CPU_NONE 0x00
-#definePART_ATTR_DEST_CPU_A53_00x000100
-#definePART_ATTR_DEST_CPU_A53_10x000200
-#definePART_ATTR_DEST_CPU_A53_20x000300
-#definePART_ATTR_DEST_CPU_A53_30x000400
-#definePART_ATTR_DEST_CPU_R5_0 0x000500
-#definePART_ATTR_DEST_CPU_R5_1 0x000600
-#definePART_ATTR_DEST_CPU_R5_L 0x000700
-#definePART_ATTR_DEST_CPU_PMU 0x000800
-#define PART_ATTR_ENCRYPTED0x80
-#define PART_ATTR_DEST_DEVICE_SHIFT4
-#define PART_ATTR_DEST_DEVICE_MASK 0x70
-#definePART_ATTR_DEST_DEVICE_NONE 0x00
-#definePART_ATTR_DEST_DEVICE_PS0x10
-#definePART_ATTR_DEST_DEVICE_PL0x20
-#definePART_ATTR_DEST_DEVICE_PMU 0x30
-#definePART_ATTR_DEST_DEVICE_XIP 0x40
-#define PART_ATTR_A53_EXEC_AARCH32 0x08
-#define PART_ATTR_TARGET_EL_SHIFT 1
-#define PART_ATTR_TARGET_EL_MASK 0x06
-#define PART_ATTR_TZ_SECURE0x01
-
-static const char *dest_cpus[0x10] = {
- "none", "a5x-0", "a5x-1", "a5x-2", "a5x-3", "r5-0", "r5-1",
- "r5-lockstep", "pmu", "unknown", "unknown", "unknown", "unknown",
- "unknown", "unknown", "unknown"
-};
-
-struct partition_header {
- uint32_t len_enc; /* 0x00, divided by 4 */
- uint32_t len_unenc; /* 0x04, divided by 4 */
- uint32_t len; /* 0x08, divided by 4 */
- uint32_t next_partition_offset; /* 0x0c */
- uint64_t entry_point; /* 0x10 */
- uint64_t load_address;/* 0x18 */
- uint32_t offset; /* 0x20, divided by 4 */
- uint32_t attributes; /* 0x24 */
- uint32_t __reserved1; /* 0x28 */
- uint32_t checksum_offset; /* 0x2c, divided by 4 */
- uint32_t __reserved2; /* 0x30 */
- uint32_t auth_certificate_offset; /* 0x34 */
- uint32_t __reserved3; /* 0x38 */
- uint32_t checksum;/* 0x3c */
-};
-
-struct zynqmp_header {
- uint32_t interrupt_vectors[HEADER_INTERRUPT_VECTORS]; /* 0
[U-Boot] [PATCH v2 1/3] tools: zynqmpimage: Add partition read support
The zynqmp image format has support for inline partitions which are
used by FSBL to describe payloads that are loaded by FSBL itself.
While we can't create images that contain partitions (yet), we should
still at least be able to examine them and show the user what's inside
when we analyze an image created by bootgen.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- prettify defines
- fix offset and size outputs
- add u-boot as payload target
- align CPU names with bif
- add shift constants
- add U-Boot as potential partition owner
- mention documentation source
- add HEADER_CPU_SELECT_A53_64BIT define
---
tools/zynqmpimage.c | 174 +++-
1 file changed, 172 insertions(+), 2 deletions(-)
diff --git a/tools/zynqmpimage.c b/tools/zynqmpimage.c
index a61fb17c40..8117913da3 100644
--- a/tools/zynqmpimage.c
+++ b/tools/zynqmpimage.c
@@ -7,6 +7,7 @@
* The following Boot Header format/structures and values are defined in the
* following documents:
* * ug1085 ZynqMP TRM doc v1.4 (Chapter 11, Table 11-4)
+ * * ug1137 ZynqMP Software Developer Guide v6.0 (Chapter 16)
*
* Expected Header Size = 0x9C0
* Forced as 'little' endian, 32-bit words
@@ -63,6 +64,7 @@
#define HEADER_REGINIT_NULL (cpu_to_le32(0x))
#define HEADER_WIDTHDETECTION (cpu_to_le32(0xaa995566))
#define HEADER_IMAGEIDENTIFIER (cpu_to_le32(0x584c4e58))
+#define HEADER_CPU_SELECT_A53_64BIT(0x2 << 10)
enum {
ENCRYPTION_EFUSE = 0xa5c3c5a3,
@@ -80,6 +82,78 @@ struct zynqmp_reginit {
#define HEADER_INTERRUPT_VECTORS 8
#define HEADER_REGINITS256
+struct image_header_table {
+ uint32_t version; /* 0x00 */
+ uint32_t nr_parts;/* 0x04 */
+ uint32_t partition_header_offset; /* 0x08, divided by 4 */
+ uint32_t image_header_offset; /* 0x0c, divided by 4 */
+ uint32_t auth_certificate_offset; /* 0x10 */
+ uint32_t boot_device; /* 0x14 */
+ uint32_t __reserved1[9]; /* 0x18 - 0x38 */
+ uint32_t checksum;/* 0x3c */
+};
+
+#define PART_ATTR_VEC_LOCATION 0x80
+#define PART_ATTR_BS_BLOCK_SIZE_MASK 0x70
+#define PART_ATTR_BS_BLOCK_SIZE_DEFAULT0x00
+#define PART_ATTR_BS_BLOCK_SIZE_8MB0x40
+#define PART_ATTR_BIG_ENDIAN 0x04
+#define PART_ATTR_PART_OWNER_MASK 0x03
+#define PART_ATTR_PART_OWNER_FSBL 0x00
+#define PART_ATTR_PART_OWNER_UBOOT 0x01
+#define PART_ATTR_RSA_SIG 0x008000
+#define PART_ATTR_CHECKSUM_MASK0x007000
+#definePART_ATTR_CHECKSUM_NONE 0x00
+#definePART_ATTR_CHECKSUM_MD5 0x001000
+#definePART_ATTR_CHECKSUM_SHA2 0x002000
+#definePART_ATTR_CHECKSUM_SHA3 0x003000
+#define PART_ATTR_DEST_CPU_SHIFT 8
+#define PART_ATTR_DEST_CPU_MASK0x000f00
+#definePART_ATTR_DEST_CPU_NONE 0x00
+#definePART_ATTR_DEST_CPU_A53_00x000100
+#definePART_ATTR_DEST_CPU_A53_10x000200
+#definePART_ATTR_DEST_CPU_A53_20x000300
+#definePART_ATTR_DEST_CPU_A53_30x000400
+#definePART_ATTR_DEST_CPU_R5_0 0x000500
+#definePART_ATTR_DEST_CPU_R5_1 0x000600
+#definePART_ATTR_DEST_CPU_R5_L 0x000700
+#definePART_ATTR_DEST_CPU_PMU 0x000800
+#define PART_ATTR_ENCRYPTED0x80
+#define PART_ATTR_DEST_DEVICE_SHIFT4
+#define PART_ATTR_DEST_DEVICE_MASK 0x70
+#definePART_ATTR_DEST_DEVICE_NONE 0x00
+#definePART_ATTR_DEST_DEVICE_PS0x10
+#definePART_ATTR_DEST_DEVICE_PL0x20
+#definePART_ATTR_DEST_DEVICE_PMU 0x30
+#definePART_ATTR_DEST_DEVICE_XIP 0x40
+#define PART_ATTR_A53_EXEC_AARCH32 0x08
+#define PART_ATTR_TARGET_EL_SHIFT 1
+#define PART_ATTR_TARGET_EL_MASK 0x06
+#define PART_ATTR_TZ_SECURE0x01
+
+static const char *dest_cpus[0x10] = {
+ "none", "a5x-0", "a5x-1", "a5x-2", "a5x-3", "r5-0", "r5-1",
+ "r5-lockstep", "pmu", "unknown", "unknown", "unknown", "unknown",
+ "unknown", "unknown", "unknown"
+};
+
+struct partition_header {
+ uint32_t len_enc; /* 0x00, divided by 4 */
+ uint32_t len_unenc; /* 0x04, divided by 4 */
+ uint32_t len; /* 0x08, divided by 4 */
+ uint32_t next_partition_offset; /* 0x0c */
+ uint64_t entry_point; /* 0x10 */
+ uint64_t load_address;/* 0x18 */
+ uint32_t offset; /* 0x20, divided by 4 */
+ uint32_t attributes; /* 0x24 */
+ uint32_t __reserved1; /* 0x28 */
+ uint32_t checksum_offset; /* 0x2c, divided by
[U-Boot] [PATCH v2 0/3] tools: zynqmpimage: Support partitions
A good chunk of the booting chain of ZynqMP based systems is open source (depending on your definition of it), except for the image generation flow. This patch set aims to change that, with read and write support for boot.bin partitions which allows us to create boot.bin files using only open source tools. Alexander Graf (3): tools: zynqmpimage: Add partition read support tools: zynqmpimage: Move defines to header tools: zynqmpimage: Add bif support common/image.c | 1 + include/image.h | 1 + tools/Makefile | 1 + tools/imagetool.h | 1 + tools/mkimage.c | 3 + tools/zynqmpbif.c | 839 tools/zynqmpimage.c | 141 ++--- tools/zynqmpimage.h | 135 + 8 files changed, 1080 insertions(+), 42 deletions(-) create mode 100644 tools/zynqmpbif.c create mode 100644 tools/zynqmpimage.h -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit
On 04/12/2018 04:43 AM, Marek Vasut wrote: > On 04/12/2018 11:42 AM, Alexander Graf wrote: > [...] None of it is enabled in SPL :). The „efi partition“ option is a misnomer - it really just enables GPT partition table support which are widely in use with Android for example. >>> I suspect we can disable that, since SoCFPGA boots from this a2 >>> partition type on MBR only (bootrom limitation). >> >> >> That's a very good point. If the bootrom does not support GPT, there is >> basically no point in enabling it in SPL, I agree. > > Patch please ! Ok...Let met get to it! Thanks for the help in debugging this issue? Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot 2018 SPI SPL
Dear Fabio, Thank you very much. I will check and inform you. Best regards. -Original Message- From: Fabio Estevam [mailto:feste...@gmail.com] Sent: Thursday, April 12, 2018 4:28 PM To: Mehmet Ali İPİN Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] u-boot 2018 SPI SPL Hi Mehmet, On Thu, Apr 12, 2018 at 10:17 AM, Mehmet Ali İPİN wrote: > Dear Sir/Madam, > > Hello, > > We have developed an i.mx6dl board which is based on "MX6 Dual Lite SABRE AI > CPU2 Card with AVB". I am using version u-boot-2018.01 with SPL. > I am downloading SPL and u-boot.img with USB loader; downloaded kernel and > device tree files and run them in nfs tftp search over ethernet.. > > Then I programmed the SPI NOR flash with u-boot with spi read/write commands > for both u-boot.imx/and u-boot.img images with offset value of 0x400 in Flash > address, set boot pins accordingly, saw signals at clock, CS and Data pins of > flash after reset, but never see a boot (character at terminal) for last few > weeks. > > As I know, make command is generating code for SD card, and SPL code is > waiting u-boot to be loaded from USB port. I searched many NXP/denx forums; > i.mx6 linux kernel ref. Manuals for u-boot with SPL, I found NXP supports > u-boot.imx images, but did not support SPL+u-boot.img. > > So I would be very grateful, if any of you know which (and how) files, > parameters (and/or make command) should be set for u-boot.img+SPL boot for > SPI nor flash boot in u-boot 2018.1? Or give link to document(s), which > explain the i.mx6dl SPL and u-boot.img boot process for SPI nor flash > (except i.mx6 ref manual).. Take a look at board/congatec/cgtqmx6eval/README (2. Flashing U-Boot in the SPI NOR). It explains how to flash SPL + u-boot.img into SPI NOR on a mx6 board. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V4 1/2] imx6: Convert sabrelite and nitrogen6x boards to distro boot support
Boot tested on sabrelite board.
Signed-off-by: Guillaume GARDET
Cc: Troy Kisky
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Gary Bisson
---
include/configs/nitrogen6x.h | 180 +--
1 file changed, 54 insertions(+), 126 deletions(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..f6dce6c069 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -101,140 +101,68 @@
#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
#define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
+#ifdef CONFIG_CMD_MMC
+#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
+#else
+#define DISTRO_BOOT_DEV_MMC(func)
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define DISTRO_BOOT_DEV_SATA(func) func(SATA, sata, 0)
+#else
+#define DISTRO_BOOT_DEV_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define DISTRO_BOOT_DEV_USB(func) func(USB, usb, 0)
+#else
+#define DISTRO_BOOT_DEV_USB(func)
+#endif
+
+#ifdef CONFIG_CMD_PXE
+#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na)
+#else
+#define DISTRO_BOOT_DEV_PXE(func)
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na)
+#else
+#define DISTRO_BOOT_DEV_DHCP(func)
+#endif
+
+
#if defined(CONFIG_SABRELITE)
+#define FDTFILE "fdtfile=imx6q-sabrelite.dtb\0"
+#else
+/* FIXME: nitrogen6x covers multiple configs. Define fdtfile for each
supported config. */
+#define FDTFILE
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+ DISTRO_BOOT_DEV_MMC(func) \
+ DISTRO_BOOT_DEV_SATA(func) \
+ DISTRO_BOOT_DEV_USB(func) \
+ DISTRO_BOOT_DEV_PXE(func) \
+ DISTRO_BOOT_DEV_DHCP(func)
+
+#include
+
#define CONFIG_EXTRA_ENV_SETTINGS \
- "script=boot.scr\0" \
- "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
- "fdt_file=imx6q-sabrelite.dtb\0" \
- "fdt_addr=0x1800\0" \
- "boot_fdt=try\0" \
+ "fdt_addr_r=0x1800\0" \
+ FDTFILE \
+ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+ "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+ "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+ "ramdisk_addr_r=0x1300\0" \
+ "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
- "mmcdevs=0 1\0" \
- "mmcpart=1\0" \
- "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
- "mmcargs=setenv bootargs console=${console},${baudrate} " \
- "root=${mmcroot}\0" \
- "loadbootscript=" \
- "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
- "bootscript=echo Running bootscript from mmc ...; " \
- "source\0" \
- "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
- "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
- "mmcboot=echo Booting from mmc ...; " \
- "run mmcargs; " \
- "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
- "if run loadfdt; then " \
- "bootm ${loadaddr} - ${fdt_addr}; " \
- "else " \
- "if test ${boot_fdt} = try; then " \
- "bootm; " \
- "else " \
- "echo WARN: Cannot load the DT; " \
- "fi; " \
- "fi; " \
- "else " \
- "bootm; " \
- "fi;\0" \
- "netargs=setenv bootargs console=${console},${baudrate} " \
- "root=/dev/nfs " \
- "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
- "netboot=echo Booting from net ...; " \
- "run netargs; " \
- "if test ${ip_dyn} = yes; then " \
- "setenv get_cmd dhcp; " \
- "else " \
- "setenv get_cmd tftp; " \
- "fi; " \
- "${get_cmd} ${uimage}; " \
- "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
- "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
- "bootm ${loadaddr} - ${fdt_addr}; " \
- "else " \
- "if test ${boot_fdt} = try; then " \
- "bootm; " \
- "else " \
- "echo WARN: Cannot load the DT; " \
- "fi; " \
- "fi; " \
- "else " \
- "bootm; " \
- "fi;\0"
-
-#define CONFIG_BOOTCOMMAND \
- "for mmcdev in ${mmcdevs}; do " \
- "mmc dev ${mmcdev}; " \
- "if mmc rescan; then " \
-
[U-Boot] [PATCH V4 2/2] imx6: sabrelite: update defconfig to use distro defaults
Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots on sabrelite board. Signed-off-by: Guillaume GARDET Cc: Troy Kisky Cc: Stefano Babic Cc: Fabio Estevam Cc: Gary Bisson --- configs/mx6qsabrelite_defconfig | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig index 7499704058..fee33cfff1 100644 --- a/configs/mx6qsabrelite_defconfig +++ b/configs/mx6qsabrelite_defconfig @@ -3,15 +3,15 @@ CONFIG_ARCH_MX6=y CONFIG_SYS_TEXT_BASE=0x1780 CONFIG_TARGET_NITROGEN6X=y CONFIG_CMD_HDMIDETECT=y +CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE" CONFIG_BOOTDELAY=3 +# CONFIG_USE_BOOTCOMMAND is not set CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y -CONFIG_SUPPORT_RAW_INITRD=y +CONFIG_ARCH_MISC_INIT=y CONFIG_BOARD_EARLY_INIT_F=y -CONFIG_HUSH_PARSER=y CONFIG_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x1200 -CONFIG_CMD_BOOTZ=y CONFIG_CMD_MEMTEST=y CONFIG_SYS_ALT_MEMTEST=y # CONFIG_CMD_FLASH is not set @@ -22,17 +22,12 @@ CONFIG_CMD_SATA=y CONFIG_CMD_SF=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y -CONFIG_CMD_DHCP=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_DM=y CONFIG_DWC_AHSATA=y -- 2.13.6 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V4 0/2] Update sabrelite and nitrogen6x boards to use distro boot support
This patch serie updates sabrelite and nitrogen6x boards to use distro boot support. Sabrelite has been boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots. Nitrogen6* boards have been build tested only. Currently, only the Sabrelite has fdtfile defined. Signed-off-by: Guillaume GARDET Cc: Troy Kisky Cc: Stefano Babic Cc: Fabio Estevam Cc: Gary Bisson Changes in V4: * Remove imx6 soc definition * Change comment on not defined fdtfile (no more fallback) Changes in V3: * Add imx6 soc definition * Also update nitrogen6x config, not only sabrelite * Split mx6qsabrelite_defconfig update to a separate patch Changes in V2: * add mx6qsabrelite_defconfig update Guillaume GARDET (2): imx6: Convert sabrelite and nitrogen6x boards to distro boot support imx6: sabrelite: update defconfig to use distro defaults configs/mx6qsabrelite_defconfig | 15 ++-- include/configs/nitrogen6x.h| 180 2 files changed, 59 insertions(+), 136 deletions(-) -- 2.13.6 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot 2018 SPI SPL
Hi Mehmet, On Thu, Apr 12, 2018 at 10:17 AM, Mehmet Ali İPİN wrote: > Dear Sir/Madam, > > Hello, > > We have developed an i.mx6dl board which is based on "MX6 Dual Lite SABRE AI > CPU2 Card with AVB". I am using version u-boot-2018.01 with SPL. > I am downloading SPL and u-boot.img with USB loader; downloaded kernel and > device tree files and run them in nfs tftp search over ethernet.. > > Then I programmed the SPI NOR flash with u-boot with spi read/write commands > for both u-boot.imx/and u-boot.img images with offset value of 0x400 in Flash > address, set boot pins accordingly, saw signals at clock, CS and Data pins of > flash after reset, but never see a boot (character at terminal) for last few > weeks. > > As I know, make command is generating code for SD card, and SPL code is > waiting u-boot to be loaded from USB port. I searched many NXP/denx forums; > i.mx6 linux kernel ref. Manuals for u-boot with SPL, I found NXP supports > u-boot.imx images, but did not support SPL+u-boot.img. > > So I would be very grateful, if any of you know which (and how) files, > parameters (and/or make command) should be set for u-boot.img+SPL boot for > SPI nor flash boot in u-boot 2018.1? Or give link to document(s), which > explain the i.mx6dl SPL and u-boot.img boot process for SPI nor flash > (except i.mx6 ref manual).. Take a look at board/congatec/cgtqmx6eval/README (2. Flashing U-Boot in the SPI NOR). It explains how to flash SPL + u-boot.img into SPI NOR on a mx6 board. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] u-boot 2018 SPI SPL
Dear Sir/Madam, Hello, We have developed an i.mx6dl board which is based on "MX6 Dual Lite SABRE AI CPU2 Card with AVB". I am using version u-boot-2018.01 with SPL. I am downloading SPL and u-boot.img with USB loader; downloaded kernel and device tree files and run them in nfs tftp search over ethernet.. Then I programmed the SPI NOR flash with u-boot with spi read/write commands for both u-boot.imx/and u-boot.img images with offset value of 0x400 in Flash address, set boot pins accordingly, saw signals at clock, CS and Data pins of flash after reset, but never see a boot (character at terminal) for last few weeks. As I know, make command is generating code for SD card, and SPL code is waiting u-boot to be loaded from USB port. I searched many NXP/denx forums; i.mx6 linux kernel ref. Manuals for u-boot with SPL, I found NXP supports u-boot.imx images, but did not support SPL+u-boot.img. So I would be very grateful, if any of you know which (and how) files, parameters (and/or make command) should be set for u-boot.img+SPL boot for SPI nor flash boot in u-boot 2018.1? Or give link to document(s), which explain the i.mx6dl SPL and u-boot.img boot process for SPI nor flash (except i.mx6 ref manual).. Thanks and best regards. Mehmet Ali Ipin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC
Le 12/04/2018 à 14:58, Gary Bisson a écrit :
Hi Guillaume,
On Thu, Apr 12, 2018 at 02:48:07PM +0200, Guillaume Gardet wrote:
Le 12/04/2018 à 14:36, Gary Bisson a écrit :
Hi Fabio, Guillaume
On Thu, Apr 12, 2018 at 08:14:51AM -0300, Fabio Estevam wrote:
On Thu, Apr 12, 2018 at 5:13 AM, Guillaume Gardet
wrote:
script that picks the correct dtb.
Ok. So, how would you like to proceed?
Remove the generic mx6 'soc' definition and use a board sepcific 'board_rev'
(or maybe a static definition if one configuration match a single dtb) to
define the right dtb?
I prefer to keep the same solution as done in other boards sucn as
mx6sabresd, wandboard and cuboxi.
Ok. My suggestion was to have something generic so that it matches the
fdt name set in config_distro_bootcmd.h
(${soc}-${board}${boardver}.dtb).
I especially like the naming in that standard, don't think board_rev
should be the SOC name.
This would also avoid redundancy in each board_late_init functions since
only the board name would need to be setup (and boardver in some cases
like wandboard).
Guillaume, please forget that point for now and just set your fdtfile
name in the config file. I'll update the board file later on.
Ok.
Could you just confirm which DTB should work with the various nitrogen6x boards
config, please?
Are the following ok?
* imx6q-nitrogen6x.dts => nitrogen6q2g_defconfig nitrogen6q_defconfig
* imx6dl-nitrogen6x.dts => nitrogen6dl2g_defconfig nitrogen6dl_defconfig
* imx6sx-nitrogen6sx.dts => nitrogen6s1g_defconfig nitrogen6s_defconfig
No, imx6sx is different than imx6s. Solo is the same as imx6dl as far as
the kernl is concerned.
Maybe just leave fdt_file blank for nitrogen6x for now, it's only necessary
for PXE which isn't enabled in nitrogen6*defconfig.
Ok, I will leave it as is for now, but fdtfile must also be defined for EFI
boot. Otherwise, you start your EFI payload without device tree.
Guillaume
Regards,
Gary
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] SPI Flash: add support of sst26wf* flash ICs protection ops
Hi Jagan,
Maybe you have any comments or remarks about this patch? And if you don't could
you please apply it.
Thanks!
On Tue, 2018-04-10 at 14:40 +0300, Eugeniy Paltsev wrote:
> sst26wf flash series block protection implementation differs
> from other SST series, so add specific implementation
> flash_lock/flash_unlock/flash_is_locked functions for sst26wf
> flash ICs.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v4->v5:
> * Return EACCES when flash is locked instead of custom define (SF_LOCKED)
> * Add SST26_CTL_* prefix to sst27 lock ops enum.
> * Move all sst26 code inside of existing CONFIG_SPI_FLASH_SST #ifdef.
>
> Changes v3->v4:
> * Make sst26_process_bpr() and sst26_lock_ctl() functions static.
>
> Changes v2->v3:
> * Move SST26 command defenition to sf_internal.h
> * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
>into single sst26_process_bpr function.
> * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
>sst26_lock_ctl()
>
> Changes v1->v2:
> * Use generic defines from linux/sizes.h instead of custom ones.
>
> drivers/mtd/spi/sf_internal.h | 13
> drivers/mtd/spi/spi_flash.c | 168
> ++
> 2 files changed, 181 insertions(+)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 839cdbe1b0..614a293234 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -87,6 +87,19 @@ enum spi_nor_option_flags {
>
> /* SST specific */
> #ifdef CONFIG_SPI_FLASH_SST
> +#define SST26_CMD_READ_BPR 0x72
> +#define SST26_CMD_WRITE_BPR 0x42
> +
> +#define SST26_BPR_8K_NUM 4
> +#define SST26_MAX_BPR_REG_LEN(18 + 1)
> +#define SST26_BOUND_REG_SIZE ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
> +
> +enum lock_ctl {
> + SST26_CTL_LOCK,
> + SST26_CTL_UNLOCK,
> + SST26_CTL_CHECK
> +};
> +
> # define CMD_SST_BP 0x02/* Byte Program */
> # define CMD_SST_AAI_WP 0xAD/* Auto Address Incr Word
> Program */
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 2e61685d3e..5e5bd5d533 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "sf_internal.h"
> @@ -541,6 +542,164 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32
> offset,
> }
>
> #ifdef CONFIG_SPI_FLASH_SST
> +static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl
> ctl)
> +{
> + switch (ctl) {
> + case SST26_CTL_LOCK:
> + cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
> + break;
> + case SST26_CTL_UNLOCK:
> + cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
> + break;
> + case SST26_CTL_CHECK:
> + return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
> + }
> +
> + return false;
> +}
> +
> +/*
> + * sst26wf016/sst26wf032/sst26wf064 have next block protection:
> + * 4x - 8 KByte blocks - read & write protection bits - upper addresses
> + * 1x - 32 KByte blocks - write protection bits
> + * rest - 64 KByte blocks - write protection bits
> + * 1x - 32 KByte blocks - write protection bits
> + * 4x - 8 KByte blocks - read & write protection bits - lower addresses
> + *
> + * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
> + * will be treated as single block.
> + */
> +
> +/*
> + * Lock, unlock or check lock status of the flash region of the flash
> (depending
> + * on the lock_ctl value)
> + */
> +static int sst26_lock_ctl(struct spi_flash *flash, u32 ofs, size_t len, enum
> lock_ctl ctl)
> +{
> + u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
> + bool lower_64k = false, upper_64k = false;
> + u8 cmd, bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
> + int ret;
> +
> + /* Check length and offset for 64k alignment */
> + if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1)))
> + return -EINVAL;
> +
> + if (ofs + len > flash->size)
> + return -EINVAL;
> +
> + /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
> + if (flash->size != SZ_2M &&
> + flash->size != SZ_4M &&
> + flash->size != SZ_8M)
> + return -EINVAL;
> +
> + bpr_size = 2 + (flash->size / SZ_64K / 8);
> +
> + cmd = SST26_CMD_READ_BPR;
> + ret = spi_flash_read_common(flash, &cmd, 1, bpr_buff, bpr_size);
> + if (ret < 0) {
> + printf("SF: fail to read block-protection register\n");
> + return ret;
> + }
> +
> + rptr_64k = min_t(u32, ofs + len , flash->size - SST26_BOUND_REG_SIZE);
> + lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
> +
> + upper_64k = ((ofs + len) > (flash->size - SST26_BOUND_REG_SIZE));
> + lower_64k = (ofs < SST26_BOUND
Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC
Hi Guillaume,
On Thu, Apr 12, 2018 at 02:48:07PM +0200, Guillaume Gardet wrote:
>
>
> Le 12/04/2018 à 14:36, Gary Bisson a écrit :
> > Hi Fabio, Guillaume
> >
> > On Thu, Apr 12, 2018 at 08:14:51AM -0300, Fabio Estevam wrote:
> > > On Thu, Apr 12, 2018 at 5:13 AM, Guillaume Gardet
> > > wrote:
> > > script that picks the correct dtb.
> > > > Ok. So, how would you like to proceed?
> > > > Remove the generic mx6 'soc' definition and use a board sepcific
> > > > 'board_rev'
> > > > (or maybe a static definition if one configuration match a single dtb)
> > > > to
> > > > define the right dtb?
> > > I prefer to keep the same solution as done in other boards sucn as
> > > mx6sabresd, wandboard and cuboxi.
> > Ok. My suggestion was to have something generic so that it matches the
> > fdt name set in config_distro_bootcmd.h
> > (${soc}-${board}${boardver}.dtb).
> >
> > I especially like the naming in that standard, don't think board_rev
> > should be the SOC name.
> >
> > This would also avoid redundancy in each board_late_init functions since
> > only the board name would need to be setup (and boardver in some cases
> > like wandboard).
> >
> > Guillaume, please forget that point for now and just set your fdtfile
> > name in the config file. I'll update the board file later on.
>
> Ok.
>
> Could you just confirm which DTB should work with the various nitrogen6x
> boards config, please?
> Are the following ok?
> * imx6q-nitrogen6x.dts => nitrogen6q2g_defconfig nitrogen6q_defconfig
> * imx6dl-nitrogen6x.dts => nitrogen6dl2g_defconfig
> nitrogen6dl_defconfig
> * imx6sx-nitrogen6sx.dts => nitrogen6s1g_defconfig
> nitrogen6s_defconfig
No, imx6sx is different than imx6s. Solo is the same as imx6dl as far as
the kernl is concerned.
Maybe just leave fdt_file blank for nitrogen6x for now, it's only necessary
for PXE which isn't enabled in nitrogen6*defconfig.
Regards,
Gary
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver
Hi Siva, I wasn't able to find it on the Xilinx github. Is it in that tree already? Thanks, Liam On Thu, 12 Apr 2018 at 07:18 Siva Durga Prasad Paladugu wrote: > Hi Liam, > > > > We already have a patch for IO mode that we just verified internally. We > got it for our tree from NGC guy John Moon. I will be sending that patch > soon may be with v3 which I am planning to send once I got response from > Jagan on my v2 queries. > > > > Regards, > > Siva > > > > *From:* Liam Beguin [mailto:liambeg...@gmail.com] > *Sent:* Tuesday, April 10, 2018 8:56 PM > *To:* Siva Durga Prasad Paladugu > *Cc:* Jagan Teki ; U-Boot-Denx < > u-boot@lists.denx.de>; Michal Simek > > > *Subject:* Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for > ZynqMP qspi driver > > > > Hi Siva, > > > > I've been working on a patch to add support for io-mode [1]. > > It's based on xilinx/master which is closer to v1 (no include file). > > I haven't had much time to test it further but I can load a bitstream > > from a ubifs partition with it. > > Let me know if you have comments. > > > > On Tue, 10 Apr 2018 at 02:27 Siva Durga Prasad Paladugu < > siva...@xilinx.com> wrote: > > H Jagan, > > Any further comments on this. I am waiting for your reply on some of my > replies to your comment. > > Thanks, > Siva > > > > Thanks, > > Liam > > > > [1] https://github.com/Liambeguin/u-boot/tree/io-mode > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC
Le 12/04/2018 à 14:36, Gary Bisson a écrit :
Hi Fabio, Guillaume
On Thu, Apr 12, 2018 at 08:14:51AM -0300, Fabio Estevam wrote:
On Thu, Apr 12, 2018 at 5:13 AM, Guillaume Gardet
wrote:
script that picks the correct dtb.
Ok. So, how would you like to proceed?
Remove the generic mx6 'soc' definition and use a board sepcific 'board_rev'
(or maybe a static definition if one configuration match a single dtb) to
define the right dtb?
I prefer to keep the same solution as done in other boards sucn as
mx6sabresd, wandboard and cuboxi.
Ok. My suggestion was to have something generic so that it matches the
fdt name set in config_distro_bootcmd.h
(${soc}-${board}${boardver}.dtb).
I especially like the naming in that standard, don't think board_rev
should be the SOC name.
This would also avoid redundancy in each board_late_init functions since
only the board name would need to be setup (and boardver in some cases
like wandboard).
Guillaume, please forget that point for now and just set your fdtfile
name in the config file. I'll update the board file later on.
Ok.
Could you just confirm which DTB should work with the various nitrogen6x boards
config, please?
Are the following ok?
* imx6q-nitrogen6x.dts => nitrogen6q2g_defconfig nitrogen6q_defconfig
* imx6dl-nitrogen6x.dts => nitrogen6dl2g_defconfig nitrogen6dl_defconfig
* imx6sx-nitrogen6sx.dts => nitrogen6s1g_defconfig nitrogen6s_defconfig
* imx6q-sabrelite.dts => mx6qsabrelite_defconfig
Guillaume
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC
Hi Fabio, Guillaume
On Thu, Apr 12, 2018 at 08:14:51AM -0300, Fabio Estevam wrote:
> On Thu, Apr 12, 2018 at 5:13 AM, Guillaume Gardet
> wrote:
> script that picks the correct dtb.
> >>
> > Ok. So, how would you like to proceed?
> > Remove the generic mx6 'soc' definition and use a board sepcific 'board_rev'
> > (or maybe a static definition if one configuration match a single dtb) to
> > define the right dtb?
>
> I prefer to keep the same solution as done in other boards sucn as
> mx6sabresd, wandboard and cuboxi.
Ok. My suggestion was to have something generic so that it matches the
fdt name set in config_distro_bootcmd.h
(${soc}-${board}${boardver}.dtb).
I especially like the naming in that standard, don't think board_rev
should be the SOC name.
This would also avoid redundancy in each board_late_init functions since
only the board name would need to be setup (and boardver in some cases
like wandboard).
Guillaume, please forget that point for now and just set your fdtfile
name in the config file. I'll update the board file later on.
Regards,
Gary
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/11] Add support for DM_USB for TI's DRA7 EVMs and AM57 EVMs platforms
On 04/12/2018 10:41 AM, Jean-Jacques Hiblot wrote: > Supporting DM USB is required to support DM_ETH and USB network adapters > with the same binary. > This series adds support for DM_USB for the DRA7/AM57 families. As a bonus > it adds support for USB3. > > This series applies on the usb tree with the following fixes: > -[PATCH] reset: fix bulk API when DM_RESET is disabled > -[PATCH] usb: dwc3-of-simple: fix error check of clk_get_bulk when disabled > > limitation: > - only Host mode is supported. The Device mode can be added later. > > Tested on: > - dra7 evm > - dra71 evm > - dra72 evm > - dra72 evm rev C > - dra76 evm > - AM572 evm [...] I'll pull 01 and 02 through USB, pull the rest through TI. Thanks -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 00/11] Add support for DM_USB for TI's DRA7 EVMs and AM57 EVMs platforms
Supporting DM USB is required to support DM_ETH and USB network adapters with the same binary. This series adds support for DM_USB for the DRA7/AM57 families. As a bonus it adds support for USB3. This series applies on the usb tree with the following fixes: -[PATCH] reset: fix bulk API when DM_RESET is disabled -[PATCH] usb: dwc3-of-simple: fix error check of clk_get_bulk when disabled limitation: - only Host mode is supported. The Device mode can be added later. Tested on: - dra7 evm - dra71 evm - dra72 evm - dra72 evm rev C - dra76 evm - AM572 evm Changes in v4: - Fix word missing in commit log - Remove dependency on MISC - Renamed the commit "configs: enable DM_USB for all the platforms of the DRA7 family" - Remove omap specific glue layer and use dwc3-of-simple glue layer Changes in v3: - in syscon_regmap_lookup_by_phandle(), use dev_dbg() instead of printf() - added unit test for syscon_regmap_lookup_by_phandle() Changes in v2: - Add USB3 support to ti-pipe3-phy driver - omap-usb2-phy: Implement power_on and power_off callbacks - am57xx boards: when DM_USB is used, turn on the required USB clocks - split dts changes in 2 commits: one for binding the children of ocp2scp@4a08, and one to disable USB1 on all DRA7 EVMs - Instead of disabling USB1 port in dts files, use *-u-boot.dtsi files - Enable DM_USB in am57xx_evm_defconfig. USB3 (super speed) is supported. Jean-Jacques Hiblot (9): usb: dwc3-of-simple: Fix dependencies usb: dwc3-of-simple: Add support for DRA7/AM57 platforms. syscon: dm: Add a new method to get a regmap from DTS phy: Add a new driver for OMAP's USB2 PHYs board: ti: dra7xx-evm: turn on USB clocks in late init stage dts: dra7x: make ocp2scp@4a08 compatible with simple-bus dts: dra7x: Disable USB1 on all evms configs: enable OMAP_USB2_PHY for all DRA7 platforms configs: am57xx_evm: Enable DM_USB and dependencies Vignesh R (2): phy: ti-pip3-phy: Add support for USB3 PHY board; ti: am57xx: turn on USB clocks arch/arm/dts/dra7-evm-u-boot.dtsi | 8 ++ arch/arm/dts/dra71-evm-u-boot.dtsi | 9 ++ arch/arm/dts/dra72-evm-revc-u-boot.dtsi | 8 ++ arch/arm/dts/dra72-evm-u-boot.dtsi | 22 arch/arm/dts/dra76-evm-u-boot.dtsi | 9 ++ arch/arm/dts/omap5-u-boot.dtsi | 4 + arch/sandbox/dts/test.dts | 6 +- board/ti/am57xx/board.c | 19 board/ti/dra7xx/evm.c | 19 configs/am57xx_evm_defconfig| 4 + configs/dra7xx_evm_defconfig| 1 + configs/dra7xx_hs_evm_defconfig | 1 + drivers/core/syscon-uclass.c| 23 drivers/phy/Kconfig | 8 ++ drivers/phy/Makefile| 1 + drivers/phy/omap-usb2-phy.c | 196 drivers/phy/ti-pipe3-phy.c | 30 +++-- drivers/usb/host/Kconfig| 3 +- drivers/usb/host/dwc3-of-simple.c | 1 + include/syscon.h| 13 +++ test/dm/syscon.c| 29 + 21 files changed, 404 insertions(+), 10 deletions(-) create mode 100644 arch/arm/dts/dra72-evm-u-boot.dtsi create mode 100644 drivers/phy/omap-usb2-phy.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Re-introducing support for OLD hardware
Good day all I am currently faced with a task of having to run new software on ageing hardware. We have currently about 1000 units in the field of a machine that runs Windows CE using the Samsung S3C6410. Because these are considerable assets its not a simple case of replacing them with new, more modern hardware. The goal is to be able to get these existing boards to run Ubuntu so that we can run GoLang applications, so we need the GUI with just a relatively recent browser. The board in question is a near perfect clone of the SMDK6410, which was supported fully in U-boot in the past, indeed I can select SMDK6410 and compile a working U-boot using 1.3.4 sources After much effort I managed to get a tailored (tailored as in having changed the memory configuration to match the hardware) U-boot V1.3.4 compiled and running for this chip, the problem now, obviously we have a fairly recent Linux kernel compiled and it won't boot because the Device Tree Blob doesn't exist on such an old version of U-boot. So my questions are: - Has anyone perhaps created a branch or fork of the current or nearly current version of U-boot and patched in this support. I see a lot of Chinese websites where they seem to have done this but the language barrier is a big problem. Also a lot of dead links are another problem. - If there isn't something out there, would it be possible to run through the steps with me to add support for this CPU again. I don't mind doing the work, the main issue is I have no clue how U-boot actually works internally. I have FULL JTAG access to this board, with a perfectly functional OpenOCD setup. This is how we are able to program versions of U-boot into the FLASH. Hoping someone can assist Kindest Regards, Jason Mitchell Software Developer Spark ATM Systems (PTY) LTD ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] chiliSOM: USB bug
Marcin Niestroj wrote: On 12.04.2018 11:09, sdrb wrote: Marcin Niestrój wrote: >> Could you describe what is you BOOT[4:0] configuration? And you want to boot from MMC1, right? If I read the BOOT[4:0] properly it is: 0011. I want to boot from SD card. Please provide these 5 pins (including 4 and 0) configuration. Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011. Regards, WK ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Add support of SD3.0 UHS modes for ZynqMP
Hi Jaehoon, Ping! Thanks, Siva > -Original Message- > From: Siva Durga Prasad Paladugu > Sent: Tuesday, April 10, 2018 12:02 PM > To: Jaehoon Chung ; u-boot@lists.denx.de > Subject: RE: [PATCH v2 0/7] Add support of SD3.0 UHS modes for ZynqMP > > Hi Jaehoon, > > I would like to send v3 for this series, Any specific branch that you want me > to rebase the series? > > Thanks, > DP > > > -Original Message- > > From: Jaehoon Chung [mailto:jh80.ch...@samsung.com] > > Sent: Wednesday, January 17, 2018 8:04 AM > > To: Siva Durga Prasad Paladugu ; u- > > b...@lists.denx.de > > Subject: Re: [PATCH v2 0/7] Add support of SD3.0 UHS modes for > ZynqMP > > > > Hi Siva, > > > > On 01/16/2018 07:10 PM, Siva Durga Prasad Paladugu wrote: > > > Hi Jaehoon, > > > > > > Any review comments on this. > > > > Thanks for reminding. Will check! :) > > > > Best Regards, > > Jaehoon Chung > > > > > > Thanks, > > > Siva > > > > > >> -Original Message- > > >> From: Siva Durga Prasad Paladugu > > >> [mailto:siva.durga.palad...@xilinx.com] > > >> Sent: Thursday, January 04, 2018 3:11 PM > > >> To: u-boot@lists.denx.de > > >> Cc: jh80.ch...@samsung.com; Siva Durga Prasad Paladugu > > >> > > >> Subject: [PATCH v2 0/7] Add support of SD3.0 UHS modes for ZynqMP > > >> > > >> This patch series is meant to add SD3.0 support for ZynqMP platform. > > >> The first five patches in the series mostly setting up things in > > >> sdhci layer to support SD3.0 , the sixth patch is to add SD3.0 > > >> support for ZynqMP platform and the last patch is to enable this > > >> support for ZynqMP zcu102 > > >> rev1.0 eval board. > > >> > > >> Repo: u-boot-mmc.git > > >> Branch: hs200-working > > >> > > >> Siva Durga Prasad Paladugu (7): > > >> mmc: sdhci: Add support for disabling clock > > >> mmc: sdhci: Handle execute tuning command in > sdhci_send_command > > >> sdhci: Add new sdhci ops for platform specific tuning and delays > > >> mmc: sdhci: Invoke platform specific tuning and delay routines > > >> mmc : sdhci: Read capabilities register1 and update host caps > > >> mmc: zynq_sdhci: Add support for SD3.0 > > >> zynqmp: zcu102: Enable UHS support for ZCU102 Rev1.0 board > > >> > > >> board/xilinx/zynqmp/Makefile | 2 + > > >> board/xilinx/zynqmp/tap_delays.c | 230 > > >> ++ > > >> configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 2 + > > >> drivers/mmc/sdhci.c | 67 +++- > > >> drivers/mmc/zynq_sdhci.c | 230 > > >> +- > > >> include/sdhci.h | 9 + > > >> include/zynqmp_tap_delay.h| 20 +++ > > >> 7 files changed, 550 insertions(+), 10 deletions(-) create mode > > >> 100644 board/xilinx/zynqmp/tap_delays.c create mode 100644 > > >> include/zynqmp_tap_delay.h > > >> > > >> -- > > >> 2.7.4 > > > > > > > > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver
Hi Liam, We already have a patch for IO mode that we just verified internally. We got it for our tree from NGC guy John Moon. I will be sending that patch soon may be with v3 which I am planning to send once I got response from Jagan on my v2 queries. Regards, Siva From: Liam Beguin [mailto:liambeg...@gmail.com] Sent: Tuesday, April 10, 2018 8:56 PM To: Siva Durga Prasad Paladugu Cc: Jagan Teki ; U-Boot-Denx ; Michal Simek Subject: Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver Hi Siva, I've been working on a patch to add support for io-mode [1]. It's based on xilinx/master which is closer to v1 (no include file). I haven't had much time to test it further but I can load a bitstream from a ubifs partition with it. Let me know if you have comments. On Tue, 10 Apr 2018 at 02:27 Siva Durga Prasad Paladugu mailto:siva...@xilinx.com>> wrote: H Jagan, Any further comments on this. I am waiting for your reply on some of my replies to your comment. Thanks, Siva Thanks, Liam [1] https://github.com/Liambeguin/u-boot/tree/io-mode ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] imx6: Define 'soc' env var for imx6 SoC
On Thu, Apr 12, 2018 at 5:13 AM, Guillaume Gardet wrote: script that picks the correct dtb. >> > Ok. So, how would you like to proceed? > Remove the generic mx6 'soc' definition and use a board sepcific 'board_rev' > (or maybe a static definition if one configuration match a single dtb) to > define the right dtb? I prefer to keep the same solution as done in other boards sucn as mx6sabresd, wandboard and cuboxi. > Could you tell me which DTB should work with the various nitrogen6x boards > config? I will let Gary confirm this one, as I am not familiar with the board variants from Boundary Devices. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] chiliSOM: USB bug
On 12.04.2018 11:09, sdrb wrote: Marcin Niestrój wrote: >> Could you describe what is you BOOT[4:0] configuration? And you want to boot from MMC1, right? If I read the BOOT[4:0] properly it is: 0011. I want to boot from SD card. Please provide these 5 pins (including 4 and 0) configuration. -- Marcin Niestroj ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH][v2] armv8: sec_firmware: Remove JR3 from device tree node in all cases
JR3 was getting removed from device tree only if random number generation
was successful. However, if SEC firmware is present,JR3 should be removed
from device tree node irrespective of the random seed generation as
SEC firmware reserves it for it's use. Not removing it in case of random
number generation failure causes the kernel to crash.
Random number generation was being called twice. This is not required.
If SEC firmware is running, SIP call can be made to the SEC firmware to
get the random number. This call itself would return failure if function
is not supported. Duplicate calling of random number generation function
has been removed
Signed-off-by: Ruchika Gupta
---
Changes from v1:
Removed unused variable rand from the sec_firmware_support_hwrng function
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 4 ++--
arch/arm/cpu/armv8/sec_firmware.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 99c5d13..955ef30 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -415,8 +415,8 @@ void ft_cpu_setup(void *blob, bd_t *bd)
ccsr_sec_t __iomem *sec;
#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- if (fdt_fixup_kaslr(blob))
- fdt_fixup_remove_jr(blob);
+ fdt_fixup_remove_jr(blob);
+ fdt_fixup_kaslr(blob);
#endif
sec = (void __iomem *)CONFIG_SYS_FSL_SEC_ADDR;
diff --git a/arch/arm/cpu/armv8/sec_firmware.c
b/arch/arm/cpu/armv8/sec_firmware.c
index b56ea78..98d7be3 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -318,9 +318,7 @@ unsigned int sec_firmware_support_psci_version(void)
*/
bool sec_firmware_support_hwrng(void)
{
- uint8_t rand[8];
if (sec_firmware_addr & SEC_FIRMWARE_RUNNING) {
- if (!sec_firmware_get_random(rand, 8))
return true;
}
@@ -429,8 +427,10 @@ int fdt_fixup_kaslr(void *fdt)
#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT)
/* Check if random seed generation is supported */
- if (sec_firmware_support_hwrng() == false)
+ if (sec_firmware_support_hwrng() == false) {
+ printf("WARNING: SEC firmware not running, no kaslr-seed\n");
return 0;
+ }
ret = sec_firmware_get_random(rand, 8);
if (ret < 0) {
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: zynq: Sync zc770 xm011 defconfigs
x8 and x16 configurations should be in sync. Signed-off-by: Michal Simek --- configs/zynq_zc770_xm011_x16_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/zynq_zc770_xm011_x16_defconfig b/configs/zynq_zc770_xm011_x16_defconfig index ae6029a71e7d..756200a9ae11 100644 --- a/configs/zynq_zc770_xm011_x16_defconfig +++ b/configs/zynq_zc770_xm011_x16_defconfig @@ -32,11 +32,11 @@ CONFIG_CMD_CACHE=y # CONFIG_SPL_ISO_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_BLK=y CONFIG_FPGA_XILINX=y CONFIG_FPGA_ZYNQPL=y CONFIG_DM_GPIO=y # CONFIG_MMC is not set -CONFIG_DM_MMC=y CONFIG_NAND=y CONFIG_NAND_ZYNQ=y CONFIG_DEBUG_UART_ZYNQ=y -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: zynq: Disable NFS and MII on zc770 xm011
Disable NFS/MII because this board has no ethernet enabled. Signed-off-by: Michal Simek --- configs/zynq_zc770_xm011_defconfig | 2 ++ configs/zynq_zc770_xm011_x16_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/zynq_zc770_xm011_defconfig b/configs/zynq_zc770_xm011_defconfig index 9613b8af258c..5cc739f255e8 100644 --- a/configs/zynq_zc770_xm011_defconfig +++ b/configs/zynq_zc770_xm011_defconfig @@ -25,6 +25,8 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_NAND_LOCK_UNLOCK=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NET is not set +# CONFIG_CMD_NFS is not set +# CONFIG_CMD_MII is not set CONFIG_CMD_CACHE=y # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_ISO_PARTITION is not set diff --git a/configs/zynq_zc770_xm011_x16_defconfig b/configs/zynq_zc770_xm011_x16_defconfig index 08cb0419b65f..756200a9ae11 100644 --- a/configs/zynq_zc770_xm011_x16_defconfig +++ b/configs/zynq_zc770_xm011_x16_defconfig @@ -25,6 +25,8 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_NAND_LOCK_UNLOCK=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NET is not set +# CONFIG_CMD_NFS is not set +# CONFIG_CMD_MII is not set CONFIG_CMD_CACHE=y # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_ISO_PARTITION is not set -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] microblaze: Dont enable UBI support by default
From: Siva Durga Prasad Paladugu This patch removes UBI support from defconfig and it can be enabled from menuconfig as per need. Signed-off-by: Siva Durga Prasad Paladugu Signed-off-by: Michal Simek --- configs/microblaze-generic_defconfig | 4 1 file changed, 4 deletions(-) diff --git a/configs/microblaze-generic_defconfig b/configs/microblaze-generic_defconfig index 18bec1f2e5de..79eec95493ab 100644 --- a/configs/microblaze-generic_defconfig +++ b/configs/microblaze-generic_defconfig @@ -35,10 +35,6 @@ CONFIG_CMD_DHCP=y CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_JFFS2=y -CONFIG_MTDIDS_DEFAULT="nor0=flash-0" -CONFIG_MTDPARTS_DEFAULT="mtdparts=flash-0:256k(u-boot),256k(env),3m(kernel),1m(romfs),1m(cramfs),-(jffs2)" -CONFIG_CMD_UBI=y -# CONFIG_CMD_UBIFS is not set CONFIG_SPL_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_NETCONSOLE=y -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: Add new defconfig for zc1275 revB
From: Siva Durga Prasad Paladugu
This patch enables support zc1275 revB board. It has
SD added compared to revA. The same configuration will
work for RevC boards aswell.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/zynqmp-zc1275-revB.dts | 79 +++
.../zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c | 523 ++
configs/xilinx_zynqmp_zc1275_revB_defconfig | 56 ++
include/configs/xilinx_zynqmp_zc1275_revB.h | 16 +
5 files changed, 675 insertions(+)
create mode 100644 arch/arm/dts/zynqmp-zc1275-revB.dts
create mode 100644 board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
create mode 100644 configs/xilinx_zynqmp_zc1275_revB_defconfig
create mode 100644 include/configs/xilinx_zynqmp_zc1275_revB.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 62fbf32a62ab..e11c41da0156 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -159,6 +159,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
zynqmp-zc1232-revA.dtb \
zynqmp-zc1254-revA.dtb \
zynqmp-zc1275-revA.dtb \
+ zynqmp-zc1275-revB.dtb \
zynqmp-zc1751-xm015-dc1.dtb \
zynqmp-zc1751-xm016-dc2.dtb \
zynqmp-zc1751-xm017-dc3.dtb \
diff --git a/arch/arm/dts/zynqmp-zc1275-revB.dts
b/arch/arm/dts/zynqmp-zc1275-revB.dts
new file mode 100644
index ..f694faeeb5c2
--- /dev/null
+++ b/arch/arm/dts/zynqmp-zc1275-revB.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx ZynqMP ZC1275 RevB
+ *
+ * (C) Copyright 2018, Xilinx, Inc.
+ *
+ * Michal Simek
+ * Siva Durga Prasad Paladugu
+ */
+
+/dts-v1/;
+
+#include "zynqmp.dtsi"
+#include "zynqmp-clk-ccf.dtsi"
+
+/ {
+ model = "ZynqMP ZC1275 RevB";
+ compatible = "xlnx,zynqmp-zc1275-revB", "xlnx,zynqmp-zc1275",
"xlnx,zynqmp";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &dcc;
+ spi0 = &qspi;
+ mmc0 = &sdhci1;
+ };
+
+ chosen {
+ bootargs = "earlycon";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+};
+
+&dcc {
+ status = "okay";
+};
+
+&qspi {
+ status = "okay";
+ flash@0 {
+ compatible = "m25p80"; /* 32MB */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <10800>; /* Based on DC1 spec */
+ partition@qspi-fsbl-uboot { /* for testing purpose */
+ label = "qspi-fsbl-uboot";
+ reg = <0x0 0x10>;
+ };
+ partition@qspi-linux { /* for testing purpose */
+ label = "qspi-linux";
+ reg = <0x10 0x50>;
+ };
+ partition@qspi-device-tree { /* for testing purpose */
+ label = "qspi-device-tree";
+ reg = <0x60 0x2>;
+ };
+ partition@qspi-rootfs { /* for testing purpose */
+ label = "qspi-rootfs";
+ reg = <0x62 0x5E>;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&sdhci1 {
+ status = "okay";
+ no-1-8-v;
+ xlnx,mio_bank = <1>;
+};
diff --git a/board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
b/board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
new file mode 100644
index ..54cc82869820
--- /dev/null
+++ b/board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
@@ -0,0 +1,523 @@
+/*
+ * (c) Copyright 2015 Xilinx, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+
+static unsigned long psu_pll_init_data(void)
+{
+ psu_mask_write(0xFF5E0034, 0xFE7FEDEFU, 0x7E4E2C62U);
+ psu_mask_write(0xFF5E0030, 0x00717F00U, 0x00013C00U);
+ psu_mask_write(0xFF5E0030, 0x0008U, 0x0008U);
+ psu_mask_write(0xFF5E0030, 0x0001U, 0x0001U);
+ psu_mask_write(0xFF5E0030, 0x0001U, 0xU);
+ mask_poll(0xFF5E0040, 0x0002U);
+ psu_mask_write(0xFF5E0030, 0x0008U, 0xU);
+ psu_mask_write(0xFF5E0048, 0x3F00U, 0x0200U);
+ psu_mask_write(0xFF5E0024, 0xFE7FEDEFU, 0x7E4B0C82U);
+ psu_mask_write(0xFF5E0020, 0x00717F00U, 0x00015A00U);
+ psu_mask_write(0xFF5E0020, 0x0008U, 0x0008U);
+ psu_mask_write(0xFF5E0020, 0x0001U, 0x0001U);
+ psu_mask_write(0xFF5E0020, 0x0001U, 0xU);
+ mask_poll(0xFF5E0040, 0x0001U);
+ psu_mask_write(0xFF5E0
[U-Boot] [PATCH] env: Relocate env drivers if manual reloc is required
From: Siva Durga Prasad Paladugu
Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
env/common.c | 1 +
env/env.c | 21 +
include/environment.h | 5 +
3 files changed, 27 insertions(+)
diff --git a/env/common.c b/env/common.c
index f21ff7009695..d282868ee51b 100644
--- a/env/common.c
+++ b/env/common.c
@@ -227,6 +227,7 @@ void env_relocate(void)
{
#if defined(CONFIG_NEEDS_MANUAL_RELOC)
env_reloc();
+ fix_envdriver();
env_htab.change_ok += gd->reloc_off;
#endif
if (gd->env_valid == ENV_INVALID) {
diff --git a/env/env.c b/env/env.c
index 3795dbc24e2b..15a0597100f4 100644
--- a/env/env.c
+++ b/env/env.c
@@ -10,6 +10,27 @@
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
+void fix_envdriver(void)
+{
+ struct env_driver *drv;
+ const int n_ents = ll_entry_count(struct env_driver, env_driver);
+ struct env_driver *entry;
+
+ drv = ll_entry_start(struct env_driver, env_driver);
+ for (entry = drv; entry != drv + n_ents; entry++) {
+ if (entry->name)
+ entry->name += gd->reloc_off;
+ if (entry->load)
+ entry->load += gd->reloc_off;
+ if (entry->save)
+ entry->save += gd->reloc_off;
+ if (entry->init)
+ entry->init += gd->reloc_off;
+ }
+}
+#endif
+
static struct env_driver *_env_driver_lookup(enum env_location loc)
{
struct env_driver *drv;
diff --git a/include/environment.h b/include/environment.h
index 1b52353365ed..41df52756bde 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -314,6 +314,11 @@ int env_load(void);
*/
int env_save(void);
+/**
+ * fix_envdriver() - Updates envdriver as per relocation
+ */
+void fix_envdriver(void);
+
void eth_parse_enetaddr(const char *addr, uint8_t *enetaddr);
int eth_env_get_enetaddr(const char *name, uint8_t *enetaddr);
int eth_env_set_enetaddr(const char *name, const uint8_t *enetaddr);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mv_sdhci: zero out sdhci_host structure
Hi Matt, On 27.03.2018 19:53, Matt Pelland wrote: The mv_sdhci driver was not zeroing the sdhci_host structure it allocates causing random access violations in parts of the mmc core where the "ops" member pointers are checked and called if not NULL. Signed-off-by: Matt Pelland --- drivers/mmc/mv_sdhci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c index 69aa87babe..afc03f75a0 100644 --- a/drivers/mmc/mv_sdhci.c +++ b/drivers/mmc/mv_sdhci.c @@ -74,6 +74,8 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks) return -ENOMEM; } + memset(host, 0, sizeof(struct sdhci_host)); + host->name = MVSDH_NAME; host->ioaddr = (void *)regbase; host->quirks = quirks; Thanks for finding this. But please use calloc() instead of malloc() and the memset can be dropped. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: zynq_gem: Use max-speed property from dt
From: Siva Durga Prasad Paladugu
Add support to use max-speed property from dt for
determining the supported speed. Use 1000Mbps as
default.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
drivers/net/zynq_gem.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 1390c36c6141..dd36a8c22aa7 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -182,6 +182,7 @@ struct zynq_gem_priv {
int phy_of_handle;
struct mii_dev *bus;
struct clk clk;
+ u32 max_speed;
bool int_pcs;
};
@@ -341,6 +342,12 @@ static int zynq_phy_init(struct udevice *dev)
priv->phydev->supported &= supported | ADVERTISED_Pause |
ADVERTISED_Asym_Pause;
+ if (priv->max_speed) {
+ ret = phy_set_supported(priv->phydev, priv->max_speed);
+ if (ret)
+ return ret;
+ }
+
priv->phydev->advertising = priv->phydev->supported;
if (priv->phy_of_handle > 0)
@@ -704,6 +711,8 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
}
priv->interface = pdata->phy_interface;
+ priv->max_speed = fdtdec_get_uint(gd->fdt_blob, priv->phy_of_handle,
+ "max-speed", SPEED_1000);
priv->int_pcs = fdtdec_get_bool(gd->fdt_blob, node,
"is-internal-pcspma");
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: mvneta: support setting hardware address
Hi Matt,
(added Joe as network custodian to Cc)
On 27.03.2018 19:18, Matt Pelland wrote:
mvneta already supports setting the MAC address but this was only done
internally when some other part of U-Boot tries to actually use the
interface. This commit exposes this functionality to the ethernet core
code so that the MAC addresses of all interfaces are configured
correctly even if they are not used before loading Linux.
Signed-off-by: Matt Pelland
---
drivers/net/mvneta.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index 83e3153768..fdff772178 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -890,6 +890,16 @@ static void mvneta_mac_addr_set(struct mvneta_port *pp,
unsigned char *addr,
mvneta_set_ucast_addr(pp, addr[5], queue);
}
+static int mvneta_write_hwaddr(struct udevice *dev)
+{
+ mvneta_mac_addr_set(
+ dev_get_priv(dev),
+ ((struct eth_pdata *)dev_get_platdata(dev))->enetaddr,
+ rxq_def);
+
+ return 0;
+}
+
/* Handle rx descriptor fill by setting buf_cookie and buf_phys_addr */
static void mvneta_rx_desc_fill(struct mvneta_rx_desc *rx_desc,
u32 phys_addr, u32 cookie)
@@ -1753,6 +1763,7 @@ static const struct eth_ops mvneta_ops = {
.send = mvneta_send,
.recv = mvneta_recv,
.stop = mvneta_stop,
+ .write_hwaddr = mvneta_write_hwaddr,
};
static int mvneta_ofdata_to_platdata(struct udevice *dev)
Reviewed-by: Stefan Roese
Joe, will you pick this one up (if you have no objections)? Or should I
push it via the Marvell repo?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit
On 04/12/2018 11:42 AM, Alexander Graf wrote: [...] >>> None of it is enabled in SPL :). The „efi partition“ option is a >>> misnomer - it really just enables GPT partition table support which >>> are widely in use with Android for example. >> I suspect we can disable that, since SoCFPGA boots from this a2 >> partition type on MBR only (bootrom limitation). > > > That's a very good point. If the bootrom does not support GPT, there is > basically no point in enabling it in SPL, I agree. Patch please ! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit
On 04/12/2018 11:17 AM, Marek Vasut wrote: On 04/12/2018 11:15 AM, Alexander Graf wrote: Am 12.04.2018 um 10:37 schrieb Marek Vasut : On 04/12/2018 10:01 AM, Alexander Graf wrote: On 11.04.18 16:43, Dinh Nguyen wrote: On Wed, Apr 11, 2018 at 7:55 AM, Alexander Graf wrote: On 04/11/2018 02:37 PM, Marek Vasut wrote: On 04/11/2018 02:26 PM, Tom Rini wrote: On Wed, Apr 11, 2018 at 10:12:42AM +0200, Marek Vasut wrote: On 04/11/2018 04:52 AM, Dinh Nguyen wrote: [...] u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la spl/u-boot-spl.bin HEAD is now at f3dd87e0b9 Prepare v2018.01 -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la spl/u-boot-spl.bin HEAD is now at f95ab1fb6e Prepare v2018.03 -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin Try bisecting out the commit which caused this 7 kiB growth between 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it was at 53 kiB for a while (2017.05 is also ~53 kiB) Do you have a size constraint and are not setting the correct CONFIG options so that it becomes a build failure? Doing the bisect points me to this commit: commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2 Author: Tom Rini Date: Sat Feb 10 16:54:38 2018 -0500 configs: Re-sync with CONFIG_DISTRO_DEFAULTS A number of platforms include config_distro_defaults.h but do not enable CONFIG_DISTRO_DEFAULTS. As they plainly intended to, set that flag and re-sync config files. Signed-off-by: Tom Rini Doing a revert of the above commit shrinks the SPL back down to ~7 kiB. Dinh It looks like the enablement of CONFIG_DISTRO_DEFAULTS, enables these configs: CONFIG_ISO_PARTITION=y CONFIG_SPL_ISO_PARTITION=y # CONFIG_AMIGA_PARTITION is not set # CONFIG_SPL_AMIGA_PARTITION is not set CONFIG_EFI_PARTITION=y CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128 CONFIG_EFI_PARTITION_ENTRIES_OFF=0 CONFIG_SPL_EFI_PARTITION=y CONFIG_PARTITION_UUIDS=y CONFIG_SPL_PARTITION_UUIDS=y # CONFIG_PARTITION_TYPE_GUID is not set Which is contributing to the SPL growth. Turning the following config options off subtracts 7k from the SPL: +# CONFIG_SPL_ISO_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set Not sure if these are needed? IMO not on SoCFPGA. Also CCing Tom. Yes, all of those options are part of CONFIG_DISTRO_DEFAULTS and are needed so that booting from various distro media works. In SPL on boards which usually boot from SDMMC or QSPI NOR ? How is EFI or ISO partition needed there ? I don't think ISO partitioning is needed in SPL. However, for GPT I'm not 100% sure. People tend to go with GPT more often than not these days - and to be able to fetch U-Boot proper from a GPT partition may make sense. How much reduction do you get when you only disable CONFIG_SPL_ISO_PARTITION? ~3 kiB Ok, so that's not enough to get us back to reasonable space, but it's at least a step in the right direction. I sent a patch to disable CONFIG_SPL_ISO_PARTITION for everyone by default ;). If we remove all printfs from part_efi.c we could for example gain another 1.5kb. But I'm not sure that's worth it - and if feels like we're shaving on the wrong end at this point. Is there any other big chunk in there that wastes space? The entire EFI support, which is never used on SoCFPGA to my knowledge, esp. in SPL . None of it is enabled in SPL :). The „efi partition“ option is a misnomer - it really just enables GPT partition table support which are widely in use with Android for example. I suspect we can disable that, since SoCFPGA boots from this a2 partition type on MBR only (bootrom limitation). That's a very good point. If the bootrom does not support GPT, there is basically no point in enabling it in SPL, I agree. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm64: Add SMC and HVC commands
Okay, i see. The change is the replacement of the dependency of ARM64 to ARM_SMCCC in Kconfig. If you think it's necessary to issue a v4 and document the changes properly please let me know and I'll do so. Michalis On 04/11/2018 03:36 PM, Simon Glass wrote: On 9 April 2018 at 09:17, Michalis Pappas wrote: This patch adds smc and hvc commands, that allow issuing Secure Monitor Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention. Add Kconfig items to allow each command can be individually enabled. Signed-off-by: Michalis Pappas --- cmd/Kconfig | 14 ++ cmd/Makefile | 2 ++ cmd/smccc.c | 72 3 files changed, 88 insertions(+) create mode 100644 cmd/smccc.c Reviewed-by: Simon Glass But you need a change list ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit
On 04/12/2018 11:15 AM, Alexander Graf wrote: > > >> Am 12.04.2018 um 10:37 schrieb Marek Vasut : >> >>> On 04/12/2018 10:01 AM, Alexander Graf wrote: >>> >>> On 11.04.18 16:43, Dinh Nguyen wrote: > On Wed, Apr 11, 2018 at 7:55 AM, Alexander Graf wrote: >> On 04/11/2018 02:37 PM, Marek Vasut wrote: >> >>> On 04/11/2018 02:26 PM, Tom Rini wrote: >>> On Wed, Apr 11, 2018 at 10:12:42AM +0200, Marek Vasut wrote: On 04/11/2018 04:52 AM, Dinh Nguyen wrote: [...] u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la spl/u-boot-spl.bin HEAD is now at f3dd87e0b9 Prepare v2018.01 -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la spl/u-boot-spl.bin HEAD is now at f95ab1fb6e Prepare v2018.03 -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin Try bisecting out the commit which caused this 7 kiB growth between 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it was at 53 kiB for a while (2017.05 is also ~53 kiB) >>> >>> Do you have a size constraint and are not setting the correct CONFIG >>> options so that it becomes a build failure? >>> >>> Doing the bisect points me to this commit: >>> >>> commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2 >>> Author: Tom Rini >>> Date: Sat Feb 10 16:54:38 2018 -0500 >>> >>> configs: Re-sync with CONFIG_DISTRO_DEFAULTS >>> >>> A number of platforms include config_distro_defaults.h but do >>> not enable >>> CONFIG_DISTRO_DEFAULTS. As they plainly intended to, set that >>> flag and >>> re-sync config files. >>> >>> Signed-off-by: Tom Rini >>> >>> Doing a revert of the above commit shrinks the SPL back down to ~7 >>> kiB. >>> >>> Dinh >>> >> It looks like the enablement of CONFIG_DISTRO_DEFAULTS, enables these >> configs: >> >> CONFIG_ISO_PARTITION=y >> CONFIG_SPL_ISO_PARTITION=y >> # CONFIG_AMIGA_PARTITION is not set >> # CONFIG_SPL_AMIGA_PARTITION is not set >> CONFIG_EFI_PARTITION=y >> CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128 >> CONFIG_EFI_PARTITION_ENTRIES_OFF=0 >> CONFIG_SPL_EFI_PARTITION=y >> CONFIG_PARTITION_UUIDS=y >> CONFIG_SPL_PARTITION_UUIDS=y >> # CONFIG_PARTITION_TYPE_GUID is not set >> >> Which is contributing to the SPL growth. >> > Turning the following config options off subtracts 7k from the SPL: > > +# CONFIG_SPL_ISO_PARTITION is not set > +# CONFIG_SPL_EFI_PARTITION is not set > > Not sure if these are needed? IMO not on SoCFPGA. Also CCing Tom. >>> >>> Yes, all of those options are part of CONFIG_DISTRO_DEFAULTS and are >>> needed so that booting from various distro media works. >> >> In SPL on boards which usually boot from SDMMC or QSPI NOR ? How is EFI >> or ISO partition needed there ? > > > > I don't think ISO partitioning is needed in SPL. However, for GPT I'm not > 100% sure. People tend to go with GPT more often than not these days - and > to be able to fetch U-Boot proper from a GPT partition may make sense. > > How much reduction do you get when you only disable > CONFIG_SPL_ISO_PARTITION? > ~3 kiB >>> >>> Ok, so that's not enough to get us back to reasonable space, but it's at >>> least a step in the right direction. I sent a patch to disable >>> CONFIG_SPL_ISO_PARTITION for everyone by default ;). >>> >>> If we remove all printfs from part_efi.c we could for example gain >>> another 1.5kb. But I'm not sure that's worth it - and if feels like >>> we're shaving on the wrong end at this point. >>> >>> Is there any other big chunk in there that wastes space? >> >> The entire EFI support, which is never used on SoCFPGA to my knowledge, >> esp. in SPL . > > None of it is enabled in SPL :). The „efi partition“ option is a misnomer - > it really just enables GPT partition table support which are widely in use > with Android for example. I suspect we can disable that, since SoCFPGA boots from this a2 partition type on MBR only (bootrom limitation). -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit
> Am 12.04.2018 um 10:37 schrieb Marek Vasut : > >> On 04/12/2018 10:01 AM, Alexander Graf wrote: >> >> >>> On 11.04.18 16:43, Dinh Nguyen wrote: On Wed, Apr 11, 2018 at 7:55 AM, Alexander Graf wrote: > On 04/11/2018 02:37 PM, Marek Vasut wrote: > >> On 04/11/2018 02:26 PM, Tom Rini wrote: >> >>> On Wed, Apr 11, 2018 at 10:12:42AM +0200, Marek Vasut wrote: >>> >>> On 04/11/2018 04:52 AM, Dinh Nguyen wrote: >>> [...] >>> >>> u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la >>> spl/u-boot-spl.bin >>> HEAD is now at f3dd87e0b9 Prepare v2018.01 >>> -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin >>> >>> u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la >>> spl/u-boot-spl.bin >>> HEAD is now at f95ab1fb6e Prepare v2018.03 >>> -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin >>> >>> Try bisecting out the commit which caused this 7 kiB growth between >>> 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it >>> was >>> at 53 kiB for a while (2017.05 is also ~53 kiB) >> >> Do you have a size constraint and are not setting the correct CONFIG >> options so that it becomes a build failure? >> >> Doing the bisect points me to this commit: >> >> commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2 >> Author: Tom Rini >> Date: Sat Feb 10 16:54:38 2018 -0500 >> >> configs: Re-sync with CONFIG_DISTRO_DEFAULTS >> >> A number of platforms include config_distro_defaults.h but do >> not enable >> CONFIG_DISTRO_DEFAULTS. As they plainly intended to, set that >> flag and >> re-sync config files. >> >> Signed-off-by: Tom Rini >> >> Doing a revert of the above commit shrinks the SPL back down to ~7 >> kiB. >> >> Dinh >> > It looks like the enablement of CONFIG_DISTRO_DEFAULTS, enables these > configs: > > CONFIG_ISO_PARTITION=y > CONFIG_SPL_ISO_PARTITION=y > # CONFIG_AMIGA_PARTITION is not set > # CONFIG_SPL_AMIGA_PARTITION is not set > CONFIG_EFI_PARTITION=y > CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128 > CONFIG_EFI_PARTITION_ENTRIES_OFF=0 > CONFIG_SPL_EFI_PARTITION=y > CONFIG_PARTITION_UUIDS=y > CONFIG_SPL_PARTITION_UUIDS=y > # CONFIG_PARTITION_TYPE_GUID is not set > > Which is contributing to the SPL growth. > Turning the following config options off subtracts 7k from the SPL: +# CONFIG_SPL_ISO_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set Not sure if these are needed? >>> >>> IMO not on SoCFPGA. Also CCing Tom. >> >> Yes, all of those options are part of CONFIG_DISTRO_DEFAULTS and are >> needed so that booting from various distro media works. > > In SPL on boards which usually boot from SDMMC or QSPI NOR ? How is EFI > or ISO partition needed there ? I don't think ISO partitioning is needed in SPL. However, for GPT I'm not 100% sure. People tend to go with GPT more often than not these days - and to be able to fetch U-Boot proper from a GPT partition may make sense. How much reduction do you get when you only disable CONFIG_SPL_ISO_PARTITION? >>> >>> ~3 kiB >> >> Ok, so that's not enough to get us back to reasonable space, but it's at >> least a step in the right direction. I sent a patch to disable >> CONFIG_SPL_ISO_PARTITION for everyone by default ;). >> >> If we remove all printfs from part_efi.c we could for example gain >> another 1.5kb. But I'm not sure that's worth it - and if feels like >> we're shaving on the wrong end at this point. >> >> Is there any other big chunk in there that wastes space? > > The entire EFI support, which is never used on SoCFPGA to my knowledge, > esp. in SPL . None of it is enabled in SPL :). The „efi partition“ option is a misnomer - it really just enables GPT partition table support which are widely in use with Android for example. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] chiliSOM: USB bug
Marcin Niestrój wrote: On 12.04.2018 06:37, sdrb wrote: Hi Marcin, Marcin Niestroj wrote: Hi Witold, On 11.04.2018 08:18, sdrb wrote: Hi, I use Grinn's chiliSOM and very old U-boot 2014.07 on it. Unfortunately the newest u-boot doesn't run SPL properly - so I'm forced to use 2014.07 version. What are your problems exactly with SPL? What version of chiliSOM does you board have? Mainline u-boot with SPL runs successfully on chiliboard 1.1 (containing chiliSOM 2.2). I've got ChiliSOM 2.2 version. I don't use chiliboard - I've got only chiliSOM 2.2 integrated in our carrying board. The problem is that SPL is not starting as good as in 2014.07 version. I mean - firmware shows only a few 'C' letters and then it hungs in some infinite loop: CCC but when at that moment I press Reset button it starts but unfortunately something is going wrong because it restarts: U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 So - to run newest u-boot I need to power-on board and then press reset. Could you describe what is you BOOT[4:0] configuration? And you want to boot from MMC1, right? If I read the BOOT[4:0] properly it is: 0011. I want to boot from SD card. If you are booting u-boot 2014.07 version, do you still see C on the beginning? Yes I have noticed something else on chiliboard. Device is normally powered on with no problems (after plugging in USB cable for example). But after it powers off (to RTC only), then I push power button to wakeup device, it shows CCC in infinite loop. To recover from this state I need to plug out SD card and plug it in once again. Then device boots correctly. Thought this is hardware issue and didn't have enough time to look at that. I wonder if both issues have the same root cause... I have also noticed that sometimes the whole system is not starting properly and still shows 'C' letters. And yes - I also replug SD card or turn off the power to fix the problem. I dig a litte in source of latest uboot and noticed that the last procedure which is invoked in SPL is jump_to_image_no_args(). This proc tries to go to 0x8080 addr and then reset appears. But before it tries to go into this addr it successfully reads u-boot.img file. So rather the problem is in invocation of TPL than in SPL. I wonder why the u-boot.img file is only 389392 bytes long while in old u-boot it was 1.7 MB. Additionally - I see no device tree source file for chilisom in git repo but the configuration file mention it in CONFIG_DEFAULT_FDT_FILE. This configuration sets name of dts file to be used with Linux kernel. Ok, I thought that u-boot uses it for its own purposes. Regards, WK ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 02/11] usb: dwc3-of-simple: Add support for DRA7/AM57 platforms.
On 04/12/2018 10:41 AM, Jean-Jacques Hiblot wrote:
> Add the compatibility with "ti,dwc3" and enable it by default if DM_USB
> is enabled.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> drivers/usb/host/Kconfig | 1 +
> drivers/usb/host/dwc3-of-simple.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 6ea9621..3455e81 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -24,6 +24,7 @@ config USB_XHCI_DWC3
> config USB_XHCI_DWC3_OF_SIMPLE
> bool "DesignWare USB3 DRD Generic OF Simple Glue Layer"
> depends on DM_USB
> + default y if DRA7XX
> help
> Support USB2/3 functionality in simple SoC integrations with
> USB controller based on the DesignWare USB3 IP Core.
> diff --git a/drivers/usb/host/dwc3-of-simple.c
> b/drivers/usb/host/dwc3-of-simple.c
> index 54a5f60..abc3928 100644
> --- a/drivers/usb/host/dwc3-of-simple.c
> +++ b/drivers/usb/host/dwc3-of-simple.c
> @@ -95,6 +95,7 @@ static int dwc3_of_simple_remove(struct udevice *dev)
>
> static const struct udevice_id dwc3_of_simple_ids[] = {
> { .compatible = "amlogic,meson-gxl-dwc3" },
> + { .compatible = "ti,dwc3" },
> { }
> };
>
>
Applied to USB , thanks
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
