Re: [U-Boot] [PATCH 1/1] efi_loader: PSCI reset and shutdown for EL1
On Thu, 11 Oct 2018 at 17:50, Sumit Garg wrote:
>
> On Thu, 11 Oct 2018 at 08:56, Heinrich Schuchardt wrote:
> >
> > When starting an aarch64 system under QEMU it runs in EL1/EL0. So we have
> > to use HVC for PSCI calls.
> >
> > Without the patch resetting Linux started with bootefi under
> > qemu-system-aarch64 results in a crash.
> >
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > arch/arm/cpu/armv8/fwcall.c | 14 +-
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
>
> I too was facing this crash and got it fixed before I saw this patch today.
>
> Tested-by: Sumit Garg
>
> > diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
> > index 0ba3dad8cc..f1b6e60bae 100644
> > --- a/arch/arm/cpu/armv8/fwcall.c
> > +++ b/arch/arm/cpu/armv8/fwcall.c
> > @@ -78,12 +78,10 @@ void __efi_runtime smc_call(struct pt_regs *args)
> > }
> >
> > /*
> > - * For now, all systems we support run at least in EL2 and thus
> > - * trigger PSCI calls to EL3 using SMC. If anyone ever wants to
> > - * use PSCI on U-Boot running below a hypervisor, please detect
> > - * this and set the flag accordingly.
> > + * This flag controls if SMC or HVC is used to call PSCI services. If
> > U-Boot has
> > + * been called by a hypervisor (e.g. QEMU), it has to be set to false.
> > */
> > -static const __efi_runtime_data bool use_smc_for_psci = true;
> > +static __efi_runtime_data bool use_smc_for_psci = true;
> >
> > void __noreturn __efi_runtime psci_system_reset(void)
> > {
> > @@ -138,6 +136,12 @@ void reset_misc(void)
> > }
> >
> > #ifdef CONFIG_EFI_LOADER
> > +efi_status_t efi_reset_system_init(void)
> > +{
> > + use_smc_for_psci = (current_el() >= 2);
It doesn't seems to be a generic solution as u-boot could be loaded at
EL1 with PSCI calls still implemented in EL3 (smc for PSCI) in cases
like EL2 (virt. extension) isn't implemented on platform etc. So I
would probably suggest to use device tree parsing for PSCI method to
configure this variable here.
-Sumit
> > + return EFI_SUCCESS;
> > +}
> > +
> > void __efi_runtime EFIAPI efi_reset_system(
> > enum efi_reset_type reset_type,
> > efi_status_t reset_status,
> > --
> > 2.19.1
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: qemu-arm: enable USB boot in distro boot with UEFI
With this patch which adds a removable USB mass storage to a list of bootable devices, USB boot is supported in distro boot if UEFI is configured. Signed-off-by: AKASHI Takahiro --- include/configs/qemu-arm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h index 0e66f946dde5..395cb911f5fe 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -45,6 +45,7 @@ #define CONFIG_ENV_SECT_SIZE SZ_1M #define BOOT_TARGET_DEVICES(func) \ + func(USB, usb, 0) \ func(SCSI, scsi, 0) \ func(DHCP, dhcp, na) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] efi_loader: support USB boot in distro boot script
With this patch, a removable USB mass storage device attached to the system
will also be scanned to find and boot an EFI binary (that is BOOTEFI_NAME,
see config_distro_bootcmd.h).
Signed-off-by: AKASHI Takahiro
---
include/config_distro_bootcmd.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 76e12b7bf4ee..dd47e27d6835 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -26,7 +26,12 @@
*/
#define BOOTENV_SHARED_BLKDEV_BODY(devtypel) \
- "if " #devtypel " dev ${devnum}; then " \
+ "if test " #devtypel " = usb ; then " \
+ "if " #devtypel " info ${devnum}; then " \
+ "setenv devtype " #devtypel "; " \
+ "run scan_dev_for_boot_part; " \
+ "fi;" \
+ "elif " #devtypel " dev ${devnum}; then " \
"setenv devtype " #devtypel "; " \
"run scan_dev_for_boot_part; " \
"fi\0"
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] uefi: support USB boot in distro boot
I think that it will be nice if we can install a distro linux from, say, USB memory with ISO image, to a hard disk off the shelf. Even with the current u-boot, we can do this by having two *scsi* disks, but using an USB device looks more realistic, doesn't it? This patch set give us a base for this; I was able to successfully start a familiar "install" screen on qemu, using an ubuntu server ISO image for arm64. CUI of course. Thanks, -Takahiro Akashi AKASHI Takahiro (3): efi_loader: support USB boot in distro boot script ARM: qemu-arm: enable usb mass storage in default configuration ARM: qemu-arm: enable USB boot in distro boot with UEFI configs/qemu_arm64_defconfig| 1 + configs/qemu_arm_defconfig | 1 + include/config_distro_bootcmd.h | 7 ++- include/configs/qemu-arm.h | 1 + 4 files changed, 9 insertions(+), 1 deletion(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: qemu-arm: enable usb mass storage in default configuration
This is a preparatory patch so that USB boot will be supported in distro boot script by default. Signed-off-by: AKASHI Takahiro --- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig index 7fd726fdda35..91c97181ab9f 100644 --- a/configs/qemu_arm64_defconfig +++ b/configs/qemu_arm64_defconfig @@ -32,3 +32,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y +CONFIG_USB_STORAGE=y diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig index fbceaf3c52f3..4f4f9b791415 100644 --- a/configs/qemu_arm_defconfig +++ b/configs/qemu_arm_defconfig @@ -32,3 +32,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y +CONFIG_USB_STORAGE=y -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: qemu-arm: define fdt_addr_r
This variable, fdt_addr_t, is missing in the current qemu-arm.h while it seems to be mandatory, at least, to run distro_bootcmd as expected. So just add its definition. A size of 1MB would be enough. Signed-off-by: AKASHI Takahiro --- include/configs/qemu-arm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h index 91fb8d47edf8..0e66f946dde5 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -55,6 +55,7 @@ "fdt_high=0x\0" \ "initrd_high=0x\0" \ "fdt_addr=0x4000\0" \ + "fdt_addr_r=0x4010\0" \ "scriptaddr=0x4020\0" \ "pxefile_addr_r=0x4030\0" \ "kernel_addr_r=0x4040\0" \ -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] efi_loader: rework fdt handling in distro boot script
The current scenario for default UEFI booting, scan_dev_for_efi, has
several issues:
* invoke 'bootmgr' only if BOOTEFI_NAME binary does exit even though
'bootmgr' can and should work independently whether or not the binary
exist,
* always assume that a 'fdtfile' variable is defined,
* redundantly check for 'fdt_addr_r' in boot_efi_binary
In this patch, all the issues above are sorted out.
Signed-off-by: AKASHI Takahiro
---
include/config_distro_bootcmd.h | 43 -
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 373fee78a999..76e12b7bf4ee 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -124,42 +124,41 @@
#define BOOTENV_SHARED_EFI\
"boot_efi_binary="\
- "if fdt addr ${fdt_addr_r}; then "\
- "bootefi bootmgr ${fdt_addr_r};" \
- "else " \
- "bootefi bootmgr ${fdtcontroladdr};" \
- "fi;" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
- "if fdt addr ${fdt_addr_r}; then "\
- "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
- "else " \
- "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
- "fi\0"\
+ "bootefi ${kernel_addr_r} ${efi_fdt_addr};\0" \
\
"load_efi_dtb=" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
- "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
+ "${fdt_addr_r} ${prefix}${efi_fdtfile};" \
+ "if fdt addr ${fdt_addr_r}; then "\
+ "setenv efi_fdt_addr ${fdt_addr_r}; " \
+ "else; " \
+ "setenv efi_fdt_addr ${fdtcontroladdr}; " \
+ "fi;\0" \
\
- "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
- "scan_dev_for_efi=" \
+ "set_efi_fdt_addr=" \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
- "for prefix in ${efi_dtb_prefixes}; do " \
- "if test -e ${devtype} " \
- "${devnum}:${distro_bootpart} " \
- "${prefix}${efi_fdtfile}; then " \
- "run load_efi_dtb; " \
- "fi;" \
- "done;" \
+ "if test x${efi_fdtfile} != x -a x{$fdt_addr_r} != x ; then " \
+ "run load_efi_dtb; " \
+ "else; " \
+ "setenv efi_fdt_addr ${fdtcontroladdr}; " \
+ "fi; "\
+ "setenv efi_fdtfile\0"\
+ \
+ "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+ "scan_dev_for_efi=" \
+ "run set_efi_fdt_addr; " \
+ "bootefi bootmgr ${efi_fdt_addr};"\
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
"efi/boot/"BOOTEFI_NAME"; " \
"run boot_efi_binary; " \
"echo EFI LOAD FAILED: continuing...; " \
- "fi; "\
- "setenv efi_fdtfile\0"
+ "fi; "\
+ "setenv efi_fdt_addr\0"
Re: [U-Boot] [PATCH 2/4] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build
Hi Heinrich, On Fri, Oct 12, 2018 at 2:04 AM Heinrich Schuchardt wrote: > > On 10/11/2018 03:53 AM, Bin Meng wrote: > > With the '-march=core2' fix, it seems that we have some luck that > > the 64-bit U-Boot boots again. However if we examine the disassembly > > codes there are still SSE instructions elsewhere which means passing > > cpu type to GCC is not enough to prevent it from generating these > > instructions. A simple test case is doing a 'bootefi selftest' from > > the U-Boot shell and it leads to a reset too. > > I can confirm that an unexpected reset patch occurs without the patch. > I think you mean "bootefi selftest" reset, right? > > > > The 'bootefi selftest' reset is even seen with the image created by > > the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04. > > > > To make sure no MMX/SSE instruction sets are generated, tell GCC not > > to do this. Note AVX is out of the question as CORE2 is old enough > > to support AVX yet. > > > > Signed-off-by: Bin Meng > > --- > > > > arch/x86/config.mk | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > > index 576501e..8151e47 100644 > > --- a/arch/x86/config.mk > > +++ b/arch/x86/config.mk > > @@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y) > > PLATFORM_CPPFLAGS += -march=i386 -m32 > > else > > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common > > -march=core2 -m64 > > +PLATFORM_CPPFLAGS += -mno-mmx -mno-sse > > According to https://wiki.osdev.org/SSE SSE has to be initialized. > Otherwise SSE instructions lead to an undefined instruction exception. > Is it this initialization that we lack? If this is your motivation > please, state it in the commit message. > Yes, it's intentional. U-Boot as a bootloader does not want to handle these advanced SIMD stuff. > I think this patch could be squashed with the prior one. They are different thing, although they solved similar reset. The first patch is adding the -march=core2 which is the counterpart of -march=i386 for 32-bit U-Boot. This patch is to disable MMX/SSE completely which I think deserve a separate patch. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing
Hi Heinrich, On Fri, Oct 12, 2018 at 6:10 AM Heinrich Schuchardt wrote: > > On 10/11/2018 03:57 AM, Bin Meng wrote: > > Hi Heinrich, > > > > On Thu, Oct 11, 2018 at 9:48 AM Bin Meng wrote: > >> > >> Add qemu-x86_64 to the list of targets we use for test.py runs. > >> > >> Signed-off-by: Bin Meng > >> > >> --- > >> testp.py testing is currently failing at 'bootefi selftest'. > >> > > > > Can you try this series for the 'bootefi selftest' testing? > > I am clueless why the EFI subsystems is failing completely on > qemu-x86_64_defconfig. > > Any printf() or puts() statement I put into > lib/efi_loader/efi_boottime.c leads to no output at all. > > I connected gdb with > > gdb u-boot -ex 'target remote localhost:1234' > add-symbol-file u-boot > > But the debugger did not stop at breakpoints. I encountered exactly the same issue that breakpoint is not hit when debugging this endless loop issue. And I finally figured it out: The symbol table should not be loaded to , instead it needs to be loaded to . The .text.start was introduced in commit 7e21fbca26d18327cf7cabaad08df276a06a07d8 "efi_loader: Rename sections to allow for implicit data", and its commit message mentioned: [agraf: Fix x86_64 breakage], although I was not sure what x86_64 breakage was fixed. Please have a try. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] efi_loader: set image_base and image_size to correct values
On Thu, Oct 11, 2018 at 04:18:33PM +0200, Heinrich Schuchardt wrote:
> On 10/11/2018 01:11 PM, AKASHI Takahiro wrote:
> > Currently, image's image_base points to an address where the image was
> > temporarily uploaded for further loading. Since efi_loader relocates
> > the image to final destination, image_base and image_size should reflect
> > that.
> >
> > This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
> > which shows that 'Unload' function doesn't fit into a range suggested by
> > image_base and image_size.
> > TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/
> > LoadedImageBBTestMain.c:1002
> >
> > Changes in this patch also includes:
> > * reverts a patch, "efi_loader: save image relocation address
> > and size" since newly added fields are no longer needed.
> > * copy PE headers as well since those information will be needed
> > for module loading, in particular, at gurb.
> > (This bug was reported by Heinrich.)
> >
> > Signed-off-by: AKASHI Takahiro
> > Reported-by: Heinrich Schuchardt
> > ---
> > lib/efi_loader/efi_image_loader.c | 22 +++---
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_image_loader.c
> > b/lib/efi_loader/efi_image_loader.c
> > index a18ce0a5705e..d1b6c0d3cdf2 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -59,10 +59,10 @@ static efi_status_t efi_print_image_info(struct
> > efi_loaded_image_obj *obj,
> > {
> > printf("UEFI image");
> > printf(" [0x%p:0x%p]",
> > - obj->reloc_base, obj->reloc_base + obj->reloc_size - 1);
> > - if (pc && pc >= obj->reloc_base &&
> > - pc < obj->reloc_base + obj->reloc_size)
> > - printf(" pc=0x%zx", pc - obj->reloc_base);
> > + image->image_base, image->image_base + image->image_size - 1);
> > + if (pc && pc >= image->image_base &&
> > + pc < image->image_base + image->image_size)
> > + printf(" pc=0x%zx", pc - image->image_base);
> > if (image->file_path)
> > printf(" '%pD'", image->file_path);
> > printf("\n");
> > @@ -212,7 +212,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> > void *efi,
> > int rel_idx = IMAGE_DIRECTORY_ENTRY_BASERELOC;
> > void *entry;
> > uint64_t image_base;
> > - uint64_t image_size;
> > unsigned long virt_size = 0;
> > int supported = 0;
> >
> > @@ -256,7 +255,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> > void *efi,
> > IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
> > IMAGE_OPTIONAL_HEADER64 *opt = >OptionalHeader;
> > image_base = opt->ImageBase;
> > - image_size = opt->SizeOfImage;
> > efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> > efi_reloc = efi_alloc(virt_size,
> > loaded_image_info->image_code_type);
> > @@ -272,7 +270,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> > void *efi,
> > } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
> > IMAGE_OPTIONAL_HEADER32 *opt = >OptionalHeader;
> > image_base = opt->ImageBase;
> > - image_size = opt->SizeOfImage;
> > efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> > efi_reloc = efi_alloc(virt_size,
> > loaded_image_info->image_code_type);
> > @@ -291,6 +288,11 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> > void *efi,
> > return NULL;
> > }
> >
> > + /* Copy PE headers */
> > + memcpy(efi_reloc, efi, sizeof(*dos) + sizeof(*nt)
> > + + nt->FileHeader.SizeOfOptionalHeader
> > + + num_sections * sizeof(IMAGE_SECTION_HEADER));
> > +
>
> Why do we have to copy PE headers and the sections below separately? My
> understanding is that the relative positions do not need any adjustment.
I think I have already answered your questions here:
https://lists.denx.de/pipermail/u-boot/2018-October/343876.html
Did you read it?
> Nothing in the spec requires the COFF header to be at offset
> sizeof(dos). You can put the COFF headder anywhere in the file. Please,
> read
But as far as I look at grub code (that you pointed out in your e-mail),
grub expects that PE headers be also "loaded" within an allocated region
(more specifically at the beginning of the region)
along with other sections in order to handle a (grub-specific? I don't know)
"mods" section.
-Takahiro Akashi
> https://media.blackhat.com/bh-us-11/Vuksan/BH_US_11_VuksanPericin_PECOFF_WP.pdf
>
> We should not assign new memory here. Nor should we copy anything here.
> We should simply use the relocation table to update the indicated memory
> locations.
>
> Best regards
>
> Heinrich
>
>
> > /* Load sections into RAM */
> > for (i = num_sections - 1; i >= 0; i--) {
> >
Re: [U-Boot] [PATCH v10 12/16] regmap: Add endianness support
On 4 October 2018 at 01:00, Mario Six wrote: > Add support for switching the endianness of regmap accesses via the > "little-endian", "big-endian", and "native-endian" boolean properties in > the device tree. > > The default endianness is native endianness. > > Signed-off-by: Mario Six > > --- > > v9 -> v10: > * Switched to readb/writeb for 8-bit reads/writes > > v8 -> v9: > New in v9 > > --- > drivers/core/regmap.c | 130 > ++ > include/regmap.h | 14 ++ > 2 files changed, 136 insertions(+), 8 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 02/19] dm: i2c: Add dm_i2c_probe_device() to test the presence of a chip
Hi Jean-Jacques,
On 11 October 2018 at 06:01, Jean-Jacques Hiblot wrote:
> Hi Simon,
>
> thanks for the reviews.
>
>
>
> On 11/10/2018 05:13, Simon Glass wrote:
>>
>> Hi Jean-Jacques,
>>
>> On 5 October 2018 at 10:45, Jean-Jacques Hiblot wrote:
>>>
>>> In a non-DM environment, it is possible to test the presence of a chip
>>> using i2c_probe(chip_addr).
>>> dm_i2c_probe_device() brings the same functionality with a DM interface.
>>> The intent is to be able to test the presence of a chip for the device
>>> has
>>> been created with i2c_get_chip_for_busnum(bus_num, chip_addr, ...)
>>>
>>> Signed-off-by: Jean-Jacques Hiblot
>>> ---
>>>
>>> Changes in v2: None
>>>
>>> drivers/i2c/i2c-uclass.c | 8
>>> include/i2c.h| 13 +
>>> 2 files changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
>>> index c5a3c4e..ec88168 100644
>>> --- a/drivers/i2c/i2c-uclass.c
>>> +++ b/drivers/i2c/i2c-uclass.c
>>> @@ -378,6 +378,14 @@ int dm_i2c_probe(struct udevice *bus, uint
>>> chip_addr, uint chip_flags,
>>> return ret;
>>> }
>>>
>>> +int dm_i2c_probe_device(struct udevice *dev)
>>> +{
>>> + struct udevice *bus = dev_get_parent(dev);
>>> + struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
>>> +
>>> + return i2c_probe_chip(bus, chip->chip_addr, chip->flags);
>>> +}
>>
>> Why not just probe the device? That should have the same effect.
>
> The device itself is not probed when using i2c_get_chip_for_busnum(). I
> could have changed it there but was sure about possible side-effects on all
> boards.
> The code that uses the non-DM API usually calls I2C_probe() at some point,
> this function is the equivalent in the DM world.
So if you change your above function to:
int dm_i2c_probe_device(struct udevice *dev)
{
return device_probe(dev);
}
what happens?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper
On 10 October 2018 at 19:53, Bin Meng wrote: > With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image > built for qemu-x86_64 target does not boot. It keeps resetting > soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows > that the reset happens inside env_callback_init(). > > 0113dd85 : > 113dd85: 41 54 push %r12 > 113dd87: 55 push %rbp > 113dd88: 31 c0 xor%eax,%eax > 113dd8a: 53 push %rbx > 113dd8b: 0f 57 c0xorps %xmm0,%xmm0 > > Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset. > However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04) > does not generate such instructions that utilizes SSE for this > function - env_callback_init() and U-Boot boots without any issue. > Explicitly specifying -march=core2 for newer GCC allows U-Boot > proper to boot again. Examine assembly codes of env_callback_init > and there is no SSE instruction in that function hence U-Boot > continues to boot. > > core2 seems to be the oldest arch in GCC that supports 64-bit. > Like 32-bit U-Boot build we use -march=i386 which is the most > conservative cpu type so that the image can run on any x86 > processor, let's do the same for the 64-bit U-Boot build. > > Signed-off-by: Bin Meng > --- > > arch/x86/config.mk | 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 03/27] virtio: Add codes for virtual queue/ring management
Hi Bin, On 11 October 2018 at 03:50, Bin Meng wrote: > Hi Simon, > > On Thu, Sep 27, 2018 at 9:42 PM Simon Glass wrote: >> >> On 23 September 2018 at 06:42, Bin Meng wrote: >> > From: Tuomas Tynkkynen >> > >> > This adds support for managing virtual queue/ring, the channel >> > for high performance I/O between host and guest. >> > >> > Signed-off-by: Tuomas Tynkkynen >> > Signed-off-by: Bin Meng >> > --- >> > >> > drivers/virtio/Makefile | 2 +- >> > drivers/virtio/virtio_ring.c | 356 >> > +++ >> > include/virtio_ring.h| 320 ++ >> > 3 files changed, 677 insertions(+), 1 deletion(-) >> > create mode 100644 drivers/virtio/virtio_ring.c >> > create mode 100644 include/virtio_ring.h >> >> Seems like vring_create_virtqueue() should return an error code rather >> than a pointer? > > I think NULL as a pointer can be a sign for the error. Yes but the issue here is that it returns more than one error, so an in is easier. With NULL you don't know what went wrong. There is ERR_PTR of course. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/13] aspeed: ast2500: fix D2-PLL clock setting in RGMII mode
On Wed, 10 Oct 2018 at 22:13, Cédric Le Goater wrote: > > The algorithm in the ast2500_calc_clock_config() routine suffers from > integer rounding and the requested rate does not get the appropriate > set of Numerator, Denumerator, Post Divider parameters. > > This is the case for the D2-PLL clock used by the MAC controllers in > RGMII mode. The requested rated is 250MHz but a 251MHz is assigned. > > The easiest way to fix this problem is to introduce an array of clock > settings defining the N, M, P parameters for well known frequencies > used by the Aspeed SoC. > > Signed-off-by: Cédric Le Goater > Reviewed-by: Simon Glass Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/13] aspeed: Activate ethernet devices on the ast2500 Eval Board
On Wed, 10 Oct 2018 at 22:13, Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater > Reviewed-by: Simon Glass Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/13] net: ftgmac100: Add support for the Aspeed SoC
On Wed, 10 Oct 2018 at 22:13, Cédric Le Goater wrote: > > The Faraday ftgmac100 MAC controllers as found on the Aspeed SoCs have > some slight differences in the HW interface (End-Of-Rx/Tx-Ring bits). > > Signed-off-by: Cédric Le Goater > Reviewed-by: Simon Glass Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/13] net: ftgmac100: add clock support
On Wed, 10 Oct 2018 at 22:13, Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/13] net: ftgmac100: handle timeouts when transmitting
On Wed, 10 Oct 2018 at 22:13, Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/13] net: ftgmac100: convert the RX/TX descriptor arrays
On Wed, 10 Oct 2018 at 22:13, Cédric Le Goater wrote: > > Use simple arrays under the device priv structure to hold the RX and > TX descriptors and handle memory coherency by invalidating or flushing > the d-cache when required. > > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/13] net: ftgmac100: add MDIO bus and phylib support
On Wed, 10 Oct 2018 at 22:12, Cédric Le Goater wrote: > > Implement the MDIO bus read/write functions using the readl_poll_timeout() > routine, initialize the bus and scan for the PHY. RGMII and RMII mode > are supported. > > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/13] net: ftgmac100: use setbits_le32() in the reset method
On Wed, 10 Oct 2018 at 22:12, Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/13] net: ftgmac100: convert to driver model
On Wed, 10 Oct 2018 at 22:12, Cédric Le Goater wrote: > > The driver is based on the previous one and the code is only adapted > to fit the driver model. The support for the Faraday ftgmac100 > controller is the same with MAC and MDIO bus support for RGMII/RMII > modes. > > Configuration is updated to enable compile again. At this stage, the > driver compiles but is not yet functional. Is this commit message still valid? > > Signed-off-by: Cédric Le Goater The code looks good. Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/13] net: ftgmac100: use the aligned() macro
On Wed, 10 Oct 2018 at 22:12, Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/13] net: ftgmac100: use the BIT() macro
On Wed, 10 Oct 2018 at 22:12, Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing
On 10/11/2018 03:57 AM, Bin Meng wrote: > Hi Heinrich, > > On Thu, Oct 11, 2018 at 9:48 AM Bin Meng wrote: >> >> Add qemu-x86_64 to the list of targets we use for test.py runs. >> >> Signed-off-by: Bin Meng >> >> --- >> testp.py testing is currently failing at 'bootefi selftest'. >> > > Can you try this series for the 'bootefi selftest' testing? I am clueless why the EFI subsystems is failing completely on qemu-x86_64_defconfig. Any printf() or puts() statement I put into lib/efi_loader/efi_boottime.c leads to no output at all. I connected gdb with gdb u-boot -ex 'target remote localhost:1234' add-symbol-file u-boot But the debugger did not stop at breakpoints. Regards Heinrich > > BTW: do you know how to call test.py on the local machine to do > testing on QEMU? The doc does not provide enough information .. > >> .travis.yml | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/.travis.yml b/.travis.yml >> index 2b759c9..9d0531f 100644 >> --- a/.travis.yml >> +++ b/.travis.yml >> @@ -408,6 +408,14 @@ matrix: >>BUILDMAN="^qemu-x86$" >>TOOLCHAIN="x86_64" >>BUILD_ROM="yes" >> +- name: "test/py qemu-x86_64" >> + env: >> +- TEST_PY_BD="qemu-x86_64" >> + TEST_PY_TEST_SPEC="not sleep" >> + QEMU_TARGET="x86_64-softmmu" >> + BUILDMAN="^qemu-x86_64$" >> + TOOLCHAIN="x86_64" >> + BUILD_ROM="yes" >> - name: "test/py zynq_zc702" >>env: >> - TEST_PY_BD="zynq_zc702" >> -- > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARC: Don't use COMMON section for global not-initialized variables
By default GCC puts global non-initialized variables in COMMON section. And we used to ignore existence of COMMON section in our linker scripts though smart LD silently appended it right after .bss. And the problem here is variables from COMMON section even though require zeroing in run-time were not zeroed as they were placed right after __bss_end symbol. It was a pure luck we never faced serious problem due to this, but now it is fixed. Now as for some other architectures we'll just force GCC to put those global variables in normal .bss section. This solution is much nicer than adding COMMON section to each and every linker script. Signed-off-by: Alexey Brodkin --- arch/arc/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/config.mk b/arch/arc/config.mk index d255c90..18005d9 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -43,7 +43,7 @@ PLATFORM_CPPFLAGS += -mcpu=archs endif PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -gdwarf-2 -mno-sdata -PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections -fno-common # Needed for relocation LDFLAGS_FINAL += -pie --gc-sections -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] iot_dk: Link for eFlash
That's what we'll have in production. But note it won't work for loading via JTAG as eFlash is not directly writable, one needs to use prebootloader to flash uboot.bin from SD-card into eFlash. Signed-off-by: Alexey Brodkin --- configs/iot_devkit_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/iot_devkit_defconfig b/configs/iot_devkit_defconfig index 3facce1..1b6dd9e 100644 --- a/configs/iot_devkit_defconfig +++ b/configs/iot_devkit_defconfig @@ -4,7 +4,7 @@ CONFIG_CPU_ARCEM6=y CONFIG_SYS_ICACHE_OFF=y CONFIG_SYS_DCACHE_OFF=y CONFIG_TARGET_IOT_DEVKIT=y -CONFIG_SYS_TEXT_BASE=0x2000 +CONFIG_SYS_TEXT_BASE=0x CONFIG_SYS_CLK_FREQ=1600 CONFIG_LOCALVERSION="-iotdk-1.0" # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] axs10x/emdk/hsdk/iot_dk: Implement board_mmc_getcd()
So now we may detect MMC/SD-card existence and
instead of completely misleading message on missing card:
>8---
Loading Environment from FAT... Card did not respond to voltage select!
>8---
we now get very clear one:
>8---
Loading Environment from FAT... MMC: no card present
>8---
Signed-off-by: Alexey Brodkin
---
board/synopsys/axs10x/axs10x.c | 7 +++
board/synopsys/emdk/emdk.c | 7 +++
board/synopsys/hsdk/hsdk.c | 7 +++
board/synopsys/iot_devkit/iot_devkit.c | 7 +++
4 files changed, 28 insertions(+)
diff --git a/board/synopsys/axs10x/axs10x.c b/board/synopsys/axs10x/axs10x.c
index af78127..c95f7af 100644
--- a/board/synopsys/axs10x/axs10x.c
+++ b/board/synopsys/axs10x/axs10x.c
@@ -33,6 +33,13 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
#define AXS_MB_CREG0xE0011000
int board_early_init_f(void)
diff --git a/board/synopsys/emdk/emdk.c b/board/synopsys/emdk/emdk.c
index bbb946a..79cafef 100644
--- a/board/synopsys/emdk/emdk.c
+++ b/board/synopsys/emdk/emdk.c
@@ -34,6 +34,13 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
#define CREG_BASE 0xF0001000
#define CREG_BOOT_OFFSET 0
#define CREG_BOOT_WP_OFFSET8
diff --git a/board/synopsys/hsdk/hsdk.c b/board/synopsys/hsdk/hsdk.c
index 4f46d2e..b6aefdb 100644
--- a/board/synopsys/hsdk/hsdk.c
+++ b/board/synopsys/hsdk/hsdk.c
@@ -1019,6 +1019,13 @@ int board_late_init(void)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
int board_mmc_init(bd_t *bis)
{
struct dwmci_host *host = NULL;
diff --git a/board/synopsys/iot_devkit/iot_devkit.c
b/board/synopsys/iot_devkit/iot_devkit.c
index 40c29e7..f8838fb 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -170,6 +170,13 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
#define IOTDK_RESET_SEQ0x55AA6699
void reset_cpu(ulong addr)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] iot_dk: Save CPU clock value to gd->cpu_clk
Since gd->cpu_clk is a global item we may once populate it from .dtb
ans use it then in other places like for printing CPU info etc.
Signed-off-by: Alexey Brodkin
---
board/synopsys/iot_devkit/iot_devkit.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/board/synopsys/iot_devkit/iot_devkit.c
b/board/synopsys/iot_devkit/iot_devkit.c
index 04e003c..40c29e7 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -108,7 +108,7 @@ extern u8 __ram_end[];
*/
int mach_cpu_init(void)
{
- int offset, freq;
+ int offset;
/* Don't relocate U-Boot */
gd->flags |= GD_FLG_SKIP_RELOC;
@@ -129,12 +129,12 @@ int mach_cpu_init(void)
if (offset < 0)
return offset;
- freq = fdtdec_get_int(gd->fdt_blob, offset, "clock-frequency", 0);
- if (!freq)
+ gd->cpu_clk = fdtdec_get_int(gd->fdt_blob, offset, "clock-frequency",
0);
+ if (!gd->cpu_clk)
return -EINVAL;
/* If CPU freq > 100 MHz, divide eFLASH clock by 2 */
- if (freq > 1) {
+ if (gd->cpu_clk > 1) {
u32 reg = readl(AHBCKDIV);
reg &= ~(0xF << 8);
@@ -142,7 +142,7 @@ int mach_cpu_init(void)
writel(reg, AHBCKDIV);
}
- return set_cpu_freq(freq);
+ return set_cpu_freq(gd->cpu_clk);
}
#define ARC_PERIPHERAL_BASE0xF000
@@ -186,7 +186,9 @@ int checkboard(void)
#ifdef CONFIG_DISPLAY_CPUINFO
int print_cpuinfo(void)
{
- printf("CPU: ARC EM9D\n");
+ char mhz[8];
+
+ printf("CPU: ARC EM9D at %s MHz\n", strmhz(mhz, gd->cpu_clk));
return 0;
}
#endif /* CONFIG_DISPLAY_CPUINFO */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] iot_dk: Add support of 136 MHz clock
Signed-off-by: Alexey Brodkin --- board/synopsys/iot_devkit/iot_devkit.c | 8 1 file changed, 8 insertions(+) diff --git a/board/synopsys/iot_devkit/iot_devkit.c b/board/synopsys/iot_devkit/iot_devkit.c index fb39e6d..04e003c 100644 --- a/board/synopsys/iot_devkit/iot_devkit.c +++ b/board/synopsys/iot_devkit/iot_devkit.c @@ -68,6 +68,14 @@ static int set_cpu_freq(unsigned int clk) writel((readl(PLLCON) & PLL_MASK_2) | 0x200191, PLLCON); break; + case 136: + writel(readl(PLLCON) & PLL_MASK_0, PLLCON); + /* pll_off=1, M=17, N=1, OD=1, PLL_OUT_CLK=136M */ + writel((readl(PLLCON) & PLL_MASK_1) | 0x100111, PLLCON); + /* pll_off=0, M=17, N=1, OD=1, PLL_OUT_CLK=136M */ + writel((readl(PLLCON) & PLL_MASK_2) | 0x100111, PLLCON); + break; + case 144: writel(readl(PLLCON) & PLL_MASK_0, PLLCON); /* pll_off=1, M=18, N=1, OD=1, PLL_OUT_CLK=144M */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] iot_dk: Implement board reset
It is done by writing some magic sequence in a special register.
Signed-off-by: Alexey Brodkin
---
board/synopsys/iot_devkit/iot_devkit.c | 8
1 file changed, 8 insertions(+)
diff --git a/board/synopsys/iot_devkit/iot_devkit.c
b/board/synopsys/iot_devkit/iot_devkit.c
index 1d848dd..fb39e6d 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -17,6 +17,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define AHBCKDIV (void *)(SYSCON_BASE + 0x04)
#define APBCKDIV (void *)(SYSCON_BASE + 0x08)
#define APBCKEN(void *)(SYSCON_BASE + 0x0C)
+#define RESET_REG (void *)(SYSCON_BASE + 0x18)
#define CLKSEL (void *)(SYSCON_BASE + 0x24)
#define CLKSTAT(void *)(SYSCON_BASE + 0x28)
#define PLLCON (void *)(SYSCON_BASE + 0x2C)
@@ -161,6 +162,13 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+#define IOTDK_RESET_SEQ0x55AA6699
+
+void reset_cpu(ulong addr)
+{
+ writel(IOTDK_RESET_SEQ, RESET_REG);
+}
+
int checkboard(void)
{
puts("Board: Synopsys IoT Development Kit\n");
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] iot_dk/hsdk: Implement its own print_cpuinfo()
ARC IDENTITY register only encodes major architecture
type and version while for a particular board/silicon we
may know better which template was used and so we may identify
CPU more precise, which exactly we do here.
Signed-off-by: Alexey Brodkin
---
board/synopsys/hsdk/hsdk.c | 8
board/synopsys/iot_devkit/iot_devkit.c | 8
2 files changed, 16 insertions(+)
diff --git a/board/synopsys/hsdk/hsdk.c b/board/synopsys/hsdk/hsdk.c
index fb4286f..4f46d2e 100644
--- a/board/synopsys/hsdk/hsdk.c
+++ b/board/synopsys/hsdk/hsdk.c
@@ -1046,3 +1046,11 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+
+#ifdef CONFIG_DISPLAY_CPUINFO
+int print_cpuinfo(void)
+{
+ printf("CPU: ARC HS38 v2.1c\n");
+ return 0;
+}
+#endif /* CONFIG_DISPLAY_CPUINFO */
diff --git a/board/synopsys/iot_devkit/iot_devkit.c
b/board/synopsys/iot_devkit/iot_devkit.c
index c185d5c..1d848dd 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -166,3 +166,11 @@ int checkboard(void)
puts("Board: Synopsys IoT Development Kit\n");
return 0;
};
+
+#ifdef CONFIG_DISPLAY_CPUINFO
+int print_cpuinfo(void)
+{
+ printf("CPU: ARC EM9D\n");
+ return 0;
+}
+#endif /* CONFIG_DISPLAY_CPUINFO */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARC: make generic print_cpuinfo() weak
This allows board to override print_cpuinfo() because
they might know better which ARChitect template was used.
This way we may not only derive base architecture type and
version but more meaningful things like "ARC EM7D" instead of
simple "ARC EM", "ARC HS36" instead of "ARC HS".
Signed-off-by: Alexey Brodkin
---
arch/arc/lib/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/lib/cpu.c b/arch/arc/lib/cpu.c
index 50cd7cd..a969a16 100644
--- a/arch/arc/lib/cpu.c
+++ b/arch/arc/lib/cpu.c
@@ -60,7 +60,7 @@ const char *decode_identity(void)
}
}
-int print_cpuinfo(void)
+__weak int print_cpuinfo(void)
{
printf("CPU: %s\n", decode_identity());
return 0;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARC: Allow per-board more precise CPU identification
Some of ARC boards do sport real silicon and given how flexible ARC cores might be configured it's hard to tell what "template" was used initially. For FPGA-based boards we're left with basic info derived from IDENTITY register but for real silicon we may know more details so let's print them then. Alexey Brodkin (2): ARC: make generic print_cpuinfo() weak iot_dk/hsdk: Implement its own print_cpuinfo() arch/arc/lib/cpu.c | 2 +- board/synopsys/hsdk/hsdk.c | 8 board/synopsys/iot_devkit/iot_devkit.c | 8 3 files changed, 17 insertions(+), 1 deletion(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] iot_dk: Add localversion string
Signed-off-by: Alexey Brodkin --- configs/iot_devkit_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/iot_devkit_defconfig b/configs/iot_devkit_defconfig index 1f0f9c3..0c5aba3 100644 --- a/configs/iot_devkit_defconfig +++ b/configs/iot_devkit_defconfig @@ -6,6 +6,7 @@ CONFIG_SYS_DCACHE_OFF=y CONFIG_TARGET_IOT_DEVKIT=y CONFIG_SYS_TEXT_BASE=0x2000 CONFIG_SYS_CLK_FREQ=1600 +CONFIG_LOCALVERSION="-iotdk-1.0" # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_SYS_PROMPT="IoTDK# " # CONFIG_CMD_BOOTD is not set -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,11/45] rtc: Allow use of RTC in SPL and TPL
On 10/11/2018 09:21 PM, Heinrich Schuchardt wrote: > > On 10/01/2018 08:22 PM, Simon Glass wrote: >> Add Kconfig options so that the RTC can be used in SPL and TPL. This is >> helpful for accessing the contents of CMOS RAM, for example. >> >> Signed-off-by: Simon Glass >> Signed-off-by: Simon Glass >> --- > > Hello Simon, > > with this patch x86_64 does not boot anymore: > $ qemu-system-x86_64 -bios u-boot.rom -nographic --enable-kvm --cpu host > ### ERROR ### Please RESET the board ### > > I am currently testing Bin's patch series: > https://patchwork.ozlabs.org/project/uboot/list/?series=70127 > [U-Boot,1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper > As a workaround for qemu-x86_defconfig I have sent a patch changing that single configuration file. But your patch may have broken more boards. https://lists.denx.de/pipermail/u-boot/2018-October/344137.html x86: qemu: enable CONFIG_SPL_DM_RTC Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] x86: qemu: enable CONFIG_SPL_DM_RTC
Since commit 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL")
qemu-x86_64_defconfig does not boot anymore.
Fixes: 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL")
Signed-off-by: Heinrich Schuchardt
---
configs/qemu-x86_64_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index cf1ba8ea61..32922b84ff 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -63,6 +63,7 @@ CONFIG_SPL_REGMAP=y
CONFIG_SYSCON=y
CONFIG_SPL_SYSCON=y
CONFIG_CPU=y
+CONFIG_SPL_DM_RTC=y
CONFIG_SPI=y
CONFIG_SPL_TIMER=y
CONFIG_USB_STORAGE=y
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: Don't overwrite waiting packets with asynchronous replies
Hi Joe, https://patchwork.ozlabs.org/patch/975416/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] test: eth: Add a test for ARP requests
Hi Joe, https://patchwork.ozlabs.org/patch/975412/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Make the fake eth driver response configurable
Hi Joe, https://patchwork.ozlabs.org/patch/975408/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Allow fake eth to handle more than 1 packet response
Hi Joe, https://patchwork.ozlabs.org/patch/975413/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Refactor sandbox send function
Hi Joe, https://patchwork.ozlabs.org/patch/975414/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: Add an accessor to know if waiting for ARP
Hi Joe, https://patchwork.ozlabs.org/patch/975417/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/if_ether.h: Add VLAN related macros
Hi Bin, https://patchwork.ozlabs.org/patch/951501/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Move disabled flag into priv struct
Hi Joe, https://patchwork.ozlabs.org/patch/975411/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] test: eth: Add a test for the target being pinged
Hi Joe, https://patchwork.ozlabs.org/patch/975410/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: pch_gbe: Make probe/remove static
Hi Bin, https://patchwork.ozlabs.org/patch/950525/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: ti: Add binding for the CLK_OUT pin muxing
Hi Janine, https://patchwork.ozlabs.org/patch/962743/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/if_ether.h: Initial import from Linux kernel v4.17
Hi Bin, https://patchwork.ozlabs.org/patch/951499/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: Consolidate UDP header functions
Hi Duncan, https://patchwork.ozlabs.org/patch/934006/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver
Hi Janine, https://patchwork.ozlabs.org/patch/962741/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Add a priv ptr for tests to use
Hi Joe, https://patchwork.ozlabs.org/patch/975419/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Share the priv structure with tests
Hi Joe, https://patchwork.ozlabs.org/patch/975409/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: ti: Recover from "port mirroring" N/A MODE4
Hi Janine, https://patchwork.ozlabs.org/patch/962746/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] phy: Add 25G_AUI, XLAUI, CAUI2, CAUI4 related macros
Hi Priyanka, https://patchwork.ozlabs.org/patch/962408/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net.h: Include linux/if_ether.h to avoid duplication
Hi Bin, https://patchwork.ozlabs.org/patch/951500/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/mii.h: Sync with Linux kernel v4.17
Hi Bin, https://patchwork.ozlabs.org/patch/949572/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/compat.h: Add netdev_### log macros
Hi Bin, https://patchwork.ozlabs.org/patch/949577/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/mdio.h: Sync with Linux kernel v4.17
Hi Bin, https://patchwork.ozlabs.org/patch/949573/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Hi Tom, The few checkpatch alerts were checked to be exceptions. All passed travis. Thanks! The following changes since commit 0a60a81ba3860946551cb79aa6486aa076e357f3: Kconfig: sandbox: enable cmd_avb and dependencies (2018-10-07 13:34:19 -0400) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to 1a048cd65645338069d591108031fa4ebe96d53f: driver: net: fsl-mc: Add support of multiple phys for dpmac (2018-10-10 12:45:28 -0500) Bin Meng (7): linux/mii.h: Sync with Linux kernel v4.17 linux/mdio.h: Sync with Linux kernel v4.17 linux/compat.h: Add netdev_### log macros net: pch_gbe: Make probe/remove static linux/if_ether.h: Initial import from Linux kernel v4.17 net.h: Include linux/if_ether.h to avoid duplication linux/if_ether.h: Add VLAN related macros Duncan Hare (1): net: Consolidate UDP header functions Janine Hagemann (3): net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver net: phy: ti: Recover from "port mirroring" N/A MODE4 net: phy: ti: Add binding for the CLK_OUT pin muxing Joe Hershberger (10): net: sandbox: Move disabled flag into priv struct net: sandbox: Refactor sandbox send function net: sandbox: Make the fake eth driver response configurable net: sandbox: Share the priv structure with tests net: sandbox: Allow fake eth to handle more than 1 packet response net: Add an accessor to know if waiting for ARP net: sandbox: Add a priv ptr for tests to use test: eth: Add a test for ARP requests test: eth: Add a test for the target being pinged net: Don't overwrite waiting packets with asynchronous replies Pankaj Bansal (6): driver: net: fsl-mc: modify the label name driver: net: fsl-mc: remove unused strcture elements driver: net: fsl-mc: fix error handing in init_phy driver: net: fsl-mc: Modify the dpmac link detection method driver: net: fsl-mc: initialize dpmac irrespective of phy driver: net: fsl-mc: Add support of multiple phys for dpmac Priyanka Jain (1): phy: Add 25G_AUI, XLAUI, CAUI2, CAUI4 related macros arch/sandbox/include/asm/eth.h | 93 +++ board/Synology/ds414/cmd_syno.c | 1 - board/freescale/ls1088a/eth_ls1088aqds.c| 18 +- board/freescale/ls1088a/eth_ls1088ardb.c| 21 +- board/freescale/ls2080aqds/eth.c| 26 +- board/freescale/ls2080ardb/eth_ls2080rdb.c | 24 +- doc/device-tree-bindings/net/ti,dp83867.txt | 8 + drivers/net/dc2114x.c | 1 - drivers/net/eepro100.c | 2 - drivers/net/fsl-mc/mc.c | 6 +- drivers/net/ldpaa_eth/ldpaa_eth.c | 171 +++- drivers/net/ldpaa_eth/ldpaa_eth.h | 1 - drivers/net/ldpaa_eth/ldpaa_wriop.c | 69 +++-- drivers/net/mvneta.c| 8 - drivers/net/mvpp2.c | 13 - drivers/net/natsemi.c | 1 - drivers/net/ns8382x.c | 1 - drivers/net/pch_gbe.c | 4 +- drivers/net/phy/ti.c| 93 ++- drivers/net/rtl8139.c | 4 - drivers/net/rtl8169.c | 4 - drivers/net/sandbox.c | 417 +--- drivers/usb/eth/lan7x.h | 2 +- drivers/usb/gadget/ether.c | 9 +- drivers/usb/gadget/rndis.c | 6 - include/dt-bindings/net/ti-dp83867.h| 15 + include/fsl-mc/ldpaa_wriop.h| 46 +-- include/linux/compat.h | 19 ++ include/linux/if_ether.h| 178 include/linux/mdio.h| 34 ++- include/linux/mii.h | 126 + include/net.h | 16 +- include/phy_interface.h | 8 + include/usb_ether.h | 10 - net/arp.c | 20 +- net/arp.h | 1 + net/net.c | 43 ++- net/ping.c | 14 +- test/dm/eth.c | 170 39 files changed, 1294 insertions(+), 409 deletions(-) create mode 100644 include/linux/if_ether.h Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,11/45] rtc: Allow use of RTC in SPL and TPL
On 10/01/2018 08:22 PM, Simon Glass wrote:
> Add Kconfig options so that the RTC can be used in SPL and TPL. This is
> helpful for accessing the contents of CMOS RAM, for example.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Simon Glass
> ---
Hello Simon,
with this patch x86_64 does not boot anymore:
$ qemu-system-x86_64 -bios u-boot.rom -nographic --enable-kvm --cpu host
### ERROR ### Please RESET the board ###
I am currently testing Bin's patch series:
https://patchwork.ozlabs.org/project/uboot/list/?series=70127
[U-Boot,1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper
>
> drivers/rtc/Kconfig | 18 ++
> drivers/rtc/Makefile | 2 +-
> drivers/rtc/rtc-uclass.c | 1 +
> 3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 97cf7d84dfa..bcc01b135e5 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -13,6 +13,24 @@ config DM_RTC
> drivers to perform the actual functions. See rtc.h for a
> description of the API.
>
> +config SPL_DM_RTC
> + bool "Enable Driver Model for RTC drivers in SPL"
> + depends on SPL_DM
> + help
> + Enable drver model for real-time-clock drivers. The RTC uclass
> + then provides the rtc_get()/rtc_set() interface, delegating to
> + drivers to perform the actual functions. See rtc.h for a
> + description of the API.
> +
> +config TPL_DM_RTC
> + bool "Enable Driver Model for RTC drivers in TPL"
> + depends on TPL_DM
> + help
> + Enable drver model for real-time-clock drivers. The RTC uclass
> + then provides the rtc_get()/rtc_set() interface, delegating to
> + drivers to perform the actual functions. See rtc.h for a
> + description of the API.
> +
> config RTC_PCF2127
> bool "Enable PCF2127 driver"
> depends on DM_RTC
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 513e3ffc079..1724602f1cb 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -4,7 +4,7 @@
> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> #ccflags-y += -DDEBUG
>
> -obj-$(CONFIG_DM_RTC) += rtc-uclass.o
> +obj-$(CONFIG_$(SPL_TPL_)DM_RTC) += rtc-uclass.o
This is the line to be reverted.
Best regards
Heinrich
>
> obj-$(CONFIG_RTC_AT91SAM9_RTT) += at91sam9_rtt.o
> obj-y += date.o
> diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
> index c676f0ff359..a0a238aedda 100644
> --- a/drivers/rtc/rtc-uclass.c
> +++ b/drivers/rtc/rtc-uclass.c
> @@ -122,4 +122,5 @@ int rtc_write32(struct udevice *dev, unsigned int reg,
> u32 value)
> UCLASS_DRIVER(rtc) = {
> .name = "rtc",
> .id = UCLASS_RTC,
> + .post_bind = dm_scan_fdt_dev,
> };
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build
On 10/11/2018 03:53 AM, Bin Meng wrote: > With the '-march=core2' fix, it seems that we have some luck that > the 64-bit U-Boot boots again. However if we examine the disassembly > codes there are still SSE instructions elsewhere which means passing > cpu type to GCC is not enough to prevent it from generating these > instructions. A simple test case is doing a 'bootefi selftest' from > the U-Boot shell and it leads to a reset too. I can confirm that an unexpected reset patch occurs without the patch. > > The 'bootefi selftest' reset is even seen with the image created by > the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04. > > To make sure no MMX/SSE instruction sets are generated, tell GCC not > to do this. Note AVX is out of the question as CORE2 is old enough > to support AVX yet. > > Signed-off-by: Bin Meng > --- > > arch/x86/config.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > index 576501e..8151e47 100644 > --- a/arch/x86/config.mk > +++ b/arch/x86/config.mk > @@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y) > PLATFORM_CPPFLAGS += -march=i386 -m32 > else > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common > -march=core2 -m64 > +PLATFORM_CPPFLAGS += -mno-mmx -mno-sse According to https://wiki.osdev.org/SSE SSE has to be initialized. Otherwise SSE instructions lead to an undefined instruction exception. Is it this initialization that we lack? If this is your motivation please, state it in the commit message. I think this patch could be squashed with the prior one. Heinrich > endif > > PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] bcm6858: add initial support
This add the initial support of the broadcom bcm6858 SoC family,
only the cpu, dram and uart are supported.
Signed-off-by: Philippe Reynes
---
arch/arm/Kconfig | 7
arch/arm/dts/bcm6858.dtsi | 85 +++
2 files changed, 92 insertions(+)
create mode 100644 arch/arm/dts/bcm6858.dtsi
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ccf2a84..99c1711 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -538,6 +538,12 @@ config ARCH_BCM283X
imply CMD_DM
imply FAT_WRITE
+config ARCH_BCM6858
+ bool "Broadcom BCM6858 family"
+ select DM
+ select OF_CONTROL
+ imply CMD_DM
+
config TARGET_VEXPRESS_CA15_TC2
bool "Support vexpress_ca15_tc2"
select CPU_V7A
@@ -1468,6 +1474,7 @@ source "board/armltd/vexpress/Kconfig"
source "board/armltd/vexpress64/Kconfig"
source "board/broadcom/bcm23550_w1d/Kconfig"
source "board/broadcom/bcm28155_ap/Kconfig"
+source "board/broadcom/bcm968580xref/Kconfig"
source "board/broadcom/bcmcygnus/Kconfig"
source "board/broadcom/bcmnsp/Kconfig"
source "board/broadcom/bcmns2/Kconfig"
diff --git a/arch/arm/dts/bcm6858.dtsi b/arch/arm/dts/bcm6858.dtsi
new file mode 100644
index 000..9869d72
--- /dev/null
+++ b/arch/arm/dts/bcm6858.dtsi
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Philippe Reynes
+ */
+
+#include "skeleton64.dtsi"
+
+/ {
+ compatible = "brcm,bcm6858";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ u-boot,dm-pre-reloc;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ next-level-cache = <>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x1>;
+ next-level-cache = <>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x2>;
+ next-level-cache = <>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x3>;
+ next-level-cache = <>;
+ u-boot,dm-pre-reloc;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ u-boot,dm-pre-reloc;
+
+ periph_osc: periph-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2>;
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ ubus {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ u-boot,dm-pre-reloc;
+
+ uart0: serial@ff800640 {
+ compatible = "brcm,bcm6858-uart";
+ reg = <0x0 0xff800640 0x0 0x18>;
+ clocks = <_osc>;
+
+ status = "disabled";
+ };
+ };
+};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] bcm968580xref: add initial support
This add the initial support of the broadcom reference
board bcm968580xref with a bcm6858 SoC.
This board has 512 MB of ram, 256 MB of flash (nand),
2 usb port, 1 uart, 4 ethernet ports (LAN), 1 ethernet port (WAN).
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm968580xref.dts | 31 ++
board/broadcom/bcm968580xref/Kconfig | 17
board/broadcom/bcm968580xref/MAINTAINERS | 6 +++
board/broadcom/bcm968580xref/Makefile| 3 ++
board/broadcom/bcm968580xref/bcm968580xref.c | 61
configs/bcm968580_ram_defconfig | 36
include/configs/broadcom_bcm968580xref.h | 36
7 files changed, 190 insertions(+)
create mode 100644 arch/arm/dts/bcm968580xref.dts
create mode 100644 board/broadcom/bcm968580xref/Kconfig
create mode 100644 board/broadcom/bcm968580xref/MAINTAINERS
create mode 100644 board/broadcom/bcm968580xref/Makefile
create mode 100644 board/broadcom/bcm968580xref/bcm968580xref.c
create mode 100644 configs/bcm968580_ram_defconfig
create mode 100644 include/configs/broadcom_bcm968580xref.h
diff --git a/arch/arm/dts/bcm968580xref.dts b/arch/arm/dts/bcm968580xref.dts
new file mode 100644
index 000..0c59f94
--- /dev/null
+++ b/arch/arm/dts/bcm968580xref.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Philippe Reynes
+ */
+
+/dts-v1/;
+
+#include "bcm6858.dtsi"
+
+/ {
+ model = "Broadcom bcm68580xref";
+ compatible = "broadcom,bcm68580xref", "brcm,bcm6858";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x2000>;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/board/broadcom/bcm968580xref/Kconfig
b/board/broadcom/bcm968580xref/Kconfig
new file mode 100644
index 000..b573036
--- /dev/null
+++ b/board/broadcom/bcm968580xref/Kconfig
@@ -0,0 +1,17 @@
+if ARCH_BCM6858
+
+config SYS_VENDOR
+ default "broadcom"
+
+config SYS_BOARD
+ default "bcm968580xref"
+
+config SYS_CONFIG_NAME
+ default "broadcom_bcm968580xref"
+
+endif
+
+config TARGET_BCM968580XREF
+ bool "Support Broadcom bcm968580xref"
+ depends on ARCH_BCM6858
+ select ARM64
diff --git a/board/broadcom/bcm968580xref/MAINTAINERS
b/board/broadcom/bcm968580xref/MAINTAINERS
new file mode 100644
index 000..3e4691a
--- /dev/null
+++ b/board/broadcom/bcm968580xref/MAINTAINERS
@@ -0,0 +1,6 @@
+BROADCOM BCM968580XREF
+M: Philippe Reynes
+S: Maintained
+F: board/broadcom/bcm968580xref/
+F: include/configs/broadcom_bcm968580xref.h
+F: configs/bcm9686580xref_ram_defconfig
diff --git a/board/broadcom/bcm968580xref/Makefile
b/board/broadcom/bcm968580xref/Makefile
new file mode 100644
index 000..5cd393b
--- /dev/null
+++ b/board/broadcom/bcm968580xref/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += bcm968580xref.o
diff --git a/board/broadcom/bcm968580xref/bcm968580xref.c
b/board/broadcom/bcm968580xref/bcm968580xref.c
new file mode 100644
index 000..2e547f5
--- /dev/null
+++ b/board/broadcom/bcm968580xref/bcm968580xref.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Philippe Reynes
+ */
+
+#include
+#include
+#include
+
+#ifdef CONFIG_ARM64
+#include
+
+static struct mm_region broadcom_bcm968580xref_mem_map[] = {
+ {
+ /* RAM */
+ .virt = 0xUL,
+ .phys = 0xUL,
+ .size = 8UL * SZ_1G,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ /* SoC */
+ .virt = 0x8000UL,
+ .phys = 0x8000UL,
+ .size = 0xff8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+struct mm_region *mem_map = broadcom_bcm968580xref_mem_map;
+#endif
+
+int board_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+ if (fdtdec_setup_mem_size_base() != 0)
+ printf("fdtdec_setup_mem_size_base() has failed\n");
+
+ return 0;
+}
+
+int dram_init_banksize(void)
+{
+ fdtdec_setup_memory_banksize();
+
+ return 0;
+}
+
+int print_cpuinfo(void)
+{
+ return 0;
+}
diff --git a/configs/bcm968580_ram_defconfig b/configs/bcm968580_ram_defconfig
new file mode 100644
index 000..abe90ee
--- /dev/null
+++ b/configs/bcm968580_ram_defconfig
@@ -0,0 +1,36 @@
+CONFIG_ARM=y
+CONFIG_ARCH_BCM6858=y
+CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
[U-Boot] [PATCH 1/3] serial: bcm6858: add serial support
This driver add the support of serial on bcm6858. It's based on serial for bcm6345. Signed-off-by: Philippe Reynes --- drivers/serial/Kconfig | 6 + drivers/serial/Makefile | 1 + drivers/serial/serial_bcm6858.c | 300 3 files changed, 307 insertions(+) create mode 100644 drivers/serial/serial_bcm6858.c diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 5fa2725..4d094c3 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -479,6 +479,12 @@ config BCM6345_SERIAL help Select this to enable UART on BCM6345 SoCs. +config BCM6858_SERIAL + bool "Support for BCM6858 UART" + depends on DM_SERIAL && ARCH_BCM6858 + help + Select this to enable UART on BCM6358 SoCs. + config FSL_LINFLEXUART bool "Freescale Linflex UART support" depends on DM_SERIAL diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index 03dc29e..a48458f 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_AR933X_UART) += serial_ar933x.o obj-$(CONFIG_ARM_DCC) += arm_dcc.o obj-$(CONFIG_ATMEL_USART) += atmel_usart.o obj-$(CONFIG_BCM6345_SERIAL) += serial_bcm6345.o +obj-$(CONFIG_BCM6858_SERIAL) += serial_bcm6858.o obj-$(CONFIG_EFI_APP) += serial_efi.o obj-$(CONFIG_LPC32XX_HSUART) += lpc32xx_hsuart.o obj-$(CONFIG_MCFUART) += mcfuart.o diff --git a/drivers/serial/serial_bcm6858.c b/drivers/serial/serial_bcm6858.c new file mode 100644 index 000..8aa3705 --- /dev/null +++ b/drivers/serial/serial_bcm6858.c @@ -0,0 +1,300 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Philippe Reynes + * + * Derived from linux/drivers/tty/serial/bcm63xx_uart.c: + * Copyright (C) 2008 Maxime Bizon + * Derived from linux/drivers/tty/serial/serial_bcm6345.c + * Copyright (C) 2017 Álvaro Fernández Rojas + */ + +#include +#include +#include +#include +#include +#include +#include + +/* UART Control register */ +#define UART_CTL_REG 0x0 +#define UART_CTL_RXTIMEOUT_MASK0x1f +#define UART_CTL_RXTIMEOUT_5 0x5 +#define UART_CTL_RSTRXFIFO_SHIFT 6 +#define UART_CTL_RSTRXFIFO_MASK(1 << UART_CTL_RSTRXFIFO_SHIFT) +#define UART_CTL_RSTTXFIFO_SHIFT 7 +#define UART_CTL_RSTTXFIFO_MASK(1 << UART_CTL_RSTTXFIFO_SHIFT) +#define UART_CTL_STOPBITS_SHIFT8 +#define UART_CTL_STOPBITS_MASK (0xf << UART_CTL_STOPBITS_SHIFT) +#define UART_CTL_STOPBITS_1(0x7 << UART_CTL_STOPBITS_SHIFT) +#define UART_CTL_BITSPERSYM_SHIFT 12 +#define UART_CTL_BITSPERSYM_MASK (0x3 << UART_CTL_BITSPERSYM_SHIFT) +#define UART_CTL_BITSPERSYM_8 (0x3 << UART_CTL_BITSPERSYM_SHIFT) +#define UART_CTL_XMITBRK_SHIFT 14 +#define UART_CTL_XMITBRK_MASK (1 << UART_CTL_XMITBRK_SHIFT) +#define UART_CTL_RSVD_SHIFT15 +#define UART_CTL_RSVD_MASK (1 << UART_CTL_RSVD_SHIFT) +#define UART_CTL_RXPAREVEN_SHIFT 16 +#define UART_CTL_RXPAREVEN_MASK(1 << UART_CTL_RXPAREVEN_SHIFT) +#define UART_CTL_RXPAREN_SHIFT 17 +#define UART_CTL_RXPAREN_MASK (1 << UART_CTL_RXPAREN_SHIFT) +#define UART_CTL_TXPAREVEN_SHIFT 18 +#define UART_CTL_TXPAREVEN_MASK(1 << UART_CTL_TXPAREVEN_SHIFT) +#define UART_CTL_TXPAREN_SHIFT 19 +#define UART_CTL_TXPAREN_MASK (1 << UART_CTL_TXPAREN_SHIFT) +#define UART_CTL_LOOPBACK_SHIFT20 +#define UART_CTL_LOOPBACK_MASK (1 << UART_CTL_LOOPBACK_SHIFT) +#define UART_CTL_RXEN_SHIFT21 +#define UART_CTL_RXEN_MASK (1 << UART_CTL_RXEN_SHIFT) +#define UART_CTL_TXEN_SHIFT22 +#define UART_CTL_TXEN_MASK (1 << UART_CTL_TXEN_SHIFT) +#define UART_CTL_BRGEN_SHIFT 23 +#define UART_CTL_BRGEN_MASK(1 << UART_CTL_BRGEN_SHIFT) + +/* UART Baudword register */ +#define UART_BAUD_REG 0x4 + +/* UART FIFO Config register */ +#define UART_FIFO_CFG_REG 0x8 +#define UART_FIFO_CFG_RX_SHIFT 8 +#define UART_FIFO_CFG_RX_MASK (0xf << UART_FIFO_CFG_RX_SHIFT) +#define UART_FIFO_CFG_RX_4 (0x4 << UART_FIFO_CFG_RX_SHIFT) +#define UART_FIFO_CFG_TX_SHIFT 12 +#define UART_FIFO_CFG_TX_MASK (0xf << UART_FIFO_CFG_TX_SHIFT) +#define UART_FIFO_CFG_TX_4 (0x4 << UART_FIFO_CFG_TX_SHIFT) + +/* UART Interrupt register */ +#define UART_IR_REG0x10 +#define UART_IR_STAT(x)(1 << (x)) +#define UART_IR_TXEMPTY5 +#define UART_IR_RXOVER 7 +#define UART_IR_RXNOTEMPTY 11 + +/* UART FIFO register */ +#define UART_FIFO_REG 0x14 +#define UART_FIFO_VALID_MASK 0xff +#define UART_FIFO_FRAMEERR_SHIFT 8 +#define UART_FIFO_FRAMEERR_MASK(1 << UART_FIFO_FRAMEERR_SHIFT)
[U-Boot] [PATCH 3/4] cmd: adc: print single conversion also in uV
Use newly introduced adc_raw_to_uV() API to print conversion result
both as raw value and micro-volts by default.
Signed-off-by: Fabrice Gasnier
---
cmd/adc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 39f61c1..7360a96 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -71,8 +71,9 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
{
+ struct udevice *dev;
unsigned int data;
- int ret;
+ int ret, uV;
if (argc < 3)
return CMD_RET_USAGE;
@@ -85,7 +86,11 @@ static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_FAILURE;
}
- printf("%u\n", data);
+ ret = uclass_get_device_by_name(UCLASS_ADC, argv[1], );
+ if (!ret && !adc_raw_to_uV(dev, data, ))
+ printf("%u, %d uV\n", data, uV);
+ else
+ printf("%u\n", data);
return CMD_RET_SUCCESS;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] cmd: adc: add an option to scan some or all available channels
Add new option to 'adc' command to do a single scan of:
- some channel(s), using mask argument
- all channels available on an ADC device (when optional mask is omitted).
Signed-off-by: Fabrice Gasnier
---
cmd/adc.c | 55 ++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 7360a96..2d635ac 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -95,10 +95,62 @@ static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_SUCCESS;
}
+static int do_adc_scan(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct adc_channel ch[ADC_MAX_CHANNEL];
+ struct udevice *dev;
+ unsigned int ch_mask;
+ int i, chan, ret, uV;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ ret = uclass_get_device_by_name(UCLASS_ADC, argv[1], );
+ if (ret) {
+ pr_err("Can't get the ADC %s: %d\n", argv[1], ret);
+ return CMD_RET_FAILURE;
+ }
+
+ switch (argc) {
+ case 3:
+ ch_mask = simple_strtoul(argv[2], NULL, 0);
+ if (ch_mask)
+ break;
+ case 2:
+ ret = adc_channel_mask(dev, _mask);
+ if (ret) {
+ pr_err("Can't get mask for %s: %d\n", dev->name, ret);
+ return CMD_RET_FAILURE;
+ }
+ break;
+ }
+
+ ret = adc_channels_single_shot(dev->name, ch_mask, ch);
+ if (ret) {
+ pr_err("Can't get single shot for %s (chans mask: 0x%x): %d\n",
+ dev->name, ch_mask, ret);
+ return CMD_RET_FAILURE;
+ }
+
+ for (chan = 0, i = 0; chan < ADC_MAX_CHANNEL; chan++) {
+ if (!(ch_mask & ADC_CHANNEL(chan)))
+ continue;
+ if (!adc_raw_to_uV(dev, ch[i].data, ))
+ printf("[%02d]: %u, %d uV\n", ch[i].id, ch[i].data, uV);
+ else
+ printf("[%02d]: %u\n", ch[i].id, ch[i].data);
+ i++;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
static cmd_tbl_t cmd_adc_sub[] = {
U_BOOT_CMD_MKENT(list, 1, 1, do_adc_list, "", ""),
U_BOOT_CMD_MKENT(info, 2, 1, do_adc_info, "", ""),
U_BOOT_CMD_MKENT(single, 3, 1, do_adc_single, "", ""),
+ U_BOOT_CMD_MKENT(scan, 3, 1, do_adc_scan, "", ""),
};
static int do_adc(cmd_tbl_t *cmdtp, int flag, int argc,
@@ -124,6 +176,7 @@ static int do_adc(cmd_tbl_t *cmdtp, int flag, int argc,
static char adc_help_text[] =
"list - list ADC devices\n"
"adc info - Get ADC device info\n"
- "adc single - Get Single data of ADC device channel";
+ "adc single - Get Single data of ADC device channel\n"
+ "adc scan [channel mask] - Scan all [or masked] ADC channels";
U_BOOT_CMD(adc, 4, 1, do_adc, "ADC sub-system", adc_help_text);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add adc uclass's channel mask and conversion helpers and enhance adc cmd
This series adds ADC uclass's helpers to - retrieve the ADC device available channels - ease conversions to standard unit (µV) - enhance 'adc' command to print information on available ADC channels - enhance 'adc' command to print conversion result both as raw and µV - enhance 'adc' command to scan once several or all channels Fabrice Gasnier (4): dm: adc: add uclass's mask and conversion helpers cmd: adc: add info on channel mask cmd: adc: print single conversion also in uV cmd: adc: add an option to scan some or all available channels cmd/adc.c| 70 +--- drivers/adc/adc-uclass.c | 37 + include/adc.h| 21 +++ 3 files changed, 124 insertions(+), 4 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] cmd: adc: add info on channel mask
Enhance adc info command to report also the channel mask.
Signed-off-by: Fabrice Gasnier
---
cmd/adc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index c8857ed..39f61c1 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -35,7 +35,7 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
{
struct udevice *dev;
- unsigned int data_mask;
+ unsigned int data_mask, ch_mask;
int ret, vss, vdd;
if (argc < 2)
@@ -49,6 +49,10 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
printf("ADC Device '%s' :\n", argv[1]);
+ ret = adc_channel_mask(dev, _mask);
+ if (!ret)
+ printf("channel mask: %x\n", ch_mask);
+
ret = adc_data_mask(dev, _mask);
if (!ret)
printf("data mask: %x\n", data_mask);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] dm: adc: add uclass's mask and conversion helpers
Add two functions to ADC uclass's:
- adc_raw_to_uV() to ease ADC raw value conversion to microvolts
- adc_channel_mask() to get channels on consumer side
Signed-off-by: Fabrice Gasnier
---
drivers/adc/adc-uclass.c | 37 +
include/adc.h| 21 +
2 files changed, 58 insertions(+)
diff --git a/drivers/adc/adc-uclass.c b/drivers/adc/adc-uclass.c
index 738c1ea..0a492eb 100644
--- a/drivers/adc/adc-uclass.c
+++ b/drivers/adc/adc-uclass.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,18 @@ int adc_data_mask(struct udevice *dev, unsigned int
*data_mask)
return 0;
}
+int adc_channel_mask(struct udevice *dev, unsigned int *channel_mask)
+{
+ struct adc_uclass_platdata *uc_pdata = dev_get_uclass_platdata(dev);
+
+ if (!uc_pdata)
+ return -ENOSYS;
+
+ *channel_mask = uc_pdata->channel_mask;
+
+ return 0;
+}
+
int adc_stop(struct udevice *dev)
{
const struct adc_ops *ops = dev_get_driver_ops(dev);
@@ -329,6 +342,30 @@ int adc_vss_value(struct udevice *dev, int *uV)
return 0;
}
+int adc_raw_to_uV(struct udevice *dev, unsigned int raw, int *uV)
+{
+ unsigned int data_mask;
+ int ret, val, vref;
+ u64 raw64 = raw;
+
+ ret = adc_vdd_value(dev, );
+ if (ret)
+ return ret;
+
+ if (!adc_vss_value(dev, ))
+ vref -= val;
+
+ ret = adc_data_mask(dev, _mask);
+ if (ret)
+ return ret;
+
+ raw64 *= vref;
+ do_div(raw64, data_mask);
+ *uV = raw64;
+
+ return 0;
+}
+
static int adc_vdd_platdata_set(struct udevice *dev)
{
struct adc_uclass_platdata *uc_pdata = dev_get_uclass_platdata(dev);
diff --git a/include/adc.h b/include/adc.h
index d04c9c4..5841dfb 100644
--- a/include/adc.h
+++ b/include/adc.h
@@ -219,6 +219,17 @@ int adc_channels_data(struct udevice *dev, unsigned int
channel_mask,
int adc_data_mask(struct udevice *dev, unsigned int *data_mask);
/**
+ * adc_channel_mask() - get channel mask for given ADC device
+ *
+ * This can be used if adc uclass platform data is filled.
+ *
+ * @dev: ADC device to check
+ * @channel_mask: pointer to the returned channel bitmask
+ * @return: 0 if OK, -ve on error
+ */
+int adc_channel_mask(struct udevice *dev, unsigned int *channel_mask);
+
+/**
* adc_channel_single_shot() - get output data of conversion for the ADC
* device's channel. This function searches for the device with the given name,
* starts the given channel conversion and returns the output data.
@@ -284,4 +295,14 @@ int adc_vss_value(struct udevice *dev, int *uV);
*/
int adc_stop(struct udevice *dev);
+/**
+ * adc_raw_to_uV() - converts raw value to microvolts for given ADC device.
+ *
+ * @dev: ADC device used from conversion
+ * @raw: raw value to convert
+ * @uV: converted value in microvolts
+ * @return: 0 on success or -ve on error
+ */
+int adc_raw_to_uV(struct udevice *dev, unsigned int raw, int *uV);
+
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i2c: Fix pca953x endianess issue, commit daa75b34828d45b7c1d63009188d45f4a32d06ba
On Thu, 2018-10-11 at 16:11 +0200, Dirk Eibach wrote: > > Hello, > > we have a 16 bit value here, so we have to define whether bit0(containin the > information for IO0.0) is in the first or the second byte. Since the PCA9555 > does this encoding little endian, the conversion is allright. > You used it as some number but this is really just a bunch I/O pins. I haven't seen any endian conversion in the kernel driver, have you? This is a bigger question than this driver really, so: Does IO pins have an endian? Jocke > Cheers > Dirk > Am Do., 11. Okt. 2018 um 07:42 Uhr schrieb Heiko Schocher : > > > > Hello Joakim, > > > > Am 10.10.2018 um 19:34 schrieb Joakim Tjernlund: > > > This commit broke our pca953x usage(on ppc). > > > > > > I wonder why gpio pins here has an endian, its not a number. > > > If there must be an endian connected with this, should it not > > > be a cpu_to_be16 instead, which will retain compatibility ? > > > > Hmm.. good question, I think you are right. May dirk can do a test? > > I have no pca953x with 16bit for doing a test. > > > > bye, > > Heiko > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] mtd: rawnand: pxa3xx: fix 2kiB pages with 8b strength chips layout
The initial layout for such NAND chips was the following:
++
| 1024 (data) | 30 (ECC) | 1024 (data) | 30 (ECC) | 32 (free OOB) | 30 (ECC) |
++
This layout has a weakness: reading empty pages trigger ECC errors
(this is expected), but the hardware ECC engine tries to correct the
data anyway and creates itself bitflips, hence bitflips are detected
in erased pages while actually there are none in the NAND chip.
Two solutions have been found at the same time. One was to enlarge the
free OOB area to 64 bytes, changing the layout to be:
++
| 1024 (data) | 30 (ECC) | 1024 (data) | 30 (ECC) | 64 (free OOB) | 30 (ECC) |
++
^^
The very big drawbacks of this solution are:
1/ It prevents booting from NAND.
2/ The current Linux driver (marvell_nand) does not have such problem
because it already re-reads possible empty pages in raw mode before
checking for bitflips. Using different layouts in U-Boot and Linux
would simply not work.
As this driver does support raw reads now and uses it to check for
empty pages, let's forget about this broken hack and return to the
initial layout with only 32 free OOB bytes.
Fixes: ac56a3b30c ("mtd: nand: pxa3xx: add support for 2KB 8-bit flash")
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 492485b1d0..4d2712df4c 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -327,14 +327,14 @@ static struct nand_ecclayout ecc_layout_2KB_bch4bit = {
static struct nand_ecclayout ecc_layout_2KB_bch8bit = {
.eccbytes = 64,
.eccpos = {
- 64, 65, 66, 67, 68, 69, 70, 71,
- 72, 73, 74, 75, 76, 77, 78, 79,
- 80, 81, 82, 83, 84, 85, 86, 87,
- 88, 89, 90, 91, 92, 93, 94, 95,
- 96, 97, 98, 99, 100, 101, 102, 103,
- 104, 105, 106, 107, 108, 109, 110, 111,
- 112, 113, 114, 115, 116, 117, 118, 119,
- 120, 121, 122, 123, 124, 125, 126, 127},
+ 32, 33, 34, 35, 36, 37, 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 48, 49, 50, 51, 52, 53, 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63,
+ 64, 65, 66, 67, 68, 69, 70, 71,
+ 72, 73, 74, 75, 76, 77, 78, 79,
+ 80, 81, 82, 83, 84, 85, 86, 87,
+ 88, 89, 90, 91, 92, 93, 94, 95},
.oobfree = { {1, 4}, {6, 26} }
};
@@ -1591,7 +1591,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
info->chunk_size = 1024;
info->spare_size = 0;
info->last_chunk_size = 1024;
- info->last_spare_size = 64;
+ info->last_spare_size = 32;
info->ecc_size = 32;
ecc->mode = NAND_ECC_HW;
ecc->size = info->chunk_size;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] mtd: nand: pxa3xx: add raw read support
Raw read support is added by editing a few code sections:
->handle_data_pio() includes the ECC bytes that are not consumed
anymore by the ECC engine.
->prepare_set_command() is changed so that the ECC bytes are
requested as part of the data I/O length.
->drain_fifo() shall also avoid checking the R/B pin too often
when in raw mode.
->read_page_raw()/->read_oob_raw() are written from scratch.
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 98 --
1 file changed, 92 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 4c783f1e1e..454597355b 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -195,6 +195,7 @@ struct pxa3xx_nand_info {
int cs;
int use_ecc;/* use HW ECC ? */
+ int force_raw; /* prevent use_ecc to be set */
int ecc_bch;/* using BCH ECC? */
int use_spare; /* use spare ? */
int need_wait;
@@ -579,7 +580,7 @@ static void disable_int(struct pxa3xx_nand_info *info,
uint32_t int_mask)
static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
{
- if (info->ecc_bch) {
+ if (info->ecc_bch && !info->force_raw) {
u32 ts;
/*
@@ -612,12 +613,22 @@ static void drain_fifo(struct pxa3xx_nand_info *info,
void *data, int len)
static void handle_data_pio(struct pxa3xx_nand_info *info)
{
+ int data_len = info->step_chunk_size;
+
+ /*
+* In raw mode, include the spare area and the ECC bytes that are not
+* consumed by the controller in the data section. Do not reorganize
+* here, do it in the ->read_page_raw() handler instead.
+*/
+ if (info->force_raw)
+ data_len += info->step_spare_size + info->ecc_size;
+
switch (info->state) {
case STATE_PIO_WRITING:
if (info->step_chunk_size)
writesl(info->mmio_base + NDDB,
info->data_buff + info->data_buff_pos,
- DIV_ROUND_UP(info->step_chunk_size, 4));
+ DIV_ROUND_UP(data_len, 4));
if (info->step_spare_size)
writesl(info->mmio_base + NDDB,
@@ -628,7 +639,10 @@ static void handle_data_pio(struct pxa3xx_nand_info *info)
if (info->step_chunk_size)
drain_fifo(info,
info->data_buff + info->data_buff_pos,
- DIV_ROUND_UP(info->step_chunk_size, 4));
+ DIV_ROUND_UP(data_len, 4));
+
+ if (info->force_raw)
+ break;
if (info->step_spare_size)
drain_fifo(info,
@@ -642,7 +656,7 @@ static void handle_data_pio(struct pxa3xx_nand_info *info)
}
/* Update buffer pointers for multi-page read/write */
- info->data_buff_pos += info->step_chunk_size;
+ info->data_buff_pos += data_len;
info->oob_buff_pos += info->step_spare_size;
}
@@ -796,7 +810,8 @@ static void prepare_start_command(struct pxa3xx_nand_info
*info, int command)
case NAND_CMD_READ0:
case NAND_CMD_READOOB:
case NAND_CMD_PAGEPROG:
- info->use_ecc = 1;
+ if (!info->force_raw)
+ info->use_ecc = 1;
break;
case NAND_CMD_PARAM:
info->use_spare = 0;
@@ -866,7 +881,13 @@ static int prepare_set_command(struct pxa3xx_nand_info
*info, int command,
* which is either naked-read or last-read according to the
* state.
*/
- if (mtd->writesize == info->chunk_size) {
+ if (info->force_raw) {
+ info->ndcb0 |= NDCB0_DBC | (NAND_CMD_READSTART << 8) |
+ NDCB0_LEN_OVRD |
+ NDCB0_EXT_CMD_TYPE(ext_cmd_type);
+ info->ndcb3 = info->step_chunk_size +
+ info->step_spare_size + info->ecc_size;
+ } else if (mtd->writesize == info->chunk_size) {
info->ndcb0 |= NDCB0_DBC | (NAND_CMD_READSTART << 8);
} else if (mtd->writesize > info->chunk_size) {
info->ndcb0 |= NDCB0_DBC | (NAND_CMD_READSTART << 8)
@@ -1238,6 +1259,69 @@ static int pxa3xx_nand_read_page_hwecc(struct mtd_info
*mtd,
return info->max_bitflips;
}
+static int pxa3xx_nand_read_page_raw(struct mtd_info *mtd,
+struct nand_chip *chip, uint8_t *buf,
+
[U-Boot] [PATCH 2/3] mtd: nand: pxa3xx: re-read a page in raw mode on uncorrectable error
This only applies on BCH path.
When an empty page is read, it triggers an uncorrectable error. While
this is expected, the ECC engine might produce itself bitflips in the
read data under certain layouts. To overcome this situation, always
re-read the entire page in raw mode and check for the whole page to be
empty.
Also report the right number of bitflips if there are any.
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 454597355b..492485b1d0 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -1237,6 +1237,7 @@ static int pxa3xx_nand_read_page_hwecc(struct mtd_info
*mtd,
{
struct pxa3xx_nand_host *host = nand_get_controller_data(chip);
struct pxa3xx_nand_info *info = host->info_data;
+ int bf;
chip->read_buf(mtd, buf, mtd->writesize);
chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1244,12 +1245,30 @@ static int pxa3xx_nand_read_page_hwecc(struct mtd_info
*mtd,
if (info->retcode == ERR_CORERR && info->use_ecc) {
mtd->ecc_stats.corrected += info->ecc_err_cnt;
- } else if (info->retcode == ERR_UNCORERR) {
+ } else if (info->retcode == ERR_UNCORERR && info->ecc_bch) {
/*
-* for blank page (all 0xff), HW will calculate its ECC as
-* 0, which is different from the ECC information within
-* OOB, ignore such uncorrectable errors
+* Empty pages will trigger uncorrectable errors. Re-read the
+* entire page in raw mode and check for bits not being "1".
+* If there are more than the supported strength, then it means
+* this is an actual uncorrectable error.
*/
+ chip->ecc.read_page_raw(mtd, chip, buf, oob_required, page);
+ bf = nand_check_erased_ecc_chunk(buf, mtd->writesize,
+chip->oob_poi, mtd->oobsize,
+NULL, 0, chip->ecc.strength);
+ if (bf < 0) {
+ mtd->ecc_stats.failed++;
+ } else if (bf) {
+ mtd->ecc_stats.corrected += bf;
+ info->max_bitflips = max_t(unsigned int,
+ info->max_bitflips, bf);
+ info->retcode = ERR_CORERR;
+ } else {
+ info->retcode = ERR_NONE;
+ }
+
+ } else if (info->retcode == ERR_UNCORERR && !info->ecc_bch) {
+ /* Raw read is not supported with Hamming ECC engine */
if (is_buf_blank(buf, mtd->writesize))
info->retcode = ERR_NONE;
else
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] Add raw read support and use it in pxa3xx NAND driver
When using 2kiB-pages NAND chips requesting an 8-bit strength ECC, the layout used is a bit particular and it happens that the ECC engine tries to correct uncorrectable errors on empty pages, producing bitflips. To avoid such situation, raw read support is added to the pxa3xx_nand driver, and then used to re-read the page (in raw mode) upon uncorrectable error detection to know if there is an actual ECC mismatch or if the page is empty. This way we avoid seeing the bitflips created by the hardware ECC engine. Once this done, we can revert the hack that was done in the driver to enlarge the last spare area for this layout to 64B instead of 32B, breaking U-Boot/Linux compatibility and preventing the BootROM to boot from NAND. Thanks, Miquèl Miquel Raynal (3): mtd: nand: pxa3xx: add raw read support mtd: nand: pxa3xx: re-read a page in raw mode on uncorrectable error mtd: rawnand: pxa3xx: fix 2kiB pages with 8b strength chips layout drivers/mtd/nand/raw/pxa3xx_nand.c | 143 + 1 file changed, 124 insertions(+), 19 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ls1012afrwy:update ls1012afrwy env board variable
On 10/10/2018 11:40 PM, Pramod Kumar wrote: > ls1012afrwy and ls1012afrdm both boards are varinat of ls1012a based > SoC board. > By default board and board_name uboot env variables are set as > ls1012afrdm. > whenever board is detected as ls1012afrwy, uboot env > variables are upadted to ls1012afrwy if it set as ls1012afrdm. Please reformat your subject and commit message, as described as https://www.denx.de/wiki/view/U-Boot/Patches#Commit_message_conventions York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
Hi Heinrich, On Thu, Oct 11, 2018 at 11:32 PM Heinrich Schuchardt wrote: > > On 10/11/2018 05:27 PM, Bin Meng wrote: > > Hi Heinrich, > > > > On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt > > wrote: > >> > >> On 10/11/2018 03:53 AM, Bin Meng wrote: > >>> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention > >>> the 64-bit support. > >>> > >>> Signed-off-by: Bin Meng > >>> --- > >>> > >>> doc/README.x86 | 8 ++-- > >>> 1 file changed, 6 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/doc/README.x86 b/doc/README.x86 > >>> index 8cc4672..ab48466 100644 > >>> --- a/doc/README.x86 > >>> +++ b/doc/README.x86 > >>> @@ -32,7 +32,7 @@ are supported: > >>> - Link (Chromebook Pixel) > >>> - Minnowboard MAX > >>> - Samus (Chromebook Pixel 2015) > >>> - - QEMU x86 > >>> + - QEMU x86 (32-bit & 64-bit) > >>> > >>> As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit > >>> Linux kernel as part of a FIT image. It also supports a compressed > >>> zImage. > >>> @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: > >>> > >>> To build u-boot.rom for QEMU x86 targets, just simply run > >>> > >>> -$ make qemu-x86_defconfig > >>> +$ make qemu-x86_defconfig (for 32-bit) > >>> +or > >>> +$ make qemu-x86_64_defconfig (for 64-bit) > >>> $ make all > >> > >> If your patch series creates a U-Boot usable with QEMU depends on the > >> chosen CPU: > >> > >> This one seems to work: > >> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo > >> > >> This one fails (as expected): > >> qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium > > > > Pentium does not support 64-bit, so it is expected. In my testing I > > always omit the '-cpu' so this is not a problem. But I can document > > this. > > > >> > >> I could not get the emulation running without -nographic. Do you know why? > >> > > > > This is due to currently the VGA support is missing in the 64-bit U-Boot. > > > >> The documentation above is insufficient. Please, provide a minimum QEMU > >> command line which includes a CPU specification. > >> > >> I would prefer if you could specify two lines per bitness - one with kvm > >> and one without, e.g. > > > > I doubt -enable-kvm works with U-Boot. > > Why? It is just an instruction how QEMU should emulate the CPU. KVM does > not require anything on the target software side. > > I have had no problem with KVM on the i386 target. I suspect some drivers may have issues when working with KVM, eg: some memory barriers might be needed due to guest (U-Boot) and host (x86 machine) are speaking the same language. But I have never fully test this configuration. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
On 10/11/2018 05:27 PM, Bin Meng wrote: > Hi Heinrich, > > On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt > wrote: >> >> On 10/11/2018 03:53 AM, Bin Meng wrote: >>> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention >>> the 64-bit support. >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> doc/README.x86 | 8 ++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/doc/README.x86 b/doc/README.x86 >>> index 8cc4672..ab48466 100644 >>> --- a/doc/README.x86 >>> +++ b/doc/README.x86 >>> @@ -32,7 +32,7 @@ are supported: >>> - Link (Chromebook Pixel) >>> - Minnowboard MAX >>> - Samus (Chromebook Pixel 2015) >>> - - QEMU x86 >>> + - QEMU x86 (32-bit & 64-bit) >>> >>> As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit >>> Linux kernel as part of a FIT image. It also supports a compressed zImage. >>> @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: >>> >>> To build u-boot.rom for QEMU x86 targets, just simply run >>> >>> -$ make qemu-x86_defconfig >>> +$ make qemu-x86_defconfig (for 32-bit) >>> +or >>> +$ make qemu-x86_64_defconfig (for 64-bit) >>> $ make all >> >> If your patch series creates a U-Boot usable with QEMU depends on the >> chosen CPU: >> >> This one seems to work: >> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo >> >> This one fails (as expected): >> qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium > > Pentium does not support 64-bit, so it is expected. In my testing I > always omit the '-cpu' so this is not a problem. But I can document > this. > >> >> I could not get the emulation running without -nographic. Do you know why? >> > > This is due to currently the VGA support is missing in the 64-bit U-Boot. > >> The documentation above is insufficient. Please, provide a minimum QEMU >> command line which includes a CPU specification. >> >> I would prefer if you could specify two lines per bitness - one with kvm >> and one without, e.g. > > I doubt -enable-kvm works with U-Boot. Why? It is just an instruction how QEMU should emulate the CPU. KVM does not require anything on the target software side. I have had no problem with KVM on the i386 target. Regards Heinrich > >> >> qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host >> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo >> >> qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host >> qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo >> > > Will add more info in v2. > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
Hi Heinrich, On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt wrote: > > On 10/11/2018 03:53 AM, Bin Meng wrote: > > Currently only 32-bit U-Boot for QEMU x86 is documented. Mention > > the 64-bit support. > > > > Signed-off-by: Bin Meng > > --- > > > > doc/README.x86 | 8 ++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/doc/README.x86 b/doc/README.x86 > > index 8cc4672..ab48466 100644 > > --- a/doc/README.x86 > > +++ b/doc/README.x86 > > @@ -32,7 +32,7 @@ are supported: > > - Link (Chromebook Pixel) > > - Minnowboard MAX > > - Samus (Chromebook Pixel 2015) > > - - QEMU x86 > > + - QEMU x86 (32-bit & 64-bit) > > > > As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit > > Linux kernel as part of a FIT image. It also supports a compressed zImage. > > @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: > > > > To build u-boot.rom for QEMU x86 targets, just simply run > > > > -$ make qemu-x86_defconfig > > +$ make qemu-x86_defconfig (for 32-bit) > > +or > > +$ make qemu-x86_64_defconfig (for 64-bit) > > $ make all > > If your patch series creates a U-Boot usable with QEMU depends on the > chosen CPU: > > This one seems to work: > qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo > > This one fails (as expected): > qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium Pentium does not support 64-bit, so it is expected. In my testing I always omit the '-cpu' so this is not a problem. But I can document this. > > I could not get the emulation running without -nographic. Do you know why? > This is due to currently the VGA support is missing in the 64-bit U-Boot. > The documentation above is insufficient. Please, provide a minimum QEMU > command line which includes a CPU specification. > > I would prefer if you could specify two lines per bitness - one with kvm > and one without, e.g. I doubt -enable-kvm works with U-Boot. > > qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host > qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo > > qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host > qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo > Will add more info in v2. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper
On 10/11/2018 03:53 AM, Bin Meng wrote: > With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image > built for qemu-x86_64 target does not boot. It keeps resetting > soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows > that the reset happens inside env_callback_init(). > > 0113dd85 : > 113dd85: 41 54 push %r12 > 113dd87: 55 push %rbp > 113dd88: 31 c0 xor%eax,%eax > 113dd8a: 53 push %rbx > 113dd8b: 0f 57 c0xorps %xmm0,%xmm0 > > Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset. > However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04) > does not generate such instructions that utilizes SSE for this > function - env_callback_init() and U-Boot boots without any issue. > Explicitly specifying -march=core2 for newer GCC allows U-Boot > proper to boot again. Examine assembly codes of env_callback_init > and there is no SSE instruction in that function hence U-Boot > continues to boot. > > core2 seems to be the oldest arch in GCC that supports 64-bit. > Like 32-bit U-Boot build we use -march=i386 which is the most > conservative cpu type so that the image can run on any x86 > processor, let's do the same for the 64-bit U-Boot build. > > Signed-off-by: Bin Meng Reviewed-by: Heinrich Schuchardt > --- > > arch/x86/config.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > index cc94071..576501e 100644 > --- a/arch/x86/config.mk > +++ b/arch/x86/config.mk > @@ -23,7 +23,7 @@ endif > ifeq ($(IS_32BIT),y) > PLATFORM_CPPFLAGS += -march=i386 -m32 > else > -PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64 > +PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common > -march=core2 -m64 > endif > > PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
On 10/11/2018 03:53 AM, Bin Meng wrote: > Currently only 32-bit U-Boot for QEMU x86 is documented. Mention > the 64-bit support. > > Signed-off-by: Bin Meng > --- > > doc/README.x86 | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/doc/README.x86 b/doc/README.x86 > index 8cc4672..ab48466 100644 > --- a/doc/README.x86 > +++ b/doc/README.x86 > @@ -32,7 +32,7 @@ are supported: > - Link (Chromebook Pixel) > - Minnowboard MAX > - Samus (Chromebook Pixel 2015) > - - QEMU x86 > + - QEMU x86 (32-bit & 64-bit) > > As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit > Linux kernel as part of a FIT image. It also supports a compressed zImage. > @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: > > To build u-boot.rom for QEMU x86 targets, just simply run > > -$ make qemu-x86_defconfig > +$ make qemu-x86_defconfig (for 32-bit) > +or > +$ make qemu-x86_64_defconfig (for 64-bit) > $ make all If your patch series creates a U-Boot usable with QEMU depends on the chosen CPU: This one seems to work: qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo This one fails (as expected): qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium I could not get the emulation running without -nographic. Do you know why? The documentation above is insufficient. Please, provide a minimum QEMU command line which includes a CPU specification. I would prefer if you could specify two lines per bitness - one with kvm and one without, e.g. qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo Best regards Heinrich > > Note this default configuration will build a U-Boot for the QEMU x86 i440FX > @@ -387,6 +389,8 @@ Device Tree Control ---> > ... > (qemu-x86_q35) Default Device Tree for DT control > > +To run 64-bit U-Boot, qemu-system-x86_64 should be used instead. > + > Test with coreboot > -- > For testing U-Boot as the coreboot payload, there are things that need be > paid > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Some SPI NOR chips only support 4-byte mode addressing. Here the default
3-byte mode does not work and leads to incorrect accesses. This patch
now reads the 4-byte mode status bit (in this case in the CR register
of the Macronix SPI NOR) and configures the SPI transfers accordingly.
This was noticed on the LinkIt Smart 7688 modul, which is equipped with
an Macronix MX25L25635F device. But this device does *NOT* support
switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to
4-byte mode and runs U-Boot after this. U-Boot should dectect this
mode (if the 4-byte mode detection is available for this chip) and
use the correct OPs in this case.
Signed-off-by: Stefan Roese
Cc: Jagan Teki
Tested-by: Simon Goldschmidt
---
v3:
- Rebased on latest version (merge conflict because of new patches
from Simon Glass)
- Added Tested-by tag from Simon Goldschmidt
v2:
- Integrated STMICRO 4-byte detection from Simon
drivers/mtd/spi/sf_internal.h | 3 +-
drivers/mtd/spi/spi_flash.c | 131 --
include/spi_flash.h | 5 ++
3 files changed, 118 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 4f63cacc64..eb076401d1 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -26,7 +26,8 @@ enum spi_nor_option_flags {
};
#define SPI_FLASH_3B_ADDR_LEN 3
-#define SPI_FLASH_CMD_LEN (1 + SPI_FLASH_3B_ADDR_LEN)
+#define SPI_FLASH_4B_ADDR_LEN 4
+#define SPI_FLASH_CMD_MAX_LEN (1 + SPI_FLASH_4B_ADDR_LEN)
#define SPI_FLASH_16MB_BOUN0x100
/* CFI Manufacture ID's */
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 9230060364..b22eea2d1c 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -20,12 +20,19 @@
#include "sf_internal.h"
-static void spi_flash_addr(u32 addr, u8 *cmd)
+static void spi_flash_addr(struct spi_flash *flash, u32 addr, u8 *cmd)
{
/* cmd[0] is actual command */
- cmd[1] = addr >> 16;
- cmd[2] = addr >> 8;
- cmd[3] = addr >> 0;
+ if (flash->in_4byte_mode) {
+ cmd[1] = addr >> 24;
+ cmd[2] = addr >> 16;
+ cmd[3] = addr >> 8;
+ cmd[4] = addr >> 0;
+ } else {
+ cmd[1] = addr >> 16;
+ cmd[2] = addr >> 8;
+ cmd[3] = addr >> 0;
+ }
}
static int read_sr(struct spi_flash *flash, u8 *rs)
@@ -110,6 +117,72 @@ static int write_cr(struct spi_flash *flash, u8 wc)
}
#endif
+#if defined(CONFIG_SPI_FLASH_MACRONIX)
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ int ret;
+ u8 cr;
+ u8 cmd;
+
+ cmd = 0x15; /* Macronix: read configuration register RDCR */
+ ret = spi_flash_read_common(flash, , 1, , 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (cr & BIT(5))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ int ret;
+ u8 fsr;
+ u8 cmd;
+
+ cmd = 0x70; /* STMicro/Micron: read flag status register */
+ ret = spi_flash_read_common(flash, , 1, , 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (fsr & BIT(0))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+static bool flash_in_4byte_mode(struct spi_flash *flash,
+ const struct spi_flash_info *info)
+{
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX)
+ return flash_in_4byte_mode_macronix(flash);
+
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_STMICRO)
+ return flash_in_4byte_mode_stmicro(flash);
+
+ return false;
+}
+
#ifdef CONFIG_SPI_FLASH_BAR
/*
* This "clean_bar" is necessary in a situation when one was accessing
@@ -314,7 +387,7 @@ int spi_flash_write_common(struct spi_flash *flash, const
u8 *cmd,
int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
{
u32 erase_size, erase_addr;
- u8 cmd[SPI_FLASH_CMD_LEN];
+ u8 cmd[SPI_FLASH_CMD_MAX_LEN];
int ret = -1;
erase_size = flash->erase_size;
@@ -344,12 +417,13 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32
offset, size_t len)
if (ret < 0)
return ret;
#endif
-
[U-Boot] [PATCH v2] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Some SPI NOR chips only support 4-byte mode addressing. Here the default
3-byte mode does not work and leads to incorrect accesses. This patch
now reads the 4-byte mode status bit (in this case in the CR register
of the Macronix SPI NOR) and configures the SPI transfers accordingly.
This was noticed on the LinkIt Smart 7688 modul, which is equipped with
an Macronix MX25L25635F device. But this device does *NOT* support
switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to
4-byte mode and runs U-Boot after this. U-Boot should dectect this
mode (if the 4-byte mode detection is available for this chip) and
use the correct OPs in this case.
Signed-off-by: Stefan Roese
Cc: Jagan Teki
Cc: Simon Goldschmidt
---
v2:
- Integrated STMICRO 4-byte detection from Simon
drivers/mtd/spi/sf_internal.h | 3 +-
drivers/mtd/spi/spi_flash.c | 131 --
include/spi_flash.h | 5 ++
3 files changed, 118 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 4f63cacc64..eb076401d1 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -26,7 +26,8 @@ enum spi_nor_option_flags {
};
#define SPI_FLASH_3B_ADDR_LEN 3
-#define SPI_FLASH_CMD_LEN (1 + SPI_FLASH_3B_ADDR_LEN)
+#define SPI_FLASH_4B_ADDR_LEN 4
+#define SPI_FLASH_CMD_MAX_LEN (1 + SPI_FLASH_4B_ADDR_LEN)
#define SPI_FLASH_16MB_BOUN0x100
/* CFI Manufacture ID's */
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index c159124259..e41c5a961b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -20,12 +20,19 @@
#include "sf_internal.h"
-static void spi_flash_addr(u32 addr, u8 *cmd)
+static void spi_flash_addr(struct spi_flash *flash, u32 addr, u8 *cmd)
{
/* cmd[0] is actual command */
- cmd[1] = addr >> 16;
- cmd[2] = addr >> 8;
- cmd[3] = addr >> 0;
+ if (flash->in_4byte_mode) {
+ cmd[1] = addr >> 24;
+ cmd[2] = addr >> 16;
+ cmd[3] = addr >> 8;
+ cmd[4] = addr >> 0;
+ } else {
+ cmd[1] = addr >> 16;
+ cmd[2] = addr >> 8;
+ cmd[3] = addr >> 0;
+ }
}
static int read_sr(struct spi_flash *flash, u8 *rs)
@@ -110,6 +117,72 @@ static int write_cr(struct spi_flash *flash, u8 wc)
}
#endif
+#if defined(CONFIG_SPI_FLASH_MACRONIX)
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ int ret;
+ u8 cr;
+ u8 cmd;
+
+ cmd = 0x15; /* Macronix: read configuration register RDCR */
+ ret = spi_flash_read_common(flash, , 1, , 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (cr & BIT(5))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ int ret;
+ u8 fsr;
+ u8 cmd;
+
+ cmd = 0x70; /* STMicro/Micron: read flag status register */
+ ret = spi_flash_read_common(flash, , 1, , 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (fsr & BIT(0))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+static bool flash_in_4byte_mode(struct spi_flash *flash,
+ const struct spi_flash_info *info)
+{
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX)
+ return flash_in_4byte_mode_macronix(flash);
+
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_STMICRO)
+ return flash_in_4byte_mode_stmicro(flash);
+
+ return false;
+}
+
#ifdef CONFIG_SPI_FLASH_BAR
/*
* This "clean_bar" is necessary in a situation when one was accessing
@@ -314,7 +387,7 @@ int spi_flash_write_common(struct spi_flash *flash, const
u8 *cmd,
int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
{
u32 erase_size, erase_addr;
- u8 cmd[SPI_FLASH_CMD_LEN];
+ u8 cmd[SPI_FLASH_CMD_MAX_LEN];
int ret = -1;
erase_size = flash->erase_size;
@@ -344,12 +417,13 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32
offset, size_t len)
if (ret < 0)
return ret;
#endif
- spi_flash_addr(erase_addr, cmd);
+ spi_flash_addr(flash, erase_addr, cmd);
debug("SF: erase %2x %2x %2x %2x
Re: [U-Boot] tests/test_bind.py: Update test to match the wider 'dm tree' output
Hi Tom,
On 11 October 2018 at 08:11, Tom Rini wrote:
>
> On Tue, Oct 02, 2018 at 04:22:58PM +0100, Liviu Dudau wrote:
>
> > Commit ("dm: core: Widen the dump tree to show more of the driver's
> > name") has widened the field reserved for the name of a driver, so
> > we need to update the test to match.
> >
> > Signed-off-by: Liviu Dudau
> > ---
> > test/py/tests/test_bind.py | 28 ++--
> > 1 file changed, 14 insertions(+), 14 deletions(-)
>
> For me, this breaks "make tests".
Yes, it needs another patch, that I dropped because it breaks the
tests. This patch fixes them but only if that patch is applied.
Liviu, how about sending a patch that combines both?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] linux/compat.h: Add netdev_### log macros
Hi Joe, On Wed, Oct 10, 2018 at 4:39 AM Joe Hershberger wrote: > > On Sun, Oct 7, 2018 at 7:53 AM Bin Meng wrote: > > > > Hi Joe, > > > > On Sat, Sep 15, 2018 at 4:37 AM Joe Hershberger > > wrote: > > > > > > Hi Bin, > > > On Tue, Sep 11, 2018 at 5:07 AM Bin Meng wrote: > > > > > > > > Hi Joe, > > > > > > > > On Fri, Jul 27, 2018 at 2:52 AM Joe Hershberger > > > > wrote: > > > > > > > > > > On Thu, Jul 26, 2018 at 5:15 AM, Bin Meng wrote: > > > > > > Currently there are two ethernet drivers (mvneta.c and mvpp2.c) that > > > > > > has netdev_### (eg: netdev_dbg) log macros defined in its own driver > > > > > > file. This adds these log macros in a common place linux/compat.h. > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > > > Acked-by: Joe Hershberger > > > > > > > > When will the following be merged? Thanks! > > > > > > Now that we have a release, I'll try to get them in my queue next week. > > > > > > > ping ? > > Part of my current test building on travis: > https://travis-ci.org/jhershbe/u-boot/builds/439322261 > Please let me know when the PR will be sent. I have some patches that are dependent on these. Thanks! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] efi_loader: set image_base and image_size to correct values
On 10/11/2018 01:11 PM, AKASHI Takahiro wrote:
> Currently, image's image_base points to an address where the image was
> temporarily uploaded for further loading. Since efi_loader relocates
> the image to final destination, image_base and image_size should reflect
> that.
>
> This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
> which shows that 'Unload' function doesn't fit into a range suggested by
> image_base and image_size.
> TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/
> LoadedImageBBTestMain.c:1002
>
> Changes in this patch also includes:
> * reverts a patch, "efi_loader: save image relocation address
> and size" since newly added fields are no longer needed.
> * copy PE headers as well since those information will be needed
> for module loading, in particular, at gurb.
> (This bug was reported by Heinrich.)
>
> Signed-off-by: AKASHI Takahiro
> Reported-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_image_loader.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/lib/efi_loader/efi_image_loader.c
> b/lib/efi_loader/efi_image_loader.c
> index a18ce0a5705e..d1b6c0d3cdf2 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -59,10 +59,10 @@ static efi_status_t efi_print_image_info(struct
> efi_loaded_image_obj *obj,
> {
> printf("UEFI image");
> printf(" [0x%p:0x%p]",
> -obj->reloc_base, obj->reloc_base + obj->reloc_size - 1);
> - if (pc && pc >= obj->reloc_base &&
> - pc < obj->reloc_base + obj->reloc_size)
> - printf(" pc=0x%zx", pc - obj->reloc_base);
> +image->image_base, image->image_base + image->image_size - 1);
> + if (pc && pc >= image->image_base &&
> + pc < image->image_base + image->image_size)
> + printf(" pc=0x%zx", pc - image->image_base);
> if (image->file_path)
> printf(" '%pD'", image->file_path);
> printf("\n");
> @@ -212,7 +212,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> int rel_idx = IMAGE_DIRECTORY_ENTRY_BASERELOC;
> void *entry;
> uint64_t image_base;
> - uint64_t image_size;
> unsigned long virt_size = 0;
> int supported = 0;
>
> @@ -256,7 +255,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
> IMAGE_OPTIONAL_HEADER64 *opt = >OptionalHeader;
> image_base = opt->ImageBase;
> - image_size = opt->SizeOfImage;
> efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> efi_reloc = efi_alloc(virt_size,
> loaded_image_info->image_code_type);
> @@ -272,7 +270,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
> IMAGE_OPTIONAL_HEADER32 *opt = >OptionalHeader;
> image_base = opt->ImageBase;
> - image_size = opt->SizeOfImage;
> efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> efi_reloc = efi_alloc(virt_size,
> loaded_image_info->image_code_type);
> @@ -291,6 +288,11 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> return NULL;
> }
>
> + /* Copy PE headers */
> + memcpy(efi_reloc, efi, sizeof(*dos) + sizeof(*nt)
> + + nt->FileHeader.SizeOfOptionalHeader
> + + num_sections * sizeof(IMAGE_SECTION_HEADER));
> +
Why do we have to copy PE headers and the sections below separately? My
understanding is that the relative positions do not need any adjustment.
Nothing in the spec requires the COFF header to be at offset
sizeof(dos). You can put the COFF headder anywhere in the file. Please,
read
https://media.blackhat.com/bh-us-11/Vuksan/BH_US_11_VuksanPericin_PECOFF_WP.pdf
We should not assign new memory here. Nor should we copy anything here.
We should simply use the relocation table to update the indicated memory
locations.
Best regards
Heinrich
> /* Load sections into RAM */
> for (i = num_sections - 1; i >= 0; i--) {
> IMAGE_SECTION_HEADER *sec = [i];
> @@ -315,10 +317,8 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> invalidate_icache_all();
>
> /* Populate the loaded image interface bits */
> - loaded_image_info->image_base = efi;
> - loaded_image_info->image_size = image_size;
> - handle->reloc_base = efi_reloc;
> - handle->reloc_size = virt_size;
> + loaded_image_info->image_base = efi_reloc;
> + loaded_image_info->image_size = virt_size;
>
> return entry;
> }
>
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] bootm: Add board specific OS preboot hook
On Thu, Oct 04, 2018 at 09:16:31PM +0200, Marek Vasut wrote: > Add board-specific hook which is executed before the code hands over > control to the OS. This lets the board perform some last-minute clean > ups. > > Signed-off-by: Marek Vasut > Cc: Tom Rini > Reviewed-by: Simon Goldschmidt 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] [U-Boot, 2/2] ARM: meson: Add Khadas VIM2 board support
On Wed, Oct 03, 2018 at 12:02:07PM +0200, Loic Devulder wrote: > This adds platform code for the Khadas VIM2 board based on a > Meson GXM (S912) SoC with the Meson GXM configuration. > > This initial submission supports UART, MMC/SDCard and Ethernet. > USB is partially supported. > > All the code is from Neil Armstrong! I just rebased the code, do > some cleanup and tested on my board. > > Signed-off-by: Neil Armstrong > Signed-off-by: Loic Devulder > Acked-by: Neil Armstrong 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] [U-Boot, v2, 2/2] gpio: da8xx: Push generic defines of gpio.h out of mach-davinci
On Wed, Oct 03, 2018 at 05:55:14PM +0530, Keerthy wrote: > Push generic defines of gpio.h out of mach-davinci to drivers/gpio > now that non-davinci architectures are beginning to use this IP. > > Signed-off-by: Keerthy > Reviewed-by: Tom Rini 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] [U-Boot, v2, 2/2] board: ks2: move uinitrd fixup logic inside ft_board_setup_ex
On Wed, Oct 03, 2018 at 12:58:49PM +0200, Nicholas Faustini wrote: > The uinitrd fixup logic should be executed after the FDT /chosen > node has been properly populated by fdt_initrd() > > Signed-off-by: Nicholas Faustini > Reviewed-by: Tom Rini 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] [U-Boot,3/5] arm: remove prototype for udelay_masked
On Fri, Oct 05, 2018 at 11:33:51AM +0200, Patrick Delaunay wrote: > The interruption support had be removed for ARM architecture and > the function udelay_masked() is no more used except in some timer.c > files and have the same content than udelay() or __udelay(). > > This patch update each timer.c implementing this function and > remove the associated prototype in u-boot-arm.h. > > Signed-off-by: Patrick Delaunay 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] [U-Boot,1/2] ARM: meson: Add Khadas VIM2 board DT
On Wed, Oct 03, 2018 at 12:02:06PM +0200, Loic Devulder wrote: > This adds Device Tree for the Khadas VIM2 board. > > The meson-gxm-khadas-vim2.dts is synchronized from Linux 4.18.10. > > Signed-off-by: Neil Armstrong > Signed-off-by: Loic Devulder > Acked-by: Neil Armstrong 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] [U-Boot, 1/5] arm: remove prototype for arch_interrupt_init
On Fri, Oct 05, 2018 at 11:33:49AM +0200, Patrick Delaunay wrote: > Remove prototype for no more existing function > > Signed-off-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARC: Don't use COMMON section for global not-initialized variables
By default GCC puts global non-initialized variables in COMMON section. And we used to ignore existence of COMMON section in our linker scripts though smart LD silently appended it right after .bss. And the problem here is variables from COMMON section even though require zeroing in run-time were not zeroed as they were placed right after __bss_end symbol. It was a pure luck we never faced serious problem due to this, but now it is fixed. Now as for some other architectures we'll just force GCC to put those global variables in normal .bss section. This solution is much nicer than adding COMMON section to each and every linker script. Signed-off-by: Alexey Brodkin --- arch/arc/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/config.mk b/arch/arc/config.mk index d255c90..18005d9 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -43,7 +43,7 @@ PLATFORM_CPPFLAGS += -mcpu=archs endif PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -gdwarf-2 -mno-sdata -PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections -fno-common # Needed for relocation LDFLAGS_FINAL += -pie --gc-sections -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] arm: K3: am654: Add support for getting boot mode
On Wed, Oct 03, 2018 at 10:03:23AM -0500, Andrew F. Davis wrote: > Read the boot mode register to find the boot mode. Only use eMMC boot0 > mode when the mode is eMMC boot (called BOOT_DEVICE_MMC1 currently due > to current conflating of boot mode and boot device), and not iff the > boot device is MMC port 0. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > Reviewed-by: Lokesh Vutla 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] [U-Boot, v2, 1/2] fdt: add call to ft_board_setup_ex() for ks2 boards
On Wed, Oct 03, 2018 at 12:58:48PM +0200, Nicholas Faustini wrote: > When updating the board FDT, some of the operations > are performed by ft_board_setup_ex() and should be > executed also by the fdt command. > > Signed-off-by: Nicholas Faustini > Reviewed-by: Tom Rini 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] [U-Boot, 1/2] arm: K3: am654: Choose MMC boot device based on boot port
On Wed, Oct 03, 2018 at 10:03:22AM -0500, Andrew F. Davis wrote: > For most devices the boot mode maps directly to the boot > device. For MMC this is not the case as we have two MMC > boot modes and two MMC boot devices (ports). Check the > boot port to determine which MMC device was our boot > device. Make this change for both primary and secondary > boot modes. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > Reviewed-by: Lokesh Vutla 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] ARM: dts: stm32mp1: Add usbotg_hs regulator for stm32mp157c-ev1
On Wed, Oct 03, 2018 at 09:38:38AM +0200, Patrice Chotard wrote: > Add usbotg_hs regulator to allow to use the USB mass-storage > feature on OTG usb port. > > Signed-off-by: Patrice Chotard 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] [U-Boot, 2/5] arm: remove prototype for reset_timer_masked
On Fri, Oct 05, 2018 at 11:33:50AM +0200, Patrick Delaunay wrote: > Remove prototype for function only used in one file > > Signed-off-by: Patrick Delaunay 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
