Re: [U-Boot] efi_loader: execute image's unload function
Heinrich,
On Fri, Sep 28, 2018 at 04:35:57AM +0200, Heinrich Schuchardt wrote:
> On 08/09/2018 08:50 AM, AKASHI Takahiro wrote:
> > Currently, unload function in EFI_LOADED_IMAGE_PROTOCOL is never called
> > at UnloadImage Boot Service. This is not compliant to UEFI specification.
> > See chapter "9.1 EFI Loaded Image Protocol."
>
> With all the patches we got into U-Boot (+HII protocols, +HOB and DXE
> tables) we now can start the EFI shell. But I do not succeed to run the
> SCT. Could you, please, provide an overview what is needed.
>
> I use the sct-prepare target in
> https://github.com/xypron/u-boot-build/blob/qemu-arm64/Makefile to set
> up my disk image with the SCT.
>
> Are we missing further patches or is there something wrong with the
> image I generate?
I have the same problem since I rebased my own branch to Alex's
efi-next this week. I'm trying to understand what's happening now.
I will address your comments below later.
Thanks,
-Takahiro Akashi
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > include/efi_api.h | 4 +++-
> > lib/efi_loader/efi_boottime.c | 9 +
> > 2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/efi_api.h b/include/efi_api.h
> > index a4343ae98e2..b2806fba3b8 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -326,6 +326,8 @@ struct efi_system_table {
> >
> > #define EFI_LOADED_IMAGE_PROTOCOL_REVISION 0x1000
> >
> > +typedef efi_status_t (EFIAPI *efi_image_unload_t)(efi_handle_t
> > *image_handle);
>
> In the rest of efi_api.h we never used typedefs for function prototypes.
> I would prefer to use the explicit type.
>
> In scripts/checkpatch.pl this will create a warning.
>
> > +
> > struct efi_loaded_image {
> > u32 revision;
> > void *parent_handle;
> > @@ -339,7 +341,7 @@ struct efi_loaded_image {
> > aligned_u64 image_size;
> > unsigned int image_code_type;
> > unsigned int image_data_type;
> > - unsigned long unload;
> > + efi_image_unload_t unload;
> >
> > /* Below are efi loader private fields */
> > #ifdef CONFIG_EFI_LOADER
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index 80061e10ebc..d6fcf7e0049 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -1843,9 +1843,18 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t
> > image_handle,
> > */
> > static efi_status_t EFIAPI efi_unload_image(efi_handle_t image_handle)
> > {
> > + struct efi_loaded_image *info = image_handle;
>
> Please, do not assume the the image_handle points to the
> EFI_LOADED_IMAGE_PROTOCOL. Anyway this is not valid anymore after
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=c982874e930d5d673501cd94df07bcbd215d5883
>
> Best regards
>
> Heinrich
>
> > struct efi_object *efiobj;
> > + efi_status_t ret;
> >
> > EFI_ENTRY("%p", image_handle);
> > +
> > + if (info->unload) {
> > + ret = info->unload(image_handle);
> > + if (ret != EFI_SUCCESS)
> > + return EFI_EXIT(ret);
> > + }
> > +
> > efiobj = efi_search_obj(image_handle);
> > if (efiobj)
> > list_del(>link);
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/18] gpio: mpc8xxx: add support for Layerscape SoC
Hi, York, I prefer not to rename it. This is consistent with Linux kernel. -Original Message- From: York Sun Sent: 2018年9月22日 5:06 To: Ying Zhang Cc: u-boot@lists.denx.de Subject: Re: [PATCH 01/18] gpio: mpc8xxx: add support for Layerscape SoC On 08/23/2018 08:27 AM, York Sun wrote: > On 08/22/2018 06:15 PM, ying.zhang22...@nxp.com wrote: >> From: Zhang Ying-22455 >> >> * Add mpc8xxx_gpio_plat for for Layerscape SoC >> * Make the mpc8xxx driver capable of handling Layerscape Soc. >> > > > This looks weird. Why don't you rename mpc8xxx_gpio driver to be generic? > Are you going to rename the driver? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] enabling MMU in U-Boot-2017.09
Hi, On Fri, Sep 28, 2018 at 11:30 AM Mrun Lele wrote: > > Hello Everyone, > > I am using U-Boot-2017.09. I want to enable MMU before U-Boot loads uImage. > > I googled it and I found one thread dated back in July 2010. > this is the link > https://lists.denx.de/pipermail/u-boot/2010-July/073510.html > > Basically, it involved code change (enabling MMU in start.S and some other > modifications). > > Before walking down on that road described in that link, I want to know is > there any configuration parameter with which I can achieve it easily in > U-Boot-2017.09? > > If not, then is there any document/ guide which I can follow for > U-Boot-2017.09? I am using armv7 cpu. > > Any help would be highly appreciated. You did not specify which exact armv7 processor you are using, and what issues are you trying to fix. Please provide more details. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] enabling MMU in U-Boot-2017.09
Hello Everyone, I am using U-Boot-2017.09. I want to enable MMU before U-Boot loads uImage. I googled it and I found one thread dated back in July 2010. this is the link https://lists.denx.de/pipermail/u-boot/2010-July/073510.html Basically, it involved code change (enabling MMU in start.S and some other modifications). Before walking down on that road described in that link, I want to know is there any configuration parameter with which I can achieve it easily in U-Boot-2017.09? If not, then is there any document/ guide which I can follow for U-Boot-2017.09? I am using armv7 cpu. Any help would be highly appreciated. Thanks you, Harshad. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] efi_loader: set image_base and image_size to correct values
On 08/09/2018 08:51 AM, 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.
Thanks for pointing this out.
This patch needs to be rebased due to
c982874e930d ("efi_loader: refactor efi_setup_loaded_image()")
When rebasing it you could eliminate parameter parameter 'handle' of
efi_load_pe() which will not be needed anymore.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] efi_loader: execute image's unload function
On 08/09/2018 08:50 AM, AKASHI Takahiro wrote:
> Currently, unload function in EFI_LOADED_IMAGE_PROTOCOL is never called
> at UnloadImage Boot Service. This is not compliant to UEFI specification.
> See chapter "9.1 EFI Loaded Image Protocol."
With all the patches we got into U-Boot (+HII protocols, +HOB and DXE
tables) we now can start the EFI shell. But I do not succeed to run the
SCT. Could you, please, provide an overview what is needed.
I use the sct-prepare target in
https://github.com/xypron/u-boot-build/blob/qemu-arm64/Makefile to set
up my disk image with the SCT.
Are we missing further patches or is there something wrong with the
image I generate?
>
> Signed-off-by: AKASHI Takahiro
> ---
> include/efi_api.h | 4 +++-
> lib/efi_loader/efi_boottime.c | 9 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index a4343ae98e2..b2806fba3b8 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -326,6 +326,8 @@ struct efi_system_table {
>
> #define EFI_LOADED_IMAGE_PROTOCOL_REVISION 0x1000
>
> +typedef efi_status_t (EFIAPI *efi_image_unload_t)(efi_handle_t
> *image_handle);
In the rest of efi_api.h we never used typedefs for function prototypes.
I would prefer to use the explicit type.
In scripts/checkpatch.pl this will create a warning.
> +
> struct efi_loaded_image {
> u32 revision;
> void *parent_handle;
> @@ -339,7 +341,7 @@ struct efi_loaded_image {
> aligned_u64 image_size;
> unsigned int image_code_type;
> unsigned int image_data_type;
> - unsigned long unload;
> + efi_image_unload_t unload;
>
> /* Below are efi loader private fields */
> #ifdef CONFIG_EFI_LOADER
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 80061e10ebc..d6fcf7e0049 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1843,9 +1843,18 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t
> image_handle,
> */
> static efi_status_t EFIAPI efi_unload_image(efi_handle_t image_handle)
> {
> + struct efi_loaded_image *info = image_handle;
Please, do not assume the the image_handle points to the
EFI_LOADED_IMAGE_PROTOCOL. Anyway this is not valid anymore after
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=c982874e930d5d673501cd94df07bcbd215d5883
Best regards
Heinrich
> struct efi_object *efiobj;
> + efi_status_t ret;
>
> EFI_ENTRY("%p", image_handle);
> +
> + if (info->unload) {
> + ret = info->unload(image_handle);
> + if (ret != EFI_SUCCESS)
> + return EFI_EXIT(ret);
> + }
> +
> efiobj = efi_search_obj(image_handle);
> if (efiobj)
> list_del(>link);
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] armv7: ls102xa: Disable QE before enter deep sleep
Hi York, > -Original Message- > From: York Sun > Sent: Friday, September 28, 2018 00:53 > To: Ran Wang ; Alison Wang > Cc: Qiang Zhao ; u-boot@lists.denx.de > Subject: Re: [PATCH v3 2/2] armv7: ls102xa: Disable QE before enter deep > sleep > > On 09/25/2018 10:46 PM, Ran Wang wrote: > > Otherwise system will hang after executing wfi. > > This patch doesn't depend on the first patch, does it? Yes >In another word, this > issue exists before, we didn't notice before because no one put the system > on deep sleep. Is that right? Yes, I think so, I found this issue only when try to enable deep sleep feature. Per my observation, this problem will block system enter deep sleep every time. Furthermore, this QE disabling here will not impact QE function when system wakeup due to there will be a warm reset actually. However, I found another issue that QE re-initialization will randomly cause system hang when resume (actually it even randomly happen in normal boot, too), that's why I decide to move CONFIG_U_QE to Kconfig to allow user get chance to workaround them. Regards, Ran > York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/17] riscv: Add QEMU virt board support
Hi Rick, On Wed, Sep 26, 2018 at 9:50 PM Bin Meng wrote: > > This series adds QEMU RISC-V 'virt' board target support, with the > hope of helping people easily test U-Boot on RISC-V. > > Some existing RISC-V codes have been changed to make it easily to > support new targets. Some spotted coding style issues are fixed. > > This series is available at u-boot-x86/riscv-working for testing. > > Changes in v3: > - net patch to print the relocation address in cmd 'bdinfo' > - new patch to imply DM support for some common drivers > - reword the reset message a little, and call hang() in the end > > Changes in v2: > - Change Linux kernel entry parameters' type to support 32/64 bit > - new patch to remove CSR read/write defines in encoding.h > - new patch to pass mhartid CSR value to kernel > - new patch to move do_reset() to a common place > Any comments for v3? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/27] virtio: Introduce VirtIO driver support
Hi Simon, On 09/27/2018 04:43 PM, Simon Glass wrote: ... How does this all get tested? Could we have a simple sandbox driver? We can switch the Travis-CI jobs for the QEMU boards to use virtio-net instead of the current network cards for the TFTP tests. I don't know if there are pytest equivalents for block devices. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 18/27] riscv: qemu: Include some useful commands
Hi Bin, On 09/23/2018 04:42 PM, Bin Meng wrote: With the virtio net and blk drivers, we can do more stuff with some useful commands. Imply those in the board Kconfig. Signed-off-by: Bin Meng --- board/emulation/qemu-riscv/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 5ae56da..37a80db 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -21,5 +21,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply VIRTIO_MMIO imply VIRTIO_NET imply VIRTIO_BLK + imply CMD_PING + imply CMD_FS_GENERIC + imply DOS_PARTITION + imply EFI_PARTITION + imply ISO_PARTITION + imply CMD_EXT2 + imply CMD_EXT4 + imply CMD_FAT endif How about using DISTRO_DEFAULTS? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/27] arm: qemu: Enumerate virtio bus during early boot
Hi Bin,
On 09/23/2018 04:42 PM, Bin Meng wrote:
Currently devices on the virtio bus is not automatically enumerated,
which means peripherals on the virtio bus are not discovered by their
drivers. This uses board_init() to do the virtio enumeration.
Signed-off-by: Bin Meng
---
board/emulation/qemu-arm/Kconfig| 3 +++
board/emulation/qemu-arm/qemu-arm.c | 7 +++
2 files changed, 10 insertions(+)
...
diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig
index d1c08c2..16b80fe 100644
--- a/board/emulation/qemu-arm/Kconfig
+++ b/board/emulation/qemu-arm/Kconfig
@@ -5,5 +5,8 @@ config SYS_TEXT_BASE
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
+ imply VIRTIO_MMIO
+ imply VIRTIO_NET
+ imply VIRTIO_BLK
I think we should have VIRTIO_PCI here as well, so that QEMU command lines
that work on x86 will work on ARM just as well.
...
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -4,6 +4,7 @@
*/
#include
#include
+#include
#ifdef CONFIG_ARM64
#include
@@ -58,6 +59,12 @@ struct mm_region *mem_map = qemu_arm64_mem_map;
int board_init(void)
{
+ /*
+* Make sure virtio bus is enumerated so that peripherals
+* on the virtio bus can be discovered by their drivers
+*/
+ virtio_init();
+
return 0;
}
Note that in include/configs/qemu-arm.h, the boards auto-enumerate
PCI devices with a different mechanism, like this:
#define CONFIG_PREBOOT "pci enum"
I am not sure which one is better but at least we should be consistent.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/27] virtio: Add block driver support
Hi Simon, On 09/27/2018 04:42 PM, Simon Glass wrote: On 23 September 2018 at 06:42, Bin Meng wrote: From: Tuomas Tynkkynen This adds virtio block device driver support. Signed-off-by: Tuomas Tynkkynen Signed-off-by: Bin Meng --- ... Why does this use __u32 instead of u32? The header comes from include/uapi from Linux where the underscored forms are the convention/rule. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/27] virtio: Add net driver support
Hi Bin,
On 09/23/2018 04:42 PM, Bin Meng wrote:
From: Tuomas Tynkkynen
This adds virtio net device driver support.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Bin Meng
---
...
+static u32 feature[] = {
+ VIRTIO_NET_F_MAC
+};
+
+static u32 feature_legacy[] = {
+ VIRTIO_NET_F_MAC
+};
These can be const.
...
+
+static void virtio_net_stop(struct udevice *dev)
+{
+ /*
+* There is no way to stop the queue from running, unless we issue
+* a reset to the virtio device, and re-do the queue initialization
+* from the beginning.
+*/
+}
Unless I missed it, we still need to do something when we pass control to
Linux so that the memory used for receive buffers doesn't get overwritten
by the virtio device during Linux boot.
I think this can be done by calling virtio_reset() on the device in some
uclass-level hook, maybe .child_post_remove().
___
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 09/23/2018 04:42 PM, 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
---
...
+
+/*
+ * Barriers in virtio are tricky. Since we are not in a hyperviosr/guest
+ * scenario, having these as nops is enough to work as expected.
+ */
+
+static inline void virtio_mb(void)
+{
+}
+
+static inline void virtio_rmb(void)
+{
+}
+
+static inline void virtio_wmb(void)
+{
+}
+
+static inline void virtio_store_mb(__virtio16 *p, __virtio16 v)
+{
+ WRITE_ONCE(*p, v);
+}
+
+#endif /* _LINUX_VIRTIO_RING_H */
I am not convinced it's safe to leave these barriers empty. For instance
if KVM acceleration is used, I believe U-Boot could be running on one
core concurrently with QEMU's IO thread running on a different core.
Thus we need memory barriers on both sides so that updates to the
vring are observed in the correct order.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/27] dm: Add a new uclass driver for VirtIO transport devices
Hi Bin,
Thanks for the patches, they look great. Some minor comments:
On 09/23/2018 04:42 PM, Bin Meng wrote:
This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.
The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.
[1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Bin Meng
---...
+
+config VIRTIO
+ bool
+ help
+ This option is selected by any driver which implements the virtio
+ bus, such as CONFIG_VIRTIO_MMIO or CONFIG_VIRTIO_PCI.
I think most other places use the term 'transport' over 'bus'.
+
+int virtio_get_config(struct udevice *vdev, unsigned int offset,
+ void *buf, unsigned int len)
+{
+ struct dm_virtio_ops *ops;
+
+ ops = virtio_get_ops(vdev->parent);
+ if (!ops->get_config)
+ return -ENOSYS;
I'm not sure how useful the -ENOSYS fallbacks for most of these ops
are. E.g. a transport lacking .find_vqs() cannot ever be useful
for implementing real-world devices.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Add generic FPGA reconfig mailbox API for S10
On 09/27/2018 08:37 AM, Ang, Chee Hong wrote: > On Thu, 2018-09-27 at 08:21 +0200, Marek Vasut wrote: >> On 09/27/2018 07:08 AM, Ang, Chee Hong wrote: >>> >>> On Wed, 2018-09-26 at 16:53 +0200, Marek Vasut wrote: On 09/26/2018 11:03 AM, chee.hong@intel.com wrote: > > > From: "Ang, Chee Hong" > > Add a generic mailbox API for FPGA reconfig status which can be > called by others. This new function accepts 2 different mailbox > commands: CONFIG_STATUS or RECONFIG_STATUS. What "others" can call this ? >>> This is a common function used to check the readiness of the FPGA. >>> FPGA configuration drivers will need to call this to make sure >>> the FPGA configuration is successfully completed and running. >>> These FPGA configuration drivers will be submitted soon after this >>> patch. >> So this should be in drivers/fpga/ ? > Yes. There is a FPGA configuration driver under this folder. Will > submit soon. >> >> Also, don't add dead code, just submit this alongside the user of >> this code. > The reason I try to get this common function upstream is because my > colleague is trying to upstream socfpga dwmac driver which also need to > call this function to check whether the soft Ip running on FPGA for the > dwmac driver is up and running. SoCFPGA dwmac support is already upstream. Can you explain why it needs to query the FPGA at all ? Is the whole dwmac in the FPGA ? Or is the dwmac just routed through FPGA ? > If I bundle this code alongside with my > FPGA configuration driver, it might take longer time to get into the > mainline. So this common function is blocking other to upstream his/her > code. I'm not really fond of accepting dead code, on which code I didn't even see and design that's unclear depends. > Signed-off-by: Ang, Chee Hong > --- > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 3 +- > arch/arm/mach-socfpga/mailbox_s10.c | 48 > > 2 files changed, 50 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h > b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h > index 81a609d..660df35 100644 > --- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h > +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h > @@ -140,5 +140,6 @@ int mbox_qspi_open(void); > #endif > > int mbox_reset_cold(void); > - > +int mbox_get_fpga_config_status(u32 cmd); > +int mbox_get_fpga_config_status_psci(u32 cmd); > #endif /* _MAILBOX_S10_H_ */ > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c > b/arch/arm/mach- > socfpga/mailbox_s10.c > index 0d906c3..345485c 100644 > --- a/arch/arm/mach-socfpga/mailbox_s10.c > +++ b/arch/arm/mach-socfpga/mailbox_s10.c > @@ -342,6 +342,54 @@ int mbox_reset_cold(void) > return 0; > } > > +/* Accepted commands: CONFIG_STATUS or RECONFIG_STATUS */ > +static __always_inline int > mbox_get_fpga_config_status_common(u32 > cmd) Why __always_inline ? >>> This function is needed in 2 sections. Our u-boot run in normal >>> code >>> section and '__secure' section which mainly used for PSCI services. >>> Refer to the 'mbox_get_fpga_config_status()' and >>> 'mbox_get_fpga_config_status_psci()' below. These 2 functions run >>> in 2 >>> different sections and they need to call this function. >> But why does this need to be __always_inline ? The compiler can >> decide >> what's best. > This is dangerous. Let me explain in more details why we need this, > '__secure' section and normal '.code' section exist in different time. > '.code' section no longer valid once u-boot boot to OS, but '__secure' > section still exist after booting to OS because OS need to call PSCI > services to achieve certain things. We need to make sure both sections > contain the full code, therefore we need to enforce the compiler to > duplicate this piece of code to both sections as well. How does the __always_inline help with that ? [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] fw_setenv: avoid writing environment when nothing has changed
In the case where one deletes an already-non-existing variable, or sets
a variable to the value it already has, there is no point in writing the
environment back, thus reducing wear on the underlying storage
device.
In the case of redundant environments, if the two environments
differ (e.g. because one is corrupt), make sure that any call of
fw_setenv causes the two to become synchronized, even if the fw_setenv
call does not change anything in the good copy.
Signed-off-by: Rasmus Villemoes
---
Add logic to ensure a corrupt copy gets replaced, even if fw_setenv
wouldn't change anything in the good copy.
tools/env/fw_env.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index a5d75958e1..66372dad55 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -110,6 +110,7 @@ struct environment {
unsigned char *flags;
char *data;
enum flag_scheme flag_scheme;
+ int dirty;
};
static struct environment environment = {
@@ -508,6 +509,9 @@ int fw_env_flush(struct env_opts *opts)
if (!opts)
opts = _opts;
+ if (!environment.dirty)
+ return 0;
+
/*
* Update CRC
*/
@@ -553,7 +557,8 @@ int fw_env_write(char *name, char *value)
deleting = (oldval && !(value && strlen(value)));
creating = (!oldval && (value && strlen(value)));
- overwriting = (oldval && (value && strlen(value)));
+ overwriting = (oldval && (value && strlen(value) &&
+ strcmp(oldval, value)));
/* check for permission */
if (deleting) {
@@ -593,6 +598,7 @@ int fw_env_write(char *name, char *value)
/* Nothing to do */
return 0;
+ environment.dirty = 1;
if (deleting || overwriting) {
if (*++nxt == '\0') {
*env = '\0';
@@ -1441,6 +1447,7 @@ int fw_env_open(struct env_opts *opts)
"Warning: Bad CRC, using default
environment\n");
memcpy(environment.data, default_environment,
sizeof(default_environment));
+ environment.dirty = 1;
}
} else {
flag0 = *environment.flags;
@@ -1494,6 +1501,16 @@ int fw_env_open(struct env_opts *opts)
crc1_ok = (crc1 == redundant->crc);
flag1 = redundant->flags;
+ /*
+* environment.data still points to ((struct
+* env_image_redundant *)addr0)->data. If the two
+* environments differ, or one has bad crc, force a
+* write-out by marking the environment dirty.
+*/
+ if (memcmp(environment.data, redundant->data, ENV_SIZE) ||
+ !crc0_ok || !crc1_ok)
+ environment.dirty = 1;
+
if (crc0_ok && !crc1_ok) {
dev_current = 0;
} else if (!crc0_ok && crc1_ok) {
@@ -1503,6 +1520,7 @@ int fw_env_open(struct env_opts *opts)
"Warning: Bad CRC, using default
environment\n");
memcpy(environment.data, default_environment,
sizeof(default_environment));
+ environment.dirty = 1;
dev_current = 0;
} else {
switch (environment.flag_scheme) {
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Xilinx changes for v2018.11
On Thu, Sep 27, 2018 at 12:43:34PM +0200, Michal Simek wrote: > Hi Tom, > > please pull these changes to your tree. > Travis build looks good. > https://travis-ci.org/michalsimek/u-boot/builds/433924161 > > Both net patches are acked by Joe. > > Thanks, > Michal > > The following changes since commit 284b27cf81da10d55070a49ee8b739f71377a4fb: > > Merge branch 'master' of git://git.denx.de/u-boot-mips (2018-09-23 > 15:14:12 -0400) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.11 > > for you to fetch changes up to 3888c8d1979289efe685fe29276aed4d4b685975: > > net: zynq_gem: Add support for fixed-link phy (2018-09-27 07:59:26 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] rockchip: rk3399: Add common Rock960 family from Vamrs
Rock960 is a family of boards based on Rockchip RK3399 SoC from Vamrs.
It consists of Rock960 (Consumer Edition) and Ficus (Enterprise Edition)
96Boards.
Below are some of the key differences between both Rock960 and Ficus
boards:
1. Different host enable GPIO for USB
2. Different power and reset GPIO for PCI-E
3. No Ethernet port on Rock960
The common board support will be utilized by both boards. The device
tree has been organized in such a way that only the properties which
differ between both boards are placed in the board specific dts and
the reset of the nodes are placed in common dtsi file.
Signed-off-by: Manivannan Sadhasivam
[Added instructions for SD card boot]
Signed-off-by: Ezequiel Garcia
---
Changes in v3: Added instruction for copying prebuilt bl31.elf for SPL
Changes in v2: None
arch/arm/dts/rk3399-rock960.dtsi| 506
arch/arm/mach-rockchip/rk3399/Kconfig | 26 +
board/vamrs/rock960_rk3399/Kconfig | 15 +
board/vamrs/rock960_rk3399/MAINTAINERS | 6 +
board/vamrs/rock960_rk3399/Makefile | 6 +
board/vamrs/rock960_rk3399/README | 152 ++
board/vamrs/rock960_rk3399/rock960-rk3399.c | 50 ++
include/configs/rock960_rk3399.h| 15 +
8 files changed, 776 insertions(+)
create mode 100644 arch/arm/dts/rk3399-rock960.dtsi
create mode 100644 board/vamrs/rock960_rk3399/Kconfig
create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
create mode 100644 board/vamrs/rock960_rk3399/Makefile
create mode 100644 board/vamrs/rock960_rk3399/README
create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
create mode 100644 include/configs/rock960_rk3399.h
diff --git a/arch/arm/dts/rk3399-rock960.dtsi b/arch/arm/dts/rk3399-rock960.dtsi
new file mode 100644
index 000..51644d6d02d
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock960.dtsi
@@ -0,0 +1,506 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Linaro Ltd.
+ */
+
+#include
+#include
+#include "rk3399.dtsi"
+
+/ {
+ vcc1v8_s0: vcc1v8-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8_s0";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <_sys>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_drv>;
+ regulator-boot-on;
+ regulator-name = "vcc3v3_pcie";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_sys>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <_sys>;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = < 0 25000 0>;
+ regulator-name = "vdd_log";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <140>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_sys>;
+ };
+
+};
+
+_l0 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l1 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l2 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l3 {
+ cpu-supply = <_cpu_l>;
+};
+
+_b0 {
+ cpu-supply = <_cpu_b>;
+};
+
+_b1 {
+ cpu-supply = <_cpu_b>;
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clock-frequency = <40>;
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ vdd_cpu_b: regulator@40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <150>;
[U-Boot] [PATCH v3 3/4] rockchip: rk3399: Add Rock960 CE board support
Add board support for Rock960 CE board from Vamrs. This board utilizes
common Rock960 family support.
Following peripherals are tested and known to work:
* USB 2.0
* MMC
This commit also adds DDR configuration for LPDDR3-2GiB-1600MHz which
is being used on the board.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Add config options for USB to Ethernet and USB2 PHY
Changes in v2:
* Added missing config options for USB/uSD
* Fixed the commit description for DDR speed
arch/arm/dts/Makefile |1 +
arch/arm/dts/rk3399-rock960.dts | 45 +
.../arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi | 1536 +
configs/rock960-rk3399_defconfig | 69 +
4 files changed, 1651 insertions(+)
create mode 100644 arch/arm/dts/rk3399-rock960.dts
create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
create mode 100644 configs/rock960-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ebfa2272627..9b891826b73 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -51,6 +51,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3399-puma-ddr1333.dtb \
rk3399-puma-ddr1600.dtb \
rk3399-puma-ddr1866.dtb \
+ rk3399-rock960.dtb \
rv1108-evb.dtb
dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-nanopi-k2.dtb \
diff --git a/arch/arm/dts/rk3399-rock960.dts b/arch/arm/dts/rk3399-rock960.dts
new file mode 100644
index 000..25c58b42611
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock960.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+#include "rk3399-rock960.dtsi"
+#include "rk3399-sdram-lpddr3-2GB-1600.dtsi"
+
+/ {
+ model = "96boards Rock960";
+ compatible = "vamrs,rock960", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+};
+
+ {
+ ep-gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+ pcie {
+ pcie_drv: pcie-drv {
+ rockchip,pins =
+ <2 RK_PA5 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 RK_PD1 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+_pcie {
+ gpio = < 5 GPIO_ACTIVE_HIGH>;
+};
+
+_host {
+ gpio = < 25 GPIO_ACTIVE_HIGH>;
+};
diff --git a/arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
b/arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
new file mode 100644
index 000..d14e833d228
--- /dev/null
+++ b/arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
@@ -0,0 +1,1536 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2018 Manivannan Sadhasivam
+ */
+
+ {
+ rockchip,sdram-params = <
+ 0x1
+ 0xa
+ 0x3
+ 0x2
+ 0x2
+ 0x0
+ 0xf
+ 0xf
+ 1
+ 0x1d191519
+ 0x14040808
+ 0x0002
+ 0x6226
+ 0x0054
+ 0x
+ 0x1
+ 0xa
+ 0x3
+ 0x2
+ 0x2
+ 0x0
+ 0xf
+ 0xf
+ 1
+ 0x1d191519
+ 0x14040808
+ 0x0002
+ 0x6226
+ 0x0054
+ 0x
+ 800
+ 6
+ 2
+ 9
+ 1
+ 0x0700
+ 0x
+ 0x
+ 0x
+ 0x
+ 0x0050
+ 0x00027100
+ 0x0320
+ 0x1f40
+ 0x0050
+ 0x00027100
+ 0x0320
+ 0x1f40
+ 0x0050
+ 0x00027100
+ 0x0320
+ 0x01001f40
+ 0x
+ 0x0101
+ 0x00020100
+ 0x00a0
+ 0x0190
+ 0x
+ 0x0618
+ 0x00061800
+ 0x04000618
+ 0x33080004
+ 0x280f0622
+ 0x22330800
+ 0x00280f06
+ 0x06223308
+ 0x0600280f
+ 0x0a0a
+ 0x0600dac0
+ 0x0a0a060c
+ 0x0600dac0
+ 0x0a0a060c
+ 0x0600dac0
+ 0x0203000c
+ 0x0f0c0f00
+ 0x040c0f0c
+ 0x14000a0a
+ 0x03030a0a
+ 0x00010003
+ 0x031b1b1b
+ 0x0011
+ 0x
+
[U-Boot] [PATCH v3 4/4] rockchip: rk3399: Add Ficus EE board support
Add board support for Ficus EE board from Vamrs. This board utilizes
common Rock960 family support.
Following peripherals are tested and known to work:
* Gigabit Ethernet
* USB 2.0
* MMC
Signed-off-by: Ezequiel Garcia
[Reworked based on common Rock960 family support]
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3: Modified the DRAM config header from LPDDR3 to DDR3
Changes in v2: None
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-ficus.dts | 78 ++
configs/ficus-rk3399_defconfig | 71 +++
3 files changed, 150 insertions(+)
create mode 100644 arch/arm/dts/rk3399-ficus.dts
create mode 100644 configs/ficus-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9b891826b73..e2bd9822aa2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-minnie.dtb \
rk3288-vyasa.dtb \
rk3328-evb.dtb \
+ rk3399-ficus.dtb \
rk3368-lion.dtb \
rk3368-sheep.dtb \
rk3368-geekbox.dtb \
diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
new file mode 100644
index 000..4af0e4e3834
--- /dev/null
+++ b/arch/arm/dts/rk3399-ficus.dts
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * Schematics available at https://dl.vamrs.com/products/ficus/docs/hw
+ */
+
+/dts-v1/;
+#include "rk3399-rock960.dtsi"
+#include "rk3399-sdram-ddr3-1600.dtsi"
+
+/ {
+ model = "96boards RK3399 Ficus";
+ compatible = "vamrs,ficus", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+};
+
+ {
+ assigned-clocks = < SCLK_RMII_SRC>;
+ assigned-clock-parents = <_gmac>;
+ clock_in_out = "input";
+ phy-supply = <_sys>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ snps,reset-gpio = < RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+ {
+ ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+ gmac {
+ rgmii_sleep_pins: rgmii-sleep-pins {
+ rockchip,pins =
+ <3 15 RK_FUNC_GPIO _output_low>;
+ };
+ };
+
+ pcie {
+ pcie_drv: pcie-drv {
+ rockchip,pins =
+ <1 24 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 27 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+_pcie {
+ gpio = < 24 GPIO_ACTIVE_HIGH>;
+};
+
+_host {
+ gpio = < 27 GPIO_ACTIVE_HIGH>;
+};
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
new file mode 100644
index 000..e890bc25238
--- /dev/null
+++ b/configs/ficus-rk3399_defconfig
@@ -0,0 +1,71 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_TARGET_ROCK960_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_STACK_R_ADDR=0x8
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-ficus"
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_RGMII=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_ROCKCHIP_RK3399=y
+CONFIG_DM_PMIC=y
[U-Boot] [PATCH v3 1/4] arm: dts: rockchip: add some common pin-settings to rk3399
From: Randy Li
Those pins would be used by many boards.
Commit grabbed from Linux:
commit b41023282d07b61a53e2c9b9508912b1e7ce7b4f
Author: Randy Li
Date: Thu Jun 21 21:32:10 2018 +0800
arm64: dts: rockchip: add some common pin-settings to rk3399
Those pins would be used by many boards.
Signed-off-by: Randy Li
Signed-off-by: Heiko Stuebner
Acked-by: Philipp Tomsich
Signed-off-by: Randy Li
Signed-off-by: Heiko Stuebner
Signed-off-by: Ezequiel Garcia
---
Changes in v3: None
Changes in v2: None
arch/arm/dts/rk3399.dtsi | 55 +++-
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 83c257b1228..8349451b03d 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -1602,19 +1602,49 @@
drive-strength = <12>;
};
+ pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+ bias-disable;
+ drive-strength = <13>;
+ };
+
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+ bias-disable;
+ drive-strength = <20>;
+ };
+
+ pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};
+ pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+ bias-pull-up;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+ bias-pull-up;
+ drive-strength = <20>;
+ };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};
- pcfg_pull_up_2ma: pcfg-pull-up-2ma {
- bias-pull-up;
- drive-strength = <2>;
+ pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+ bias-pull-down;
+ drive-strength = <8>;
};
pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1622,9 +1652,22 @@
drive-strength = <12>;
};
- pcfg_pull_none_13ma: pcfg-pull-none-13ma {
- bias-disable;
- drive-strength = <13>;
+ pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+ bias-pull-down;
+ drive-strength = <20>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
};
clock {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] Add Rock960 and Ficus 96Board support
This patchset adds support for Rock960 and Ficus 96Boards from Vamrs. Since both boards share most of the configurations, a common Rock960 family support is added with common support and the actual boards are based on this. The previous version of the patchseries were adding Rock960 [1] and Ficus [2] board support individually, but this series fuses them together based on the common board support as per Linux kernel. [1] https://patchwork.ozlabs.org/cover/963239/ [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html This patchseries has been tested on Rock960 v1.2 board and expecting Ezequiel to do the testing for Ficus. PS: I have explicitly removed the previous Ack's for the Ficus board since there has been a heavy modification done on these patches. Thanks, Mani Manivannan Sadhasivam (4): arm: dts: rockchip: add some common pin-settings to rk3399 rockchip: rk3399: Add common Rock960 family from Vamrs rockchip: rk3399: Add Rock960 CE board support rockchip: rk3399: Add Ficus EE board support arch/arm/dts/Makefile |2 + arch/arm/dts/rk3399-ficus.dts | 78 + arch/arm/dts/rk3399-rock960.dts | 45 + arch/arm/dts/rk3399-rock960.dtsi | 506 ++ .../arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi | 1536 + arch/arm/dts/rk3399.dtsi | 55 +- arch/arm/mach-rockchip/rk3399/Kconfig | 26 + board/vamrs/rock960_rk3399/Kconfig| 15 + board/vamrs/rock960_rk3399/MAINTAINERS|6 + board/vamrs/rock960_rk3399/Makefile |6 + board/vamrs/rock960_rk3399/README | 152 ++ board/vamrs/rock960_rk3399/rock960-rk3399.c | 50 + configs/ficus-rk3399_defconfig| 71 + configs/rock960-rk3399_defconfig | 69 + include/configs/rock960_rk3399.h | 15 + 15 files changed, 2626 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/rk3399-ficus.dts create mode 100644 arch/arm/dts/rk3399-rock960.dts create mode 100644 arch/arm/dts/rk3399-rock960.dtsi create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi create mode 100644 board/vamrs/rock960_rk3399/Kconfig create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS create mode 100644 board/vamrs/rock960_rk3399/Makefile create mode 100644 board/vamrs/rock960_rk3399/README create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c create mode 100644 configs/ficus-rk3399_defconfig create mode 100644 configs/rock960-rk3399_defconfig create mode 100644 include/configs/rock960_rk3399.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: efi_dp_get_next_instance() superfluous statement
Remove a superfluous statement in efi_dp_get_next_instance(). Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_device_path.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c index 6040bcff19..172317b9a0 100644 --- a/lib/efi_loader/efi_device_path.c +++ b/lib/efi_loader/efi_device_path.c @@ -387,7 +387,6 @@ struct efi_device_path *efi_dp_get_next_instance(struct efi_device_path **dp, *size = 0; if (!dp || !*dp) return NULL; - p = *dp; sz = efi_dp_instance_size(*dp); p = dp_alloc(sz + sizeof(END)); if (!p) -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_selftest: fix typos
fix typos
correct the header comment of efi_selftest_variables.c
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest_config_table.c | 12 ++--
lib/efi_selftest/efi_selftest_controllers.c | 2 +-
lib/efi_selftest/efi_selftest_crc32.c| 4 ++--
lib/efi_selftest/efi_selftest_event_groups.c | 4 ++--
lib/efi_selftest/efi_selftest_events.c | 2 +-
lib/efi_selftest/efi_selftest_exception.c| 4 ++--
lib/efi_selftest/efi_selftest_fdt.c | 2 +-
lib/efi_selftest/efi_selftest_textinput.c| 2 +-
lib/efi_selftest/efi_selftest_tpl.c | 2 +-
lib/efi_selftest/efi_selftest_variables.c| 6 ++
lib/efi_selftest/efi_selftest_watchdog.c | 2 +-
11 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_config_table.c
b/lib/efi_selftest/efi_selftest_config_table.c
index 2aa3fc7284..0bc5da6b0c 100644
--- a/lib/efi_selftest/efi_selftest_config_table.c
+++ b/lib/efi_selftest/efi_selftest_config_table.c
@@ -18,7 +18,7 @@ static efi_guid_t table_guid =
0x17, 0x2e, 0x51, 0x6b, 0x49, 0x75);
/*
- * Notification function, increments the notfication count if parameter
+ * Notification function, increments the notification count if parameter
* context is provided.
*
* @event notified event
@@ -33,23 +33,23 @@ static void EFIAPI notify(struct efi_event *event, void
*context)
}
/*
- * Check crc32 of a table.
+ * Check CRC32 of a table.
*/
static int check_table(const void *table)
{
efi_status_t ret;
u32 crc32, res;
- /* Casting from const to not const */
+ /* Casting from constant to not constant */
struct efi_table_hdr *hdr = (struct efi_table_hdr *)table;
crc32 = hdr->crc32;
/*
-* Setting the crc32 of the 'const' table to zero is easier than
+* Setting the CRC32 of the 'const' table to zero is easier than
* copying
*/
hdr->crc32 = 0;
ret = boottime->calculate_crc32(table, hdr->headersize, );
- /* Reset table crc32 so it stays constant */
+ /* Reset table CRC32 so it stays constant */
hdr->crc32 = crc32;
if (ret != EFI_ST_SUCCESS) {
efi_st_error("CalculateCrc32 failed\n");
@@ -203,7 +203,7 @@ static int execute(void)
return EFI_ST_FAILURE;
}
if (tabcnt > 1) {
- efi_st_error("Duplicate table guid\n");
+ efi_st_error("Duplicate table GUID\n");
return EFI_ST_FAILURE;
}
if (table != [1]) {
diff --git a/lib/efi_selftest/efi_selftest_controllers.c
b/lib/efi_selftest/efi_selftest_controllers.c
index ceefa03444..e8a80d778d 100644
--- a/lib/efi_selftest/efi_selftest_controllers.c
+++ b/lib/efi_selftest/efi_selftest_controllers.c
@@ -33,7 +33,7 @@ static efi_handle_t handle_driver;
* Count child controllers
*
* @handle handle on which child controllers are installed
- * @protocol protocol for which the child controlles where installed
+ * @protocol protocol for which the child controllers were installed
* @count number of child controllers
* @return status code
*/
diff --git a/lib/efi_selftest/efi_selftest_crc32.c
b/lib/efi_selftest/efi_selftest_crc32.c
index 8555b8f114..4881e8ac6f 100644
--- a/lib/efi_selftest/efi_selftest_crc32.c
+++ b/lib/efi_selftest/efi_selftest_crc32.c
@@ -5,7 +5,7 @@
* Copyright (c) 2018 Heinrich Schuchardt
*
* This unit test checks the CalculateCrc32 bootservice and checks the
- * headers of the system table, the boot services tablle, and the runtime
+ * headers of the system table, the boot services table, and the runtime
* services table before and after ExitBootServices().
*/
@@ -19,7 +19,7 @@ static int check_table(const void *table)
{
efi_status_t ret;
u32 crc32, res;
- /* Casting from const to not const */
+ /* Casting from constant to not constant */
struct efi_table_hdr *hdr = (struct efi_table_hdr *)table;
if (!hdr->signature) {
diff --git a/lib/efi_selftest/efi_selftest_event_groups.c
b/lib/efi_selftest/efi_selftest_event_groups.c
index 9b3c5132ef..5a7980c5d0 100644
--- a/lib/efi_selftest/efi_selftest_event_groups.c
+++ b/lib/efi_selftest/efi_selftest_event_groups.c
@@ -19,7 +19,7 @@ static efi_guid_t event_group =
0x0e, 0x5b, 0x45, 0xc0, 0x56, 0x91);
/*
- * Notification function, increments the notfication count if parameter
+ * Notification function, increments the notification count if parameter
* context is provided.
*
* @event notified event
@@ -114,7 +114,7 @@ static int execute(void)
(unsigned int)i, (unsigned int)j,
(unsigned int)counter[j]);
efi_st_error(
- "Nofification function not called\n");
+
Re: [U-Boot] [PATCH 2/7] drivers: spi: cf_spi: migrate to DM and DT
Hi Simon,
On Thu, Sep 27, 2018 at 06:41:37AM -0700, Simon Glass wrote:
> Hi Angelo,
>
> On 26 September 2018 at 11:53, Angelo Dureghello wrote:
> > Hi Simon,
> >
> > thanks for the review.
> >
> > On Tue, Sep 25, 2018 at 10:42:08PM -0700, Simon Glass wrote:
> >> Hi Angelo,
> >>
> >> On 20 September 2018 at 15:07, Angelo Dureghello wrote:
> >> > This patch converts cf_spi.c to DM and to read driver
> >> > platform data from flat devicetree.
> >> >
> >> > ---
> >> > Changes from v1:
> >> > - split into 2 patches
> >> >
> >> > Signed-off-by: Angelo Dureghello
> >> > ---
> >> > drivers/spi/Kconfig | 18 +-
> >> > drivers/spi/cf_spi.c| 495
> >> > include/dm/platform_data/spi_coldfire.h | 25 ++
> >> > 3 files changed, 369 insertions(+), 169 deletions(-)
> >> > create mode 100644 include/dm/platform_data/spi_coldfire.h
> >> >
> >>
> >> Good to see this.
> >>
> >> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> >> > index dcd719ff0a..974c5bbed8 100644
> >> > --- a/drivers/spi/Kconfig
> >> > +++ b/drivers/spi/Kconfig
> >> > @@ -80,6 +80,12 @@ config CADENCE_QSPI
> >> > used to access the SPI NOR flash on platforms embedding this
> >> > Cadence IP core.
> >> >
> >> > +config CF_SPI
> >> > +bool "ColdFire SPI driver"
> >> > +help
> >> > + Enable the ColdFire SPI driver. This driver can be used on
> >> > + some m68k SoCs.
> >> > +
> >> > config DESIGNWARE_SPI
> >> > bool "Designware SPI driver"
> >> > help
> >> > @@ -244,18 +250,18 @@ config ZYNQMP_GQSPI
> >> >
> >> > endif # if DM_SPI
> >> >
> >> > -config SOFT_SPI
> >> > - bool "Soft SPI driver"
> >> > - help
> >> > -Enable Soft SPI driver. This driver is to use GPIO simulate
> >> > -the SPI protocol.
> >>
> >> How come this is changing? That should be a separate patch.
> >>
> > I just respected Kconfig alphabetical order, SOFT_SPI is just moved after.
>
> OK, well I do think this should be in a separate patch.
>
Ah, ok. Will do.
> >
> >> > -
> >> > config CF_SPI
> >> > bool "ColdFire SPI driver"
> >> > help
> >> > Enable the ColdFire SPI driver. This driver can be used on
> >> > some m68k SoCs.
> >> >
> >> > +config SOFT_SPI
> >> > + bool "Soft SPI driver"
> >> > + help
> >> > +Enable Soft SPI driver. This driver is to use GPIO simulate
> >> > +the SPI protocol.
> >> > +
> >> > config FSL_ESPI
> >> > bool "Freescale eSPI driver"
> >> > help
> >> > diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
> >> > index 522631cbbf..11a11f79c4 100644
> >> > --- a/drivers/spi/cf_spi.c
> >> > +++ b/drivers/spi/cf_spi.c
> >> > @@ -6,16 +6,27 @@
> >> > *
> >> > * Copyright (C) 2004-2009 Freescale Semiconductor, Inc.
> >> > * TsiChung Liew (tsi-chung.l...@freescale.com)
> >> > + *
> >> > + * Support for device model:
> >> > + * Copyright (C) 2018 Angelo Dureghello
> >> > + *
> >> > */
> >> >
> >> > #include
> >> > +#include
> >> > +#include
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> >
> >> > -struct cf_spi_slave {
> >> > +struct coldfire_spi_priv {
> >> > +#ifndef CONFIG_DM_SPI
> >> > struct spi_slave slave;
> >> > +#endif
> >> > + struct dspi *regs;
> >> > uint baudrate;
> >> > + int mode;
> >> > int charbit;
> >> > };
> >> >
> >> > @@ -38,14 +49,14 @@ DECLARE_GLOBAL_DATA_PTR;
> >> > #define SPI_MODE_MOD 0x0020
> >> > #define SPI_DBLRATE0x0010
> >> >
> >> > -static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave
> >> > *slave)
> >> > -{
> >> > - return container_of(slave, struct cf_spi_slave, slave);
> >> > -}
> >> > +/* Default values */
> >> > +#define MCF_DSPI_DEFAULT_SCK_FREQ 1000
> >> > +#define MCF_DSPI_MAX_CHIPSELECTS 4
> >> > +#define MCF_DSPI_MODE 0
> >> >
> >> > -static void cfspi_init(void)
> >> > +static void __spi_init(struct coldfire_spi_priv *cfspi)
> >> > {
> >> > - volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
> >> > + struct dspi *dspi = cfspi->regs;
> >> >
> >> > cfspi_port_conf(); /* port configuration */
> >> >
> >> > @@ -56,125 +67,32 @@ static void cfspi_init(void)
> >> >
> >> > /* Default setting in platform configuration */
> >> > #ifdef CONFIG_SYS_DSPI_CTAR0
> >> > - dspi->ctar[0] = CONFIG_SYS_DSPI_CTAR0;
> >> > + writel(CONFIG_SYS_DSPI_CTAR0, >ctar[0]);
> >>
> >> What is going on here? I think these CONFIG options are addresses? If
> >> so, they should be read from the DT, not a CONFIG.
> >>
> >
> > These are just default settings for each channel (bus), actually coming
> > from the include/configs/boardxxx.h. Their speed an mode bitfields are
> > rewritten later, with values coming from devicetree.
> > Some driver #define the default value inside the driver itself, in case
> > i may
Re: [U-Boot] [PATCH] ls1088ardb_pb: Secure boot: Change bootscript and header name
On 09/12/2018 04:18 AM, Vinitha V Pillai wrote: > Change bootscript and its header name in > ls1088ardb_pb board specific file > > Signed-off-by: Vinitha V Pillai > --- > include/configs/ls1088ardb_pb.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Are you sure you are using right code base? This file doesn't exist. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] armv7: ls102xa: Disable QE before enter deep sleep
On 09/25/2018 10:46 PM, Ran Wang wrote: > Otherwise system will hang after executing wfi. This patch doesn't depend on the first patch, does it? In another word, this issue exists before, we didn't notice before because no one put the system on deep sleep. Is that right? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/5] dm: pinctrl: Add pinmux_show() ops
Hi Simon On 09/26/2018 07:42 AM, Simon Glass wrote: > Hi Patrice, > > On 20 September 2018 at 07:37, Patrice Chotard wrote: >> pinmux_show() allows to display the muxing of all pins >> belonging to a pin-controller >> >> Signed-off-by: Patrice Chotard >> --- >> >> drivers/pinctrl/pinctrl-uclass.c | 10 ++ >> include/dm/pinctrl.h | 29 + >> 2 files changed, 39 insertions(+) >> > > If you look at this pinctrl method: > > const char *(*get_pin_name)(struct udevice *dev, unsigned selector); > > you can see that we can specify particular pins. Can we have the > command discover what pins are available and iterate over them? Then > we can have a function which returns the status of a particular pin as > a string, and the command can output it. Perhaps like cpu_get_desc()? Understand, i will rework this series following this way of doing. Thanks Patrice > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [Uboot-stm32] [PATCH v1 4/5] pinctrl: stm32: Add pinmux_show() ops
Hi Simon
On 09/26/2018 07:41 AM, Simon Glass wrote:
> Hi Patrice,
>
> On 20 September 2018 at 07:37, Patrice Chotard wrote:
>> pinmux_show allows to display the muxing of all pins
>> belonging to pin-controller.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> drivers/pinctrl/pinctrl_stm32.c | 79
>> +
>> 1 file changed, 79 insertions(+)
>>
>
> The only thing I don't like about this is that it is quite
> SoC-specific. I am hoping we can make it more generic.
I will rework it to make it more independant.
>
>> diff --git a/drivers/pinctrl/pinctrl_stm32.c
>> b/drivers/pinctrl/pinctrl_stm32.c
>> index 31285cdd5784..a477035bf420 100644
>> --- a/drivers/pinctrl/pinctrl_stm32.c
>> +++ b/drivers/pinctrl/pinctrl_stm32.c
>> @@ -14,6 +14,16 @@ DECLARE_GLOBAL_DATA_PTR;
>> #define OTYPE_MSK 1
>> #define AFR_MASK 0xF
>>
>> +#define PINMUX_MODE_COUNT 5
>> +
>> +static const char * const pinmux_mode[PINMUX_MODE_COUNT] = {
>> + "gpio input",
>> + "gpio output",
>> + "analog",
>> + "unknown",
>> + "alt function",
>> +};
>> +
>> static int stm32_gpio_config(struct gpio_desc *desc,
>> const struct stm32_gpio_ctl *ctl)
>> {
>> @@ -176,12 +186,81 @@ static int stm32_pinctrl_set_state_simple(struct
>> udevice *dev,
>> }
>> #endif /* PINCTRL_FULL */
>>
>> +static int stm32_pinctrl_get_af(struct udevice *dev, unsigned int offset)
>> +{
>> + struct stm32_gpio_priv *priv = dev_get_priv(dev);
>> + struct stm32_gpio_regs *regs = priv->regs;
>> + u32 af;
>> + u32 alt_shift = (offset % 8) * 4;
>> + u32 alt_index = offset / 8;
>> +
>> + af = (readl(>afr[alt_index]) &
>> + GENMASK(alt_shift + 3, alt_shift)) >> alt_shift;
>> +
>> + return af;
>> +}
>> +
>> +static int stm32_pinmux_show(struct udevice *dev)
>> +{
>> + struct udevice *child;
>> + struct udevice *dev_gpio;
>> + const char *bank_name;
>> + const char *label;
>> + int offset;
>> + int ret;
>> + int num_bits;
>> + int mode;
>> + int af_num;
>> +
>> + /* parse pin-controller sub-nodes, ie gpio bank nodes */
>> + list_for_each_entry(child, >child_head, sibling_node) {
>> + ret = uclass_get_device_by_name(UCLASS_GPIO, child->name,
>> + _gpio);
>
> I wonder to what extend this is actually different from 'gpio status'?
I agree, currently, "pinmux show" and "gpio status" comments are
overlapping..
At the end, as on kernel side, only pinmux should be used to know the
pin state (configured as a GPIO or as alternate function).
pinmux command indicates if pins is configured as an alternate function
and indicates which one, what "gpio status" can't do.
>
>> +
>> + if (ret < 0 && ret != -ENODEV) {
>> + dev_err(dev, "Failed to find %s device ret = %d\n",
>> + child->name, ret);
>> + return ret;
>> + }
>> +
>> + if (!ret) {
>> + bank_name = gpio_get_bank_info(dev_gpio, _bits);
>> +
>> + printf("\nBank %s:\n", bank_name);
>> + for (offset = 0; offset < num_bits; offset++) {
>> + mode = gpio_get_raw_function(dev_gpio,
>> +offset, );
>> + printf("%s%d: %s", bank_name, offset,
>> + pinmux_mode[mode]);
>> + switch (mode) {
>> + case GPIOF_FUNC:
>> + af_num =
>> stm32_pinctrl_get_af(dev_gpio,
>> +
>> offset);
>> + printf(" %d", af_num);
>> + break;
>> + case STM32_GPIO_MODE_OUT:
>
> How come you cannot use GPIOF_OUTPUT here?
Good catch, GPIOF_OUPUT/INPUT must be used instead of
STM32_GPIO_MODE_OUT/IN.
>
>> + case STM32_GPIO_MODE_IN:
>> + printf(" %s", label ? label : "");
>> + break;
>> + }
>> + printf("\n");
>> + }
>> + }
>> +
>> + if (!child)
>> + break;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static struct pinctrl_ops stm32_pinctrl_ops = {
>> #if CONFIG_IS_ENABLED(PINCTRL_FULL)
>> .set_state = stm32_pinctrl_set_state,
>> #else /* PINCTRL_FULL */
>> .set_state_simple = stm32_pinctrl_set_state_simple,
>> #endif /* PINCTRL_FULL */
>> + .pinmux_show
Re: [U-Boot] [PATCH v4 3/3] test: Add tests for board uclass
Hi Simon, On Thu, Sep 27, 2018 at 3:45 PM Simon Glass wrote: > > Hi Mario, > > On 26 September 2018 at 06:36, Mario Six wrote: > > Hi Simon, > > On Tue, Jul 31, 2018 at 11:46 AM Mario Six wrote: > >> > >> Add tests for the new board uclass. > >> > >> Reviewed-by: Simon Glass > >> Signed-off-by: Mario Six > >> --- > >> > >> v3 -> v4: > >> No changes > >> > >> v2 -> v3: > >> * Accomodated get_board() rename > >> * Fixed style violations > >> > >> v1 -> v2: > >> New in v2 > >> --- > >> arch/sandbox/dts/test.dts | 4 ++ > >> configs/sandbox64_defconfig| 2 + > >> configs/sandbox_defconfig | 2 + > >> configs/sandbox_flattree_defconfig | 2 + > >> configs/sandbox_noblk_defconfig| 2 + > >> configs/sandbox_spl_defconfig | 2 + > >> drivers/board/Kconfig | 7 ++- > >> drivers/board/Makefile | 1 + > >> drivers/board/sandbox.c| 107 > >> + > >> drivers/board/sandbox.h| 12 + > >> test/dm/Makefile | 1 + > >> test/dm/board.c| 57 > >> 12 files changed, 198 insertions(+), 1 deletion(-) > >> create mode 100644 drivers/board/sandbox.c > >> create mode 100644 drivers/board/sandbox.h > >> create mode 100644 test/dm/board.c > >> > > > Another series for the u-boot-dm tree? > > OK, please reassign, > Done, thanks. > Regards, > Simon > Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] core: Add functions to set properties in live-tree
Hi Simon, On Thu, Sep 27, 2018 at 3:42 PM Simon Glass wrote: > > Hi Mario, > > On 26 September 2018 at 06:34, Mario Six wrote: > > > > Hi Simon, > > On Wed, Jun 27, 2018 at 1:18 AM Simon Glass wrote: > > > > > > On 26 June 2018 at 00:46, Mario Six wrote: > > > > Implement a set of functions to manipulate properties in a live device > > > > tree: > > > > > > > > * ofnode_write_prop() to set generic properties of a node > > > > * ofnode_write_string() to set string properties of a node > > > > * ofnode_set_enabled() to either enable or disable a node > > > > > > > > Signed-off-by: Mario Six > > > > > > > > --- > > > > > > > > v2 -> v3: > > > > * Removed #ifdef, and used if (!of_live_active()) instead > > > > * Removed allocation of property value (caller is now responsible for > > > > that); this also fixes a potential memory leak > > > > * Added error handling for malloc and strdup > > > > * Fixed style violations > > > > > > > > v1 -> v2: > > > > * Fix potential NULL pointer dereference in ofnode_write_property > > > > * Squashed the enable/disable functions into one > > > > * Renamed ofnode_set_property to ofnode_write_prop > > > > > > > > --- > > > > drivers/core/ofnode.c | 70 > > > > +++ > > > > include/dm/ofnode.h | 46 + > > > > 2 files changed, 116 insertions(+) > > > > > > Reviewed-by: Simon Glass > > > > This series seems to be a candidate for the u-boot-dm tree. > > > > I can assign it to you in Patchwork if you want. > > OK that's fine with me. > Thanks. I reassigned the series. > Regards, > Simon > Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 18/27] riscv: qemu: Include some useful commands
On 23 September 2018 at 06:42, Bin Meng wrote: > With the virtio net and blk drivers, we can do more stuff with some > useful commands. Imply those in the board Kconfig. > > Signed-off-by: Bin Meng > --- > > board/emulation/qemu-riscv/Kconfig | 8 > 1 file changed, 8 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/27] virtio: Add block driver support
On 23 September 2018 at 06:42, Bin Meng wrote: > From: Tuomas Tynkkynen > > This adds virtio block device driver support. > > Signed-off-by: Tuomas Tynkkynen > Signed-off-by: Bin Meng > --- > > drivers/virtio/Kconfig | 7 +++ > drivers/virtio/Makefile | 1 + > drivers/virtio/virtio_blk.c | 127 +++ > drivers/virtio/virtio_blk.h | 129 > > 4 files changed, 264 insertions(+) > create mode 100644 drivers/virtio/virtio_blk.c > create mode 100644 drivers/virtio/virtio_blk.h Reviewed-by: Simon Glass Why does this use __u32 instead of u32? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/27] blk: Introduce IF_TYPE_VIRTIO
On 23 September 2018 at 06:42, Bin Meng wrote: > From: Tuomas Tynkkynen > > This adds a new block interface type for VirtIO block devices. > > Signed-off-by: Tuomas Tynkkynen > Signed-off-by: Bin Meng > --- > > disk/part.c| 6 ++ > drivers/block/blk-uclass.c | 2 ++ > include/blk.h | 1 + > 3 files changed, 9 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/27] blk: Make blk_next_free_devnum() public
On 23 September 2018 at 06:42, Bin Meng wrote: > blk_next_free_devnum() can be helpful in some cases. Make it > a public API. > > Signed-off-by: Bin Meng > --- > > drivers/block/blk-uclass.c | 2 +- > include/blk.h | 11 +++ > 2 files changed, 12 insertions(+), 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 27/27] doc: Document virtio support
Hi Bin, On 23 September 2018 at 06:42, Bin Meng wrote: > Add REAME.virtio to describe the information about U-Boot support for > VirtIO devices, including supported boards, build instructions, driver > details etc. > > Signed-off-by: Bin Meng > > --- > > doc/README.virtio | 247 > ++ > 1 file changed, 247 insertions(+) > create mode 100644 doc/README.virtio Reviewed-by: Simon Glass Great docs! - Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/27] virtio: Introduce VirtIO driver support
Hi Bin, On 23 September 2018 at 06:41, Bin Meng wrote: > This series brings in VirtIO driver support in U-Boot. The work is based > on Tuomas's virtio support on QEMU ARM targets. > > VirtIO is a virtualization standard for network and disk device drivers > where just the guest's device driver "knows" it is running in a virtual > environment, and cooperates with the hypervisor. This enables guests to > get high performance network and disk operations, and gives most of the > performance benefits of paravirtualization. In the U-Boot case, the > guest is U-Boot itself, while the virtual environment are normally QEMU > targets like ARM, RISC-V and x86. > > Both VirtIO MMIO and PCI transport options are supported. Only VirtIO > network and block device drivers are supported for now. > > The following QEMU targets are supported. > > - qemu_arm_defconfig > - qemu_arm64_defconfig > - qemu-riscv32_defconfig > - qemu-riscv64_defconfig > - qemu-x86_defconfig > - qemu-x86_64_defconfig > > A new child_post_probe() uclass driver method is introduced to better > support virtio device driver. This also changes BLK uclass driver to > supply a post_probe() method which calls part_init(), so that we can > avoid duplicating such call in every BLK driver. > > Not every checkpatch warning reported was fixed, but I tried to fix as > many as possible which makes sense. > > This series needs to be applied after the risc-v QEMU series is applied. > > This series is available at u-boot-x86/virtio-working for testing. > Note the branch already contains the risc-v QEMU series plus one network > stack fix to make virtio-net driver happy. > Looks like a very nice implementation. How does this all get tested? Could we have a simple sandbox driver? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 22/27] x86: qemu: Imply virtio PCI transport and device drivers
On 23 September 2018 at 06:42, Bin Meng wrote: > Add virtio drivers for QEMU x86 targets. > > Signed-off-by: Bin Meng > --- > > board/emulation/qemu-x86/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/27] blk: Drop blk_prepare_device()
On 23 September 2018 at 06:42, Bin Meng wrote: > With the post_probe() changes, this API is no longer needed. > > Signed-off-by: Bin Meng > --- > > drivers/block/blk-uclass.c | 9 - > include/blk.h | 10 -- > 2 files changed, 19 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 19/27] kconfig: Introduce HAVE_ARCH_IOMAP
On 23 September 2018 at 06:42, Bin Meng wrote:
> Introduce a new Kconfig option for architecture codes to control
> whether it provides io{read,write}{8,16,32} I/O accessor functions.
>
> Signed-off-by: Bin Meng
> ---
>
> include/linux/io.h | 4
> lib/Kconfig| 6 ++
> 2 files changed, 10 insertions(+)
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/27] virtio: Add codes for virtual queue/ring management
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? Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 26/27] virtio: net: Support non-legacy device
On 23 September 2018 at 06:42, Bin Meng wrote: > For v1.0 compliant device, it always assumes the member 'num_buffers' > exists in the struct virtio_net_hdr while the legacy driver only > presented 'num_buffers' when VIRTIO_NET_F_MRG_RXBUF was negotiated. > Without that feature the structure was 2 bytes shorter. > > Update the driver to support the non-legacy device. > > Signed-off-by: Bin Meng > --- > > drivers/virtio/virtio_net.c | 31 ++- > 1 file changed, 26 insertions(+), 5 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 06/27] test: dm: blk: Correct blk_base test case
On 23 September 2018 at 06:42, Bin Meng wrote: > The blk_base test case creates a USB mass storage block device with > the Sandbox host block device as its parent. This does not make any > sense and causes potential issue, for example if the test case tries > to read/write anything on the USB mass storage block device it will > definitely fail as its parent is not on USB bus at all. > > Correct the test case by creating another Sandbox host block device > instead of the USB mass storage one and adjust the case accordingly. > > Signed-off-by: Bin Meng > --- > > test/dm/blk.c | 27 +++ > 1 file changed, 11 insertions(+), 16 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 24/27] test: dm: pci: Add cases for finding next PCI capability APIs
On 23 September 2018 at 06:42, Bin Meng wrote: > Add test cases to cover the two newly added PCI APIs: > dm_pci_find_next_capability() & dm_pci_find_next_ext_capability(). > > Signed-off-by: Bin Meng > --- > > test/dm/pci.c | 20 > 1 file changed, 20 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 25/27] virtio: pci: Support non-legacy PCI transport device
On 23 September 2018 at 06:42, Bin Meng wrote:
> By default QEMU creates legacy PCI transport devices, but we can
> ask QEMU to create non-legacy one if we pass additional device
> property/value pairs in the command line:
>
> -device virtio-blk-pci,disable-legacy=true,disable-modern=false
>
> This adds a new driver driver to support non-legacy (modern) device
> mode. Previous driver/file name is changed accordingly.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/virtio/Makefile| 2 +-
> .../virtio/{virtio_pci.c => virtio_pci_legacy.c} | 6 +-
> drivers/virtio/virtio_pci_modern.c | 612
> +
> 3 files changed, 616 insertions(+), 4 deletions(-)
> rename drivers/virtio/{virtio_pci.c => virtio_pci_legacy.c} (98%)
> create mode 100644 drivers/virtio/virtio_pci_modern.c
Reviewed-by: Simon Glass
Isn't there some common code between the two?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/27] arm: qemu: Enumerate virtio bus during early boot
On 23 September 2018 at 06:42, Bin Meng wrote:
> Currently devices on the virtio bus is not automatically enumerated,
> which means peripherals on the virtio bus are not discovered by their
> drivers. This uses board_init() to do the virtio enumeration.
>
> Signed-off-by: Bin Meng
> ---
>
> board/emulation/qemu-arm/Kconfig| 3 +++
> board/emulation/qemu-arm/qemu-arm.c | 7 +++
> 2 files changed, 10 insertions(+)
>
Reviewed-by: Simon Glass
But I wonder if we should have a flag in the uclass or perhaps device
tree, to indicate that all devices in it should be probed at start-up?
Could be useful for PCI too.
> diff --git a/board/emulation/qemu-arm/Kconfig
> b/board/emulation/qemu-arm/Kconfig
> index d1c08c2..16b80fe 100644
> --- a/board/emulation/qemu-arm/Kconfig
> +++ b/board/emulation/qemu-arm/Kconfig
> @@ -5,5 +5,8 @@ config SYS_TEXT_BASE
>
> config BOARD_SPECIFIC_OPTIONS # dummy
> def_bool y
> + imply VIRTIO_MMIO
> + imply VIRTIO_NET
> + imply VIRTIO_BLK
>
> endif
> diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> index 812c906..428498e 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -4,6 +4,7 @@
> */
> #include
> #include
> +#include
>
> #ifdef CONFIG_ARM64
> #include
> @@ -58,6 +59,12 @@ struct mm_region *mem_map = qemu_arm64_mem_map;
>
> int board_init(void)
> {
> + /*
> +* Make sure virtio bus is enumerated so that peripherals
> +* on the virtio bus can be discovered by their drivers
> +*/
> + virtio_init();
> +
> return 0;
> }
>
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 20/27] x86: Implement arch-specific io accessor routines
On 23 September 2018 at 06:42, Bin Meng wrote:
> At present the generic io{read,write}{8,16,32} routines only support
> MMIO access. With architecture like x86 that has a separate IO space,
> these routines cannot be used to access I/O ports.
>
> Implement x86-specific version to support both PIO and MMIO access,
> so that drivers for multiple architectures can use these accessors
> without the need to know whether it's MMIO or PIO.
>
> These are ported from Linux kernel lib/iomap.c, with slight changes.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/Kconfig | 1 +
> arch/x86/include/asm/io.h | 66
> +++
> 2 files changed, 67 insertions(+)
Reviewed-by: Simon Glass
Should we use regmap instead?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/27] virtio: Add virtio over pci transport driver
Hi Bin, On 23 September 2018 at 06:42, Bin Meng wrote: > This adds a transport driver that implements UCLASS_VIRTIO for > virtio over pci, which is commonly used on x86. > > It only supports the legacy interface of the pci transport, which > is the default device that QEMU emulates. > > Signed-off-by: Bin Meng > --- > > drivers/virtio/Kconfig | 8 + > drivers/virtio/Makefile | 1 + > drivers/virtio/virtio_pci.c | 420 > > drivers/virtio/virtio_pci.h | 173 ++ > 4 files changed, 602 insertions(+) > create mode 100644 drivers/virtio/virtio_pci.c > create mode 100644 drivers/virtio/virtio_pci.h Reviewed-by: Simon Glass vring_create_virtqueue() should return an error I think - you assume -ENOMEM That is a huge table of PCI devices. Can you use a class instead? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 23/27] dm: pci: Add APIs to find next capability and extended capability
On 23 September 2018 at 06:42, Bin Meng wrote: > This introduces two new APIs dm_pci_find_next_capability() and > dm_pci_find_next_ext_capability() to get PCI capability address > and PCI express extended capability address for a given PCI device > starting from a given offset. > > Signed-off-by: Bin Meng > --- > > drivers/pci/pci-uclass.c | 48 > > include/pci.h| 48 > > 2 files changed, 80 insertions(+), 16 deletions(-) Are these called somewhere from sandbox?...ah yes, next patch Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/27] sandbox: blk: Switch to use platdata_auto_alloc_size for the driver data
On 23 September 2018 at 06:42, Bin Meng wrote: > Currently the sandbox block driver uses priv_auto_alloc_size for > the driver data, however that's only available after the device > probe phase. In order to make it accessible in an earlier phase, > switch to use platdata_auto_alloc_size instead. > > This patch is the prerequisite for the follow up patch of DM BLK > driver changes to work with Sandbox. > > Signed-off-by: Bin Meng > --- > > drivers/block/sandbox.c | 15 --- > 1 file changed, 8 insertions(+), 7 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 05/27] virtio: Add net driver support
On 23 September 2018 at 06:42, Bin Meng wrote: > From: Tuomas Tynkkynen > > This adds virtio net device driver support. > > Signed-off-by: Tuomas Tynkkynen > Signed-off-by: Bin Meng > --- > > drivers/virtio/Kconfig | 7 ++ > drivers/virtio/Makefile | 1 + > drivers/virtio/virtio_net.c | 215 +++ > drivers/virtio/virtio_net.h | 268 > > 4 files changed, 491 insertions(+) > create mode 100644 drivers/virtio/virtio_net.c > create mode 100644 drivers/virtio/virtio_net.h Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/27] dm: Add a new uclass driver for VirtIO transport devices
Hi Bin,
On 23 September 2018 at 06:42, Bin Meng wrote:
> This adds a new virtio uclass driver for “virtio” [1] family of
> devices that are are found in virtual environments like QEMU,
> yet by design they look like physical devices to the guest.
>
> The uclass driver provides child_pre_probe() and child_post_probe()
> methods to do some common operations for virtio device drivers like
> device and driver supported feature negotiation, etc.
>
> [1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
Can you add this link to the header file too? This seems to be lacking
docs.in the source code. Also in a header file, a short statement of
what virtio is for would be good.
>
> Signed-off-by: Tuomas Tynkkynen
> Signed-off-by: Bin Meng
> ---
>
> drivers/Kconfig| 2 +
> drivers/Makefile | 1 +
> drivers/virtio/Kconfig | 14 +
> drivers/virtio/Makefile| 6 +
> drivers/virtio/virtio-uclass.c | 333
> include/dm/uclass-id.h | 1 +
> include/virtio.h | 694
> +
> include/virtio_types.h | 24 ++
> 8 files changed, 1075 insertions(+)
> create mode 100644 drivers/virtio/Kconfig
> create mode 100644 drivers/virtio/Makefile
> create mode 100644 drivers/virtio/virtio-uclass.c
> create mode 100644 include/virtio.h
> create mode 100644 include/virtio_types.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 56536c4..d40db0d 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -106,6 +106,8 @@ source "drivers/usb/Kconfig"
>
> source "drivers/video/Kconfig"
>
> +source "drivers/virtio/Kconfig"
> +
> source "drivers/watchdog/Kconfig"
>
> config PHYS_TO_BUS
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 23ea609..f09daae 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_$(SPL_TPL_)SERIAL_SUPPORT) += serial/
> obj-$(CONFIG_$(SPL_TPL_)SPI_FLASH_SUPPORT) += mtd/spi/
> obj-$(CONFIG_$(SPL_TPL_)SPI_SUPPORT) += spi/
> obj-$(CONFIG_$(SPL_TPL_)TIMER) += timer/
> +obj-$(CONFIG_$(SPL_TPL_)VIRTIO) += virtio/
> obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/
> obj-$(CONFIG_$(SPL_)REMOTEPROC) += remoteproc/
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> new file mode 100644
> index 000..bdfa96a
> --- /dev/null
> +++ b/drivers/virtio/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018, Tuomas Tynkkynen
> +# Copyright (C) 2018, Bin Meng
> +
> +menu "VirtIO Drivers"
> +
> +config VIRTIO
> + bool
> + help
> + This option is selected by any driver which implements the virtio
> + bus, such as CONFIG_VIRTIO_MMIO or CONFIG_VIRTIO_PCI.
What is a virtio bus?
> +
> +endmenu
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> new file mode 100644
> index 000..23e7be7
> --- /dev/null
> +++ b/drivers/virtio/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018, Tuomas Tynkkynen
> +# Copyright (C) 2018, Bin Meng
> +
> +obj-y += virtio-uclass.o
> diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
> new file mode 100644
> index 000..1c85856
> --- /dev/null
> +++ b/drivers/virtio/virtio-uclass.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Tuomas Tynkkynen
> + * Copyright (C) 2018, Bin Meng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const char *const virtio_drv_name[VIRTIO_ID_MAX_NUM] = {
> + [VIRTIO_ID_NET] = VIRTIO_NET_DRV_NAME,
> + [VIRTIO_ID_BLOCK] = VIRTIO_BLK_DRV_NAME,
> +};
> +
> +int virtio_get_config(struct udevice *vdev, unsigned int offset,
> + void *buf, unsigned int len)
> +{
> + struct dm_virtio_ops *ops;
> +
> + ops = virtio_get_ops(vdev->parent);
> + if (!ops->get_config)
> + return -ENOSYS;
blank line before return (fix globally)
> + return ops->get_config(vdev->parent, offset, buf, len);
> +}
> +
> +int virtio_set_config(struct udevice *vdev, unsigned int offset,
> + void *buf, unsigned int len)
> +{
> + struct dm_virtio_ops *ops;
> +
> + ops = virtio_get_ops(vdev->parent);
> + if (!ops->set_config)
> + return -ENOSYS;
> + return ops->set_config(vdev->parent, offset, buf, len);
> +}
> +
> +int virtio_generation(struct udevice *vdev, u32 *counter)
> +{
> + struct dm_virtio_ops *ops;
> +
> + ops = virtio_get_ops(vdev->parent);
> + if (!ops->generation)
> + return -ENOSYS;
> + return ops->generation(vdev->parent, counter);
> +}
> +
> +int virtio_get_status(struct udevice *vdev, u8 *status)
> +{
> + struct dm_virtio_ops *ops;
> +
> + ops = virtio_get_ops(vdev->parent);
> + if (!ops->get_status)
> + return -ENOSYS;
>
Re: [U-Boot] [PATCH 08/27] efi_driver: blk: Switch to use platdata_auto_alloc_size for the driver data
On 23 September 2018 at 06:42, Bin Meng wrote: > Currently the efi block driver uses priv_auto_alloc_size for the > driver data, however that's only available after the device probe > phase. In order to make it accessible in an earlier phase, switch > to use platdata_auto_alloc_size instead. > > This patch is the prerequisite for the follow up patch of DM BLK > driver changes to work with EFI loader. > > Signed-off-by: Bin Meng > --- > > lib/efi_driver/efi_block_device.c | 24 > 1 file changed, 12 insertions(+), 12 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 09/27] blk: Call part_init() in the post_probe() method
On 23 September 2018 at 06:42, Bin Meng wrote: > part_init() is currently called in every DM BLK driver, either > in its bind() or probe() method. However we can use the BLK > uclass driver's post_probe() method to do it automatically. > > Update all DM BLK drivers to adopt this change. > > Signed-off-by: Bin Meng > --- > > cmd/sata.c| 9 - > common/usb_storage.c | 4 +--- > drivers/block/blk-uclass.c| 12 > drivers/block/ide.c | 2 -- > drivers/block/sandbox.c | 2 +- > drivers/mmc/mmc.c | 3 --- > drivers/nvme/nvme.c | 1 - > drivers/scsi/scsi.c | 1 - > lib/efi_driver/efi_block_device.c | 2 -- > 9 files changed, 14 insertions(+), 22 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 17/27] riscv: qemu: Enumerate virtio bus during early boot
On 23 September 2018 at 06:42, Bin Meng wrote: > Currently devices on the virtio bus is not automatically enumerated, > which means peripherals on the virtio bus are not discovered by their > drivers. This uses board_init() to do the virtio enumeration. > > Signed-off-by: Bin Meng > --- > > board/emulation/qemu-riscv/Kconfig | 3 +++ > board/emulation/qemu-riscv/qemu-riscv.c | 7 +++ > 2 files changed, 10 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] spi: Add support for the Aspeed ast2500 SPI controllers
Hi Cedric, On 10 September 2018 at 07:16, Cédric Le Goater wrote: > The Aspeed AST2500 SoC comes with three static memory controllers, all > with a similar interface : > > * Firmware SPI Memory Controller (FMC) >. BMC firmware >. 3 chip select pins (CE0 ~ CE2) >. supports SPI type flash memory (CE0 ~ CE1) >. CE2 can be of NOR type flash but this is not supported by the > driver > > * SPI Flash Controller (SPI1 and SPI2) >. host firmware >. 2 chip select pins (CE0 ~ CE1) > > Each controller has a defined AHB window for its registers and another > AHB window on which all the flash devices are mapped. Each device is > assigned a memory range through a set of registers called the Segment > Address Registers. > > Devices are controlled using two different modes: the USER command > mode or the READ/WRITE command mode. When in USER command mode, > accesses to the AHB window of the SPI flash device are translated into > SPI command transfers. When in READ/WRITE command mode, the HW > generates the SPI commands depending on the setting of the CE control > register. > > The following driver supports the FMC and the SPI controllers with the > attached SPI flash devices. When the controller is probed, the driver > performs a read timing calibration using specific DMA control > registers (FMC only). The driver's primary goal is to support the > first device of the FMC controller on which reside U-Boot but it > should support the other controllers also. > > The Aspeed FMC controller automatically detects at boot time if a > flash device is in 4BYTE address mode and self configures to use the > appropriate address width. This can be a problem for the U-Boot SPI > Flash layer which only supports 3 byte addresses. In such a case, a > warning is emitted and the address width is fixed when sent on the > bus. > > Signed-off-by: Cédric Le Goater > --- > arch/arm/include/asm/arch-aspeed/spi.h | 114 > drivers/spi/aspeed_spi.c | 788 + > drivers/spi/Kconfig| 8 + > drivers/spi/Makefile | 1 + > 4 files changed, 911 insertions(+) > create mode 100644 arch/arm/include/asm/arch-aspeed/spi.h > create mode 100644 drivers/spi/aspeed_spi.c > > diff --git a/arch/arm/include/asm/arch-aspeed/spi.h > b/arch/arm/include/asm/arch-aspeed/spi.h > new file mode 100644 > index ..9e952933e1f1 > --- /dev/null > +++ b/arch/arm/include/asm/arch-aspeed/spi.h > @@ -0,0 +1,114 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (c) 2018, IBM Corporation. > + */ > + > +#ifndef _ASM_ARCH_ASPEED_SPI_H > +#define _ASM_ARCH_ASPEED_SPI_H > + > +/* CE Type Setting Register */ > +#define CONF_ENABLE_W2 BIT(18) > +#define CONF_ENABLE_W1 BIT(17) > +#define CONF_ENABLE_W0 BIT(16) > +#define CONF_FLASH_TYPE2 4 > +#define CONF_FLASH_TYPE1 2 /* Hardwired to SPI */ > +#define CONF_FLASH_TYPE0 0 /* Hardwired to SPI */ > +#define CONF_FLASH_TYPE_NOR 0x0 > +#define CONF_FLASH_TYPE_SPI 0x2 > + > +/* CE Control Register */ > +#define CTRL_EXTENDED2 BIT(2) /* 32 bit addressing for SPI > */ > +#define CTRL_EXTENDED1 BIT(1) /* 32 bit addressing for SPI > */ > +#define CTRL_EXTENDED0 BIT(0) /* 32 bit addressing for SPI > */ > + > +/* Interrupt Control and Status Register */ > +#define INTR_CTRL_DMA_STATUS BIT(11) > +#define INTR_CTRL_CMD_ABORT_STATUS BIT(10) > +#define INTR_CTRL_WRITE_PROTECT_STATUS BIT(9) > +#define INTR_CTRL_DMA_EN BIT(3) > +#define INTR_CTRL_CMD_ABORT_EN BIT(2) > +#define INTR_CTRL_WRITE_PROTECT_EN BIT(1) > + > +/* CEx Control Register */ > +#define CE_CTRL_IO_MODE_MASK GENMASK(30, 28) > +#define CE_CTRL_IO_DUAL_DATA BIT(29) > +#define CE_CTRL_IO_DUAL_ADDR_DATA (BIT(29) | BIT(28)) > +#define CE_CTRL_CMD_SHIFT 16 > +#define CE_CTRL_CMD_MASK 0xff > +#define CE_CTRL_CMD(cmd) \ > + (((cmd) & CE_CTRL_CMD_MASK) << CE_CTRL_CMD_SHIFT) > +#define CE_CTRL_DUMMY_HIGH_SHIFT 14 > +#define CE_CTRL_CLOCK_FREQ_SHIFT 8 > +#define CE_CTRL_CLOCK_FREQ_MASK0xf > +#define CE_CTRL_CLOCK_FREQ(div) > \ > + (((div) & CE_CTRL_CLOCK_FREQ_MASK) << CE_CTRL_CLOCK_FREQ_SHIFT) Do you need this, and other macros like it? I suppose you do use them twice in the code, at least. > +#define CE_CTRL_DUMMY_LOW_SHIFT6 /* 2 bits [7:6] */ > +#define CE_CTRL_DUMMY(dummy)\ > + (dummy) >> 2) & 0x1) << CE_CTRL_DUMMY_HIGH_SHIFT) | \ > +(((dummy) & 0x3) << CE_CTRL_DUMMY_LOW_SHIFT)) I think this needs MASK values instead of open-coding them. > +#define CE_CTRL_STOP_ACTIVE
Re: [U-Boot] [PATCH 15/27] arm: qemu: Add a Kconfig in the board directory
On 23 September 2018 at 06:42, Bin Meng wrote: > This adds a Kconfig file in the board directory, so that some > board-specific options can be specified there. > > Signed-off-by: Bin Meng > --- > > arch/arm/Kconfig | 1 + > board/emulation/qemu-arm/Kconfig | 9 + > configs/qemu_arm64_defconfig | 1 - > configs/qemu_arm_defconfig | 1 - > 4 files changed, 10 insertions(+), 2 deletions(-) > create mode 100644 board/emulation/qemu-arm/Kconfig Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] net: re-add support for the Faraday ftgmac100 controller
Hi Cedric,
On 10 September 2018 at 07:21, Cédric Le Goater wrote:
> The driver is based on the previous one and adds the same support for
> the Faraday ftgmac100 controller with MAC and MDIO bus support for
> RGMII/RMII modes.
>
> Driver model support was added as well as some enhancements and fixes.
>
> Signed-off-by: Cédric Le Goater
> ---
> drivers/net/ftgmac100.h | 242
> drivers/net/ftgmac100.c | 493
> drivers/net/Kconfig | 8 +
> drivers/net/Makefile| 1 +
> 4 files changed, 744 insertions(+)
> create mode 100644 drivers/net/ftgmac100.h
> create mode 100644 drivers/net/ftgmac100.c
Reviewed-by: Simon Glass
Various minor comments below.
>
> diff --git a/drivers/net/ftgmac100.h b/drivers/net/ftgmac100.h
> new file mode 100644
> index ..9a789e4d5bee
> --- /dev/null
> +++ b/drivers/net/ftgmac100.h
> @@ -0,0 +1,242 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Faraday FTGMAC100 Ethernet
> + *
> + * (C) Copyright 2010 Faraday Technology
> + * Po-Yu Chuang
> + *
> + * (C) Copyright 2010 Andes Technology
> + * Macpaul Lin
> + */
> +
> +#ifndef __FTGMAC100_H
> +#define __FTGMAC100_H
> +
> +/* The registers offset table of ftgmac100 */
> +struct ftgmac100 {
> + unsigned intisr;/* 0x00 */
> + unsigned intier;/* 0x04 */
> + unsigned intmac_madr; /* 0x08 */
> + unsigned intmac_ladr; /* 0x0c */
> + unsigned intmaht0; /* 0x10 */
> + unsigned intmaht1; /* 0x14 */
> + unsigned inttxpd; /* 0x18 */
> + unsigned intrxpd; /* 0x1c */
> + unsigned inttxr_badr; /* 0x20 */
> + unsigned intrxr_badr; /* 0x24 */
> + unsigned inthptxpd; /* 0x28 */
> + unsigned inthptxpd_badr;/* 0x2c */
> + unsigned intitc;/* 0x30 */
> + unsigned intaptc; /* 0x34 */
> + unsigned intdblac; /* 0x38 */
> + unsigned intdmafifos; /* 0x3c */
> + unsigned intrevr; /* 0x40 */
> + unsigned intfear; /* 0x44 */
> + unsigned inttpafcr; /* 0x48 */
> + unsigned intrbsr; /* 0x4c */
> + unsigned intmaccr; /* 0x50 */
> + unsigned intmacsr; /* 0x54 */
> + unsigned inttm; /* 0x58 */
> + unsigned intresv1; /* 0x5c */ /* not defined in spec */
> + unsigned intphycr; /* 0x60 */
> + unsigned intphydata;/* 0x64 */
> + unsigned intfcr;/* 0x68 */
> + unsigned intbpr;/* 0x6c */
> + unsigned intwolcr; /* 0x70 */
> + unsigned intwolsr; /* 0x74 */
> + unsigned intwfcrc; /* 0x78 */
> + unsigned intresv2; /* 0x7c */ /* not defined in spec */
> + unsigned intwfbm1; /* 0x80 */
> + unsigned intwfbm2; /* 0x84 */
> + unsigned intwfbm3; /* 0x88 */
> + unsigned intwfbm4; /* 0x8c */
> + unsigned intnptxr_ptr; /* 0x90 */
> + unsigned inthptxr_ptr; /* 0x94 */
> + unsigned intrxr_ptr;/* 0x98 */
> + unsigned intresv3; /* 0x9c */ /* not defined in spec */
> + unsigned inttx; /* 0xa0 */
> + unsigned inttx_mcol_scol; /* 0xa4 */
> + unsigned inttx_ecol_fail; /* 0xa8 */
> + unsigned inttx_lcol_und;/* 0xac */
> + unsigned intrx; /* 0xb0 */
> + unsigned intrx_bc; /* 0xb4 */
> + unsigned intrx_mc; /* 0xb8 */
> + unsigned intrx_pf_aep; /* 0xbc */
> + unsigned intrx_runt;/* 0xc0 */
> + unsigned intrx_crcer_ftl; /* 0xc4 */
> + unsigned intrx_col_lost;/* 0xc8 */
> +};
> +
> +/*
> + * Interrupt status register & interrupt enable register
> + */
> +#define FTGMAC100_INT_RPKT_BUF BIT(0)
> +#define FTGMAC100_INT_RPKT_FIFOBIT(1)
> +#define FTGMAC100_INT_NO_RXBUF BIT(2)
> +#define FTGMAC100_INT_RPKT_LOSTBIT(3)
> +#define FTGMAC100_INT_XPKT_ETH BIT(4)
> +#define FTGMAC100_INT_XPKT_FIFOBIT(5)
> +#define FTGMAC100_INT_NO_NPTXBUF BIT(6)
> +#define FTGMAC100_INT_XPKT_LOSTBIT(7)
> +#define FTGMAC100_INT_AHB_ERR BIT(8)
> +#define FTGMAC100_INT_PHYSTS_CHG BIT(9)
> +#define FTGMAC100_INT_NO_HPTXBUF BIT(10)
> +
> +/*
> + * Interrupt timer control register
> + */
> +#define FTGMAC100_ITC_RXINT_CNT(x) (((x) & 0xf) << 0)
> +#define FTGMAC100_ITC_RXINT_THR(x) (((x) & 0x7) << 4)
> +#define FTGMAC100_ITC_RXINT_TIME_SEL BIT(7)
> +#define FTGMAC100_ITC_TXINT_CNT(x) (((x) &
Re: [U-Boot] [PATCH 14/27] virtio: cmd: Add virtio command for virtio block devices
On 23 September 2018 at 06:42, Bin Meng wrote: > From: Tuomas Tynkkynen > > Add 'virtio' command in U-Boot command line. > > Signed-off-by: Tuomas Tynkkynen > Signed-off-by: Bin Meng > --- > > cmd/Kconfig | 7 +++ > cmd/Makefile | 1 + > cmd/virtio.c | 37 + > 3 files changed, 45 insertions(+) > create mode 100644 cmd/virtio.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/27] virtio: Add virtio over mmio transport driver
On 23 September 2018 at 06:42, Bin Meng wrote: > VirtIO can use various different buses and virtio devices are > commonly implemented as PCI devices. But virtual environments > without PCI support (a common situation in embedded devices > models) might use simple memory mapped device (“virtio-mmio”) > instead of the PCI device. > > This adds a transport driver that implements UCLASS_VIRTIO for > virtio over mmio. > > Signed-off-by: Tuomas Tynkkynen > Signed-off-by: Bin Meng > --- > > drivers/virtio/Kconfig | 7 + > drivers/virtio/Makefile | 1 + > drivers/virtio/virtio_mmio.c | 413 > +++ > drivers/virtio/virtio_mmio.h | 129 ++ > 4 files changed, 550 insertions(+) > create mode 100644 drivers/virtio/virtio_mmio.c > create mode 100644 drivers/virtio/virtio_mmio.h Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27] dm: core: Allow uclass to set up a device's child after it is probed
Hi Bin,
On 23 September 2018 at 06:41, Bin Meng wrote:
> Some buses need to set up their child devices after they are probed.
> Support a common child_post_probe() method for the uclass.
>
> With this change, the two APIs uclass_pre_probe_device() and
> uclass_post_probe_device() become symmetric.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/core/uclass.c | 13 -
> include/dm/uclass.h | 4 +++-
> 2 files changed, 15 insertions(+), 2 deletions(-)
Another option, perhaps not quite as elegant, is for the driver to
call into the uclass in its probe() method. We need to balance
elegance with the cost of adding a new field to the uclass which is
rarely used. What do you think?
Also, this does need some sort of use in sandbox, so can you update
the test driver to use it?
>
> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> index 3113d6a..3c7b9cf 100644
> --- a/drivers/core/uclass.c
> +++ b/drivers/core/uclass.c
> @@ -687,8 +687,19 @@ int uclass_pre_probe_device(struct udevice *dev)
>
> int uclass_post_probe_device(struct udevice *dev)
> {
> - struct uclass_driver *uc_drv = dev->uclass->uc_drv;
> + struct uclass_driver *uc_drv;
> + int ret;
> +
> + if (dev->parent) {
> + uc_drv = dev->parent->uclass->uc_drv;
> + if (uc_drv->child_post_probe) {
> + ret = uc_drv->child_post_probe(dev);
> + if (ret)
> + return ret;
> + }
> + }
>
> + uc_drv = dev->uclass->uc_drv;
> if (uc_drv->post_probe)
> return uc_drv->post_probe(dev);
>
> diff --git a/include/dm/uclass.h b/include/dm/uclass.h
> index 6e7c1cd..610c68d 100644
> --- a/include/dm/uclass.h
> +++ b/include/dm/uclass.h
> @@ -58,7 +58,8 @@ struct udevice;
> * @post_probe: Called after a new device is probed
> * @pre_remove: Called before a device is removed
> * @child_post_bind: Called after a child is bound to a device in this uclass
> - * @child_pre_probe: Called before a child is probed in this uclass
> + * @child_pre_probe: Called before a child in this uclass is probed
> + * @child_post_probe: Called after a child in this uclass is probed
> * @init: Called to set up the uclass
> * @destroy: Called to destroy the uclass
> * @priv_auto_alloc_size: If non-zero this is the size of the private data
> @@ -91,6 +92,7 @@ struct uclass_driver {
> int (*pre_remove)(struct udevice *dev);
> int (*child_post_bind)(struct udevice *dev);
> int (*child_pre_probe)(struct udevice *dev);
> + int (*child_post_probe)(struct udevice *dev);
> int (*init)(struct uclass *class);
> int (*destroy)(struct uclass *class);
> int priv_auto_alloc_size;
> --
> 2.7.4
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] aspeed: ast2500: Add AHB clock
On 10 September 2018 at 07:16, Cédric Le Goater wrote: > The AHB clock is used by the FMC/SPI controllers. > > Signed-off-by: Cédric Le Goater > --- > arch/arm/include/asm/arch-aspeed/scu_ast2500.h | 2 ++ > include/dt-bindings/clock/ast2500-scu.h| 1 + > drivers/clk/aspeed/clk_ast2500.c | 12 > 3 files changed, 15 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] aspeed: ast2500: fix missing break in D2PLL clock enablement
On 10 September 2018 at 07:21, Cédric Le Goater wrote: > Signed-off-by: Cédric Le Goater > --- > drivers/clk/aspeed/clk_ast2500.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] net: ftgmac100: add support for Aspeed SoC
Hi Cedric,
On 10 September 2018 at 07:21, 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). Also include the Aspeed clock enablement.
>
> Signed-off-by: Cédric Le Goater
> ---
> drivers/net/ftgmac100.h | 5 +++
> drivers/net/ftgmac100.c | 72 +
> 2 files changed, 71 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ftgmac100.h b/drivers/net/ftgmac100.h
> index 9a789e4d5bee..b8f99ddf48bc 100644
> --- a/drivers/net/ftgmac100.h
> +++ b/drivers/net/ftgmac100.h
> @@ -129,6 +129,11 @@ struct ftgmac100 {
> #define FTGMAC100_DMAFIFOS_RXDMA_REQ BIT(30)
> #define FTGMAC100_DMAFIFOS_TXDMA_REQ BIT(31)
>
> +/*
> + * Feature Register
> + */
> +#define FTGMAC100_REVR_NEW_MDIOBIT(31)
> +
> /*
> * Receive buffer size register
> */
> diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
> index 8d7bf5b9b351..3df48a82c1ad 100644
> --- a/drivers/net/ftgmac100.c
> +++ b/drivers/net/ftgmac100.c
> @@ -27,6 +27,8 @@
> /* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
> #define PKTBUFSTX 4
>
> +#define FTGMAC100_ASPEED_NR_CLKS 2
> +
> struct ftgmac100_data {
> phys_addr_t iobase;
>
> @@ -40,6 +42,11 @@ struct ftgmac100_data {
Comments on struct and members
> struct mii_dev *bus;
> u32 phy_mode;
> u32 max_speed;
> +
> + struct clk clks[FTGMAC100_ASPEED_NR_CLKS];
> + u32 rxdes0_edorr_mask;
> + u32 txdes0_edotr_mask;
> + bool is_aspeed;
> };
>
> /*
> @@ -115,9 +122,15 @@ static int ftgmac100_mdio_write(struct mii_dev *bus, int
> phy_addr, int dev_addr,
>
> static int ftgmac100_mdio_init(struct ftgmac100_data *priv, int dev_id)
> {
> + struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)priv->iobase;
> struct mii_dev *bus;
> int ret;
>
> + if (priv->is_aspeed) {
Perhaps call this old_mdio_if ?
> + /* This driver supports the old MDIO interface */
> + clrbits_le32(>revr, FTGMAC100_REVR_NEW_MDIO);
> + };
> +
> bus = mdio_alloc();
> if (!bus)
> return -ENOMEM;
> @@ -246,13 +259,13 @@ static int ftgmac100_start(struct udevice *dev)
> priv->txdes[i].txdes3 = 0;
> priv->txdes[i].txdes0 = 0;
> }
> - priv->txdes[PKTBUFSTX - 1].txdes0 = FTGMAC100_TXDES0_EDOTR;
> + priv->txdes[PKTBUFSTX - 1].txdes0 = priv->txdes0_edotr_mask;
>
> for (i = 0; i < PKTBUFSRX; i++) {
> priv->rxdes[i].rxdes3 = (unsigned int)net_rx_packets[i];
> priv->rxdes[i].rxdes0 = 0;
> }
> - priv->rxdes[PKTBUFSRX - 1].rxdes0 = FTGMAC100_RXDES0_EDORR;
> + priv->rxdes[PKTBUFSRX - 1].rxdes0 = priv->rxdes0_edorr_mask;
>
> /* transmit ring */
> writel((u32)priv->txdes, >txr_badr);
> @@ -378,7 +391,7 @@ static int ftgmac100_send(struct udevice *dev, void
> *packet, int length)
> flush_dcache_range(data_start, data_end);
>
> /* only one descriptor on TXBUF */
> - curr_des->txdes0 &= FTGMAC100_TXDES0_EDOTR;
> + curr_des->txdes0 &= priv->txdes0_edotr_mask;
> curr_des->txdes0 |= FTGMAC100_TXDES0_FTS |
> FTGMAC100_TXDES0_LTS |
> FTGMAC100_TXDES0_TXBUF_SIZE(length) |
> @@ -409,8 +422,11 @@ static int ftgmac100_write_hwaddr(struct udevice *dev)
>
> static int ftgmac100_ofdata_to_platdata(struct udevice *dev)
> {
> + struct ftgmac100_data *priv = dev_get_priv(dev);
> struct eth_pdata *pdata = dev_get_platdata(dev);
> const char *phy_mode;
> + int ret;
> + int i;
>
> pdata->iobase = devfdt_get_addr(dev);
> pdata->phy_interface = -1;
> @@ -424,13 +440,39 @@ static int ftgmac100_ofdata_to_platdata(struct udevice
> *dev)
>
> pdata->max_speed = dev_read_u32_default(dev, "max-speed", 0);
>
> + if (device_is_compatible(dev, "aspeed,ast2500-mac")) {
Should use dev_get_driver_data() here.
> + priv->rxdes0_edorr_mask = BIT(30);
> + priv->txdes0_edotr_mask = BIT(30);
> + priv->is_aspeed = true;
> + } else {
> + priv->rxdes0_edorr_mask = BIT(15);
> + priv->txdes0_edotr_mask = BIT(15);
> + }
> +
> + if (priv->is_aspeed) {
> + for (i = 0; i < FTGMAC100_ASPEED_NR_CLKS; i++) {
> + ret = clk_get_by_index(dev, i, >clks[i]);
> + if (ret) {
> + dev_err(dev, "Failed to get clock: %d\n",
> ret);
> + goto out_clk_free;
> + }
> + }
clk_get_bulk() ?
> + }
> +
> return 0;
> +
> +out_clk_free:
> + while (--i >= 0)
> + clk_free(>clks[i]);
> +
> + return ret;
> }
>
> static int
Re: [U-Boot] [PATCH 5/5] aspeed: Activate ethernet devices on the ast2500 Eval Board
On 10 September 2018 at 07:21, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater
> ---
> arch/arm/dts/ast2500-evb.dts | 17 +
> arch/arm/dts/ast2500.dtsi | 4 ++--
> configs/evb-ast2500_defconfig | 8
> 3 files changed, 27 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass
>
> diff --git a/arch/arm/dts/ast2500-evb.dts b/arch/arm/dts/ast2500-evb.dts
> index 609678ff7989..1bd224dacf78 100644
> --- a/arch/arm/dts/ast2500-evb.dts
> +++ b/arch/arm/dts/ast2500-evb.dts
> @@ -14,6 +14,7 @@
>
> aliases {
> spi0 =
> + ethernet0 =
> };
> };
>
> @@ -53,3 +54,19 @@
> spi-rx-bus-width = <2>;
> };
> };
> +
> + {
> + status = "okay";
> +
> + phy-mode = "rgmii";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_mac1link_default _mdio1_default>;
> +};
> +
> + {
> + status = "disabled";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_mac2link_default _mdio2_default>;
> +};
> diff --git a/arch/arm/dts/ast2500.dtsi b/arch/arm/dts/ast2500.dtsi
> index de7607aaafff..a1fc5370b109 100644
> --- a/arch/arm/dts/ast2500.dtsi
> +++ b/arch/arm/dts/ast2500.dtsi
> @@ -108,7 +108,7 @@
> };
>
> mac0: ethernet@1e66 {
> - compatible = "faraday,ftgmac100";
> + compatible = "aspeed,ast2500-mac",
> "faraday,ftgmac100";
> reg = <0x1e66 0x180>;
> interrupts = <2>;
> no-hw-checksum;
> @@ -116,7 +116,7 @@
> };
>
> mac1: ethernet@1e68 {
> - compatible = "faraday,ftgmac100";
> + compatible = "aspeed,ast2500-mac",
> "faraday,ftgmac100";
> reg = <0x1e68 0x180>;
> interrupts = <3>;
> no-hw-checksum;
> diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
> index eb0fe00fb49f..4e65388dab23 100644
> --- a/configs/evb-ast2500_defconfig
> +++ b/configs/evb-ast2500_defconfig
> @@ -38,3 +38,11 @@ CONFIG_CMD_SF=y
> CONFIG_CMD_SAVEENV=y
> CONFIG_ENV_IS_IN_SPI_FLASH=y
> CONFIG_FIT=y
> +CONFIG_NETDEVICES=y
> +CONFIG_PHY=y
> +CONFIG_DM_ETH=y
> +CONFIG_FTGMAC100=y
> +CONFIG_PHY_REALTEK=y
> +CONFIG_CMD_PING=y
> +CONFIG_CMD_DHCP=y
> +CONFIG_CMD_MII=y
Are these correctly sorted? (make savedevconfig)
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Enable CONFIG_TIMER_EARLY with bootstage
Hi Bin, On 25 September 2018 at 23:39, Bin Meng wrote: > Hi Simon, > > On Wed, Sep 26, 2018 at 1:42 PM Simon Glass wrote: >> >> Hi Bin, >> >> On 4 September 2018 at 03:06, Bin Meng wrote: >> > Hi Simon, >> > >> > On Mon, Sep 3, 2018 at 7:02 AM Simon Glass wrote: >> >> >> >> In initr_bootstage() we call bootstage_mark_name() which ends up calling >> >> timer_get_us(). This call happens before initr_dm(), which inits driver >> >> model. >> >> >> >> On x86 we set gd->timer to NULL in the transition from board_init_f() >> > >> > It's not just x86 we set gd->timer to NULL. It applied to all >> > architectures when CONFIG_TIMER is on. >> > >> >> to board_init_r(). See board_init_f_r() for this assignment. So U-Boot >> >> knows there is no timer available in the period immediately after >> >> relocation. >> >> >> >> On x86 the timer_get_us() call is implemented as calls to get_ticks() and >> >> get_tbclk(). Both of these call dm_timer_init() to set up the timer, if >> >> gd->timer is NULL and the early timer is not available. >> >> >> >> However dm_timer_init() cannot succeed before initr_dm() is called. >> >> >> >> So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable >> >> CONFIG_TIMER_EARLY. Update the Kconfig to handle this. >> >> >> >> Note: On most architectures we can rely on the pre-relocation memory still >> >> being available, so that gd->timer pointers to a valid timer device and >> >> everything works correctly. Admittedly this is not strictly correct since >> >> the timer device is set up by pre-relocation U-Boot, but normally this is >> >> fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot >> >> disappears in board_init_f_r() and any attempt to access it will hang. >> >> This is the reason why we must mark the timer as invalid when we get to >> >> board_init_f_r(). >> >> >> >> Signed-off-by: Simon Glass >> >> --- >> >> >> >> drivers/timer/Kconfig | 3 +++ >> >> 1 file changed, 3 insertions(+) >> >> >> >> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig >> >> index 5ab6749193c..ff434de6f7c 100644 >> >> --- a/drivers/timer/Kconfig >> >> +++ b/drivers/timer/Kconfig >> >> @@ -30,6 +30,9 @@ config TPL_TIMER >> >> config TIMER_EARLY >> >> bool "Allow timer to be used early in U-Boot" >> >> depends on TIMER >> >> + # initr_bootstage() requires a timer and is called before >> >> initr_dm() >> >> + # so only the early timer is available >> >> + default y if X86 && BOOTSTAGE >> > >> > Since this applies not only on x86, and given without TIMER_EARLY >> > BOOTSTAGE is broken, shouldn't we do this in BOOTSTAGE config instead: >> > >> > config BOOTSTAGE >> > select TIMER_EARLY >> >> Well we could, but I suspect that would break things since the early >> timer is not supported by many boards. Also for most boards this >> doesn't actually work fine. x86 is really quite awful in that it has >> no SRAM and the CAR becomes inaccessible as soon as you turn on the >> cache! > > It's true that early timer is supported by some limited boards, but > that's a different issue. For now that patch does not fix anything. If > we add BOOTSTAGE from either defconfig or 'menuconfig' for a board, > without adding TIMER_EARLY, it will for sure break. Is this because of code called in board_f.c ? I don't quite follow. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/3] test: Add tests for board uclass
Hi Mario, On 26 September 2018 at 06:36, Mario Six wrote: > Hi Simon, > On Tue, Jul 31, 2018 at 11:46 AM Mario Six wrote: >> >> Add tests for the new board uclass. >> >> Reviewed-by: Simon Glass >> Signed-off-by: Mario Six >> --- >> >> v3 -> v4: >> No changes >> >> v2 -> v3: >> * Accomodated get_board() rename >> * Fixed style violations >> >> v1 -> v2: >> New in v2 >> --- >> arch/sandbox/dts/test.dts | 4 ++ >> configs/sandbox64_defconfig| 2 + >> configs/sandbox_defconfig | 2 + >> configs/sandbox_flattree_defconfig | 2 + >> configs/sandbox_noblk_defconfig| 2 + >> configs/sandbox_spl_defconfig | 2 + >> drivers/board/Kconfig | 7 ++- >> drivers/board/Makefile | 1 + >> drivers/board/sandbox.c| 107 >> + >> drivers/board/sandbox.h| 12 + >> test/dm/Makefile | 1 + >> test/dm/board.c| 57 >> 12 files changed, 198 insertions(+), 1 deletion(-) >> create mode 100644 drivers/board/sandbox.c >> create mode 100644 drivers/board/sandbox.h >> create mode 100644 test/dm/board.c >> > Another series for the u-boot-dm tree? OK, please reassign, Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] drivers: spi: cf_spi: migrate to DM and DT
Hi Angelo,
On 26 September 2018 at 11:53, Angelo Dureghello wrote:
> Hi Simon,
>
> thanks for the review.
>
> On Tue, Sep 25, 2018 at 10:42:08PM -0700, Simon Glass wrote:
>> Hi Angelo,
>>
>> On 20 September 2018 at 15:07, Angelo Dureghello wrote:
>> > This patch converts cf_spi.c to DM and to read driver
>> > platform data from flat devicetree.
>> >
>> > ---
>> > Changes from v1:
>> > - split into 2 patches
>> >
>> > Signed-off-by: Angelo Dureghello
>> > ---
>> > drivers/spi/Kconfig | 18 +-
>> > drivers/spi/cf_spi.c| 495
>> > include/dm/platform_data/spi_coldfire.h | 25 ++
>> > 3 files changed, 369 insertions(+), 169 deletions(-)
>> > create mode 100644 include/dm/platform_data/spi_coldfire.h
>> >
>>
>> Good to see this.
>>
>> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> > index dcd719ff0a..974c5bbed8 100644
>> > --- a/drivers/spi/Kconfig
>> > +++ b/drivers/spi/Kconfig
>> > @@ -80,6 +80,12 @@ config CADENCE_QSPI
>> > used to access the SPI NOR flash on platforms embedding this
>> > Cadence IP core.
>> >
>> > +config CF_SPI
>> > +bool "ColdFire SPI driver"
>> > +help
>> > + Enable the ColdFire SPI driver. This driver can be used on
>> > + some m68k SoCs.
>> > +
>> > config DESIGNWARE_SPI
>> > bool "Designware SPI driver"
>> > help
>> > @@ -244,18 +250,18 @@ config ZYNQMP_GQSPI
>> >
>> > endif # if DM_SPI
>> >
>> > -config SOFT_SPI
>> > - bool "Soft SPI driver"
>> > - help
>> > -Enable Soft SPI driver. This driver is to use GPIO simulate
>> > -the SPI protocol.
>>
>> How come this is changing? That should be a separate patch.
>>
> I just respected Kconfig alphabetical order, SOFT_SPI is just moved after.
OK, well I do think this should be in a separate patch.
>
>> > -
>> > config CF_SPI
>> > bool "ColdFire SPI driver"
>> > help
>> > Enable the ColdFire SPI driver. This driver can be used on
>> > some m68k SoCs.
>> >
>> > +config SOFT_SPI
>> > + bool "Soft SPI driver"
>> > + help
>> > +Enable Soft SPI driver. This driver is to use GPIO simulate
>> > +the SPI protocol.
>> > +
>> > config FSL_ESPI
>> > bool "Freescale eSPI driver"
>> > help
>> > diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
>> > index 522631cbbf..11a11f79c4 100644
>> > --- a/drivers/spi/cf_spi.c
>> > +++ b/drivers/spi/cf_spi.c
>> > @@ -6,16 +6,27 @@
>> > *
>> > * Copyright (C) 2004-2009 Freescale Semiconductor, Inc.
>> > * TsiChung Liew (tsi-chung.l...@freescale.com)
>> > + *
>> > + * Support for device model:
>> > + * Copyright (C) 2018 Angelo Dureghello
>> > + *
>> > */
>> >
>> > #include
>> > +#include
>> > +#include
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > -struct cf_spi_slave {
>> > +struct coldfire_spi_priv {
>> > +#ifndef CONFIG_DM_SPI
>> > struct spi_slave slave;
>> > +#endif
>> > + struct dspi *regs;
>> > uint baudrate;
>> > + int mode;
>> > int charbit;
>> > };
>> >
>> > @@ -38,14 +49,14 @@ DECLARE_GLOBAL_DATA_PTR;
>> > #define SPI_MODE_MOD 0x0020
>> > #define SPI_DBLRATE0x0010
>> >
>> > -static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave
>> > *slave)
>> > -{
>> > - return container_of(slave, struct cf_spi_slave, slave);
>> > -}
>> > +/* Default values */
>> > +#define MCF_DSPI_DEFAULT_SCK_FREQ 1000
>> > +#define MCF_DSPI_MAX_CHIPSELECTS 4
>> > +#define MCF_DSPI_MODE 0
>> >
>> > -static void cfspi_init(void)
>> > +static void __spi_init(struct coldfire_spi_priv *cfspi)
>> > {
>> > - volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
>> > + struct dspi *dspi = cfspi->regs;
>> >
>> > cfspi_port_conf(); /* port configuration */
>> >
>> > @@ -56,125 +67,32 @@ static void cfspi_init(void)
>> >
>> > /* Default setting in platform configuration */
>> > #ifdef CONFIG_SYS_DSPI_CTAR0
>> > - dspi->ctar[0] = CONFIG_SYS_DSPI_CTAR0;
>> > + writel(CONFIG_SYS_DSPI_CTAR0, >ctar[0]);
>>
>> What is going on here? I think these CONFIG options are addresses? If
>> so, they should be read from the DT, not a CONFIG.
>>
>
> These are just default settings for each channel (bus), actually coming
> from the include/configs/boardxxx.h. Their speed an mode bitfields are
> rewritten later, with values coming from devicetree.
> Some driver #define the default value inside the driver itself, in case
> i may change in this way. No one seems reading them from device tree.
OK, can we remove these? At least they should not have a CONFIG_
prefix, so we can remove them from the whitelist.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sandbox: Fix set_working_fdt_addr users
On 26 September 2018 at 06:02, Alexander Graf wrote: > When running sandbox with the new pointer sanitization we just recently > introduced, we're running into a case with FIT images where we end up > interpreting pointers as addresses. > > What happened is that most callers of set_working_fdt_addr() simply > convert pointers into addresses without taking into account that they > might be 2 separate address spaces. Fix the callers up to map their > pointers into addresses. > > This makes sandbox tests pass for me again. > > Signed-off-by: Alexander Graf > > --- > > v1 -> v2: > > - convert callers instead of API, as the main user of > set_working_fdt_addr() is address based > --- > common/bootm.c | 2 +- > common/image-fdt.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] core: Add functions to set properties in live-tree
Hi Mario, On 26 September 2018 at 06:34, Mario Six wrote: > > Hi Simon, > On Wed, Jun 27, 2018 at 1:18 AM Simon Glass wrote: > > > > On 26 June 2018 at 00:46, Mario Six wrote: > > > Implement a set of functions to manipulate properties in a live device > > > tree: > > > > > > * ofnode_write_prop() to set generic properties of a node > > > * ofnode_write_string() to set string properties of a node > > > * ofnode_set_enabled() to either enable or disable a node > > > > > > Signed-off-by: Mario Six > > > > > > --- > > > > > > v2 -> v3: > > > * Removed #ifdef, and used if (!of_live_active()) instead > > > * Removed allocation of property value (caller is now responsible for > > > that); this also fixes a potential memory leak > > > * Added error handling for malloc and strdup > > > * Fixed style violations > > > > > > v1 -> v2: > > > * Fix potential NULL pointer dereference in ofnode_write_property > > > * Squashed the enable/disable functions into one > > > * Renamed ofnode_set_property to ofnode_write_prop > > > > > > --- > > > drivers/core/ofnode.c | 70 > > > +++ > > > include/dm/ofnode.h | 46 + > > > 2 files changed, 116 insertions(+) > > > > Reviewed-by: Simon Glass > > This series seems to be a candidate for the u-boot-dm tree. > > I can assign it to you in Patchwork if you want. OK that's fine with me. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] efi patch queue 2018-09-26
On Wed, Sep 26, 2018 at 06:11:47PM +0200, Alexander Graf wrote: > Hi Tom, > > This is my current patch queue for efi. Please pull. > > Alex > > > The following changes since commit 9dc8d155d4e88563f572ee79aab758eb4272f3fd: > > Merge git://git.denx.de/u-boot-imx (2018-09-19 20:35:27 -0400) > > are available in the git repository at: > > git://github.com/agraf/u-boot.git tags/signed-efi-next > > for you to fetch changes up to eaac4fb296b1899369e49d941f2c0d346c7f5c7a: > > sandbox: Fix set_working_fdt_addr users (2018-09-26 15:03:12 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] MSCC: add support for VCoreIII SoCs
On 27/09/2018 12:14:14+0200, Gregory CLEMENT wrote:
> Hi Daniel,
>
> First thanks for you prompt review, it is much appreciate. :)
>
> This week I am at kernel recipes conference, so I won't be able to fully
> address your comments but I will do it next week.
>
> However, here are some answers:
>
> On mer., sept. 26 2018, Daniel Schwierzeck
> wrote:
>
> > Hi Gregory,
> >
> > On 25.09.2018 15:01, Gregory CLEMENT wrote:
> >> These families of SoCs are found in the Microsemi Switches solution.
> >>
> >> Currently the support for two families support is added:
> >> - Ocelot (VSC7513, VSC7514) already supported in Linux
> >> - Luton (Luton10: VSC7423, VSC7424, VSC7428 and Luton26: VSC7425,
> >>VSC7426, VSC7426, VSC7427, VSC7429)
> >
> > Is this some polished version of the original vendor U-Boot?
>
> No the original vendor version was RedBoot
>
> > Could you maybe add Ocelot and Luton in separate patches?
>
> Yes sure the intent to have a uniq patch was to justify the common code
> between both SoC.
>
> >
> >>
> >> Signed-off-by: Gregory CLEMENT
> >> ---
> [..]
>
> >> +endif
> >
> > from the code below I assume you have a MIPS24k core? If so you should
> > use the automatic cache size detection
>
> Yes it is a MIPS24k core. I will have a look on the automatic cache size
> detection.
>
> >
> >> +
> >> +menu "MSCC VCore-III platforms"
> >> + depends on ARCH_MSCC
> >> +
> >> +config SOC_VCOREIII
> >> + select SUPPORTS_LITTLE_ENDIAN
> >> + select SUPPORTS_BIG_ENDIAN
> >> + select SUPPORTS_CPU_MIPS32_R1
> >> + select SUPPORTS_CPU_MIPS32_R2
> >> + select ROM_EXCEPTION_VECTORS
> >> + select MIPS_TUNE_24KC
> >> + bool
> >
> > sort this alpahetically
>
> OK
>
> >
> >> +
> [...]
>
> >> +void vcoreiii_tlb_init(void)
> >> +{
> >> +register int tlbix = 0;
> >> +
> >> +init_tlb();
> >> +
> >> +/* 0x7000 size 32M (0x0200) */
> >> +create_tlb(tlbix++, MSCC_IO_ORIGIN1_OFFSET, SZ_16M, MMU_REGIO_RW,
> >> MMU_REGIO_RW);
> >> +#ifdef CONFIG_SOC_LUTON
> >> + create_tlb(tlbix++, MSCC_IO_ORIGIN2_OFFSET, SZ_16M, MMU_REGIO_RW,
> >> MMU_REGIO_RW);
> >> +#endif
> >> +/* 0x4000 - 0x43ff - NON-CACHED! */
> >> +/* Flash CS0-3, each 16M = 64M total (16 x 4 below ) */
> >> +create_tlb(tlbix++, MSCC_FLASH_TO,SZ_16M, MMU_REGIO_RO,
> >> MMU_REGIO_RO);
> >> +create_tlb(tlbix++, MSCC_FLASH_TO+SZ_32M, SZ_16M, MMU_REGIO_RO,
> >> MMU_REGIO_RO);
> >> +
> >> +/* 0x2000 - up */
> >> +#if CONFIG_SYS_SDRAM_SIZE <= SZ_64M
> >> +create_tlb(tlbix++, MSCC_DDR_TO,SZ_64M, MMU_REGIO_RW,
> >> MMU_REGIO_INVAL);
> >> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_128M
> >> +create_tlb(tlbix++, MSCC_DDR_TO,SZ_64M, MMU_REGIO_RW,
> >> MMU_REGIO_RW);
> >> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_256M
> >> +create_tlb(tlbix++, MSCC_DDR_TO, SZ_256M, MMU_REGIO_RW,
> >> MMU_REGIO_INVAL);
> >> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_512M
> >> +create_tlb(tlbix++, MSCC_DDR_TO, SZ_256M, MMU_REGIO_RW,
> >> MMU_REGIO_RW);
> >> +#else /* 1024M */
> >> +create_tlb(tlbix++, MSCC_DDR_TO, SZ_512M, MMU_REGIO_RW,
> >> MMU_REGIO_RW);
> >> +#endif
> >
> > can't you leave that to the kernel? U-Boot is only running in kernel
> > mode and doesn't need MMU mappings.
>
> You should be right, I will check it.
>
At least MSCC_IO_ORIGIN1_OFFSET is necessary to get earlyprintk working
because the SoC registers are not in kseg0.
> >> +int mach_cpu_init(void)
> >> +{
> >> +/* Speed up NOR flash access */
> >> +#ifdef CONFIG_SOC_LUTON
> >> +writel(ICPU_SPI_MST_CFG_FAST_READ_ENA +
> >> +#else
> >> + writel(
> >> +#endif
> >> + ICPU_SPI_MST_CFG_CS_DESELECT_TIME(0x19) +
> >> + ICPU_SPI_MST_CFG_CLK_DIV(9), REG_CFG(ICPU_SPI_MST_CFG));
> >> +
> >> +/* Disable all IRQs - map to destination map 0 */
> >> +writel(0, REG_CFG(ICPU_INTR_ENA));
> >> +#ifdef CONFIG_SOC_OCELOT
> >> +writel(~0, REG_CFG(ICPU_DST_INTR_MAP(0)));
> >> +writel(0, REG_CFG(ICPU_DST_INTR_MAP(1)));
> >> +writel(0, REG_CFG(ICPU_DST_INTR_MAP(2)));
> >> +writel(0, REG_CFG(ICPU_DST_INTR_MAP(3)));
> >> +#else
> >> + writel(ICPU_INTR_IRQ0_ENA_IRQ0_ENA, REG_CFG(ICPU_INTR_IRQ0_ENA));
> >> +#endif
> >
> > do you really need to disable interrupts after a cold or warm boot?
>
> I think it is needed, but I will check.
>
I would think this was done to avoid the spi driver crash. The interrupt
mapping should stay though.
>
> >> +static inline void init_tlb(void)
> >> +{
> >> +register int i, max;
> >> +
> >> +max = get_tlb_count();
> >> +for(i = 0; i < max; i++)
> >> +create_tlb(i, i * SZ_1M, SZ_4K, MMU_REGIO_INVAL, MMU_REGIO_INVAL);
> >> +}
> >
> > again can't you leave the setup of MMU mappings to the kernel?
>
> I will check again
>
No, we need those mappings for earlyprintk and SoC detection. They are
needed to boot legacy kernels.
[U-Boot] [PATCH] configs: drop CONFIG_SYS_EXTRA_ENV_RELOC
Instead of manually specifying CONFIG_SYS_EXTRA_ENV_RELOC for every board that needs it, it shouldn't hurt to let initr_reloc_global_data() always relocate gd->env_addr unless we know this pointer is outside the initial binary. To achieve this, the relocation is omitted if CONFIG_ENV_ADDR is defined (and ENV_IS_EMBEDDED is not). Signed-off-by: Simon Goldschmidt --- common/board_r.c| 11 --- include/configs/B4860QDS.h | 3 --- include/configs/BSC9131RDB.h| 2 -- include/configs/BSC9132QDS.h| 3 --- include/configs/C29XPCIE.h | 1 - include/configs/MPC8536DS.h | 1 - include/configs/P1010RDB.h | 1 - include/configs/P2041RDB.h | 3 --- include/configs/T102xQDS.h | 3 --- include/configs/T102xRDB.h | 3 --- include/configs/T1040QDS.h | 3 --- include/configs/T104xRDB.h | 3 --- include/configs/T208xQDS.h | 3 --- include/configs/T208xRDB.h | 3 --- include/configs/T4240QDS.h | 3 --- include/configs/T4240RDB.h | 3 --- include/configs/UCP1020.h | 2 -- include/configs/controlcenterd.h| 2 -- include/configs/corenet_ds.h| 3 --- include/configs/cyrus.h | 1 - include/configs/km/kmp204x-common.h | 1 - include/configs/p1_twr.h| 1 - scripts/config_whitelist.txt| 1 - 23 files changed, 4 insertions(+), 56 deletions(-) diff --git a/common/board_r.c b/common/board_r.c index 9402c0ef21..c55e33eec2 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -140,15 +140,12 @@ static int initr_reloc_global_data(void) */ fixup_cpu(); #endif -#ifdef CONFIG_SYS_EXTRA_ENV_RELOC +#if !defined(CONFIG_ENV_ADDR) || defined(ENV_IS_EMBEDDED) /* -* Some systems need to relocate the env_addr pointer early because the -* location it points to will get invalidated before env_relocate is -* called. One example is on systems that might use a L2 or L3 cache -* in SRAM mode and initialize that cache from SRAM mode back to being -* a cache in cpu_init_r. +* Relocate the early env_addr pointer unless we know it is not inside +* the binary. Some systems need this and for the rest, it doesn't hurt. */ - gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE; + gd->env_addr += gd->reloc_off; #endif #ifdef CONFIG_OF_EMBED /* diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index c37864c139..d086bd71f8 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -106,7 +106,6 @@ #endif #if defined(CONFIG_SPIFLASH) -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_ENV_SPI_BUS 0 #define CONFIG_ENV_SPI_CS 0 #define CONFIG_ENV_SPI_MAX_HZ 1000 @@ -115,12 +114,10 @@ #define CONFIG_ENV_OFFSET 0x10/* 1MB */ #define CONFIG_ENV_SECT_SIZE0x1 #elif defined(CONFIG_SDCARD) -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_ENV_SIZE0x2000 #define CONFIG_ENV_OFFSET (512 * 1097) #elif defined(CONFIG_NAND) -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_ENV_SIZE0x2000 #define CONFIG_ENV_OFFSET (10 * CONFIG_SYS_NAND_BLOCK_SIZE) #elif defined(CONFIG_SRIO_PCIE_BOOT_SLAVE) diff --git a/include/configs/BSC9131RDB.h b/include/configs/BSC9131RDB.h index e6cbcf86c6..71e840a4b8 100644 --- a/include/configs/BSC9131RDB.h +++ b/include/configs/BSC9131RDB.h @@ -15,7 +15,6 @@ #ifdef CONFIG_SPIFLASH #define CONFIG_RAMBOOT_SPIFLASH #define CONFIG_SYS_RAMBOOT -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_RESET_VECTOR_ADDRESS0x110bfffc #endif @@ -266,7 +265,6 @@ extern unsigned long get_sdram_size(void); #define CONFIG_ENV_SECT_SIZE 0x1 #define CONFIG_ENV_SIZE0x2000 #elif defined(CONFIG_NAND) -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_ENV_SIZECONFIG_SYS_NAND_BLOCK_SIZE #define CONFIG_ENV_OFFSET ((768 * 1024) + CONFIG_SYS_NAND_BLOCK_SIZE) #define CONFIG_ENV_RANGE (3 * CONFIG_ENV_SIZE) diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index 7687588044..fb076b1199 100644 --- a/include/configs/BSC9132QDS.h +++ b/include/configs/BSC9132QDS.h @@ -13,19 +13,16 @@ #ifdef CONFIG_SDCARD #define CONFIG_RAMBOOT_SDCARD #define CONFIG_SYS_RAMBOOT -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_RESET_VECTOR_ADDRESS0x110bfffc #endif #ifdef CONFIG_SPIFLASH #define CONFIG_RAMBOOT_SPIFLASH #define CONFIG_SYS_RAMBOOT -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_RESET_VECTOR_ADDRESS0x110bfffc #endif #ifdef CONFIG_NAND_SECBOOT #define CONFIG_RAMBOOT_NAND #define CONFIG_SYS_RAMBOOT -#define CONFIG_SYS_EXTRA_ENV_RELOC #define CONFIG_RESET_VECTOR_ADDRESS0x110bfffc
Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Add generic FPGA reconfig mailbox API for S10
On Thu, 2018-09-27 at 08:21 +0200, Marek Vasut wrote:
> On 09/27/2018 07:08 AM, Ang, Chee Hong wrote:
> >
> > On Wed, 2018-09-26 at 16:53 +0200, Marek Vasut wrote:
> > >
> > > On 09/26/2018 11:03 AM, chee.hong@intel.com wrote:
> > > >
> > > >
> > > > From: "Ang, Chee Hong"
> > > >
> > > > Add a generic mailbox API for FPGA reconfig status which can be
> > > > called by others. This new function accepts 2 different mailbox
> > > > commands: CONFIG_STATUS or RECONFIG_STATUS.
> > > What "others" can call this ?
> > This is a common function used to check the readiness of the FPGA.
> > FPGA configuration drivers will need to call this to make sure
> > the FPGA configuration is successfully completed and running.
> > These FPGA configuration drivers will be submitted soon after this
> > patch.
> So this should be in drivers/fpga/ ?
Yes. There is a FPGA configuration driver under this folder. Will
submit soon.
>
> Also, don't add dead code, just submit this alongside the user of
> this code.
The reason I try to get this common function upstream is because my
colleague is trying to upstream socfpga dwmac driver which also need to
call this function to check whether the soft Ip running on FPGA for the
dwmac driver is up and running. If I bundle this code alongside with my
FPGA configuration driver, it might take longer time to get into the
mainline. So this common function is blocking other to upstream his/her
code.
>
> >
> > >
> > > >
> > > > Signed-off-by: Ang, Chee Hong
> > > > ---
> > > > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 3 +-
> > > > arch/arm/mach-socfpga/mailbox_s10.c | 48
> > > >
> > > > 2 files changed, 50 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > index 81a609d..660df35 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > @@ -140,5 +140,6 @@ int mbox_qspi_open(void);
> > > > #endif
> > > >
> > > > int mbox_reset_cold(void);
> > > > -
> > > > +int mbox_get_fpga_config_status(u32 cmd);
> > > > +int mbox_get_fpga_config_status_psci(u32 cmd);
> > > > #endif /* _MAILBOX_S10_H_ */
> > > > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
> > > > b/arch/arm/mach-
> > > > socfpga/mailbox_s10.c
> > > > index 0d906c3..345485c 100644
> > > > --- a/arch/arm/mach-socfpga/mailbox_s10.c
> > > > +++ b/arch/arm/mach-socfpga/mailbox_s10.c
> > > > @@ -342,6 +342,54 @@ int mbox_reset_cold(void)
> > > > return 0;
> > > > }
> > > >
> > > > +/* Accepted commands: CONFIG_STATUS or RECONFIG_STATUS */
> > > > +static __always_inline int
> > > > mbox_get_fpga_config_status_common(u32
> > > > cmd)
> > > Why __always_inline ?
> > This function is needed in 2 sections. Our u-boot run in normal
> > code
> > section and '__secure' section which mainly used for PSCI services.
> > Refer to the 'mbox_get_fpga_config_status()' and
> > 'mbox_get_fpga_config_status_psci()' below. These 2 functions run
> > in 2
> > different sections and they need to call this function.
> But why does this need to be __always_inline ? The compiler can
> decide
> what's best.
This is dangerous. Let me explain in more details why we need this,
'__secure' section and normal '.code' section exist in different time.
'.code' section no longer valid once u-boot boot to OS, but '__secure'
section still exist after booting to OS because OS need to call PSCI
services to achieve certain things. We need to make sure both sections
contain the full code, therefore we need to enforce the compiler to
duplicate this piece of code to both sections as well.
>
> >
> > >
> > > >
> > > >
> > > > +{
> > > > + u32 reconfig_status_resp_len;
> > > > + u32
> > > > reconfig_status_resp[RECONFIG_STATUS_RESPONSE_LEN];
> > > > + int ret;
> > > > +
> > > > + reconfig_status_resp_len =
> > > > RECONFIG_STATUS_RESPONSE_LEN;
> > > > + ret = mbox_send_cmd_common(MBOX_ID_UBOOT, cmd,
> > > > + MBOX_CMD_DIRECT, 0, NULL,
> > > > 0,
> > > > + _status_resp_len,
> > > > + reconfig_status_resp);
> > > > + if (!ret) {
> > > if (ret)
> > > return ret;
> > Will be addressed in v2 patch.
> > >
> > >
> > > ...
> > >
> > > >
> > > >
> > > > + /* Check for any error */
> > > > + ret =
> > > > reconfig_status_resp[RECONFIG_STATUS_STATE];
> > > > + if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
> > > > + return ret;
> > > > +
> > > > + /* Make sure nStatus is not 0 */
> > > > + ret =
> > > > reconfig_status_resp[RECONFIG_STATUS_PIN_STATUS];
> > > > + if (!(ret & RCF_PIN_STATUS_NSTATUS))
> > > > + return
> > > >
Re: [U-Boot] [PATCH RESEND] u-boot: fixup the iommu-map property of fsl-mc node
> -Original Message- > From: York Sun > Sent: Wednesday, September 26, 2018 11:24 PM > To: Nipun Gupta ; u-boot@lists.denx.de > Cc: albert.u.b...@aribaud.net; Prabhakar Kushwaha > ; Ashish Kumar ; > Priyanka Jain ; joe.hershber...@ni.com; Alison > Wang ; shaohui@nxp.com > Subject: Re: [PATCH RESEND] u-boot: fixup the iommu-map property of fsl- > mc node > > On 09/25/2018 02:23 AM, Nipun Gupta wrote: > > The iommu-map property in the fsl-mc node is updated by > > valid stream-ids by u-boot. This patch is to fixup this > > property for LS208x and LS1088. > > > > Signed-off-by: Nipun Gupta > > --- > > This patch fixes iommu-map property added for fsl-mc in kernel patch > > series: https://patchwork.kernel.org/patch/10594185/ > > Kernel patch series is accepted and would be available in kernel 4.20. > > > > This patch is backward compatible and have only a debug log if the property > > is not found in kernel. > > Why did you send it again? This one > http://patchwork.ozlabs.org/patch/959615/ is already under review. > Please check patchwork before you do this next time. I'll take of this next time :) Thanks, Nipun > > York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Add generic FPGA reconfig mailbox API for S10
On Wed, 2018-09-26 at 16:53 +0200, Marek Vasut wrote:
> On 09/26/2018 11:03 AM, chee.hong@intel.com wrote:
> >
> > From: "Ang, Chee Hong"
> >
> > Add a generic mailbox API for FPGA reconfig status which can be
> > called by others. This new function accepts 2 different mailbox
> > commands: CONFIG_STATUS or RECONFIG_STATUS.
> What "others" can call this ?
This is a common function used to check the readiness of the FPGA.
FPGA configuration drivers will need to call this to make sure
the FPGA configuration is successfully completed and running.
These FPGA configuration drivers will be submitted soon after this
patch.
>
> >
> > Signed-off-by: Ang, Chee Hong
> > ---
> > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 3 +-
> > arch/arm/mach-socfpga/mailbox_s10.c | 48
> >
> > 2 files changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > index 81a609d..660df35 100644
> > --- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > @@ -140,5 +140,6 @@ int mbox_qspi_open(void);
> > #endif
> >
> > int mbox_reset_cold(void);
> > -
> > +int mbox_get_fpga_config_status(u32 cmd);
> > +int mbox_get_fpga_config_status_psci(u32 cmd);
> > #endif /* _MAILBOX_S10_H_ */
> > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c b/arch/arm/mach-
> > socfpga/mailbox_s10.c
> > index 0d906c3..345485c 100644
> > --- a/arch/arm/mach-socfpga/mailbox_s10.c
> > +++ b/arch/arm/mach-socfpga/mailbox_s10.c
> > @@ -342,6 +342,54 @@ int mbox_reset_cold(void)
> > return 0;
> > }
> >
> > +/* Accepted commands: CONFIG_STATUS or RECONFIG_STATUS */
> > +static __always_inline int mbox_get_fpga_config_status_common(u32
> > cmd)
> Why __always_inline ?
This function is needed in 2 sections. Our u-boot run in normal code
section and '__secure' section which mainly used for PSCI services.
Refer to the 'mbox_get_fpga_config_status()' and
'mbox_get_fpga_config_status_psci()' below. These 2 functions run in 2
different sections and they need to call this function.
>
> >
> > +{
> > + u32 reconfig_status_resp_len;
> > + u32 reconfig_status_resp[RECONFIG_STATUS_RESPONSE_LEN];
> > + int ret;
> > +
> > + reconfig_status_resp_len = RECONFIG_STATUS_RESPONSE_LEN;
> > + ret = mbox_send_cmd_common(MBOX_ID_UBOOT, cmd,
> > + MBOX_CMD_DIRECT, 0, NULL, 0,
> > + _status_resp_len,
> > + reconfig_status_resp);
> > + if (!ret) {
> if (ret)
> return ret;
Will be addressed in v2 patch.
>
> ...
>
> >
> > + /* Check for any error */
> > + ret = reconfig_status_resp[RECONFIG_STATUS_STATE];
> > + if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
> > + return ret;
> > +
> > + /* Make sure nStatus is not 0 */
> > + ret =
> > reconfig_status_resp[RECONFIG_STATUS_PIN_STATUS];
> > + if (!(ret & RCF_PIN_STATUS_NSTATUS))
> > + return MBOX_CFGSTAT_STATE_ERROR_HARDWARE;
> > +
> > + ret =
> > reconfig_status_resp[RECONFIG_STATUS_SOFTFUNC_STATUS];
> > + if (ret & RCF_SOFTFUNC_STATUS_SEU_ERROR)
> > + return MBOX_CFGSTAT_STATE_ERROR_HARDWARE;
> > +
> > + if ((ret & RCF_SOFTFUNC_STATUS_CONF_DONE) &&
> > + (ret & RCF_SOFTFUNC_STATUS_INIT_DONE) &&
> > + !reconfig_status_resp[RECONFIG_STATUS_STATE])
> > + return 0; /* configuration success
> > */
> > + else
> > + return MBOX_CFGSTAT_STATE_CONFIG;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +int mbox_get_fpga_config_status(u32 cmd)
> > +{
> > + return mbox_get_fpga_config_status_common(cmd);
> > +}
> > +
> > +int __secure mbox_get_fpga_config_status_psci(u32 cmd)
> > +{
> > + return mbox_get_fpga_config_status_common(cmd);
> > +}
> > +
> > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32
> > *arg,
> > u8 urgent, u32 *resp_buf_len, u32 *resp_buf)
> > {
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/22] spl: Add features for passing info from SPL to U-Boot proper
At present we have no standard way of passing information from SPL to U-Boot. Such information may be the size of DRAM banks or some information about the reset state of the machine,for example. This series first adds a bloblist, which allows a list of 'blobs' to be created, each with a tag so that subsystems can store data and retrieve it later. Then it adds the SPL 'handoff' information, which uses bloblist. Various minor sandbox enhancements are provided to make this easier, or to support testing. Simon Glass (22): log: Correct definition of log_msg_ret() spl: Add support for logging in SPL and TPL Add core support for a bloblist to convey data from SPL spl: Set up the bloblist in SPL bloblist: Locate bloblist in U-Boot test: Add a simple test for bloblist Add bloblist documentation spl: Support hash, input, pch, pci, rtc, tpm in SPL spl: Add a define for SPL_TPL_PROMPT spl: Make SPL_DISABLE_BANNER_PRINT a positive option spl: Add a comment to spl_set_bd() spl: Print a message if we are unable to load an image sandbox: Add a memory map to the sandbox README test/py: Add a way to pass flags to sandbox sandbox: Add an option to display of-platdata in SPL sandbox: Add a new 'sb' command sandbox: Allow puts() output before global_data is set up sandbox: Refactor code to create os_jump_to_file() sandbox: Use malloc() and free() from os layer sandbox: Filter arguments when starting U-Boot sandbox: Boot in U-Boot through the standard call spl: Add support for passing handoff info to U-Boot proper arch/Kconfig | 1 + arch/powerpc/include/asm/spl.h | 3 - arch/sandbox/cpu/eth-raw-os.c | 9 +- arch/sandbox/cpu/os.c | 115 +- arch/sandbox/cpu/spl.c | 31 +++- arch/sandbox/cpu/start.c | 19 +++ arch/sandbox/cpu/u-boot-spl.lds| 2 +- arch/sandbox/include/asm/handoff.h | 18 +++ arch/sandbox/include/asm/state.h | 8 + board/sandbox/README.sandbox | 14 +- cmd/Makefile | 1 + cmd/host.c | 5 - cmd/sb.c | 65 common/Kconfig | 84 +- common/Makefile| 5 +- common/bloblist.c | 239 + common/board_f.c | 47 ++ common/console.c | 7 + common/init/Makefile | 1 + common/init/handoff.c | 47 ++ common/spl/Kconfig | 95 +++- common/spl/spl.c | 142 + configs/sandbox_spl_defconfig | 1 + doc/README.bloblist| 82 ++ drivers/Makefile | 11 +- include/asm-generic/global_data.h | 7 + include/bloblist.h | 194 +++ include/handoff.h | 36 + include/log.h | 10 +- include/spl.h | 41 + include/test/suites.h | 1 + test/Makefile | 1 + test/bloblist.c| 187 ++ test/cmd_ut.c | 3 + test/py/tests/test_handoff.py | 14 ++ test/py/tests/test_ofplatdata.py | 31 +++- test/py/u_boot_console_base.py | 2 +- test/py/u_boot_console_sandbox.py | 18 ++- test/run | 2 +- 39 files changed, 1497 insertions(+), 102 deletions(-) create mode 100644 arch/sandbox/include/asm/handoff.h create mode 100644 cmd/sb.c create mode 100644 common/bloblist.c create mode 100644 common/init/handoff.c create mode 100644 doc/README.bloblist create mode 100644 include/bloblist.h create mode 100644 include/handoff.h create mode 100644 test/bloblist.c create mode 100644 test/py/tests/test_handoff.py -- 2.19.0.605.g01d371f741-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: zynq: Add support for DLC20 board
Xilinx DLC20 has I2C0 with EEPROM(1KB), UART1, GPIO, SD0 (EMMC 4GB),
USB0 device, ENET0, QSPI (16MB) and DDR(two of 256MB each).
Signed-off-by: Michal Simek
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/zynq-dlc20-rev1.0.dts | 98
board/xilinx/zynq/zynq-dlc20-rev1.0/ps7_init_gpl.c | 280 +
configs/zynq_dlc20_rev1_0_defconfig| 73 ++
4 files changed, 452 insertions(+)
create mode 100644 arch/arm/dts/zynq-dlc20-rev1.0.dts
create mode 100644 board/xilinx/zynq/zynq-dlc20-rev1.0/ps7_init_gpl.c
create mode 100644 configs/zynq_dlc20_rev1_0_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 44ebc50bfab1..a0374b76aea0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -134,6 +134,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-cse-nand.dtb \
zynq-cse-nor.dtb \
zynq-cse-qspi-single.dtb \
+ zynq-dlc20-rev1.0.dtb \
zynq-microzed.dtb \
zynq-minized.dtb \
zynq-picozed.dtb \
diff --git a/arch/arm/dts/zynq-dlc20-rev1.0.dts
b/arch/arm/dts/zynq-dlc20-rev1.0.dts
new file mode 100644
index ..37bdee3e9f1b
--- /dev/null
+++ b/arch/arm/dts/zynq-dlc20-rev1.0.dts
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ *
+ * Michal Simek
+ */
+/dts-v1/;
+#include "zynq-7000.dtsi"
+
+/ {
+ model = "Zynq DLC20 Rev1.0";
+ compatible = "xlnx,zynq-dlc20-rev1.0", "xlnx,zynq-dlc20",
+"xlnx,zynq-7000";
+
+ aliases {
+ ethernet0 =
+ i2c0 =
+ serial0 =
+ spi0 =
+ mmc0 =
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
+
+ chosen {
+ bootargs = "";
+ stdout-path = "serial0:115200n8";
+ };
+
+ usb_phy0: phy0@e0002000 {
+ compatible = "ulpi-phy";
+ #phy-cells = <0>;
+ reg = <0xe0002000 0x1000>;
+ view-port = <0x0170>;
+ drv-vbus;
+ };
+};
+
+ {
+ ps-clk-frequency = <>; /* U7 */
+};
+
+ {
+ status = "okay"; /* MIO16-MIO27, MDIO MIO52/53 */
+ phy-mode = "rgmii-id";
+ phy-handle = <_phy>;
+
+ ethernet_phy: ethernet-phy@7 { /* rtl8211e - U25 */
+ reg = <1>;
+ };
+};
+
+ {
+ status = "okay"; /* MIO14/15 */
+ clock-frequency = <40>;
+ /* U46 - m24c08 */
+ eeprom: eeprom@54 {
+ compatible = "atmel,24c08";
+ reg = <0x54>;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+ is-dual = <1>;
+ num-cs = <1>;
+ flash@0 {
+ compatible = "n25q128fw"; /* W25Q128FWSIG - 16MB */
+ reg = <0x0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <5000>;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay"; /* EMMC MTFC4GACAJCN - MIO40-MIO45 */
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay"; /* MIO8/9 */
+};
+
+ {
+ status = "okay"; /* MIO28-MIO39 */
+ dr_mode = "device";
+ usb-phy = <_phy0>;
+};
+
+ {
+ reset-on-timeout;
+};
diff --git a/board/xilinx/zynq/zynq-dlc20-rev1.0/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-dlc20-rev1.0/ps7_init_gpl.c
new file mode 100644
index ..5366956e5bfd
--- /dev/null
+++ b/board/xilinx/zynq/zynq-dlc20-rev1.0/ps7_init_gpl.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (c) Copyright 2010-2014 Xilinx, Inc. All rights reserved.
+ */
+
+#include
+
+static unsigned long ps7_pll_init_data_3_0[] = {
+ EMIT_WRITE(0xF808, 0xDF0DU),
+ EMIT_MASKWRITE(0xF8000110, 0x0030U, 0x000FA220U),
+ EMIT_MASKWRITE(0xF8000100, 0x0007F000U, 0x00028000U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000120, 0x1F003F30U, 0x1F000200U),
+ EMIT_MASKWRITE(0xF8000114, 0x0030U, 0x0012C220U),
+ EMIT_MASKWRITE(0xF8000104, 0x0007F000U, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000124, 0xFFF3U, 0x0C23U),
+ EMIT_MASKWRITE(0xF8000118, 0x0030U, 0x001452C0U),
+ EMIT_MASKWRITE(0xF8000108, 0x0007F000U, 0x0001E000U),
+ EMIT_MASKWRITE(0xF8000108, 0x0010U,
Re: [U-Boot] [PATCH v8 08/15] regmap: Add raw read/write functions
Hi Mario,
Am Do., 27. Sep. 2018 um 11:48 Uhr schrieb Mario Six :
>
> The regmap functions currently assume that all register map accesses
> have a data width of 32 bits, but there are maps that have different
> widths.
>
> To rectify this, implement the regmap_raw_read and regmap_raw_write
> functions from the Linux kernel API that specify the width of a desired
> read or write operation on a regmap.
>
> Implement the regmap_read and regmap_write functions using these raw
> functions in a backwards-compatible manner.
>
> Reviewed-by: Anatolij Gustschin
> Signed-off-by: Mario Six
>
> ---
>
> v7 -> v8:
> No changes
>
> v6 -> v7:
> * Fixed wrong variable type in 64-bit read (u32 -> u64)
> * Added 64-bit case in write function
>
> v5 -> v6:
> * Corrected format specifier
> * Added support for 64-bit reads/writes
>
> v4 -> v5:
> No changes
>
> v3 -> v4:
> * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> * Explained the difference between the raw and non-raw read/write
> functions better in the docs
>
> v2 -> v3:
> * Implement the "raw" functions from Linux instead of adding a size
> parameter to the regmap_{read,write} functions
> * Fixed style violation
> * Improved error handling
>
> v1 -> v2:
> New in v2
>
> ---
> drivers/core/regmap.c | 64
> +--
> include/regmap.h | 58 ++
> 2 files changed, 115 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 154426269d9..1025099797f 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -188,22 +188,72 @@ int regmap_uninit(struct regmap *map)
> return 0;
> }
>
> +int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t
> val_len)
> +{
> + void *ptr;
> +
> + ptr = map_physmem(map->ranges[0].start + offset, val_len,
> MAP_NOCACHE);
> +
> + switch (val_len) {
> + case REGMAP_SIZE_8:
> + *((u8 *)valp) = in_8((u8 *)ptr);
> + break;
> + case REGMAP_SIZE_16:
> + *((u16 *)valp) = in_le16((u16 *)ptr);
> + break;
> + case REGMAP_SIZE_32:
> + *((u32 *)valp) = in_le32((u32 *)ptr);
> + break;
> +#if defined(in_le64) && defined(readq)
> + case REGMAP_SIZE_64:
> + *((u64 *)valp) = in_le64((u64 *)ptr);
> + break;
> +#endif
> + default:
> + debug("%s: regmap size %zu unknown\n", __func__, val_len);
> + return -EINVAL;
> + }
> + return 0;
> +}
I'm still not convinced why you want to enforce Little Endian here.
This makes regmap unuseable on archs like MIPS or PowerPC.
Typically a SoC with a MIPS CPU core can have an AMBA bus or other LE
based sub-systems. Some SoCs can select the endianess of the CPU core
via pin strapping. Normally the endianess conversion is automatically
done in HW.
So I suggest to simply use readl or __raw_readl to support native
endianess as default. Later we could add a DT properties
"native-endian", "big-endian" and "little-endian" like in the Linux
implementation.
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT PULL] Xilinx changes for v2018.11
Hi Tom, please pull these changes to your tree. Travis build looks good. https://travis-ci.org/michalsimek/u-boot/builds/433924161 Both net patches are acked by Joe. Thanks, Michal The following changes since commit 284b27cf81da10d55070a49ee8b739f71377a4fb: Merge branch 'master' of git://git.denx.de/u-boot-mips (2018-09-23 15:14:12 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.11 for you to fetch changes up to 3888c8d1979289efe685fe29276aed4d4b685975: net: zynq_gem: Add support for fixed-link phy (2018-09-27 07:59:26 +0200) Xilinx changes for v2018.11 - Handle BOARD_LATE_INIT via Kconfig SPL: - Enable GZIP for all partitions types(not only for kernel) ZynqMP: - Rearrange pmufw version handling - Support newer PMUFW with improved fpga load sequence Zynq: - Cleanup config file - Simplify zybo config by enabling option via Kconfig net: - Fix gems max-speed property reading - Enable support for fixed-link phys Luis Araneda (1): arm: zynq: zybo: migrate CONFIG_DISPLAY to defconfig Michal Simek (4): arm64: zynqmp: Handle CONFIG_BOARD_LATE_INIT via Kconfig arm: zynq: Remove useless comments from config file spl: fit: Enable GZIP compression also for no kernel partitions net: zynq_gem: Add support for fixed-link phy Siva Durga Prasad Paladugu (4): arm64: zynqmp: Move PM version related macros to .h arm64: zynqmp: Return pmufw version for zynqmp_pmufw_version() fpga: zynqmp: Modify PL bitstream loading sequence net: zynq_gem: Fix reading of max-speed property arch/arm/Kconfig | 4 ++-- arch/arm/cpu/armv8/zynqmp/cpu.c | 40 +++- arch/arm/include/asm/arch-zynqmp/sys_proto.h | 17 - board/xilinx/zynqmp/zynqmp.c | 11 ++- common/Kconfig | 2 +- common/spl/spl_fit.c | 5 + configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 + configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 + configs/xilinx_zynqmp_mini_nand_defconfig| 1 + configs/xilinx_zynqmp_mini_qspi_defconfig| 1 + configs/zynq_cse_nand_defconfig | 1 + configs/zynq_cse_nor_defconfig | 1 + configs/zynq_cse_qspi_defconfig | 1 + configs/zynq_zybo_defconfig | 1 + drivers/fpga/zynqmppl.c | 35 +-- drivers/net/zynq_gem.c | 16 +--- include/configs/xilinx_zynqmp_mini.h | 1 - include/configs/zynq-common.h| 8 include/configs/zynq_cse.h | 1 - include/configs/zynq_zybo.h | 2 -- 20 files changed, 87 insertions(+), 63 deletions(-) -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 12/15] regmap: Add overview documentation
On Thu, Sep 27, 2018 at 5:48 PM Mario Six wrote: > > Add some overview documentation that explains the purpose and some of > the features and limitations of the regmap interface. > > Signed-off-by: Mario Six > > --- > > v7 -> v8: > New in v8 > > --- > include/regmap.h | 25 + > 1 file changed, 25 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] MSCC: add support for VCoreIII SoCs
Hi Daniel,
First thanks for you prompt review, it is much appreciate. :)
This week I am at kernel recipes conference, so I won't be able to fully
address your comments but I will do it next week.
However, here are some answers:
On mer., sept. 26 2018, Daniel Schwierzeck
wrote:
> Hi Gregory,
>
> On 25.09.2018 15:01, Gregory CLEMENT wrote:
>> These families of SoCs are found in the Microsemi Switches solution.
>>
>> Currently the support for two families support is added:
>> - Ocelot (VSC7513, VSC7514) already supported in Linux
>> - Luton (Luton10: VSC7423, VSC7424, VSC7428 and Luton26: VSC7425,
>>VSC7426, VSC7426, VSC7427, VSC7429)
>
> Is this some polished version of the original vendor U-Boot?
No the original vendor version was RedBoot
> Could you maybe add Ocelot and Luton in separate patches?
Yes sure the intent to have a uniq patch was to justify the common code
between both SoC.
>
>>
>> Signed-off-by: Gregory CLEMENT
>> ---
[..]
>> +endif
>
> from the code below I assume you have a MIPS24k core? If so you should
> use the automatic cache size detection
Yes it is a MIPS24k core. I will have a look on the automatic cache size
detection.
>
>> +
>> +menu "MSCC VCore-III platforms"
>> +depends on ARCH_MSCC
>> +
>> +config SOC_VCOREIII
>> +select SUPPORTS_LITTLE_ENDIAN
>> +select SUPPORTS_BIG_ENDIAN
>> +select SUPPORTS_CPU_MIPS32_R1
>> +select SUPPORTS_CPU_MIPS32_R2
>> +select ROM_EXCEPTION_VECTORS
>> +select MIPS_TUNE_24KC
>> +bool
>
> sort this alpahetically
OK
>
>> +
[...]
>> +void vcoreiii_tlb_init(void)
>> +{
>> +register int tlbix = 0;
>> +
>> +init_tlb();
>> +
>> +/* 0x7000 size 32M (0x0200) */
>> +create_tlb(tlbix++, MSCC_IO_ORIGIN1_OFFSET, SZ_16M, MMU_REGIO_RW,
>> MMU_REGIO_RW);
>> +#ifdef CONFIG_SOC_LUTON
>> +create_tlb(tlbix++, MSCC_IO_ORIGIN2_OFFSET, SZ_16M, MMU_REGIO_RW,
>> MMU_REGIO_RW);
>> +#endif
>> +/* 0x4000 - 0x43ff - NON-CACHED! */
>> +/* Flash CS0-3, each 16M = 64M total (16 x 4 below ) */
>> +create_tlb(tlbix++, MSCC_FLASH_TO,SZ_16M, MMU_REGIO_RO,
>> MMU_REGIO_RO);
>> +create_tlb(tlbix++, MSCC_FLASH_TO+SZ_32M, SZ_16M, MMU_REGIO_RO,
>> MMU_REGIO_RO);
>> +
>> +/* 0x2000 - up */
>> +#if CONFIG_SYS_SDRAM_SIZE <= SZ_64M
>> +create_tlb(tlbix++, MSCC_DDR_TO,SZ_64M, MMU_REGIO_RW,
>> MMU_REGIO_INVAL);
>> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_128M
>> +create_tlb(tlbix++, MSCC_DDR_TO,SZ_64M, MMU_REGIO_RW,
>> MMU_REGIO_RW);
>> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_256M
>> +create_tlb(tlbix++, MSCC_DDR_TO, SZ_256M, MMU_REGIO_RW,
>> MMU_REGIO_INVAL);
>> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_512M
>> +create_tlb(tlbix++, MSCC_DDR_TO, SZ_256M, MMU_REGIO_RW,
>> MMU_REGIO_RW);
>> +#else /* 1024M */
>> +create_tlb(tlbix++, MSCC_DDR_TO, SZ_512M, MMU_REGIO_RW,
>> MMU_REGIO_RW);
>> +#endif
>
> can't you leave that to the kernel? U-Boot is only running in kernel
> mode and doesn't need MMU mappings.
You should be right, I will check it.
>
>> +}
>> +
>> +int mach_cpu_init(void)
>> +{
>> +/* Speed up NOR flash access */
>> +#ifdef CONFIG_SOC_LUTON
>> +writel(ICPU_SPI_MST_CFG_FAST_READ_ENA +
>> +#else
>> +writel(
>> +#endif
>> + ICPU_SPI_MST_CFG_CS_DESELECT_TIME(0x19) +
>> + ICPU_SPI_MST_CFG_CLK_DIV(9), REG_CFG(ICPU_SPI_MST_CFG));
>> +
>> +/* Disable all IRQs - map to destination map 0 */
>> +writel(0, REG_CFG(ICPU_INTR_ENA));
>> +#ifdef CONFIG_SOC_OCELOT
>> +writel(~0, REG_CFG(ICPU_DST_INTR_MAP(0)));
>> +writel(0, REG_CFG(ICPU_DST_INTR_MAP(1)));
>> +writel(0, REG_CFG(ICPU_DST_INTR_MAP(2)));
>> +writel(0, REG_CFG(ICPU_DST_INTR_MAP(3)));
>> +#else
>> +writel(ICPU_INTR_IRQ0_ENA_IRQ0_ENA, REG_CFG(ICPU_INTR_IRQ0_ENA));
>> +#endif
>
> do you really need to disable interrupts after a cold or warm boot?
I think it is needed, but I will check.
>
>> +return 0;
>> +}
>> diff --git a/arch/mips/mach-mscc/dram.c b/arch/mips/mach-mscc/dram.c
>> new file mode 100644
>> index 00..2db9001fe9
>> --- /dev/null
>> +++ b/arch/mips/mach-mscc/dram.c
>> @@ -0,0 +1,62 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2018 Microsemi Corporation
>> + */
>> +
>> +#include
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +int vcoreiii_ddr_init(void)
>> +{
>> +int res;
>> +if (!(readl(REG_CFG(ICPU_MEMCTRL_STAT)) &
>> + ICPU_MEMCTRL_STAT_INIT_DONE)) {
>> +hal_vcoreiii_init_memctl();
>> +hal_vcoreiii_wait_memctl();
>> +if (hal_vcoreiii_init_dqs() != 0 ||
>> +hal_vcoreiii_train_bytelane(0) != 0
>> +#ifdef CONFIG_SOC_OCELOT
>> +|| hal_vcoreiii_train_bytelane(1) != 0
>> +#endif
>> +
[U-Boot] [PATCH v8 10/15] regmap: Define regmap_{get,set}
It would be convenient if one could use the regmap API in conjunction
with register maps defined as structs (i.e. structs that directly mirror
the memory layout of the registers in question). A similar approach was
planned with the regmap_write32/regmap_read32 macros, but was never
used.
Hence, implement regmap_set/regmap_range_set and
regmap_get/regmap_range_get macros, which, given a register map, a
struct describing the layout of the register map, and a member name
automatically produce regmap_read/regmap_write calls that access the
specified member in the register map.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
* Fixed style violations
* Added documentation
v1 -> v2:
New in v2
---
include/regmap.h | 54 ++
1 file changed, 50 insertions(+), 4 deletions(-)
diff --git a/include/regmap.h b/include/regmap.h
index 6c4b3426812..a8eb2b604d3 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -146,11 +146,57 @@ int regmap_raw_write_range(struct regmap *map, uint
range_num, uint offset,
int regmap_raw_read_range(struct regmap *map, uint range_num, uint offset,
void *valp, size_t val_len);
-#define regmap_write32(map, ptr, member, val) \
- regmap_write(map, (uint32_t *)(ptr)->member - (uint32_t *)(ptr), val)
+/**
+ * regmap_range_set() - Set a value in a regmap range described by a struct
+ * @map:Regmap in which a value should be set
+ * @range: Range of the regmap in which a value should be set
+ * @type: Structure type that describes the memory layout of the regmap range
+ * @member: Member of the describing structure that should be set in the regmap
+ * range
+ * @val:Value which should be written to the regmap range
+ */
+#define regmap_range_set(map, range, type, member, val) \
+ do { \
+ typeof(((type *)0)->member) __tmp = val; \
+ regmap_raw_write_range(map, range, offsetof(type, member), \
+ &__tmp, sizeof(((type *)0)->member)); \
+ } while (0)
+
+/**
+ * regmap_set() - Set a value in a regmap described by a struct
+ * @map:Regmap in which a value should be set
+ * @type: Structure type that describes the memory layout of the regmap
+ * @member: Member of the describing structure that should be set in the regmap
+ * @val:Value which should be written to the regmap
+ */
+#define regmap_set(map, type, member, val) \
+ regmap_range_set(map, 0, type, member, val)
-#define regmap_read32(map, ptr, member, valp) \
- regmap_read(map, (uint32_t *)(ptr)->member - (uint32_t *)(ptr), valp)
+/**
+ * regmap_range_get() - Get a value from a regmap range described by a struct
+ * @map:Regmap from which a value should be read
+ * @range: Range of the regmap from which a value should be read
+ * @type: Structure type that describes the memory layout of the regmap
+ * range
+ * @member: Member of the describing structure that should be read in the
+ * regmap range
+ * @valp: Variable that receives the value read from the regmap range
+ */
+#define regmap_range_get(map, range, type, member, valp) \
+ regmap_raw_read_range(map, range, offsetof(type, member), \
+ (void *)valp, sizeof(((type *)0)->member))
+
+/**
+ * regmap_get() - Get a value from a regmap described by a struct
+ * @map:Regmap from which a value should be read
+ * @type: Structure type that describes the memory layout of the regmap
+ * range
+ * @member: Member of the describing structure that should be read in the
+ * regmap
+ * @valp: Variable that receives the value read from the regmap
+ */
+#define regmap_get(map, type, member, valp) \
+ regmap_range_get(map, 0, type, member, valp)
/**
* regmap_update_bits() - Perform a read/modify/write using a mask
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 11/15] test: regmap: Add test for regmap_{set, get}
Add test for regmap_{set,get} functions.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
New in v3
---
test/dm/regmap.c | 28
1 file changed, 28 insertions(+)
diff --git a/test/dm/regmap.c b/test/dm/regmap.c
index b28d6a6cd11..a8d7e6829ec 100644
--- a/test/dm/regmap.c
+++ b/test/dm/regmap.c
@@ -116,3 +116,31 @@ static int dm_test_regmap_rw(struct unit_test_state *uts)
}
DM_TEST(dm_test_regmap_rw, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Get/Set test */
+static int dm_test_regmap_getset(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+ struct regmap *map;
+ uint reg;
+ struct layout {
+ u32 val0;
+ u32 val1;
+ u32 val2;
+ u32 val3;
+ };
+
+ ut_assertok(uclass_get_device(UCLASS_SYSCON, 0, ));
+ map = syscon_get_regmap(dev);
+ ut_assertok_ptr(map);
+
+ regmap_set(map, struct layout, val0, 0xcacafafa);
+ regmap_set(map, struct layout, val3, 0x55aa2211);
+
+ ut_assertok(regmap_get(map, struct layout, val0, ));
+ ut_assertok(regmap_get(map, struct layout, val3, ));
+
+ return 0;
+}
+
+DM_TEST(dm_test_regmap_getset, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 08/15] regmap: Add raw read/write functions
The regmap functions currently assume that all register map accesses
have a data width of 32 bits, but there are maps that have different
widths.
To rectify this, implement the regmap_raw_read and regmap_raw_write
functions from the Linux kernel API that specify the width of a desired
read or write operation on a regmap.
Implement the regmap_read and regmap_write functions using these raw
functions in a backwards-compatible manner.
Reviewed-by: Anatolij Gustschin
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
* Fixed wrong variable type in 64-bit read (u32 -> u64)
* Added 64-bit case in write function
v5 -> v6:
* Corrected format specifier
* Added support for 64-bit reads/writes
v4 -> v5:
No changes
v3 -> v4:
* Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
* Explained the difference between the raw and non-raw read/write
functions better in the docs
v2 -> v3:
* Implement the "raw" functions from Linux instead of adding a size
parameter to the regmap_{read,write} functions
* Fixed style violation
* Improved error handling
v1 -> v2:
New in v2
---
drivers/core/regmap.c | 64 +--
include/regmap.h | 58 ++
2 files changed, 115 insertions(+), 7 deletions(-)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 154426269d9..1025099797f 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -188,22 +188,72 @@ int regmap_uninit(struct regmap *map)
return 0;
}
+int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t
val_len)
+{
+ void *ptr;
+
+ ptr = map_physmem(map->ranges[0].start + offset, val_len, MAP_NOCACHE);
+
+ switch (val_len) {
+ case REGMAP_SIZE_8:
+ *((u8 *)valp) = in_8((u8 *)ptr);
+ break;
+ case REGMAP_SIZE_16:
+ *((u16 *)valp) = in_le16((u16 *)ptr);
+ break;
+ case REGMAP_SIZE_32:
+ *((u32 *)valp) = in_le32((u32 *)ptr);
+ break;
+#if defined(in_le64) && defined(readq)
+ case REGMAP_SIZE_64:
+ *((u64 *)valp) = in_le64((u64 *)ptr);
+ break;
+#endif
+ default:
+ debug("%s: regmap size %zu unknown\n", __func__, val_len);
+ return -EINVAL;
+ }
+ return 0;
+}
+
int regmap_read(struct regmap *map, uint offset, uint *valp)
{
- u32 *ptr = map_physmem(map->ranges[0].start + offset, 4, MAP_NOCACHE);
+ return regmap_raw_read(map, offset, valp, REGMAP_SIZE_32);
+}
- *valp = le32_to_cpu(readl(ptr));
+int regmap_raw_write(struct regmap *map, uint offset, const void *val,
+size_t val_len)
+{
+ void *ptr;
+
+ ptr = map_physmem(map->ranges[0].start + offset, val_len, MAP_NOCACHE);
+
+ switch (val_len) {
+ case REGMAP_SIZE_8:
+ out_8((u8 *)ptr, *((u8 *)val));
+ break;
+ case REGMAP_SIZE_16:
+ out_le16((u16 *)ptr, *((u16 *)val));
+ break;
+ case REGMAP_SIZE_32:
+ out_le32((u32 *)ptr, *((u32 *)val));
+ break;
+#if defined(out_le64) && defined(writeq)
+ case REGMAP_SIZE_64:
+ out_le64((u64 *)ptr, *((u64 *)val));
+ break;
+#endif
+ default:
+ debug("%s: regmap size %zu unknown\n", __func__, val_len);
+ return -EINVAL;
+ }
return 0;
}
int regmap_write(struct regmap *map, uint offset, uint val)
{
- u32 *ptr = map_physmem(map->ranges[0].start + offset, 4, MAP_NOCACHE);
-
- writel(cpu_to_le32(val), ptr);
-
- return 0;
+ return regmap_raw_write(map, offset, , REGMAP_SIZE_32);
}
int regmap_update_bits(struct regmap *map, uint offset, uint mask, uint val)
diff --git a/include/regmap.h b/include/regmap.h
index 32f75e06f59..8a9759281a5 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -8,6 +8,21 @@
#define __REGMAP_H
/**
+ * enum regmap_size_t - Access sizes for fpgamap reads and writes
+ *
+ * @REGMAP_SIZE_8: 8-bit read/write access size
+ * @REGMAP_SIZE_16: 16-bit read/write access size
+ * @REGMAP_SIZE_32: 32-bit read/write access size
+ * @REGMAP_SIZE_64: 64-bit read/write access size
+ */
+enum regmap_size_t {
+ REGMAP_SIZE_8 = 1,
+ REGMAP_SIZE_16 = 2,
+ REGMAP_SIZE_32 = 4,
+ REGMAP_SIZE_64 = 8,
+};
+
+/**
* struct regmap_range - a register map range
*
* @start: Start address
@@ -41,6 +56,10 @@ struct regmap {
* @offset:Offset in the regmap to write to
* @val: Data to write to the regmap at the specified offset
*
+ * Note that this function will only write values of 32 bit width to the
+ * regmap; if the size of data to be read is different, the regmap_raw_write
+ * function can be used.
+ *
* Return: 0 if OK, -ve on error
*/
int regmap_write(struct regmap *map, uint offset, uint val);
@@ -53,10 +72,49 @@ int
[U-Boot] [PATCH v8 01/15] test: regmap: Increase size of syscon0 memory
The upcoming changes to the regmap interface will contain a proper check
for plausibility when reading/writing from/to a register map. To still
have the current tests pass, increase the size of the memory region for
the syscon0 device, since one of the tests reads and writes beyond this
range.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
* Fix the test that checks the changed size
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
New in v3
---
arch/sandbox/dts/test.dts | 2 +-
test/dm/regmap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index b8524e3b7d6..bd5f6adf010 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -467,7 +467,7 @@
syscon@0 {
compatible = "sandbox,syscon0";
- reg = <0x10 4>;
+ reg = <0x10 16>;
};
syscon@1 {
diff --git a/test/dm/regmap.c b/test/dm/regmap.c
index d4b86b3b03c..b28d6a6cd11 100644
--- a/test/dm/regmap.c
+++ b/test/dm/regmap.c
@@ -25,7 +25,7 @@ static int dm_test_regmap_base(struct unit_test_state *uts)
ut_assertok_ptr(map);
ut_asserteq(1, map->range_count);
ut_asserteq(0x10, map->ranges[0].start);
- ut_asserteq(4, map->ranges[0].size);
+ ut_asserteq(16, map->ranges[0].size);
ut_asserteq(0x10, map_to_sysmem(regmap_get_range(map, 0)));
ut_assertok(uclass_get_device(UCLASS_SYSCON, 1, ));
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 12/15] regmap: Add overview documentation
Add some overview documentation that explains the purpose and some of the features and limitations of the regmap interface. Signed-off-by: Mario Six --- v7 -> v8: New in v8 --- include/regmap.h | 25 + 1 file changed, 25 insertions(+) diff --git a/include/regmap.h b/include/regmap.h index a8eb2b604d3..f27ce34a34a 100644 --- a/include/regmap.h +++ b/include/regmap.h @@ -8,6 +8,31 @@ #define __REGMAP_H /** + * DOC: Overview + * + * Regmaps are an abstraction mechanism that allows device drivers to access + * register maps irrespective of the underlying bus architecture. This entails + * that for devices that support multiple busses (e.g. I2C and SPI for a GPIO + * expander chip) only one driver has to be written. This driver will + * instantiate a regmap with a backend depending on the bus the device is + * attached to, and use the regmap API to access the register map through that + * bus transparently. + * + * Read and write functions are supplied, which can read/write data of + * arbitrary length from/to the regmap. + * + * The endianness of regmaps is currently limited to little-endian accesses. + * + * Furthermore, the register map described by a regmap can be split into + * multiple disjoint areas called ranges. In this way, register maps with + * "holes", i.e. areas of addressable memory that are not part of the register + * map, can be accessed in a concise manner. + * + * Currently, only a bare "mem" backend for regmaps is supported, which + * accesses the register map as regular IO-mapped memory. + */ + +/** * enum regmap_size_t - Access sizes for fpgamap reads and writes * * @REGMAP_SIZE_8: 8-bit read/write access size -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 14/15] misc: Add gdsys_soc driver
This patch adds a driver for the bus associated with a IHS FPGA.
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
* Fixed style violations
* Added bindings file
* Added more debug output in case of errors
* Switched all printfs to debug
* Documented the private data structure
* Formatted documentation as proper kernel-doc
* Expanded Kconfig description
v1 -> v2:
* Switched to correct uclass for IHS FPGA driver (now in MISC uclass)
---
.../devicetree/bindings/misc/gdsys,soc.txt | 16 +
drivers/misc/Kconfig | 8 +++
drivers/misc/Makefile | 1 +
drivers/misc/gdsys_soc.c | 74 ++
drivers/misc/gdsys_soc.h | 23 +++
5 files changed, 122 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/gdsys,soc.txt
create mode 100644 drivers/misc/gdsys_soc.c
create mode 100644 drivers/misc/gdsys_soc.h
diff --git a/Documentation/devicetree/bindings/misc/gdsys,soc.txt
b/Documentation/devicetree/bindings/misc/gdsys,soc.txt
new file mode 100644
index 000..278e935b166
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gdsys,soc.txt
@@ -0,0 +1,16 @@
+gdsys soc bus driver
+
+This driver provides a simple interface for the busses associated with gdsys
+IHS FPGAs. The bus itself contains devices whose register maps are contained
+within the FPGA's register space.
+
+Required properties:
+- fpga: A phandle to the controlling IHS FPGA
+
+Example:
+
+FPGA0BUS: fpga0bus {
+ compatible = "gdsys,soc";
+ ranges = <0x0 0xe060 0x4000>;
+ fpga = <>;
+};
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index bfa5c916874..4ae4e457c65 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -295,4 +295,12 @@ config MPC83XX_SERDES
help
Support for serdes found on MPC83xx SoCs.
+config GDSYS_SOC
+ bool "Enable gdsys SOC driver"
+ depends on MISC
+ help
+ Support for gdsys IHS SOC, a simple bus associated with each gdsys
+ IHS (Integrated Hardware Systems) FPGA, which holds all devices whose
+ register maps are contained within the FPGA's register map.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c4fff92f54e..13ec6a4d661 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o
obj-$(CONFIG_FSL_SEC_MON) += fsl_sec_mon.o
obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o
obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
+obj-$(CONFIG_GDSYS_SOC) += gdsys_soc.o
obj-$(CONFIG_$(SPL_)I2C_EEPROM) += i2c_eeprom.o
obj-$(CONFIG_LED_STATUS) += status_led.o
obj-$(CONFIG_LED_STATUS_GPIO) += gpio_led.o
diff --git a/drivers/misc/gdsys_soc.c b/drivers/misc/gdsys_soc.c
new file mode 100644
index 000..94a21e08af7
--- /dev/null
+++ b/drivers/misc/gdsys_soc.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2017
+ * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+ */
+
+#include
+#include
+#include
+
+#include "gdsys_soc.h"
+
+/**
+ * struct gdsys_soc_priv - Private data for gdsys soc bus
+ * @fpga: The gdsys IHS FPGA this bus is associated with
+ */
+struct gdsys_soc_priv {
+ struct udevice *fpga;
+};
+
+static const struct udevice_id gdsys_soc_ids[] = {
+ { .compatible = "gdsys,soc" },
+ { /* sentinel */ }
+};
+
+int gdsys_soc_get_fpga(struct udevice *child, struct udevice **fpga)
+{
+ struct gdsys_soc_priv *bus_priv;
+
+ if (!child->parent) {
+ debug("%s: Invalid parent\n", child->name);
+ return -EINVAL;
+ }
+
+ if (!device_is_compatible(child->parent, "gdsys,soc")) {
+ debug("%s: Not child of a gdsys soc\n", child->name);
+ return -EINVAL;
+ }
+
+ bus_priv = dev_get_priv(child->parent);
+
+ *fpga = bus_priv->fpga;
+
+ return 0;
+}
+
+static int gdsys_soc_probe(struct udevice *dev)
+{
+ struct gdsys_soc_priv *priv = dev_get_priv(dev);
+ struct udevice *fpga;
+ int res = uclass_get_device_by_phandle(UCLASS_MISC, dev, "fpga",
+ );
+ if (res == -ENOENT) {
+ debug("%s: Could not find 'fpga' phandle\n", dev->name);
+ return -EINVAL;
+ }
+
+ if (res == -ENODEV) {
+ debug("%s: Could not get FPGA device\n", dev->name);
+ return -EINVAL;
+ }
+
+ priv->fpga = fpga;
+
+ return 0;
+}
+
+U_BOOT_DRIVER(gdsys_soc_bus) = {
+ .name = "gdsys_soc_bus",
+ .id = UCLASS_SIMPLE_BUS,
+ .of_match = gdsys_soc_ids,
+ .probe = gdsys_soc_probe,
+ .priv_auto_alloc_size = sizeof(struct
[U-Boot] [PATCH v8 09/15] regmap: Support reading from specific range
It is useful to be able to treat the different ranges of a regmap
separately to be able to use distinct offset for them, but this is
currently not implemented in the regmap API.
To preserve backwards compatibility, add regmap_read_range and
regmap_write_range functions that take an additional parameter
'range_num' that identifies the range to operate on.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
* Renamed the functions to regmap_{write,read}_range
* Added function comments
* Fixed style violations
* Improved error handling
v1 -> v2:
New in v2
---
drivers/core/regmap.c | 49 -
include/regmap.h | 31 +++
2 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 1025099797f..761dc535ed8 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -188,11 +188,25 @@ int regmap_uninit(struct regmap *map)
return 0;
}
-int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t
val_len)
+int regmap_raw_read_range(struct regmap *map, uint range_num, uint offset,
+ void *valp, size_t val_len)
{
+ struct regmap_range *range;
void *ptr;
- ptr = map_physmem(map->ranges[0].start + offset, val_len, MAP_NOCACHE);
+ if (range_num >= map->range_count) {
+ debug("%s: range index %d larger than range count\n",
+ __func__, range_num);
+ return -ERANGE;
+ }
+ range = >ranges[range_num];
+
+ ptr = map_physmem(range->start + offset, val_len, MAP_NOCACHE);
+
+ if (offset + val_len > range->size) {
+ debug("%s: offset/size combination invalid\n", __func__);
+ return -ERANGE;
+ }
switch (val_len) {
case REGMAP_SIZE_8:
@@ -213,20 +227,39 @@ int regmap_raw_read(struct regmap *map, uint offset, void
*valp, size_t val_len)
debug("%s: regmap size %zu unknown\n", __func__, val_len);
return -EINVAL;
}
+
return 0;
}
+int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t
val_len)
+{
+ return regmap_raw_read_range(map, 0, offset, valp, val_len);
+}
+
int regmap_read(struct regmap *map, uint offset, uint *valp)
{
return regmap_raw_read(map, offset, valp, REGMAP_SIZE_32);
}
-int regmap_raw_write(struct regmap *map, uint offset, const void *val,
-size_t val_len)
+int regmap_raw_write_range(struct regmap *map, uint range_num, uint offset,
+ const void *val, size_t val_len)
{
+ struct regmap_range *range;
void *ptr;
- ptr = map_physmem(map->ranges[0].start + offset, val_len, MAP_NOCACHE);
+ if (range_num >= map->range_count) {
+ debug("%s: range index %d larger than range count\n",
+ __func__, range_num);
+ return -ERANGE;
+ }
+ range = >ranges[range_num];
+
+ ptr = map_physmem(range->start + offset, val_len, MAP_NOCACHE);
+
+ if (offset + val_len > range->size) {
+ debug("%s: offset/size combination invalid\n", __func__);
+ return -ERANGE;
+ }
switch (val_len) {
case REGMAP_SIZE_8:
@@ -251,6 +284,12 @@ int regmap_raw_write(struct regmap *map, uint offset,
const void *val,
return 0;
}
+int regmap_raw_write(struct regmap *map, uint offset, const void *val,
+size_t val_len)
+{
+ return regmap_raw_write_range(map, 0, offset, val, val_len);
+}
+
int regmap_write(struct regmap *map, uint offset, uint val)
{
return regmap_raw_write(map, offset, , REGMAP_SIZE_32);
diff --git a/include/regmap.h b/include/regmap.h
index 8a9759281a5..6c4b3426812 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -115,6 +115,37 @@ int regmap_raw_write(struct regmap *map, uint offset,
const void *val,
int regmap_raw_read(struct regmap *map, uint offset, void *valp,
size_t val_len);
+/**
+ * regmap_raw_write_range() - Write a value of specified length to a range of a
+ * regmap
+ *
+ * @map: Regmap to write to
+ * @range_num: Number of the range in the regmap to write to
+ * @offset:Offset in the regmap to write to
+ * @val: Value to write to the regmap at the specified offset
+ * @val_len: Length of the data to be written to the regmap
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int regmap_raw_write_range(struct regmap *map, uint range_num, uint offset,
+ const void *val, size_t val_len);
+
+/**
+ * regmap_raw_read_range() - Read a value of specified length from a range of a
+ * regmap
+ *
+ * @map: Regmap to read
[U-Boot] [PATCH v8 15/15] misc: Add IHS FPGA driver
Add a driver for gdsys IHS (Integrated Hardware Systems) FPGAs, which
supports initialization of the FPGA, as well as information gathering.
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
* Switched from 'res' as the name for return variables to 'ret'
v2 -> v3:
* Fixed style violations
* Added full documentation
* Extracted some magic numbers to constants
* Removed unnecessary includes
* Extracted wait_for_fpga_done
* Improved error handling and reporting
* Added device-tree-binding files
* Improved Kconfig entry
v1 -> v2:
New in v2
---
.../devicetree/bindings/misc/gdsys,iocon_fpga.txt | 19 +
.../devicetree/bindings/misc/gdsys,iocpu_fpga.txt | 19 +
drivers/misc/Kconfig | 9 +
drivers/misc/Makefile | 1 +
drivers/misc/ihs_fpga.c| 867 +
drivers/misc/ihs_fpga.h| 49 ++
6 files changed, 964 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/gdsys,iocon_fpga.txt
create mode 100644 Documentation/devicetree/bindings/misc/gdsys,iocpu_fpga.txt
create mode 100644 drivers/misc/ihs_fpga.c
create mode 100644 drivers/misc/ihs_fpga.h
diff --git a/Documentation/devicetree/bindings/misc/gdsys,iocon_fpga.txt
b/Documentation/devicetree/bindings/misc/gdsys,iocon_fpga.txt
new file mode 100644
index 000..acd466fdc6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gdsys,iocon_fpga.txt
@@ -0,0 +1,19 @@
+gdsys IHS FPGA for CON devices
+
+The gdsys IHS FPGA is the main FPGA on gdsys CON devices. This driver provides
+support for enabling and starting the FPGA, as well as verifying working bus
+communication.
+
+Required properties:
+- compatible: must be "gdsys,iocon_fpga"
+- reset-gpios: List of GPIOs controlling the FPGA's reset
+- done-gpios: List of GPIOs notifying whether the FPGA's reconfiguration is
+ done
+
+Example:
+
+FPGA0 {
+ compatible = "gdsys,iocon_fpga";
+ reset-gpios = < 26 0>;
+ done-gpios = <_VB0 19 0>;
+};
diff --git a/Documentation/devicetree/bindings/misc/gdsys,iocpu_fpga.txt
b/Documentation/devicetree/bindings/misc/gdsys,iocpu_fpga.txt
new file mode 100644
index 000..819db22bf7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gdsys,iocpu_fpga.txt
@@ -0,0 +1,19 @@
+gdsys IHS FPGA for CPU devices
+
+The gdsys IHS FPGA is the main FPGA on gdsys CPU devices. This driver provides
+support for enabling and starting the FPGA, as well as verifying working bus
+communication.
+
+Required properties:
+- compatible: must be "gdsys,iocpu_fpga"
+- reset-gpios: List of GPIOs controlling the FPGA's reset
+- done-gpios: List of GPIOs notifying whether the FPGA's reconfiguration is
+ done
+
+Example:
+
+FPGA0 {
+ compatible = "gdsys,iocpu_fpga";
+ reset-gpios = < 26 0>;
+ done-gpios = <_VB0 19 0>;
+};
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 4ae4e457c65..8530849df82 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -303,4 +303,13 @@ config GDSYS_SOC
IHS (Integrated Hardware Systems) FPGA, which holds all devices whose
register maps are contained within the FPGA's register map.
+config IHS_FPGA
+ bool "Enable IHS FPGA driver"
+ depends on MISC
+ help
+ Support IHS (Integrated Hardware Systems) FPGA, the main FPGAs on
+ gdsys devices, which supply the majority of the functionality offered
+ by the devices. This driver supports both CON and CPU variants of the
+ devices, depending on the device tree entry.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 13ec6a4d661..a4b6587a7c6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o
obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
obj-$(CONFIG_GDSYS_SOC) += gdsys_soc.o
obj-$(CONFIG_$(SPL_)I2C_EEPROM) += i2c_eeprom.o
+obj-$(CONFIG_IHS_FPGA) += ihs_fpga.o
obj-$(CONFIG_LED_STATUS) += status_led.o
obj-$(CONFIG_LED_STATUS_GPIO) += gpio_led.o
obj-$(CONFIG_MPC83XX_SERDES) += mpc83xx_serdes.o
diff --git a/drivers/misc/ihs_fpga.c b/drivers/misc/ihs_fpga.c
new file mode 100644
index 000..f9e4b27a270
--- /dev/null
+++ b/drivers/misc/ihs_fpga.c
@@ -0,0 +1,867 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2017
+ * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * based on the ioep-fpga driver, which is
+ *
+ * (C) Copyright 2014
+ * Dirk Eibach, Guntermann & Drunck GmbH, eib...@gdsys.de
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ihs_fpga.h"
+
+/**
+ * struct ihs_fpga_priv - Private data structure for IHS FPGA driver
+ * @map:Register map for the FPGA's own register space
+ * @reset_gpio: GPIO to start FPGA reconfiguration
+ *
[U-Boot] [PATCH v8 13/15] misc: Sort Makefile entries
Makefile entries should be sorted. Reviewed-by: Anatolij Gustschin Reviewed-by: Simon Glass Signed-off-by: Mario Six Signed-off-by: Anatolij Gustschin --- v7 -> v8: No changes v6 -> v7: No changes v5 -> v6: No changes v4 -> v5: Drop re-ordered entries that are not in mainline (e.g. CONFIG_GDSYS_IOEP, CONFIG_MPC83XX_SERDES, misc_sandbox.o) v3 -> v4: No changes v2 -> v3: New in v3 --- drivers/misc/Makefile | 56 +-- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index da4666fdfcb..c4fff92f54e 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -4,11 +4,6 @@ # Wolfgang Denk, DENX Software Engineering, w...@denx.de. obj-$(CONFIG_MISC) += misc-uclass.o -obj-$(CONFIG_ALI152X) += ali512x.o -obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o -obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o -obj-$(CONFIG_DS4510) += ds4510.o -obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o ifndef CONFIG_SPL_BUILD obj-$(CONFIG_CROS_EC) += cros_ec.o obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o @@ -16,43 +11,48 @@ obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o obj-$(CONFIG_CROS_EC_SANDBOX) += cros_ec_sandbox.o obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o endif -obj-$(CONFIG_FSL_IIM) += fsl_iim.o -obj-$(CONFIG_LED_STATUS_GPIO) += gpio_led.o -obj-$(CONFIG_$(SPL_)I2C_EEPROM) += i2c_eeprom.o -obj-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o -obj-$(CONFIG_MXC_OCOTP) += mxc_ocotp.o -obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o -obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o -obj-$(CONFIG_NS87308) += ns87308.o -obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o ifdef CONFIG_DM_I2C ifndef CONFIG_SPL_BUILD obj-$(CONFIG_SANDBOX) += i2c_eeprom_emul.o endif endif -obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o -obj-$(CONFIG_SMSC_SIO1007) += smsc_sio1007.o -obj-$(CONFIG_LED_STATUS) += status_led.o -obj-$(CONFIG_SANDBOX) += swap_case.o ifdef CONFIG_SPL_OF_PLATDATA ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SANDBOX) += spltest_sandbox.o endif endif -obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o -obj-$(CONFIG_TEGRA_CAR) += tegra_car.o -obj-$(CONFIG_TEGRA186_BPMP) += tegra186_bpmp.o -obj-$(CONFIG_TWL4030_LED) += twl4030_led.o +obj-$(CONFIG_ALI152X) += ali512x.o +obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o +obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o +obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o +obj-$(CONFIG_DS4510) += ds4510.o +obj-$(CONFIG_FSL_DEVICE_DISABLE) += fsl_devdis.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o +obj-$(CONFIG_FSL_IIM) += fsl_iim.o +obj-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o obj-$(CONFIG_FSL_SEC_MON) += fsl_sec_mon.o +obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o +obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o +obj-$(CONFIG_$(SPL_)I2C_EEPROM) += i2c_eeprom.o +obj-$(CONFIG_LED_STATUS) += status_led.o +obj-$(CONFIG_LED_STATUS_GPIO) += gpio_led.o +obj-$(CONFIG_MPC83XX_SERDES) += mpc83xx_serdes.o +obj-$(CONFIG_MXC_OCOTP) += mxc_ocotp.o +obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o +obj-$(CONFIG_NS87308) += ns87308.o +obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o obj-$(CONFIG_PCA9551_LED) += pca9551_led.o -obj-$(CONFIG_FSL_DEVICE_DISABLE) += fsl_devdis.o -obj-$(CONFIG_WINBOND_W83627) += winbond_w83627.o +obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o obj-$(CONFIG_QFW) += qfw.o obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o -obj-$(CONFIG_STM32_RCC) += stm32_rcc.o +obj-$(CONFIG_SANDBOX) += swap_case.o +obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o +obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o +obj-$(CONFIG_SMSC_SIO1007) += smsc_sio1007.o obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o +obj-$(CONFIG_STM32_RCC) += stm32_rcc.o obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o -obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o -obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o -obj-$(CONFIG_MPC83XX_SERDES) += mpc83xx_serdes.o +obj-$(CONFIG_TEGRA186_BPMP) += tegra186_bpmp.o +obj-$(CONFIG_TEGRA_CAR) += tegra_car.o +obj-$(CONFIG_TWL4030_LED) += twl4030_led.o +obj-$(CONFIG_WINBOND_W83627) += winbond_w83627.o -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 03/15] regmap: Add documentation
Document the regmap_alloc() function.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
New in v3
---
drivers/core/regmap.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 8e5c3bcf61b..77f6f520a06 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -17,6 +17,12 @@
DECLARE_GLOBAL_DATA_PTR;
+/**
+ * regmap_alloc() - Allocate a regmap with a given number of ranges.
+ *
+ * @count: Number of ranges to be allocated for the regmap.
+ * Return: A pointer to the newly allocated regmap, or NULL on error.
+ */
static struct regmap *regmap_alloc(int count)
{
struct regmap *map;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 07/15] mips: Implement {in, out}_{le, be}_{16, 32, 64} and {in, out}_8
MIPS is the only architecture currently supported by U-Boot that does not implement any of the in/out register access functions. To have a interface that is useable across architectures, add the functions to the MIPS architecture (implemented using the __raw_write and __raw_read functions). Signed-off-by: Mario Six --- v7 -> v8: No changes v6 -> v7: No changes v5 -> v6: New in v6 --- arch/mips/include/asm/io.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h index 957442effd2..7c40e415c74 100644 --- a/arch/mips/include/asm/io.h +++ b/arch/mips/include/asm/io.h @@ -547,6 +547,28 @@ __BUILD_CLRSETBITS(bwlq, sfx, end, type) #define __to_cpu(v)(v) #define cpu_to__(v)(v) +#define out_arch(type, endian, a, v) __raw_write##type(cpu_to_##endian(v),a) +#define in_arch(type, endian, a) endian##_to_cpu(__raw_read##type(a)) + +#define out_le64(a, v) out_arch(q, le64, a, v) +#define out_le32(a, v) out_arch(l, le32, a, v) +#define out_le16(a, v) out_arch(w, le16, a, v) + +#define in_le64(a) in_arch(q, le64, a) +#define in_le32(a) in_arch(l, le32, a) +#define in_le16(a) in_arch(w, le16, a) + +#define out_be64(a, v) out_arch(q, be64, a, v) +#define out_be32(a, v) out_arch(l, be32, a, v) +#define out_be16(a, v) out_arch(w, be16, a, v) + +#define in_be64(a) in_arch(q, be64, a) +#define in_be32(a) in_arch(l, be32, a) +#define in_be16(a) in_arch(w, be16, a) + +#define out_8(a, v)__raw_writeb(v, a) +#define in_8(a)__raw_readb(a) + BUILD_CLRSETBITS(b, 8, _, u8) BUILD_CLRSETBITS(w, le16, le16, u16) BUILD_CLRSETBITS(w, be16, be16, u16) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 02/15] regmap: Fix documentation
The documentation in regmap.h is not in kernel-doc format. Correct this.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
New in v3
---
include/regmap.h | 48 +++-
1 file changed, 39 insertions(+), 9 deletions(-)
diff --git a/include/regmap.h b/include/regmap.h
index 6a574eaa412..32f75e06f59 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -21,8 +21,8 @@ struct regmap_range {
/**
* struct regmap - a way of accessing hardware/bus registers
*
- * @range_count: Number of ranges available within the map
- * @ranges:Array of ranges
+ * @range_count: Number of ranges available within the map
+ * @ranges:Array of ranges
*/
struct regmap {
int range_count;
@@ -33,7 +33,28 @@ struct regmap {
* Interface to provide access to registers either through a direct memory
* bus or through a peripheral bus like I2C, SPI.
*/
+
+/**
+ * regmap_write() - Write a 32-bit value to a regmap
+ *
+ * @map: Regmap to write to
+ * @offset:Offset in the regmap to write to
+ * @val: Data to write to the regmap at the specified offset
+ *
+ * Return: 0 if OK, -ve on error
+ */
int regmap_write(struct regmap *map, uint offset, uint val);
+
+/**
+ * regmap_read() - Read a 32-bit value from a regmap
+ *
+ * @map: Regmap to read from
+ * @offset:Offset in the regmap to read from
+ * @valp: Pointer to the buffer to receive the data read from the regmap
+ * at the specified offset
+ *
+ * Return: 0 if OK, -ve on error
+ */
int regmap_read(struct regmap *map, uint offset, uint *valp);
#define regmap_write32(map, ptr, member, val) \
@@ -49,31 +70,36 @@ int regmap_read(struct regmap *map, uint offset, uint
*valp);
* @offset:Offset of the memory
* @mask: Mask to apply to the read value
* @val: Value to apply to the value to write
+ * Return: 0 if OK, -ve on error
*/
int regmap_update_bits(struct regmap *map, uint offset, uint mask, uint val);
/**
* regmap_init_mem() - Set up a new register map that uses memory access
*
- * Use regmap_uninit() to free it.
- *
* @node: Device node that uses this map
* @mapp: Returns allocated map
+ * Return: 0 if OK, -ve on error
+ *
+ * Use regmap_uninit() to free it.
*/
int regmap_init_mem(ofnode node, struct regmap **mapp);
/**
- * regmap_init_mem_platdata() - Set up a new memory register map for
of-platdata
+ * regmap_init_mem_platdata() - Set up a new memory register map for
+ * of-platdata
+ *
+ * @dev: Device that uses this map
+ * @reg: List of address, size pairs
+ * @count: Number of pairs (e.g. 1 if the regmap has a single entry)
+ * @mapp: Returns allocated map
+ * Return: 0 if OK, -ve on error
*
* This creates a new regmap with a list of regions passed in, rather than
* using the device tree. It only supports 32-bit machines.
*
* Use regmap_uninit() to free it.
*
- * @dev: Device that uses this map
- * @reg: List of address, size pairs
- * @count: Number of pairs (e.g. 1 if the regmap has a single entry)
- * @mapp: Returns allocated map
*/
int regmap_init_mem_platdata(struct udevice *dev, fdt_val_t *reg, int count,
struct regmap **mapp);
@@ -83,11 +109,15 @@ int regmap_init_mem_platdata(struct udevice *dev,
fdt_val_t *reg, int count,
*
* @map: Regmap to query
* @range_num: Range to look up
+ * Return: Pointer to the range in question if OK, NULL on error
*/
void *regmap_get_range(struct regmap *map, unsigned int range_num);
/**
* regmap_uninit() - free a previously inited regmap
+ *
+ * @map: Regmap to free
+ * Return: 0 if OK, -ve on error
*/
int regmap_uninit(struct regmap *map);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 06/15] regmap: Add error output
Add some debug output in cases where the initialization of a regmap
fails.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
New in v3
---
drivers/core/regmap.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 25c1ae5d7df..154426269d9 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -139,12 +139,18 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
}
len = ofnode_read_size(node, "reg");
- if (len < 0)
+ if (len < 0) {
+ debug("%s: Error while reading reg size (ret = %d)\n",
+ ofnode_get_name(node), len);
return len;
+ }
len /= sizeof(fdt32_t);
count = len / both_len;
- if (!count)
+ if (!count) {
+ debug("%s: Not enough data in reg property\n",
+ ofnode_get_name(node));
return -EINVAL;
+ }
map = regmap_alloc(count);
if (!map)
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 05/15] regmap: Introduce init_range
Both fdtdec_get_addr_size_fixed and of_address_to_resource can fail with
an error, which is not currently checked during regmap initialization.
Since the indentation depth is already quite deep, extract a new
'init_range' method to do the initialization.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
* Introduced else clause in of_live_active() if statement to make the
distinction between live and non-live cases clearer
v2 -> v3:
New in v3
---
drivers/core/regmap.c | 68 ++-
1 file changed, 56 insertions(+), 12 deletions(-)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 4ebab233490..25c1ae5d7df 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -56,6 +56,58 @@ int regmap_init_mem_platdata(struct udevice *dev, fdt_val_t
*reg, int count,
return 0;
}
#else
+/**
+ * init_range() - Initialize a single range of a regmap
+ * @node: Device node that will use the map in question
+ * @range:Pointer to a regmap_range structure that will be initialized
+ * @addr_len: The length of the addr parts of the reg property
+ * @size_len: The length of the size parts of the reg property
+ * @index:The index of the range to initialize
+ *
+ * This function will read the necessary 'reg' information from the device tree
+ * (the 'addr' part, and the 'length' part), and initialize the range in
+ * quesion.
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static int init_range(ofnode node, struct regmap_range *range, int addr_len,
+ int size_len, int index)
+{
+ fdt_size_t sz;
+ struct resource r;
+
+ if (of_live_active()) {
+ int ret;
+
+ ret = of_address_to_resource(ofnode_to_np(node),
+index, );
+ if (ret) {
+ debug("%s: Could not read resource of range %d (ret =
%d)\n",
+ ofnode_get_name(node), index, ret);
+ return ret;
+ }
+
+ range->start = r.start;
+ range->size = r.end - r.start + 1;
+ } else {
+ int offset = ofnode_to_offset(node);
+
+ range->start = fdtdec_get_addr_size_fixed(gd->fdt_blob, offset,
+ "reg", index,
+ addr_len, size_len,
+ , true);
+ if (range->start == FDT_ADDR_T_NONE) {
+ debug("%s: Could not read start of range %d\n",
+ ofnode_get_name(node), index);
+ return -EINVAL;
+ }
+
+ range->size = sz;
+ }
+
+ return 0;
+}
+
int regmap_init_mem(ofnode node, struct regmap **mapp)
{
struct regmap_range *range;
@@ -64,7 +116,6 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
int addr_len, size_len, both_len;
int len;
int index;
- struct resource r;
addr_len = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
if (addr_len < 0) {
@@ -101,17 +152,10 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
for (range = map->ranges, index = 0; count > 0;
count--, range++, index++) {
- fdt_size_t sz;
- if (of_live_active()) {
- of_address_to_resource(ofnode_to_np(node), index, );
- range->start = r.start;
- range->size = r.end - r.start + 1;
- } else {
- range->start = fdtdec_get_addr_size_fixed(gd->fdt_blob,
- ofnode_to_offset(node), "reg", index,
- addr_len, size_len, , true);
- range->size = sz;
- }
+ int ret = init_range(node, range, addr_len, size_len, index);
+
+ if (ret)
+ return ret;
}
*mapp = map;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 04/15] regmap: Improve error handling
ofnode_read_simple_addr_cells may fail and return a negative error code.
Check for this when initializing regmaps.
Also check if both_len is zero, since this is perfectly possible, and
would lead to a division-by-zero further down the line.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
New in v3
---
drivers/core/regmap.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 77f6f520a06..4ebab233490 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -67,8 +67,25 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
struct resource r;
addr_len = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
+ if (addr_len < 0) {
+ debug("%s: Error while reading the addr length (ret = %d)\n",
+ ofnode_get_name(node), addr_len);
+ return addr_len;
+ }
+
size_len = ofnode_read_simple_size_cells(ofnode_get_parent(node));
+ if (size_len < 0) {
+ debug("%s: Error while reading the size length: (ret = %d)\n",
+ ofnode_get_name(node), size_len);
+ return size_len;
+ }
+
both_len = addr_len + size_len;
+ if (!both_len) {
+ debug("%s: Both addr and size length are zero\n",
+ ofnode_get_name(node));
+ return -EINVAL;
+ }
len = ofnode_read_size(node, "reg");
if (len < 0)
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v10 6/7] cmd: ubi: clean the partition handling
UBI should not mess with MTD partitions, now that the partitions are
handled in a clean way, clean the ubi command and avoid using this
uneeded extra-glue to reference the devices.
Signed-off-by: Miquel Raynal
Reviewed-by: Stefan Roese
Reviewed-by: Boris Brezillon
---
cmd/Kconfig | 2 ++
cmd/ubi.c | 96 ++---
2 files changed, 27 insertions(+), 71 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index b5bd978f6d..f82addca0a 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1822,6 +1822,8 @@ config CMD_UBI
capabilities. Please, consult the MTD web site for more details
(www.linux-mtd.infradead.org). Activate this option if you want
to use U-Boot UBI commands.
+ It is also strongly encouraged to also enable CONFIG_MTD to get full
+ partition support.
config CMD_UBIFS
tristate "Enable UBIFS - Unsorted block images filesystem commands"
diff --git a/cmd/ubi.c b/cmd/ubi.c
index 0a3405a3b1..bb8f97fc28 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,17 +30,6 @@
/* Private own data */
static struct ubi_device *ubi;
-static char buffer[80];
-static int ubi_initialized;
-
-struct selected_dev {
- char part_name[80];
- int selected;
- int nr;
- struct mtd_info *mtd_info;
-};
-
-static struct selected_dev ubi_dev;
#ifdef CONFIG_CMD_UBIFS
int ubifs_is_mounted(void);
@@ -404,43 +394,24 @@ int ubi_volume_read(char *volume, char *buf, size_t size)
return err;
}
-static int ubi_dev_scan(struct mtd_info *info, char *ubidev,
- const char *vid_header_offset)
+static int ubi_dev_scan(struct mtd_info *info, const char *vid_header_offset)
{
- struct mtd_device *dev;
- struct part_info *part;
- struct mtd_partition mtd_part;
char ubi_mtd_param_buffer[80];
- u8 pnum;
int err;
- if (find_dev_and_part(ubidev, , , ) != 0)
- return 1;
+ if (!vid_header_offset)
+ sprintf(ubi_mtd_param_buffer, "%s", info->name);
+ else
+ sprintf(ubi_mtd_param_buffer, "%s,%s", info->name,
+ vid_header_offset);
- sprintf(buffer, "mtd=%d", pnum);
- memset(_part, 0, sizeof(mtd_part));
- mtd_part.name = buffer;
- mtd_part.size = part->size;
- mtd_part.offset = part->offset;
- add_mtd_partitions(info, _part, 1);
-
- strcpy(ubi_mtd_param_buffer, buffer);
- if (vid_header_offset)
- sprintf(ubi_mtd_param_buffer, "mtd=%d,%s", pnum,
- vid_header_offset);
err = ubi_mtd_param_parse(ubi_mtd_param_buffer, NULL);
- if (err) {
- del_mtd_partitions(info);
+ if (err)
return -err;
- }
err = ubi_init();
- if (err) {
- del_mtd_partitions(info);
+ if (err)
return -err;
- }
-
- ubi_initialized = 1;
return 0;
}
@@ -465,50 +436,33 @@ int ubi_detach(void)
/*
* Call ubi_exit() before re-initializing the UBI subsystem
*/
- if (ubi_initialized) {
+ if (ubi)
ubi_exit();
- del_mtd_partitions(ubi_dev.mtd_info);
- ubi_initialized = 0;
- }
- ubi_dev.selected = 0;
+ ubi = NULL;
+
return 0;
}
int ubi_part(char *part_name, const char *vid_header_offset)
{
+ struct mtd_info *mtd;
int err = 0;
- char mtd_dev[16];
- struct mtd_device *dev;
- struct part_info *part;
- u8 pnum;
ubi_detach();
- /*
-* Search the mtd device number where this partition
-* is located
-*/
- if (find_dev_and_part(part_name, , , )) {
+
+ mtd_probe_devices();
+ mtd = get_mtd_device_nm(part_name);
+ if (IS_ERR(mtd)) {
printf("Partition %s not found!\n", part_name);
return 1;
}
- sprintf(mtd_dev, "%s%d", MTD_DEV_TYPE(dev->id->type), dev->id->num);
- ubi_dev.mtd_info = get_mtd_device_nm(mtd_dev);
- if (IS_ERR(ubi_dev.mtd_info)) {
- printf("Partition %s not found on device %s!\n", part_name,
- mtd_dev);
- return 1;
- }
+ put_mtd_device(mtd);
- ubi_dev.selected = 1;
-
- strcpy(ubi_dev.part_name, part_name);
- err = ubi_dev_scan(ubi_dev.mtd_info, ubi_dev.part_name,
- vid_header_offset);
+ err = ubi_dev_scan(mtd, vid_header_offset);
if (err) {
printf("UBI init error %d\n", err);
printf("Please check, if the correct MTD partition is used
(size big enough?)\n");
- ubi_dev.selected = 0;
return err;
}
@@ -539,13 +493,13 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int
[U-Boot] [PATCH v10 5/7] cmd: mtd: add 'mtd' command
There should not be a 'nand' command, a 'sf' command and certainly not
a new 'spi-nand' command. Write a 'mtd' command instead to manage all
MTD devices/partitions at once. This should be the preferred way to
access any MTD device.
Signed-off-by: Miquel Raynal
Acked-by: Jagan Teki
Reviewed-by: Stefan Roese
Reviewed-by: Boris Brezillon
---
cmd/Kconfig | 10 +-
cmd/Makefile| 1 +
cmd/mtd.c | 471
drivers/mtd/Makefile| 2 +-
drivers/mtd/mtd_uboot.c | 153 -
include/mtd.h | 1 +
6 files changed, 634 insertions(+), 4 deletions(-)
create mode 100644 cmd/mtd.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index f97d3df328..b5bd978f6d 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -854,6 +854,12 @@ config CMD_MMC_SWRITE
Enable support for the "mmc swrite" command to write Android sparse
images to eMMC.
+config CMD_MTD
+ bool "mtd"
+ select MTD_PARTITIONS
+ help
+ MTD commands support.
+
config CMD_NAND
bool "nand"
default y if NAND_SUNXI
@@ -1678,14 +1684,14 @@ config CMD_MTDPARTS
config MTDIDS_DEFAULT
string "Default MTD IDs"
- depends on CMD_MTDPARTS || CMD_NAND || CMD_FLASH
+ depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
help
Defines a default MTD IDs list for use with MTD partitions in the
Linux MTD command line partitions format.
config MTDPARTS_DEFAULT
string "Default MTD partition scheme"
- depends on CMD_MTDPARTS || CMD_NAND || CMD_FLASH
+ depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
help
Defines a default MTD partitioning scheme in the Linux MTD command
line partitions format
diff --git a/cmd/Makefile b/cmd/Makefile
index 414187f073..8107cb0aa8 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_CMD_MISC) += misc.o
obj-$(CONFIG_CMD_MMC) += mmc.o
obj-$(CONFIG_CMD_MMC_SPI) += mmc_spi.o
obj-$(CONFIG_MP) += mp.o
+obj-$(CONFIG_CMD_MTD) += mtd.o
obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
obj-$(CONFIG_CMD_NAND) += nand.o
obj-$(CONFIG_CMD_NET) += net.o
diff --git a/cmd/mtd.c b/cmd/mtd.c
new file mode 100644
index 00..559d6e6539
--- /dev/null
+++ b/cmd/mtd.c
@@ -0,0 +1,471 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * mtd.c
+ *
+ * Generic command to handle basic operations on any memory device.
+ *
+ * Copyright: Bootlin, 2018
+ * Author: Miquèl Raynal
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static uint mtd_len_to_pages(struct mtd_info *mtd, u64 len)
+{
+ do_div(len, mtd->writesize);
+
+ return len;
+}
+
+static bool mtd_is_aligned_with_min_io_size(struct mtd_info *mtd, u64 size)
+{
+ return !do_div(size, mtd->writesize);
+}
+
+static bool mtd_is_aligned_with_block_size(struct mtd_info *mtd, u64 size)
+{
+ return !do_div(size, mtd->erasesize);
+}
+
+static void mtd_dump_buf(const u8 *buf, uint len, uint offset)
+{
+ int i, j;
+
+ for (i = 0; i < len; ) {
+ printf("0x%08x:\t", offset + i);
+ for (j = 0; j < 8; j++)
+ printf("%02x ", buf[i + j]);
+ printf(" ");
+ i += 8;
+ for (j = 0; j < 8; j++)
+ printf("%02x ", buf[i + j]);
+ printf("\n");
+ i += 8;
+ }
+}
+
+static void mtd_dump_device_buf(struct mtd_info *mtd, u64 start_off,
+ const u8 *buf, u64 len, bool woob)
+{
+ bool has_pages = mtd->type == MTD_NANDFLASH ||
+ mtd->type == MTD_MLCNANDFLASH;
+ int npages = mtd_len_to_pages(mtd, len);
+ uint page;
+
+ if (has_pages) {
+ for (page = 0; page < npages; page++) {
+ u64 data_off = page * mtd->writesize;
+
+ printf("\nDump %d data bytes from 0x%08llx:\n",
+ mtd->writesize, start_off + data_off);
+ mtd_dump_buf([data_off],
+mtd->writesize, start_off + data_off);
+
+ if (woob) {
+ u64 oob_off = page * mtd->oobsize;
+
+ printf("Dump %d OOB bytes from page at
0x%08llx:\n",
+ mtd->oobsize, start_off + data_off);
+ mtd_dump_buf([len + oob_off],
+mtd->oobsize, 0);
+ }
+ }
+ } else {
+ printf("\nDump %lld data bytes from 0x%llx:\n",
+ len, start_off);
+ mtd_dump_buf(buf, len, start_off);
+ }
+}
+
+static void mtd_show_parts(struct mtd_info *mtd, int level)
+{
+ struct mtd_info *part;
+ int i;
+
+ list_for_each_entry(part, >partitions, node) {
+
