Re: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path【请注意，邮件由s...@google.com代发】
Hi Kever, On Thu, 4 Apr 2019 at 07:11, Kever Yang wrote: > > Hi Simon, > > > On 04/04/2019 03:57 AM, Simon Glass wrote: > > Hi Kever, > > > > On Sat, 30 Mar 2019 at 15:18, Simon Glass wrote: > >> Hi Kever, > >> > >> On Wed, 27 Mar 2019 at 21:01, Kever Yang wrote: > >>> Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common > >>> header file path, so that we can get the correct path directly. > >> Can you give a few more details on the reason for this change? I > >> cannot see the benefit? > > OK I figured it out from the context. > > > > Do you have interest in supporting multiple SoCs with a single build? > > Is there other vendor support multiple SoCs? > For Rockchip platform, I don't think it's easy to do it now, the different > for different SoCs now: > - SoC init, eg. debug uart init, sgrf setting and other one time init > setting; > - clock driver; > - pinctrl driver, David still working on it, but the target is for > minimum size for > each SoC, but not enable common code in pinctrl-core as much as possible, > so this is the opposite way with support multiple SoCs support. > > I would like to use common board/spl/tpl files first, and then step to > step to > see what we need to do. OK. We can today support multiple clock and pinctrl drivers. Minimising code size is a separate issue to actually making it work. For SoC init we can use compatible strings to select the init - as you say, moving to common SPL/TPL is a useful step, but in fact this is not necessary for use to use a common U-Boot proper. I believe the main requirement is to create a new config with additional drivers, then make SPL select the correct DT. But my concern is that your series to move things to #include asm/arch precludes supporting more than one SoC. So if we want this, we should leave things as they are. If you like I could create a proof of concept for this for two chosen SoCs? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path【请注意，邮件由s...@google.com代发】
Hi Kever, On Mon, 1 Apr 2019 at 19:11, Kever Yang wrote: > > > > On 04/02/2019 03:00 AM, Simon Glass wrote: > > Hi Kever, > > > > On Sun, 31 Mar 2019 at 20:46, Kever Yang wrote: > >> Hi Simon, > >> > >> > >> On 04/01/2019 10:00 AM, Simon Glass wrote: > >>> Hi Kever, > >>> > >>> On Sun, 31 Mar 2019 at 19:03, Kever Yang > >>> wrote: > Hi Simon, > > > On 03/31/2019 05:18 AM, Simon Glass wrote: > > Hi Kever, > > > > On Wed, 27 Mar 2019 at 21:01, Kever Yang > > wrote: > >> Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common > >> header file path, so that we can get the correct path directly. > > Can you give a few more details on the reason for this change? I > > cannot see the benefit? > 1. 'rockchip' is not SOC name but vendor name, we'd better use correct > name; > 2. the build system will include $(SOC)-u-boot.dtsi automatically > without modify > $(SOC).dtsi or $(board).dtsi, if the $(SOC) default to 'rockchip', > we can't use > this feature. > >>> OK I see. > >>> > >>> So far Rockchip has been designed so that a single U-Boot (proper) can > >>> support multiple SoCs, > >> I don't understand, how can a single U-Boot(proper) support multiple > >> Rockchip SoCs, > >> it sounds awesome which is kernel like. But I thought we need different > >> build > >> with different source for different SoCs now. > > It should be possible simply by enabling multiple SoCs, so long as you > > don't try to use both 32/64-bit ones. > > > > I suspect some extra work is needed, but probably not much. > > multiple SoCs + multiple boards, I know it sounds very good and we may able > to implement it, but it would be a long time. Kernel already do this, > but we have > to know that it leaves all the one time program init job to U-Boot like > loader and > load/fix a correct dtb for it. > > Can we have more common codes first, my patches for common 'board/spl/tpl' > has pending for more than one year, and I split it into pieces and hope > to get > some of then merged in next merge window. > > I know there may be change request needed, so I really want to get > patches review > and response a little faster so that I can update a new version. > > Well, this patch get reviewed pretty fast, but others seems no one sees > them. OK hopefully these can all be applied soon, perhaps in a -next branch. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] efi_loader: parameter checks in StartImage and Exit()
Add parameter checks in the StartImage() and Exit() boottime services:
- check that the image handle is valid and has the loaded image protocol
installed
- in StartImage() record the current image
- in Exit() check that the image is the current image
Signed-off-by: Heinrich Schuchardt
---
v2
avoid `parent_image` may be used uninitialized
---
lib/efi_loader/efi_boottime.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 6aac8391c5..970c01614e 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -26,6 +26,9 @@ LIST_HEAD(efi_obj_list);
/* List of all events */
LIST_HEAD(efi_events);
+/* Handle of the currently executing image */
+static efi_handle_t current_image;
+
/*
* If we're running on nasty systems (32bit ARM booting into non-EFI Linux)
* we need to do trickery with caches. Since we don't want to break the EFI
@@ -2631,9 +2634,18 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
struct efi_loaded_image_obj *image_obj =
(struct efi_loaded_image_obj *)image_handle;
efi_status_t ret;
+ void *info;
+ efi_handle_t parent_image = current_image;
EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data);
+ /* Check parameters */
+ ret = EFI_CALL(efi_open_protocol(image_handle, _guid_loaded_image,
+, NULL, NULL,
+EFI_OPEN_PROTOCOL_GET_PROTOCOL));
+ if (ret != EFI_SUCCESS)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+
efi_is_direct_boot = false;
/* call the image! */
@@ -2662,9 +2674,11 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
__efi_nesting_dec(),
(unsigned long)((uintptr_t)image_obj->exit_status &
~EFI_ERROR_MASK));
+ current_image = parent_image;
return EFI_EXIT(image_obj->exit_status);
}
+ current_image = image_handle;
ret = EFI_CALL(image_obj->entry(image_handle, ));
/*
@@ -2699,12 +2713,23 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t
image_handle,
* TODO: We should call the unload procedure of the loaded
* image protocol.
*/
+ efi_status_t ret;
+ void *info;
struct efi_loaded_image_obj *image_obj =
(struct efi_loaded_image_obj *)image_handle;
EFI_ENTRY("%p, %ld, %zu, %p", image_handle, exit_status,
exit_data_size, exit_data);
+ /* Check parameters */
+ if (image_handle != current_image)
+ goto out;
+ ret = EFI_CALL(efi_open_protocol(image_handle, _guid_loaded_image,
+, NULL, NULL,
+EFI_OPEN_PROTOCOL_GET_PROTOCOL));
+ if (ret != EFI_SUCCESS)
+ goto out;
+
/* Make sure entry/exit counts for EFI world cross-overs match */
EFI_EXIT(exit_status);
@@ -2718,6 +2743,8 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t
image_handle,
longjmp(_obj->exit_jmp, 1);
panic("EFI application exited");
+out:
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
}
/**
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] efi_loader: parameter checks in StartImage and Exit()
Add parameter checks in the StartImage() and Exit() boottime services: - check that the image handle is valid and has the loaded image protocol installed - in StartImage() record the current image - in Exit() check that the image is the current image v2 avoid `parent_image` may be used uninitialized Heinrich Schuchardt (2): efi_loader: rearrange boottime service functions efi_loader: parameter checks in StartImage and Exit() lib/efi_loader/efi_boottime.c | 245 +++--- 1 file changed, 136 insertions(+), 109 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] efi_loader: rearrange boottime service functions
To avoid forward declarations move efi_start_image() and efi_exit() down.
Signed-off-by: Heinrich Schuchardt
---
v2
no change
---
lib/efi_loader/efi_boottime.c | 218 +-
1 file changed, 109 insertions(+), 109 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 7038246902..6aac8391c5 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1744,115 +1744,6 @@ error:
return EFI_EXIT(ret);
}
-/**
- * efi_start_image() - call the entry point of an image
- * @image_handle: handle of the image
- * @exit_data_size: size of the buffer
- * @exit_data: buffer to receive the exit data of the called image
- *
- * This function implements the StartImage service.
- *
- * See the Unified Extensible Firmware Interface (UEFI) specification for
- * details.
- *
- * Return: status code
- */
-efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle,
- efi_uintn_t *exit_data_size,
- u16 **exit_data)
-{
- struct efi_loaded_image_obj *image_obj =
- (struct efi_loaded_image_obj *)image_handle;
- efi_status_t ret;
-
- EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data);
-
- efi_is_direct_boot = false;
-
- /* call the image! */
- if (setjmp(_obj->exit_jmp)) {
- /*
-* We called the entry point of the child image with EFI_CALL
-* in the lines below. The child image called the Exit() boot
-* service efi_exit() which executed the long jump that brought
-* us to the current line. This implies that the second half
-* of the EFI_CALL macro has not been executed.
-*/
-#ifdef CONFIG_ARM
- /*
-* efi_exit() called efi_restore_gd(). We have to undo this
-* otherwise __efi_entry_check() will put the wrong value into
-* app_gd.
-*/
- gd = app_gd;
-#endif
- /*
-* To get ready to call EFI_EXIT below we have to execute the
-* missed out steps of EFI_CALL.
-*/
- assert(__efi_entry_check());
- debug("%sEFI: %lu returned by started image\n",
- __efi_nesting_dec(),
- (unsigned long)((uintptr_t)image_obj->exit_status &
- ~EFI_ERROR_MASK));
- return EFI_EXIT(image_obj->exit_status);
- }
-
- ret = EFI_CALL(image_obj->entry(image_handle, ));
-
- /*
-* Usually UEFI applications call Exit() instead of returning.
-* But because the world doesn't consist of ponies and unicorns,
-* we're happy to emulate that behavior on behalf of a payload
-* that forgot.
-*/
- return EFI_CALL(systab.boottime->exit(image_handle, ret, 0, NULL));
-}
-
-/**
- * efi_exit() - leave an EFI application or driver
- * @image_handle: handle of the application or driver that is exiting
- * @exit_status:status code
- * @exit_data_size: size of the buffer in bytes
- * @exit_data: buffer with data describing an error
- *
- * This function implements the Exit service.
- *
- * See the Unified Extensible Firmware Interface (UEFI) specification for
- * details.
- *
- * Return: status code
- */
-static efi_status_t EFIAPI efi_exit(efi_handle_t image_handle,
- efi_status_t exit_status,
- efi_uintn_t exit_data_size,
- u16 *exit_data)
-{
- /*
-* TODO: We should call the unload procedure of the loaded
-* image protocol.
-*/
- struct efi_loaded_image_obj *image_obj =
- (struct efi_loaded_image_obj *)image_handle;
-
- EFI_ENTRY("%p, %ld, %zu, %p", image_handle, exit_status,
- exit_data_size, exit_data);
-
- /* Make sure entry/exit counts for EFI world cross-overs match */
- EFI_EXIT(exit_status);
-
- /*
-* But longjmp out with the U-Boot gd, not the application's, as
-* the other end is a setjmp call inside EFI context.
-*/
- efi_restore_gd();
-
- image_obj->exit_status = exit_status;
- longjmp(_obj->exit_jmp, 1);
-
- panic("EFI application exited");
-}
-
/**
* efi_unload_image() - unload an EFI image
* @image_handle: handle of the image to be unloaded
@@ -2720,6 +2611,115 @@ out:
return EFI_EXIT(r);
}
+/**
+ * efi_start_image() - call the entry point of an image
+ * @image_handle: handle of the image
+ * @exit_data_size: size of the buffer
+ * @exit_data: buffer to receive the exit data of the called image
+ *
+ * This function implements the StartImage service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI)
Re: [U-Boot] [PATCH] net: macb: Add small delay after link establishment
On Wed, Mar 27, 2019 at 5:20 AM Stefan Roese wrote: > > I've noticed that the first ethernet packet after PHY link establishment > is not tranferred correctly most of the time on my AT91SAM9G25 board. > Here I usually see a timeout of a few seconds, which is quite > annoying. > > Adding a small delay (10ms in this case) after the link establishment > helps to solve this problem. With this patch applied, this timeout > on the first packet is not seen any more. > > Signed-off-by: Stefan Roese > Cc: Wenyou Yang > Cc: Eugen Hristev > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: variables PlatformLang and PlatformLangCodes
Since TianoCore EDK2 commit d65f2cea36d1 ("ShellPkg/CommandLib: Locate
proper UnicodeCollation instance") in edk2 the UEFI Shell crashes if EFI
variable PlatformLang is not defined.
As this variable is anyway prescribed in the UEFI 2.7 spec let's define it
to L"en-US". Use the same value for PlatformLangCodes that defines the list
of all supported languages.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_setup.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 8266d06c2e..e431c1c053 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -10,6 +10,9 @@
#define OBJ_LIST_NOT_INITIALIZED 1
+/* Language code for American English according to RFC 4646 */
+#define EN_US L"en-US"
+
static efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
/* Initialize and populate EFI object list */
@@ -24,6 +27,30 @@ efi_status_t efi_init_obj_list(void)
*/
efi_save_gd();
+ /*
+* Variable PlatformLang defines the language that the machine has been
+* configured for.
+*/
+ ret = EFI_CALL(efi_set_variable(L"PlatformLang",
+ _global_variable_guid,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS,
+ sizeof(EN_US), EN_US));
+ if (ret != EFI_SUCCESS)
+ goto out;
+
+ /*
+* Variable PlatformLangCodes defines the language codes that the
+* machine can support.
+*/
+ ret = EFI_CALL(efi_set_variable(L"PlatformLangCodes",
+ _global_variable_guid,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS,
+ sizeof(EN_US), EN_US));
+ if (ret != EFI_SUCCESS)
+ goto out;
+
/* Initialize once only */
if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
return efi_obj_list_initialized;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] power: pfuze100: Fix off by one error in voltage table handling
The code that sets a regulator by looking up the voltage in a table had
an off by one error. vsel_mask is a bitmask, not the number of table
entries, so a vsel_mask value of 0x7 indicates there are 8, not 7,
entries in the table.
Cc: Peng Fan
Cc: Jaehoon Chung
Signed-off-by: Trent Piepho
---
drivers/power/regulator/pfuze100.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/regulator/pfuze100.c
b/drivers/power/regulator/pfuze100.c
index 99073d6018..d6d35f3a39 100644
--- a/drivers/power/regulator/pfuze100.c
+++ b/drivers/power/regulator/pfuze100.c
@@ -482,11 +482,11 @@ static int pfuze100_regulator_val(struct udevice *dev,
int op, int *uV)
debug("Set voltage for REGULATOR_TYPE_FIXED regulator\n");
return -EINVAL;
} else if (desc->volt_table) {
- for (i = 0; i < desc->vsel_mask; i++) {
+ for (i = 0; i <= desc->vsel_mask; i++) {
if (*uV == desc->volt_table[i])
break;
}
- if (i == desc->vsel_mask) {
+ if (i == desc->vsel_mask + 1) {
debug("Unsupported voltage %u\n", *uV);
return -EINVAL;
}
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] imx: move BOARD_SIZE_CHECK to main Makefile
On 4/2/19 7:19 PM, Heinrich Schuchardt wrote:
> We currently have duplicate definitions for BOARD_SIZE_CHECK in Makefile
> and arch/arm/mach-imx/Makefile.
>
> Move the board size check from arch/arm/mach-imx/Makefile to Makefile.
>
> Depending on the value of CONFIG_BOARD_SIZE_LIMIT an error like an error
> like the following is thrown:
>
> u-boot-dtb.imx exceeds file size limit:
> limit: 503696 bytes
> actual: 509720 bytes
> excess: 6024 bytes
> make: *** [Makefile:1051: u-boot-dtb.imx] Error 1
>
> Signed-off-by: Heinrich Schuchardt
Hello Stefano, hello Fabio,
there have been some comments to 0/4 indicating that the first patch of
the series should be reworked.
But I think this one is worth merging on it own. Could you, please,
review it and if ok add it to your IMX repository.
Best regards
Heinrich
> ---
> v4
> new patch
> ---
> Makefile | 1 +
> arch/arm/mach-imx/Makefile | 16
> 2 files changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 9878595a82..6398117e64 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1042,6 +1042,7 @@ endif
>
> %.imx: %.bin
> $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
> + $(BOARD_SIZE_CHECK)
>
> %.vyb: %.imx
> $(Q)$(MAKE) $(build)=arch/arm/cpu/armv7/vf610 $@
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index c3ed62aed6..7985afb154 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -61,21 +61,6 @@ obj-$(CONFIG_CMD_HDMIDETECT) += cmd_hdmidet.o
> obj-$(CONFIG_CMD_DEKBLOB) += cmd_dek.o
> endif
>
> -ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
> -BOARD_SIZE_CHECK = \
> -@actual=`wc -c $@ | awk '{print $$1}'`; \
> -limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
> -if test $$actual -gt $$limit; then \
> -echo "$@ exceeds file size limit:" >&2 ; \
> -echo " limit: $$limit bytes" >&2 ; \
> -echo " actual: $$actual bytes" >&2 ; \
> -echo " excess: $$((actual - limit)) bytes" >&2; \
> -exit 1; \
> -fi
> -else
> -BOARD_SIZE_CHECK =
> -endif
> -
> PLUGIN = board/$(BOARDDIR)/plugin
>
> ifeq ($(CONFIG_USE_IMXIMG_PLUGIN),y)
> @@ -124,7 +109,6 @@ u-boot.imx: MKIMAGEOUTPUT = u-boot.imx.log
>
> u-boot.imx: u-boot.bin u-boot.cfgout $(PLUGIN).bin FORCE
> $(call if_changed,mkimage)
> - $(BOARD_SIZE_CHECK)
>
> ifeq ($(CONFIG_OF_SEPARATE),y)
> MKIMAGEFLAGS_u-boot-dtb.imx = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \
> --
> 2.20.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
Hi Jagan, > On Thu, Apr 4, 2019 at 3:31 PM Lukasz Majewski wrote: > > > > On Thu, 4 Apr 2019 14:56:36 +0530 > > Jagan Teki wrote: > > > > > On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski > > > wrote: > > > > > > > > On Tue, 2 Apr 2019 16:58:33 +0530 > > > > Jagan Teki wrote: > > > > > > > > > This is revised version of previous i.MX6 clock management > > > > > [1]. > > > > > > > > > > The main difference between previous version is > > > > > - Group the i.MX6 ccm clocks into gates and tree instead of > > > > > handling the clocks in simple way using case statement. > > > > > - use gate clocks for enable/disable management. > > > > > - use tree clocks for get/set rate or parent traverse > > > > > management. > > > > > - parent clock handling via clock type. > > > > > - traverse the parent clock using recursive functionlaity. > > > > > > > > > > The main motive behind this tree framework is to make the > > > > > clock tree management simple and useful for U-Boot > > > > > requirements instead of garbing Linux clock management code. > > > > > > > > > > We are trying to manage the Allwinner clocks with similar > > > > > kind, so having this would really help i.MX6 as well. > > > > > > > > > > Added simple names for clock macros, but will update it in > > > > > future version. > > > > > > > > > > I have skipped ENET clocks from previous series, will add it > > > > > in future patches. > > > > > > > > > > Changes for v2: > > > > > - changed framework patches. > > > > > - add support for imx6qdl and imx6ul boards > > > > > - add clock gates, tree. > > > > > > > > > > [1] https://patchwork.ozlabs.org/cover/950964/ > > > > > > > > > > Any inputs? > > > > > > > > Hmm It looks like we are doing some development in parallel. > > > > > > > > Please look into following commit [1]: > > > > https://patchwork.ozlabs.org/patch/1034051/ > > > > > > > > It ports from Linux 5.0 the CCF framework for iMX6Q, which IMHO > > > > in the long term is a better approach. > > > > The code is kept simple and resembles the code from Barebox. > > > > > > > > Please correct me if I'm wrong, but the code from your work is > > > > not modeling muxes, gates and other components from Linux CCF. > > > > > > The U-Boot implementation of CLK would require as minimal and > > > simple as possible due to requirement of U-Boot itself. Hope you > > > agree this point? > > > > Now i.MX6 is using clock.c CLK implementation. If we decide to > > replace it - we shall do it in a way, which would allow us to follow > > Linux kernel. (the barebox implementation is a stripped CCF from > > Linux, the same is in patch [1]). > > > > > if yes having CCF stack code to handle all clock with > > > respective separate drivers management is may not require as of > > > now, IMHO. > > > > I do have a gut feeling, that we will end up with the need to have > > the CCF framework ported anyway. As for example imx7/8 can re-use > > muxes, gates code. > > As per my experience the main the over-ahead to handle clocks in > U-Boot if we go with separate clock drivers is for Video and Ethernet > peripherals. these are key IP's which use more clocks from U-Boot > point-of-view, others can be handle pretty straight-forward unless if > they don't have too much tree chain. > > On this series, the tree management is already supported ENET in > i.MX6, and Allwinner platforms. > > As of now, I'm thinking I can handle reset of the clocks with similar > way. But this code also supports ENET and ESDHCI clocks on i.MX6Q (as supporting those was the motivator for this work). One important thing to be aware of - the problem with SPL's footprint. The implementation with clock.c is small and simple, but doesn't scale well. > > > > > However, those are only my "feelings" after a glimpse look - I will > > look into your code more thoroughly and provide feedback. > > Please have a look, if possible check even the code size by adding > USDHC clocks. Yes, code size (especially in SPL) is an _important_ factor here. > > > > > > > > > This series is using recursive calls for handling parenting stuff > > > to handle get or set rates, which is fine for handling clock tree > > > management as far as U-Boot point-of-view. We have faced similar > > > situation as I explained in commit message about Allwinner clocks > > > [2] and we ended up going this way. > > > > I'm not Allwinner expert - but if I may ask - how far away is this > > implementation from mainline Linux kernel? > > > > How difficult is it to port the new code (or update it)? > > Allwinner clocks also has similar gates, muxs, and with other platform > stuff which has too much scope in Linux to use CCM. For example the barebox managed to get subset of Linux CCF ported, without loosing the CCF similarity. Important factors/requirements for the i.MX clock code: 1. Easy maintenance in long-term 2. Reusing the code in SPL (with a very important factor of _code_size_). 3. Reuse the code for
[U-Boot] [PATCH 1/1] efi_loader: EFI_PRINT instead of debug for memory services
For debug messages inside EFI API functions we should use the EFI_PRINT
macro which gives us well aligned output like:
EFI: Entry efi_allocate_pool_ext(4, 14, 7edd7718)
EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes
EFI: Exit: efi_allocate_pool_ext: 0
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 55622d2fb4..469a667b3f 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -204,8 +204,8 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t pages,
int memory_type,
bool carve_again;
uint64_t carved_pages = 0;
- debug("%s: 0x%llx 0x%llx %d %s\n", __func__,
- start, pages, memory_type, overlap_only_ram ? "yes" : "no");
+ EFI_PRINT("%s: 0x%llx 0x%llx %d %s\n", __func__,
+ start, pages, memory_type, overlap_only_ram ? "yes" : "no");
if (memory_type >= EFI_MAX_MEMORY_TYPE)
return EFI_INVALID_PARAMETER;
--
2.20.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_PRINT instead of debug for variable services
For debug messages inside EFI API functions we should use the EFI_PRINT
macro which gives us well aligned output like:
EFI: Entry efi_get_variable("PlatformLang" ...)
EFI: get 'efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang'
EFI: Exit: efi_get_variable: 14
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 699f4184d9..37728c3c16 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -180,7 +180,7 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
if (ret)
return EFI_EXIT(ret);
- debug("%s: get '%s'\n", __func__, native_name);
+ EFI_PRINT("get '%s'\n", native_name);
val = env_get(native_name);
free(native_name);
@@ -211,7 +211,7 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
if (hex2bin(data, s, len))
return EFI_EXIT(EFI_DEVICE_ERROR);
- debug("%s: got value: \"%s\"\n", __func__, s);
+ EFI_PRINT("got value: \"%s\"\n", s);
} else if ((s = prefix(val, "(utf8)"))) {
unsigned len = strlen(s) + 1;
@@ -226,9 +226,9 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
memcpy(data, s, len);
((char *)data)[len] = '\0';
- debug("%s: got value: \"%s\"\n", __func__, (char *)data);
+ EFI_PRINT("got value: \"%s\"\n", (char *)data);
} else {
- debug("%s: invalid value: '%s'\n", __func__, val);
+ EFI_PRINT("invalid value: '%s'\n", val);
return EFI_EXIT(EFI_DEVICE_ERROR);
}
@@ -485,7 +485,7 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
s = bin2hex(s, data, data_size);
*s = '\0';
- debug("%s: setting: %s=%s\n", __func__, native_name, val);
+ EFI_PRINT("setting: %s=%s\n", native_name, val);
if (env_set(native_name, val))
ret = EFI_DEVICE_ERROR;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] arm: print information about loaded UEFI images
If an exception occurs in a UEFI loaded image we need the start address of
the image to determine the relocation offset.
This patch adds the necessary lines after the registers in the crash dump
for armv8. A possible output would be:
UEFI image [0xbffe6000:0xbffe631f] pc=0x138 '/\snp.efi'
With the offset 0x138 we can now find the relevant instruction in the
disassembled 'snp.efi' binary.
Signed-off-by: Heinrich Schuchardt
---
arch/arm/lib/interrupts_64.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/lib/interrupts_64.c b/arch/arm/lib/interrupts_64.c
index 458319ab48..0bfdb8d93d 100644
--- a/arch/arm/lib/interrupts_64.c
+++ b/arch/arm/lib/interrupts_64.c
@@ -25,6 +25,11 @@ int disable_interrupts(void)
return 0;
}
+static void show_efi_loaded_images(struct pt_regs *regs)
+{
+ efi_print_image_infos((void *)regs->elr);
+}
+
void show_regs(struct pt_regs *regs)
{
int i;
@@ -49,6 +54,7 @@ void do_bad_sync(struct pt_regs *pt_regs, unsigned int esr)
efi_restore_gd();
printf("Bad mode in \"Synchronous Abort\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
@@ -60,6 +66,7 @@ void do_bad_irq(struct pt_regs *pt_regs, unsigned int esr)
efi_restore_gd();
printf("Bad mode in \"Irq\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
@@ -71,6 +78,7 @@ void do_bad_fiq(struct pt_regs *pt_regs, unsigned int esr)
efi_restore_gd();
printf("Bad mode in \"Fiq\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
@@ -82,6 +90,7 @@ void do_bad_error(struct pt_regs *pt_regs, unsigned int esr)
efi_restore_gd();
printf("Bad mode in \"Error\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
@@ -93,6 +102,7 @@ void do_sync(struct pt_regs *pt_regs, unsigned int esr)
efi_restore_gd();
printf("\"Synchronous Abort\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
@@ -104,6 +114,7 @@ void do_irq(struct pt_regs *pt_regs, unsigned int esr)
efi_restore_gd();
printf("\"Irq\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
@@ -115,6 +126,7 @@ void do_fiq(struct pt_regs *pt_regs, unsigned int esr)
efi_restore_gd();
printf("\"Fiq\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
@@ -129,5 +141,6 @@ void __weak do_error(struct pt_regs *pt_regs, unsigned int
esr)
efi_restore_gd();
printf("\"Error\" handler, esr 0x%08x\n", esr);
show_regs(pt_regs);
+ show_efi_loaded_images(pt_regs);
panic("Resetting CPU ...\n");
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] bug "missing clock-frequency property" (sunxi/sun7i)
Hi, I used the latest u-boot version via "git clone git://git.denx.de/u-boot.git u-boot/" and built using Lamobo_R1_defconfig. After copying the u-boot-sunxi-with-spl.bin to the boot device with these commands: dd if=/dev/zero of=/dev/mmcblk0 bs=1k count=1023 seek=1 dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8 sync and rebooting the device, the kernel writes the following errors to the logfile: [0.049630] /cpus/cpu@0 missing clock-frequency property [0.049647] /cpus/cpu@1 missing clock-frequency property How to fix this? Thx my build script: ... make -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mrproper makeARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Lamobo_R1_defconfig makeARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- # # Automatically generated file; DO NOT EDIT. # U-Boot 2019.04-rc4 Configuration ... CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv7" CONFIG_SYS_SOC="sunxi" CONFIG_SYS_BOARD="sunxi" CONFIG_SYS_CONFIG_NAME="sun7i" ... CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" ... -- U.Mutlu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/1] Add ps7_init_gpl.c for Z-turn board
From: Anton Gerasimov Device tree and defconfig are already in U-boot. I've done basic testing (i.e. it boots). Anton Gerasimov (1): Add ps7_init_gpl.c for Z-turn board board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c | 12387 ++ 1 file changed, 12387 insertions(+) create mode 100644 board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Thu, Apr 04, 2019 at 09:35:43PM +0530, Jagan Teki wrote: > On Thu, Apr 4, 2019 at 9:26 PM Tom Rini wrote: > > > > On Thu, Apr 04, 2019 at 12:48:58PM -0300, Fabio Estevam wrote: > > > On Thu, Apr 4, 2019 at 7:01 AM Lukasz Majewski wrote: > > > > > > > Fabio, Stefano what do you think? > > > > > > > > As we change the clock.c code, IMHO we shall do the new port properly. > > > > > > I think the CCF solution proposed by Lukasz looks good and it will be > > > easier to maintain and sync with the kernel. > > > > This sounds like an important goal as well, to me. Thanks! > > I don't know why we rely too-much on Linux to import the big stack > code, since the requirement of U-Boot here is to handle the clocks as > minimum(as required) as compared to what OS is looking for. > > Are we looking for handling clock tree management for a whole or > looking as required (or as simple) is the main criteria to think > about. We rely on leveraging Linux when possible for a lot of reasons. First, it's generally going to have to solve most of the same problems we have to solve. Second, it's what most folks are going to be familiar with. So if we can strip down that same framework to work for us, it'll make life easier on everyone involved. -- 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 1/2] image: android: allow booting lz4-compressed kernels
On 4/4/19 1:14 PM, Eugeniu Rosca wrote:
> Hi Marek and thanks for your swift comment,
>
> On Thu, Apr 04, 2019 at 03:39:30AM +0200, Marek Vasut wrote:
>> On 4/3/19 11:35 PM, Eugeniu Rosca wrote:
>>> According to Android image format [1], kernel image resides at 1 page
>>> offset from the boot image address. Grab the magic number from there
>>> and allow U-Boot to handle LZ4-compressed KNL binaries instead of
>>> hardcoding compression type to IH_COMP_NONE. Other compression types,
>>> if needed, can be added later.
>>>
>
> [..]
>
>>>
>>> +#define LZ4F_MAGIC 0x184D2204
>>
>> Don't we already have this magic in some common header ?
>
> Unfortunately not. It is present in lib/lz4_wrapper.c only.
> Would it be OK to relocate it to include/image.h?
Yes
>>> +ulong android_image_get_kcomp(const struct andr_img_hdr *hdr)
>>> +{
>>> + u32 *magic = (u32 *)((ulong)hdr + hdr->page_size);
>>
>> Should this be get_unaligned((uintptr_t)hdr + hdr->page_size) ?
>> get_unaligned() because the image may be at unaligned address (although
>> that's unlikely) [..]
>
> Just out of curiosity I've copied the Android image to 0x4c01
> instead of 0x4c00 in RAM and by calling 'bootm 0x4c01', the
> compression type is still correctly identified and OS boots properly
> (w/o get_unaligned).
It will work on arm64, other platforms might fail.
> But that's because the data cache is enabled. Booting from 0x4c01
> after calling `dcache off` no longer works and generates a
> "Synchronous Abort".
>
> Actually having dcache enabled is a requirement for LZ4, since it
> heavily relies on unaligned memory access and produces the same data
> abort in case dcache is turned off (even if it is passed the image at
> a properly aligned location in RAM).
>
> So, bottom line, even if we use get_unaligned() here, the LZ4 kernel
> still won't boot with data cache disabled. Anyway, I agree to use an
> alignment-aware primitive here, as you suggested.
>
>> and uintptr_t to cater for both 32 and 64bit pointers.
>
> Worked for me.
>
> [..]
>
>>> @@ -1312,6 +1312,7 @@ int android_image_get_second(const struct
>>> andr_img_hdr *hdr,
>>> ulong *second_data, ulong *second_len);
>>> ulong android_image_get_end(const struct andr_img_hdr *hdr);
>>> ulong android_image_get_kload(const struct andr_img_hdr *hdr);
>>> +ulong android_image_get_kcomp(const struct andr_img_hdr *hdr);
>
> Would you like ulong/int here?
ulong to keep it consistent ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Thu, Apr 4, 2019 at 3:31 PM Lukasz Majewski wrote: > > On Thu, 4 Apr 2019 14:56:36 +0530 > Jagan Teki wrote: > > > On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski wrote: > > > > > > On Tue, 2 Apr 2019 16:58:33 +0530 > > > Jagan Teki wrote: > > > > > > > This is revised version of previous i.MX6 clock management [1]. > > > > > > > > The main difference between previous version is > > > > - Group the i.MX6 ccm clocks into gates and tree instead of > > > > handling the clocks in simple way using case statement. > > > > - use gate clocks for enable/disable management. > > > > - use tree clocks for get/set rate or parent traverse management. > > > > - parent clock handling via clock type. > > > > - traverse the parent clock using recursive functionlaity. > > > > > > > > The main motive behind this tree framework is to make the clock > > > > tree management simple and useful for U-Boot requirements instead > > > > of garbing Linux clock management code. > > > > > > > > We are trying to manage the Allwinner clocks with similar kind, so > > > > having this would really help i.MX6 as well. > > > > > > > > Added simple names for clock macros, but will update it in future > > > > version. > > > > > > > > I have skipped ENET clocks from previous series, will add it in > > > > future patches. > > > > > > > > Changes for v2: > > > > - changed framework patches. > > > > - add support for imx6qdl and imx6ul boards > > > > - add clock gates, tree. > > > > > > > > [1] https://patchwork.ozlabs.org/cover/950964/ > > > > > > > > Any inputs? > > > > > > Hmm It looks like we are doing some development in parallel. > > > > > > Please look into following commit [1]: > > > https://patchwork.ozlabs.org/patch/1034051/ > > > > > > It ports from Linux 5.0 the CCF framework for iMX6Q, which IMHO in > > > the long term is a better approach. > > > The code is kept simple and resembles the code from Barebox. > > > > > > Please correct me if I'm wrong, but the code from your work is not > > > modeling muxes, gates and other components from Linux CCF. > > > > The U-Boot implementation of CLK would require as minimal and simple > > as possible due to requirement of U-Boot itself. Hope you agree this > > point? > > Now i.MX6 is using clock.c CLK implementation. If we decide to > replace it - we shall do it in a way, which would allow us to follow > Linux kernel. (the barebox implementation is a stripped CCF from > Linux, the same is in patch [1]). > > > if yes having CCF stack code to handle all clock with > > respective separate drivers management is may not require as of now, > > IMHO. > > I do have a gut feeling, that we will end up with the need to have the > CCF framework ported anyway. As for example imx7/8 can re-use muxes, > gates code. As per my experience the main the over-ahead to handle clocks in U-Boot if we go with separate clock drivers is for Video and Ethernet peripherals. these are key IP's which use more clocks from U-Boot point-of-view, others can be handle pretty straight-forward unless if they don't have too much tree chain. On this series, the tree management is already supported ENET in i.MX6, and Allwinner platforms. As of now, I'm thinking I can handle reset of the clocks with similar way. > > However, those are only my "feelings" after a glimpse look - I will look > into your code more thoroughly and provide feedback. Please have a look, if possible check even the code size by adding USDHC clocks. > > > > > This series is using recursive calls for handling parenting stuff to > > handle get or set rates, which is fine for handling clock tree > > management as far as U-Boot point-of-view. We have faced similar > > situation as I explained in commit message about Allwinner clocks [2] > > and we ended up going this way. > > I'm not Allwinner expert - but if I may ask - how far away is this > implementation from mainline Linux kernel? > > How difficult is it to port the new code (or update it)? Allwinner clocks also has similar gates, muxs, and with other platform stuff which has too much scope in Linux to use CCM. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Thu, Apr 4, 2019 at 9:26 PM Tom Rini wrote: > > On Thu, Apr 04, 2019 at 12:48:58PM -0300, Fabio Estevam wrote: > > On Thu, Apr 4, 2019 at 7:01 AM Lukasz Majewski wrote: > > > > > Fabio, Stefano what do you think? > > > > > > As we change the clock.c code, IMHO we shall do the new port properly. > > > > I think the CCF solution proposed by Lukasz looks good and it will be > > easier to maintain and sync with the kernel. > > This sounds like an important goal as well, to me. Thanks! I don't know why we rely too-much on Linux to import the big stack code, since the requirement of U-Boot here is to handle the clocks as minimum(as required) as compared to what OS is looking for. Are we looking for handling clock tree management for a whole or looking as required (or as simple) is the main criteria to think about. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Thu, Apr 04, 2019 at 12:48:58PM -0300, Fabio Estevam wrote: > On Thu, Apr 4, 2019 at 7:01 AM Lukasz Majewski wrote: > > > Fabio, Stefano what do you think? > > > > As we change the clock.c code, IMHO we shall do the new port properly. > > I think the CCF solution proposed by Lukasz looks good and it will be > easier to maintain and sync with the kernel. This sounds like an important goal as well, to me. 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 v2 00/10] clk: imx: Add i.MX6 CLK support
On Thu, Apr 4, 2019 at 7:01 AM Lukasz Majewski wrote: > Fabio, Stefano what do you think? > > As we change the clock.c code, IMHO we shall do the new port properly. I think the CCF solution proposed by Lukasz looks good and it will be easier to maintain and sync with the kernel. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm: kirkwood: lsxl: enable DM for SATA
On 03.04.19 23:28, Michael Walle wrote:
Switch from legacy IDE driver to sata_mv driver.
Signed-off-by: Michael Walle
---
configs/lschlv2_defconfig | 4 ++--
configs/lsxhl_defconfig | 4 ++--
include/configs/lsxl.h| 23 ++-
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/configs/lschlv2_defconfig b/configs/lschlv2_defconfig
index e1ff355731..c550798bcd 100644
--- a/configs/lschlv2_defconfig
+++ b/configs/lschlv2_defconfig
@@ -16,7 +16,7 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_MISC_INIT_R=y
# CONFIG_DISPLAY_BOARDINFO is not set
# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_IDE=y
+CONFIG_CMD_SATA=y
CONFIG_CMD_SF=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
@@ -26,7 +26,7 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-lschlv2"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DM=y
-CONFIG_MVSATA_IDE=y
+CONFIG_SATA_MV=y
CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
diff --git a/configs/lsxhl_defconfig b/configs/lsxhl_defconfig
index 48678bdb8f..efcce455a4 100644
--- a/configs/lsxhl_defconfig
+++ b/configs/lsxhl_defconfig
@@ -16,7 +16,7 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_MISC_INIT_R=y
# CONFIG_DISPLAY_BOARDINFO is not set
# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_IDE=y
+CONFIG_CMD_SATA=y
CONFIG_CMD_SF=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
@@ -26,7 +26,7 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-lsxhl"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DM=y
-CONFIG_MVSATA_IDE=y
+CONFIG_SATA_MV=y
CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h
index 72e62658d0..55c4e63325 100644
--- a/include/configs/lsxl.h
+++ b/include/configs/lsxl.h
@@ -76,9 +76,9 @@
"kernel_addr=0x0080\0"\
"ramdisk_addr=0x0100\0" \
"fdt_addr=0x00ff\0" \
- "bootcmd_legacy=ide reset " \
- "&& load ide ${hdpart} ${kernel_addr} /uImage.buffalo " \
- "&& load ide ${hdpart} ${ramdisk_addr} /initrd.buffalo "\
+ "bootcmd_legacy=sata init " \
+ "&& load sata ${hdpart} ${kernel_addr} /uImage.buffalo "\
+ "&& load sata ${hdpart} ${ramdisk_addr} /initrd.buffalo "\
"&& bootm ${kernel_addr} ${ramdisk_addr}\0" \
"bootcmd_net=bootp ${kernel_addr} vmlinuz " \
"&& tftpboot ${ramdisk_addr} initrd.img " \
@@ -86,11 +86,11 @@
"&& tftpboot ${fdt_addr} " CONFIG_FDTFILE " " \
"&& bootz ${kernel_addr} "\
"${ramdisk_addr}:${ramdisk_len} ${fdt_addr}\0"\
- "bootcmd_hdd=ide reset " \
- "&& load ide ${hdpart} ${kernel_addr} /vmlinuz " \
- "&& load ide ${hdpart} ${ramdisk_addr} /initrd.img " \
+ "bootcmd_hdd=sata init " \
+ "&& load sata ${hdpart} ${kernel_addr} /vmlinuz " \
+ "&& load sata ${hdpart} ${ramdisk_addr} /initrd.img " \
"&& setenv ramdisk_len ${filesize} " \
- "&& load ide ${hdpart} ${fdt_addr} /dtb " \
+ "&& load sata ${hdpart} ${fdt_addr} /dtb "\
"&& bootz ${kernel_addr} "\
"${ramdisk_addr}:${ramdisk_len} ${fdt_addr}\0"\
"bootcmd_usb=usb start " \
@@ -131,13 +131,10 @@
#undef CONFIG_RESET_PHY_R
#endif /* CONFIG_CMD_NET */
-#ifdef CONFIG_IDE
-#undef CONFIG_SYS_IDE_MAXBUS
-#define CONFIG_SYS_IDE_MAXBUS 1
-#undef CONFIG_SYS_IDE_MAXDEVICE
-#define CONFIG_SYS_IDE_MAXDEVICE 1
-#define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET
+#ifdef CONFIG_SATA
+#define CONFIG_SYS_SATA_MAX_DEVICE 1
#define CONFIG_SYS_64BIT_LBA
+#define CONFIG_LBA48
#endif
#endif /* _CONFIG_LSXL_H */
Reviewed-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] sata: sata_mv: support kirkwood architecture
On 04.04.19 09:11, Chris Packham wrote: On Thu, Apr 4, 2019 at 10:28 AM Michael Walle wrote: Fix the worng include and offset macros. Typo worng -> wrong Signed-off-by: Michael Walle --- drivers/ata/sata_mv.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index 87ea95f75d..b691107dc0 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -44,11 +44,10 @@ #include #include +#include #if defined(CONFIG_KIRKWOOD) -#include #define SATAHC_BASEKW_SATA_BASE #else -#include #define SATAHC_BASEMVEBU_AXP_SATA_BASE #endif It might be a better idea to update these defines to be definitions for these in the soc.h. We're already doing this for some other peripheral blocks between mach-kirkwood and mach-mvebu. On the other hand SATAHC_BASE already achieves this so maybe it's not worth bothering. I'm fine with this change for now. *If* we change something here, we might make the step towards address probing via DT. But that's some future work, if it's really worth it. As we most likely won't see new platforms with new addresses to support any more. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] sata: sata_mv: add orion-sata compatible string
On 03.04.19 23:28, Michael Walle wrote:
The kirkwood devices are compatible with this driver.
Signed-off-by: Michael Walle
---
drivers/ata/sata_mv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index b691107dc0..2a630d46c1 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1079,6 +1079,7 @@ static int sata_mv_scan(struct udevice *dev)
static const struct udevice_id sata_mv_ids[] = {
{ .compatible = "marvell,armada-370-sata" },
+ { .compatible = "marvell,orion-sata" },
{ }
};
Reviewed-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] sata: sata_mv: support kirkwood architecture
On 03.04.19 23:28, Michael Walle wrote:
Fix the worng include and offset macros.
Signed-off-by: Michael Walle
---
drivers/ata/sata_mv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 87ea95f75d..b691107dc0 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -44,11 +44,10 @@
#include
#include
+#include
#if defined(CONFIG_KIRKWOOD)
-#include
#define SATAHC_BASE KW_SATA_BASE
#else
-#include
#define SATAHC_BASE MVEBU_AXP_SATA_BASE
#endif
@@ -218,8 +217,8 @@ struct crqb {
#define CRQB_SECTCOUNT_COUNT_EXP_MASK (0xff << 8)
#define CRQB_SECTCOUNT_COUNT_EXP_SHIFT8
-#define MVSATA_WIN_CONTROL(w) (MVEBU_AXP_SATA_BASE + 0x30 + ((w) << 4))
-#define MVSATA_WIN_BASE(w) (MVEBU_AXP_SATA_BASE + 0x34 + ((w) << 4))
+#define MVSATA_WIN_CONTROL(w) (SATAHC_BASE + 0x30 + ((w) << 4))
+#define MVSATA_WIN_BASE(w) (SATAHC_BASE + 0x34 + ((w) << 4))
struct eprd {
u32 phyaddr_low;
Reviewed-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sata: sata_mv: use correct format specifier in debug()
On 03.04.19 23:28, Michael Walle wrote:
This fixes a compile error on kirkwood.
Signed-off-by: Michael Walle
---
drivers/ata/sata_mv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index d13695d79e..87ea95f75d 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -727,7 +727,7 @@ static u32 ata_low_level_rw(struct udevice *dev, int port,
lbaint_t blknr,
u8 *addr;
int max_blks;
- debug("%s: %ld %ld\n", __func__, blknr, blkcnt);
+ debug("%s: " LBAFU " " LBAFU "\n", __func__, blknr, blkcnt);
start = blknr;
blks = blkcnt;
Reviewed-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] AE350 SMP support RISC-V
Hi Rick, On Wed, Apr 3, 2019 at 9:37 AM Rick Chen wrote: > > Hi Bin and Lukas > > Rick Chen 於 2019年4月2日 週二 上午9:22寫道： > > > > Hi Bin > > > > Bin Meng 於 2019年4月1日 週一 下午5:01寫道： > > > > > > Hi Rick, > > > > > > On Mon, Apr 1, 2019 at 4:29 PM Andes wrote: > > > > > > > > From: Rick Chen > > > > > > > > Changes in v3: > > > > Patch 1 > > > > - Rename plic_init() as enable_ipi() > > > > - Remove PLIC_BASE_GET() from enable_ipi() > > > > Patch 2 > > > > - Add a space before (PLMT) > > > > Patch 6 > > > > - Fix some mis-alignments > > > > - Recovery isa string of CPU1 > > > > > > > > Changes in v2: > > > > - Drop patch1 and replace by simple-bus driver > > > > - Rename nds_plic as andes_plic > > > > - Move initialize plic to PLIC_BASE_GET() and called automatically > > > > - Rename nds_plmt as andes_plmt > > > > - Recovery dts isa string > > > > > > > > Rick Chen (7): > > > > riscv: Add a SYSCON driver for Andestech's PLIC > > > > riscv: Add a SYSCON driver for Andestech's PLMT > > > > riscv: ae350: disable ATCPIT100 timer > > > > riscv: ax25: Add platform-specific Kconfig options > > > > riscv: ax25: Andes specific cache shall only support in M-mode > > > > riscv: dts: ae350 support SMP > > > > riscv: ae350: enable SMP > > > > > > > > > > Looks good to me. Are you going to send PR to Tom to include SMP > > > series in v2019.04? > > > > > > > Thanks for your review. > > But there seem have some suggestions from Lukas to be fixed. > > After that I will send PR to Tom ASAP. > > > > I have send V4 and Lukas have reviewed it. > When I try to sync to master, I found that there seem > have CONFIG_DEFAULT_DEVICE_TREE failures issue in u-boot.git master. > Troy have reported it actually. But u-boot-riscv.git is fine. > So I am not sure if I shall sync to master now. > Or I shall wait until it has been fixed. > The CONFIG_DEFAULT_DEVICE_TREE fix was reviewed by Lukas and me. I suppose it's good to send PR now? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: renesas: Configure DRAM size from ATF DT fragment
Hi Marek,
On Tue, Apr 02, 2019 at 05:45:29AM +0200, Marek Vasut wrote:
> On 3/13/19 4:25 PM, Eugeniu Rosca wrote:
> > On Tue, Mar 12, 2019 at 10:11:21PM +0100, Marek Vasut wrote:
> >> On 3/12/19 8:30 PM, Eugeniu Rosca wrote:
> >>> Hi Marek cc: Michael
> >>
> >> Hi,
> >>
> >>> On Tue, Mar 5, 2019 at 4:37 AM Marek Vasut wrote:
>
> The ATF can pass additional information via the first four registers,
> x0...x3. The R-Car Gen3 with mainline ATF, register x1 contains pointer
> to a device tree with platform information. Parse this device tree and
> extract DRAM size information from it. This is useful on systems where
> the DRAM size can vary between configurations.
> >>>
> >>> 1. Do the ATF changes supporting this feature already exist in mainline
> >>> ATF?
> >>
> >> Yes, for quite some time, see
> >> commit 1d85c4bd5b6291b99feb2409525c96f0c1744328
> >> plat: rcar: Pass DTB with DRAM layout from BL2 to next stages
> >
> > That's helpful, but I think such information should go by default into
> > commit description.
> >
> > [..]
> >
> > Besides the above, I wonder why this patch duplicates code across three
> > board files? Could this code be relocated to some common area like [1]?
>
> That's the plan.
I look forward to seeing v2 then, since this would allow us not
duplicating this code over and over again in the board-specific files
of the customer R-Car3 targets.
>
> > FWIW building the latter could be re-enabled by reverting the Makefile
> > changes from v2018.01-rc1 commit [2].
>
> I prefer a more progressive approach, that is applying patches, rather
> than reverting.
"reverting" is used here figuratively, suggesting to undo the Makefile
changes added by commit [2], in order to create/restore the R-Car3
common/board-independent space. It doesn't ask creating a revert commit.
> > To differentiate between the boards which expect/require the ATF args
> > and those which don't, I guess that run-time (IS_ENABLED) checking of
> > a newly created Kconfig symbol, e.g. SUPPORTS_ATF_ARGS or similar,
> > selected on per-board basis, could do the job?
>
> No, the code should auto-detect whether the ATF supports the DT passing
> or not.
Great. Less build-time options the better.
> > Note that we already face the need to have an area for Android features
> > common between all Gen3 boards, so I think reviving [1] is inevitable.
> >
> > [1] board/renesas/rcar-common/common.c
> > [2] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=e23eb942ad10
> > ("ARM: rmobile: Stop using rcar-common/common.c on Gen3")
> >
> > Best regards,
> > Eugeniu.
> >
> --
> Best regards,
> Marek Vasut
I would appreciate being CC-ed in v2, if possible. Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path【请注意，邮件由s...@google.com代发】
Hi Simon, On 04/04/2019 03:57 AM, Simon Glass wrote: > Hi Kever, > > On Sat, 30 Mar 2019 at 15:18, Simon Glass wrote: >> Hi Kever, >> >> On Wed, 27 Mar 2019 at 21:01, Kever Yang wrote: >>> Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common >>> header file path, so that we can get the correct path directly. >> Can you give a few more details on the reason for this change? I >> cannot see the benefit? > OK I figured it out from the context. > > Do you have interest in supporting multiple SoCs with a single build? Is there other vendor support multiple SoCs? For Rockchip platform, I don't think it's easy to do it now, the different for different SoCs now: - SoC init, eg. debug uart init, sgrf setting and other one time init setting; - clock driver; - pinctrl driver, David still working on it, but the target is for minimum size for each SoC, but not enable common code in pinctrl-core as much as possible, so this is the opposite way with support multiple SoCs support. I would like to use common board/spl/tpl files first, and then step to step to see what we need to do. Thanks, - Kever > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq
On Mon, Apr 01, 2019 at 04:08:33PM +0800, Bin Meng wrote: > On Mon, Apr 1, 2019 at 3:48 PM Christian Gmeiner > wrote: > > Am Fr., 15. März 2019 um 09:03 Uhr schrieb Bin Meng : > > > On Wed, Mar 13, 2019 at 5:27 PM Christian Gmeiner > > > wrote: > > > > Am Mo., 11. März 2019 um 15:41 Uhr schrieb Bin Meng > > > > : > > > > > On Wed, Mar 6, 2019 at 7:09 PM Andy Shevchenko > > > > > wrote: > > > > > > On Thu, Feb 28, 2019 at 11:29:50AM +0800, Bin Meng wrote: > > > > > > > On Thu, May 24, 2018 at 12:00 PM Bin Meng > > > > > > > wrote: > > > > > > > > On Thu, Apr 12, 2018 at 4:07 PM, Christian Gmeiner > > > > > > > > wrote: > > > > We need to set these two msr registers to the values they provided to > > > > us. > > > > These msr register should be described in #29324. > > > > > > Could you please provide details about these 2 MSR registers? And is > > > there any official document from Intel about what is the behavior of > > > having EIST disabled? > > > > > > > I only got an excerpt of two pages describing these 2 MSR and I am quite > > sure > > I am not allowed to share these. As I wrote these MSR should be documented > > in #29324 (which I do not have access to). > > > > Thanks for sharing the information. > > Andy, do you have access to the #29324, and check whether it has some > explanation about my assumption about Intel EIST? I have no idea what that number means. Christian might sent me (*) at least a title of the document for easy search. *) privately to @intel.com address, for example. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] pico-imx6ul, pico-imx7d: Explain how to use eMMC user partition
Hi Otavio, On Thu, Apr 4, 2019 at 9:41 AM Otavio Salvador wrote: > It is really weird and it always work for us here. Vanessa and > Richard, could you give it a try? Once the board is "unlocked" your instructions work fine. Try "locking" it first and then try your instructions again. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pinctrl: renesas: Fix linker error when PINCTRL_PFC=n
Hi Marek, On Thu, Apr 04, 2019 at 03:36:45AM +0200, Marek Vasut wrote: [..] > I was thinking about this patch further and I think the best way forward > would be to extend the pinmux/pinctrl API with a callback to set a pin > as GPIO and then just call that API from the GPIO driver. That would be > the generic solution and would make this whole > sh_pfc_config_mux_for_gpio() go away altogether. I don't think anybody is going to contradict you, as long as your solution resolves/prevents the build error reported in this thread. Since you have the best vision of it, I assume you take the ownership of the change and CC the relevant people upon patch submission? Best regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] pico-imx6ul, pico-imx7d: Explain how to use eMMC user partition
On Wed, Apr 3, 2019 at 9:22 PM Fabio Estevam wrote: > On Wed, Apr 3, 2019 at 3:45 PM Otavio Salvador > wrote: > > On Fri, Mar 22, 2019 at 2:53 PM Otavio Salvador > > wrote: > > > The default U-Boot environment expects the use of eMMC user > > > partition. To ensure we are using the proper eMMC partition for boot > > > we need to run the `mmc partconf` command. > > > > > > This patch updates the README instructions to avoid users to follow > > > misleading instructions. > > > > > > Signed-off-by: Otavio Salvador > > > > Could this to be applied? > > The instructions on this patch did not work for me. > > It only worked if I called 'mmc partconf 0 0 0 0' after the DFU command. It is really weird and it always work for us here. Vanessa and Richard, could you give it a try? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] pico-imx7d: Add support for BL33 case
On Wed, Apr 3, 2019 at 9:00 AM Jun Nie wrote: > And for the file name pico-imx7d_bl33_defconfig, > pico-pi-imx7d_bl33_defconfig should be better in my later thought. > Because a concrete device tree source file should be specified in > defconfig file, so that public key can be stored in u-boot FDT blob > for kernel/initramfs FIT signature verification. What's your comments? The FIT image might have them all, no? It would allow a single binary to work on all baseboards, giving a very nice user experience. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
This fixes relaction isses with the PSCI_TABLE entries in the psci_32_table and psci_64_table. When using 32-bit adress pointers relocation was not being applied to the tables, causing PSCI handlers to point to the un-relocated code area. By using 64-bit data relocation is properly applied. The handlers are thus in the "secure data" area, which is protected by /memreserve/ in the FDT. Signed-off-by: Lars Povlsen --- arch/arm/cpu/armv8/psci.S | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/arm/cpu/armv8/psci.S b/arch/arm/cpu/armv8/psci.S index 358df8fee9..b4568cf053 100644 --- a/arch/arm/cpu/armv8/psci.S +++ b/arch/arm/cpu/armv8/psci.S @@ -19,8 +19,8 @@ /* PSCI function and ID table definition*/ #define PSCI_TABLE(__id, __fn) \ - .word __id; \ - .word __fn + .quad __id; \ + .quad __fn .pushsection ._secure.text, "ax" @@ -132,16 +132,15 @@ PSCI_TABLE(0, 0) /* Caller must put PSCI function-ID table base in x9 */ handle_psci: psci_enter -1: ldr x10, [x9] /* Load PSCI function table */ - ubfx x11, x10, #32, #32 - ubfx x10, x10, #0, #32 +1: ldr x10, [x9] /* Load PSCI function table */ cbz x10, 3f /* If reach the end, bail out */ cmp x10, x0 b.eq2f /* PSCI function found */ - add x9, x9, #8 /* If not match, try next entry */ + add x9, x9, #16 /* If not match, try next entry */ b 1b -2: blr x11 /* Call PSCI function */ +2: ldr x11, [x9, #8] /* Load PSCI function */ + blr x11 /* Call PSCI function */ psci_return 3: mov x0, #ARM_PSCI_RET_NI -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
This fixes relaction isses with the PSCI_TABLE entries in the psci_32_table and psci_64_table. When using 32-bit adress pointers relocation was not being applied to the tables, causing PSCI handlers to point to the un-relocated code area. By using 64-bit data relocation is properly applied. The handlers are thus in the "secure data" area, which is protected by /memreserve/ in the FDT. Signed-off-by: Lars Povlsen --- arch/arm/cpu/armv8/psci.S | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/arm/cpu/armv8/psci.S b/arch/arm/cpu/armv8/psci.S index 358df8fee9..b4568cf053 100644 --- a/arch/arm/cpu/armv8/psci.S +++ b/arch/arm/cpu/armv8/psci.S @@ -19,8 +19,8 @@ /* PSCI function and ID table definition*/ #define PSCI_TABLE(__id, __fn) \ - .word __id; \ - .word __fn + .quad __id; \ + .quad __fn .pushsection ._secure.text, "ax" @@ -132,16 +132,15 @@ PSCI_TABLE(0, 0) /* Caller must put PSCI function-ID table base in x9 */ handle_psci: psci_enter -1: ldr x10, [x9] /* Load PSCI function table */ - ubfx x11, x10, #32, #32 - ubfx x10, x10, #0, #32 +1: ldr x10, [x9] /* Load PSCI function table */ cbz x10, 3f /* If reach the end, bail out */ cmp x10, x0 b.eq2f /* PSCI function found */ - add x9, x9, #8 /* If not match, try next entry */ + add x9, x9, #16 /* If not match, try next entry */ b 1b -2: blr x11 /* Call PSCI function */ +2: ldr x11, [x9, #8] /* Load PSCI function */ + blr x11 /* Call PSCI function */ psci_return 3: mov x0, #ARM_PSCI_RET_NI -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/5] Arm: imx7d-pico: Import all Linux device tree for Pico i.MX7D SOM
This patch imports the Linux kernel base board imx7d-pico.dtsi,
pi board imx7d-pico-pi.dts and hobbit board imx7d-pico-hobbit.dts
from Linux v5.1-rc1.
Signed-off-by: Joris Offouga
---
arch/arm/dts/Makefile | 5 +-
arch/arm/dts/imx7d-pico-hobbit.dts | 105 +++
arch/arm/dts/imx7d-pico-pi.dts | 93 ++
arch/arm/dts/imx7d-pico.dtsi | 586 +
4 files changed, 788 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/imx7d-pico-hobbit.dts
create mode 100644 arch/arm/dts/imx7d-pico-pi.dts
create mode 100644 arch/arm/dts/imx7d-pico.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0e2ffdb..e30c57b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -544,7 +544,10 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
imx7d-sdb-qspi.dtb \
imx7-colibri-emmc.dtb \
imx7-colibri-rawnand.dtb \
- imx7s-warp.dtb
+ imx7s-warp.dtb \
+ imx7d-pico-pi.dtb \
+ imx7d-pico-hobbit.dtb
+
dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
diff --git a/arch/arm/dts/imx7d-pico-hobbit.dts
b/arch/arm/dts/imx7d-pico-hobbit.dts
new file mode 100644
index 000..98604f0
--- /dev/null
+++ b/arch/arm/dts/imx7d-pico-hobbit.dts
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+//
+// Copyright 2017 NXP
+
+#include "imx7d-pico.dtsi"
+
+/ {
+ model = "TechNexion PICO-IMX7D Board using Hobbit baseboard";
+ compatible = "technexion,imx7d-pico-hobbit", "fsl,imx7d";
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_leds>;
+
+ led {
+ label = "gpio-led";
+ gpios = < 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "imx7-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_master>;
+ simple-audio-card,frame-master = <_master>;
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ dailink_master: simple-audio-card,codec {
+ sound-dai = <>;
+ clocks = < IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ };
+ };
+};
+
+ {
+ sgtl5000: codec@a {
+ #sound-dai-cells = <0>;
+ reg = <0x0a>;
+ compatible = "fsl,sgtl5000";
+ clocks = < IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ VDDA-supply = <_2p5v>;
+ VDDIO-supply = <_vref_1v8>;
+ };
+};
+
+ {
+ status = "okay";
+
+ adc081c: adc@50 {
+ compatible = "ti,adc081c";
+ reg = <0x50>;
+ vref-supply = <_3p3v>;
+ };
+};
+
+ {
+ ads7846@0 {
+ reg = <0>;
+ compatible = "ti,ads7846";
+ interrupt-parent = <>;
+ interrupts = <7 0>;
+ spi-max-frequency = <100>;
+ pendown-gpio = < 7 0>;
+ vcc-supply = <_3p3v>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <4095>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4095>;
+ ti,pressure-max = /bits/ 16 <1024>;
+ ti,x-plate-ohms = /bits/ 16 <90>;
+ ti,y-plate-ohms = /bits/ 16 <90>;
+ ti,debounce-max = /bits/ 16 <70>;
+ ti,debounce-tol = /bits/ 16 <3>;
+ ti,debounce-rep = /bits/ 16 <2>;
+ ti,settle-delay-usec = /bits/ 16 <150>;
+ wakeup-source;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA00__GPIO2_IO0 0x14
+ MX7D_PAD_EPDC_DATA01__GPIO2_IO1 0x14
+ MX7D_PAD_EPDC_DATA02__GPIO2_IO2 0x14
+ MX7D_PAD_EPDC_DATA03__GPIO2_IO3 0x14
+ MX7D_PAD_EPDC_DATA05__GPIO2_IO5 0x14
+ MX7D_PAD_EPDC_DATA12__GPIO2_IO120x14
+ MX7D_PAD_EPDC_DATA07__GPIO2_IO7 0x14
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA13__GPIO2_IO130x14
+ >;
+ };
+};
\ No newline at end of file
diff --git a/arch/arm/dts/imx7d-pico-pi.dts b/arch/arm/dts/imx7d-pico-pi.dts
new file mode 100644
index 000..66ca590
--- /dev/null
+++ b/arch/arm/dts/imx7d-pico-pi.dts
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+//
+// Copyright 2017 NXP
+
+#include "imx7d-pico.dtsi"
+
+/ {
+ model = "TechNexion PICO-IMX7D Board and PI baseboard";
+
[U-Boot] [PATCH V2 3/5] pico-imx7d: defconfig Enable DM gpio pinctrl and pinctrl_imx7
This patch is necessary for convert this board to dm driver model
DM GPIO requires gpio_request() to be called explicitly before
doing any gpio operation
Signed-off-by: Joris Offouga
---
board/technexion/pico-imx7d/pico-imx7d.c | 4 +++-
configs/pico-hobbit-imx7d_defconfig | 3 +++
configs/pico-imx7d_defconfig | 3 +++
configs/pico-pi-imx7d_defconfig | 3 +++
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c
b/board/technexion/pico-imx7d/pico-imx7d.c
index 767d13d..3b9be45 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -165,7 +165,7 @@ static iomux_v3_cfg_t const fec1_pads[] = {
static void setup_iomux_fec(void)
{
imx_iomux_v3_setup_multiple_pads(fec1_pads, ARRAY_SIZE(fec1_pads));
-
+ gpio_request(FEC1_RST_GPIO, "phy_rst");
gpio_direction_output(FEC1_RST_GPIO, 0);
udelay(500);
gpio_set_value(FEC1_RST_GPIO, 1);
@@ -291,6 +291,8 @@ static iomux_v3_cfg_t const lcd_pads[] = {
void setup_lcd(void)
{
imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
+ gpio_request(IMX_GPIO_NR(1, 11), "lcd_brightness");
+ gpio_request(IMX_GPIO_NR(1, 6), "lcd_enable");
/* Set Brightness to high */
gpio_direction_output(IMX_GPIO_NR(1, 11) , 1);
/* Set LCD enable to high */
diff --git a/configs/pico-hobbit-imx7d_defconfig
b/configs/pico-hobbit-imx7d_defconfig
index 75eab28..a830aa8 100644
--- a/configs/pico-hobbit-imx7d_defconfig
+++ b/configs/pico-hobbit-imx7d_defconfig
@@ -27,6 +27,9 @@ CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_CMD_BOOTMENU=y
# CONFIG_CMD_IMI is not set
# CONFIG_CMD_XIMG is not set
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX7=y
+CONFIG_DM_GPIO=y
CONFIG_CMD_SPL=y
CONFIG_CMD_SPL_WRITE_SIZE=0x2
CONFIG_CMD_DFU=y
diff --git a/configs/pico-imx7d_defconfig b/configs/pico-imx7d_defconfig
index beee839..ec7faf9 100644
--- a/configs/pico-imx7d_defconfig
+++ b/configs/pico-imx7d_defconfig
@@ -27,6 +27,9 @@ CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_CMD_BOOTMENU=y
# CONFIG_CMD_IMI is not set
# CONFIG_CMD_XIMG is not set
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX7=y
+CONFIG_DM_GPIO=y
CONFIG_CMD_SPL=y
CONFIG_CMD_SPL_WRITE_SIZE=0x2
CONFIG_CMD_DFU=y
diff --git a/configs/pico-pi-imx7d_defconfig b/configs/pico-pi-imx7d_defconfig
index 05d5fe5..662492a 100644
--- a/configs/pico-pi-imx7d_defconfig
+++ b/configs/pico-pi-imx7d_defconfig
@@ -27,6 +27,9 @@ CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_CMD_BOOTMENU=y
# CONFIG_CMD_IMI is not set
# CONFIG_CMD_XIMG is not set
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX7=y
+CONFIG_DM_GPIO=y
CONFIG_CMD_SPL=y
CONFIG_CMD_SPL_WRITE_SIZE=0x2
CONFIG_CMD_DFU=y
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 0/5] Convert Pico i.MX7 to DM
This series convert Pico i.MX7 and variant board to DM. The following options have been enabled: -CONFIG_DM_GPIO -CONFIG_DM_EMMC Signed-off-by: Joris Offouga --- Change in v2: - add missing dtb in Makefile Joris Offouga (5): Arm: imx7d-pico: Import all Linux device tree for Pico i.MX7D SOM pico-imx7d: defconfig: Add DT file hooks pico-imx7d: defconfig Enable DM gpio pinctrl and pinctrl_imx7 pico-imx7d: Convert DM MMC pico-imx7d: Increase u-boot size for dfu request arch/arm/dts/Makefile| 5 +- arch/arm/dts/imx7d-pico-hobbit.dts | 105 ++ arch/arm/dts/imx7d-pico-pi.dts | 93 + arch/arm/dts/imx7d-pico.dtsi | 590 +++ board/technexion/pico-imx7d/pico-imx7d.c | 42 +-- board/technexion/pico-imx7d/spl.c| 38 ++ configs/pico-hobbit-imx7d_defconfig | 7 +- configs/pico-imx7d_defconfig | 7 +- configs/pico-pi-imx7d_defconfig | 7 +- include/configs/pico-imx7d.h | 2 +- 10 files changed, 852 insertions(+), 44 deletions(-) create mode 100644 arch/arm/dts/imx7d-pico-hobbit.dts create mode 100644 arch/arm/dts/imx7d-pico-pi.dts create mode 100644 arch/arm/dts/imx7d-pico.dtsi -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 2/5] pico-imx7d: defconfig: Add DT file hooks
This patch adds DT file hooks for Pico i.MX7D SOM and variant boards Signed-off-by: Joris Offouga --- configs/pico-hobbit-imx7d_defconfig | 3 ++- configs/pico-imx7d_defconfig| 3 ++- configs/pico-pi-imx7d_defconfig | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/configs/pico-hobbit-imx7d_defconfig b/configs/pico-hobbit-imx7d_defconfig index f58d517..75eab28 100644 --- a/configs/pico-hobbit-imx7d_defconfig +++ b/configs/pico-hobbit-imx7d_defconfig @@ -16,6 +16,8 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" CONFIG_DEFAULT_FDT_FILE="imx7d-pico-hobbit.dtb" +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="imx7d-pico-hoobit" CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_USB_HOST_SUPPORT=y @@ -58,4 +60,3 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_VIDEO=y -CONFIG_OF_LIBFDT=y diff --git a/configs/pico-imx7d_defconfig b/configs/pico-imx7d_defconfig index 7e13923..beee839 100644 --- a/configs/pico-imx7d_defconfig +++ b/configs/pico-imx7d_defconfig @@ -16,6 +16,8 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" CONFIG_DEFAULT_FDT_FILE="ask" +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="imx7d-pico" CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_USB_HOST_SUPPORT=y @@ -58,4 +60,3 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_VIDEO=y -CONFIG_OF_LIBFDT=y diff --git a/configs/pico-pi-imx7d_defconfig b/configs/pico-pi-imx7d_defconfig index c8ac2ff..05d5fe5 100644 --- a/configs/pico-pi-imx7d_defconfig +++ b/configs/pico-pi-imx7d_defconfig @@ -16,6 +16,8 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd" CONFIG_DEFAULT_FDT_FILE="imx7d-pico-pi.dtb" +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="imx7d-pico-pi" CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_USB_HOST_SUPPORT=y @@ -58,4 +60,3 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_VIDEO=y -CONFIG_OF_LIBFDT=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 5/5] pico-imx7d: Increase u-boot size for dfu request
After DM conversion, the size of U-Boot binary to increase. Previous size is 480K after DM Conversion the new size is 557K So it's necessary to increase the dfu request for store u-boot-dtb.img in eMMC. Signed-off-by: Joris Offouga --- include/configs/pico-imx7d.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h index 0f6d6b7..04d316f 100644 --- a/include/configs/pico-imx7d.h +++ b/include/configs/pico-imx7d.h @@ -46,7 +46,7 @@ #define CONFIG_DFU_ENV_SETTINGS \ "dfu_alt_info=" \ "spl raw 0x2 0x400;" \ - "u-boot raw 0x8a 0x400;" \ + "u-boot raw 0x8a 0x1000;" \ "/boot/zImage ext4 0 1;" \ "/boot/imx7d-pico-hobbit.dtb ext4 0 1;" \ "/boot/imx7d-pico-pi.dtb ext4 0 1;" \ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 16/19] p2371-2180: Pass Ethernet MAC to the kernel
From: Thierry Reding
Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.
Signed-off-by: Thierry Reding
---
board/nvidia/p2371-2180/p2371-2180.c | 50
configs/p2371-2180_defconfig | 1 +
2 files changed, 51 insertions(+)
diff --git a/board/nvidia/p2371-2180/p2371-2180.c
b/board/nvidia/p2371-2180/p2371-2180.c
index 212037da5ac0..a444d692d7ea 100644
--- a/board/nvidia/p2371-2180/p2371-2180.c
+++ b/board/nvidia/p2371-2180/p2371-2180.c
@@ -5,9 +5,12 @@
*/
#include
+#include
#include
+#include
#include
#include
+#include
#include "../p2571/max77620_init.h"
#include "pinmux-config-p2371-2180.h"
@@ -94,3 +97,50 @@ int tegra_pcie_board_init(void)
return 0;
}
#endif /* PCI */
+
+static void ft_mac_address_setup(void *fdt)
+{
+ const void *cboot_fdt = (const void *)cboot_boot_x0;
+ uint8_t mac[ETH_ALEN], local_mac[ETH_ALEN];
+ const char *path;
+ int offset, err;
+
+ err = cboot_get_ethaddr(cboot_fdt, local_mac);
+ if (err < 0)
+ memset(local_mac, 0, ETH_ALEN);
+
+ path = fdt_get_alias(fdt, "ethernet");
+ if (!path)
+ return;
+
+ debug("ethernet alias found: %s\n", path);
+
+ offset = fdt_path_offset(fdt, path);
+ if (offset < 0) {
+ printf("ethernet alias points to absent node %s\n", path);
+ return;
+ }
+
+ if (is_valid_ethaddr(local_mac)) {
+ err = fdt_setprop(fdt, offset, "local-mac-address", local_mac,
+ ETH_ALEN);
+ if (!err)
+ debug("Local MAC address set: %pM\n", local_mac);
+ }
+
+ if (eth_env_get_enetaddr("ethaddr", mac)) {
+ if (memcmp(local_mac, mac, ETH_ALEN) != 0) {
+ err = fdt_setprop(fdt, offset, "mac-address", mac,
+ ETH_ALEN);
+ if (!err)
+ debug("MAC address set: %pM\n", mac);
+ }
+ }
+}
+
+int ft_board_setup(void *fdt, bd_t *bd)
+{
+ ft_mac_address_setup(fdt);
+
+ return 0;
+}
diff --git a/configs/p2371-2180_defconfig b/configs/p2371-2180_defconfig
index 4923d330de6c..0ee4913a0469 100644
--- a/configs/p2371-2180_defconfig
+++ b/configs/p2371-2180_defconfig
@@ -5,6 +5,7 @@ CONFIG_TEGRA210=y
CONFIG_TARGET_P2371_2180=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_OF_SYSTEM_SETUP=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_CONSOLE_MUX=y
CONFIG_SYS_STDIO_DEREGISTER=y
CONFIG_SYS_PROMPT="Tegra210 (P2371-2180) # "
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 12/19] ARM: tegra: Unify Tegra186 builds
From: Thierry Reding
Tegra186 build are currently dealt with in very special ways, which is
because Tegra186 is fundamentally different in many respects. It is no
longer necessary to do many of the low-level programming because early
boot firmware will already have taken care of it.
Unfortunately, separating Tegra186 builds from the rest in this way
makes it difficult to share code with prior generations of Tegra. With
all of the low-level programming code behind Kconfig guards, the build
for Tegra186 can again be unified.
As a side-effect, and partial reason for this change, other Tegra SoC
generations can now make use of the code that deals with taking over a
boot from earlier bootloaders. This used to be nvtboot, but has been
replaced by cboot nowadays. Rename the files and functions related to
this to avoid confusion. The implemented protocols are unchanged.
Signed-off-by: Thierry Reding
---
Changes in v4:
- consistently use /chosen/nvidia,ether-mac property
Changes in v3:
- load cboot DTB address to fdt_addr instead of fdtaddr
arch/arm/include/asm/arch-tegra/cboot.h | 39
arch/arm/mach-tegra/Makefile | 4 +-
arch/arm/mach-tegra/board.c | 23 ++
arch/arm/mach-tegra/board186.c| 32 ---
arch/arm/mach-tegra/board2.c | 21 ++
.../{tegra186/nvtboot_board.c => cboot.c} | 200 --
.../{tegra186/nvtboot_ll.S => cboot_ll.S} | 12 +-
arch/arm/mach-tegra/tegra186/Makefile | 4 -
arch/arm/mach-tegra/tegra186/nvtboot_mem.c| 172 ---
board/nvidia/p2771-/p2771-.c | 10 +-
10 files changed, 278 insertions(+), 239 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra/cboot.h
delete mode 100644 arch/arm/mach-tegra/board186.c
rename arch/arm/mach-tegra/{tegra186/nvtboot_board.c => cboot.c} (56%)
rename arch/arm/mach-tegra/{tegra186/nvtboot_ll.S => cboot_ll.S} (57%)
delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_mem.c
diff --git a/arch/arm/include/asm/arch-tegra/cboot.h
b/arch/arm/include/asm/arch-tegra/cboot.h
new file mode 100644
index ..b3441ec178b3
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/cboot.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 NVIDIA Corporation. All rights reserved.
+ */
+
+#ifndef _TEGRA_CBOOT_H_
+#define _TEGRA_CBOOT_H_
+
+#ifdef CONFIG_ARM64
+extern unsigned long cboot_boot_x0;
+
+void cboot_save_boot_params(unsigned long x0, unsigned long x1,
+ unsigned long x2, unsigned long x3);
+int cboot_dram_init(void);
+int cboot_dram_init_banksize(void);
+ulong cboot_get_usable_ram_top(ulong total_size);
+#else
+static inline void cboot_save_boot_params(unsigned long x0, unsigned long x1,
+ unsigned long x2, unsigned long x3)
+{
+}
+
+static inline int cboot_dram_init(void)
+{
+ return -ENOSYS;
+}
+
+static inline int cboot_dram_init_banksize(void)
+{
+ return -ENOSYS;
+}
+
+static inline ulong cboot_get_usable_ram_top(ulong total_size)
+{
+ return 0;
+}
+#endif
+
+#endif
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f8bc65aa8b18..41ba674edff4 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -5,7 +5,6 @@
# (C) Copyright 2000-2008
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-ifndef CONFIG_TEGRA186
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
obj-y += cpu.o
@@ -20,9 +19,8 @@ obj-$(CONFIG_TEGRA_CLKRST) += clock.o
obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
obj-$(CONFIG_TEGRA_PMC) += powergate.o
obj-y += xusb-padctl-dummy.o
-endif
-obj-$(CONFIG_ARM64) += arm64-mmu.o
+obj-$(CONFIG_ARM64) += arm64-mmu.o cboot_ll.o cboot.o
obj-y += dt-setup.o
obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
obj-$(CONFIG_TEGRA_GPU) += gpu.o
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index 59d2f347485d..c3ba00811e83 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -46,6 +47,21 @@ void save_boot_params(unsigned long r0, unsigned long r1,
unsigned long r2,
unsigned long r3)
{
from_spl = r0 != UBOOT_NOT_LOADED_FROM_SPL;
+
+ /*
+* The logic for this is somewhat indirect. The purpose of the marker
+* (UBOOT_NOT_LOADED_FROM_SPL) is in fact used to determine if U-Boot
+* was loaded from a read-only instance of itself, which is something
+* that can happen in secure boot setups. So basically the presence
+* of the marker is an indication that U-Boot was loaded by one such
+* special variant of U-Boot. Conversely, the absence of the marker
+* indicates that this instance of U-Boot was loaded by something
+* other than a special U-Boot. This could be SPL, but it could just
+*
[U-Boot] [PATCH v4 14/19] ARM: tegra: Implement cboot_get_ethaddr()
From: Thierry Reding
This function will attempt to look up an ethernet address in the DTB
that was passed in from cboot. It does so by first trying to locate the
primary ethernet device for the board (identified by the "ethernet"
alias) and if found, reads the "local-mac-address" property. If the
"ethernet" alias does not exist, or if it points to a device tree node
that doesn't exist, or if the device tree node that it points to does
not have a "local-mac-address" property or if the value is invalid, it
will fall back to the legacy mechanism of looking for the MAC address
stored in the "nvidia,ethernet-mac" or "nvidia,ether-mac" properties of
the "/chosen" node.
Signed-off-by: Thierry Reding
---
Changes in v4:
- also check the /chosen/nvidia,ethernet-mac property for compatibility
with Tegra210
Changes in v2:
- make dummy static inline to avoid duplicate definitions
arch/arm/include/asm/arch-tegra/cboot.h | 6 ++
arch/arm/mach-tegra/cboot.c | 92 -
2 files changed, 81 insertions(+), 17 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/cboot.h
b/arch/arm/include/asm/arch-tegra/cboot.h
index b3441ec178b3..021c24617575 100644
--- a/arch/arm/include/asm/arch-tegra/cboot.h
+++ b/arch/arm/include/asm/arch-tegra/cboot.h
@@ -14,6 +14,7 @@ void cboot_save_boot_params(unsigned long x0, unsigned long
x1,
int cboot_dram_init(void);
int cboot_dram_init_banksize(void);
ulong cboot_get_usable_ram_top(ulong total_size);
+int cboot_get_ethaddr(const void *fdt, uint8_t mac[ETH_ALEN]);
#else
static inline void cboot_save_boot_params(unsigned long x0, unsigned long x1,
unsigned long x2, unsigned long x3)
@@ -34,6 +35,11 @@ static inline ulong cboot_get_usable_ram_top(ulong
total_size)
{
return 0;
}
+
+static inline int cboot_get_ethaddr(const void *fdt, uint8_t mac[ETH_ALEN])
+{
+ return -ENOSYS;
+}
#endif
#endif
diff --git a/arch/arm/mach-tegra/cboot.c b/arch/arm/mach-tegra/cboot.c
index a302ca45f39b..6c6d06d89a5d 100644
--- a/arch/arm/mach-tegra/cboot.c
+++ b/arch/arm/mach-tegra/cboot.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -465,46 +466,103 @@ static int set_fdt_addr(void)
* Attempt to use /chosen/nvidia,ether-mac in the cboot DTB to U-Boot's
* ethaddr environment variable if possible.
*/
-static int set_ethaddr_from_cboot(void)
+static int cboot_get_ethaddr_legacy(const void *fdt, uint8_t mac[ETH_ALEN])
{
- const void *cboot_blob = (void *)cboot_boot_x0;
- int ret, node, len;
- const u32 *prop;
-
- /* Already a valid address in the environment? If so, keep it */
- if (env_get("ethaddr"))
- return 0;
-
- node = fdt_path_offset(cboot_blob, "/chosen");
+ const char *const properties[] = {
+ "nvidia,ethernet-mac",
+ "nvidia,ether-mac",
+ };
+ const char *prop;
+ unsigned int i;
+ int node, len;
+
+ node = fdt_path_offset(fdt, "/chosen");
if (node < 0) {
printf("Can't find /chosen node in cboot DTB\n");
return node;
}
- prop = fdt_getprop(cboot_blob, node, "nvidia,ether-mac", );
+
+ for (i = 0; i < ARRAY_SIZE(properties); i++) {
+ prop = fdt_getprop(fdt, node, properties[i], );
+ if (prop)
+ break;
+ }
+
if (!prop) {
- printf("Can't find nvidia,ether-mac property in cboot DTB\n");
+ printf("Can't find Ethernet MAC address in cboot DTB\n");
return -ENOENT;
}
- ret = env_set("ethaddr", (void *)prop);
- if (ret) {
- printf("Failed to set ethaddr from cboot DTB: %d\n", ret);
- return ret;
+ eth_parse_enetaddr(prop, mac);
+
+ if (!is_valid_ethaddr(mac)) {
+ printf("Invalid MAC address: %s\n", prop);
+ return -EINVAL;
}
+ debug("Legacy MAC address: %pM\n", mac);
+
return 0;
}
+int cboot_get_ethaddr(const void *fdt, uint8_t mac[ETH_ALEN])
+{
+ int node, len, err = 0;
+ const uchar *prop;
+ const char *path;
+
+ path = fdt_get_alias(fdt, "ethernet");
+ if (!path) {
+ err = -ENOENT;
+ goto out;
+ }
+
+ debug("ethernet alias found: %s\n", path);
+
+ node = fdt_path_offset(fdt, path);
+ if (node < 0) {
+ err = -ENOENT;
+ goto out;
+ }
+
+ prop = fdt_getprop(fdt, node, "local-mac-address", );
+ if (!prop) {
+ err = -ENOENT;
+ goto out;
+ }
+
+ if (len != ETH_ALEN) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ debug("MAC address: %pM\n", prop);
+ memcpy(mac, prop, ETH_ALEN);
+
+out:
+ if (err < 0)
+ err = cboot_get_ethaddr_legacy(fdt, mac);
+
+
[U-Boot] [PATCH v4 19/19] ARM: tegra: Import cbootargs value from cboot DTB
From: Thierry Reding
Read the boot arguments passed by cboot via the /chosen/bootargs
property and store it in the cbootargs environment variable.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/cboot.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/mach-tegra/cboot.c b/arch/arm/mach-tegra/cboot.c
index 6c6d06d89a5d..3f42ffeb73c0 100644
--- a/arch/arm/mach-tegra/cboot.c
+++ b/arch/arm/mach-tegra/cboot.c
@@ -8,7 +8,9 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -546,10 +548,49 @@ out:
return err;
}
+static char *strip(const char *ptr)
+{
+ const char *end;
+
+ while (*ptr && isblank(*ptr))
+ ptr++;
+
+ /* empty string */
+ if (*ptr == '\0')
+ return strdup(ptr);
+
+ end = ptr;
+
+ while (end[1])
+ end++;
+
+ while (isblank(*end))
+ end--;
+
+ return strndup(ptr, end - ptr + 1);
+}
+
+static char *cboot_get_bootargs(const void *fdt)
+{
+ const char *args;
+ int offset, len;
+
+ offset = fdt_path_offset(fdt, "/chosen");
+ if (offset < 0)
+ return NULL;
+
+ args = fdt_getprop(fdt, offset, "bootargs", );
+ if (!args)
+ return NULL;
+
+ return strip(args);
+}
+
int cboot_late_init(void)
{
const void *fdt = (const void *)cboot_boot_x0;
uint8_t mac[ETH_ALEN];
+ char *bootargs;
int err;
set_calculated_env_vars();
@@ -564,5 +605,11 @@ int cboot_late_init(void)
if (!err)
eth_env_set_enetaddr("ethaddr", mac);
+ bootargs = cboot_get_bootargs(fdt);
+ if (bootargs) {
+ env_set("cbootargs", bootargs);
+ free(bootargs);
+ }
+
return 0;
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 18/19] lib: Implement strndup()
From: Thierry Reding
Signed-off-by: Thierry Reding
---
include/linux/string.h | 1 +
lib/string.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index 36066207392e..5d63be4ce5b0 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -94,6 +94,7 @@ size_t strcspn(const char *s, const char *reject);
#ifndef __HAVE_ARCH_STRDUP
extern char * strdup(const char *);
#endif
+extern char * strndup(const char *, size_t);
#ifndef __HAVE_ARCH_STRSWAB
extern char * strswab(const char *);
#endif
diff --git a/lib/string.c b/lib/string.c
index af17c16f616d..9b779ddc3bbe 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -326,6 +326,29 @@ char * strdup(const char *s)
}
#endif
+char * strndup(const char *s, size_t n)
+{
+ size_t len;
+ char *new;
+
+ if (s == NULL)
+ return NULL;
+
+ len = strlen(s);
+
+ if (n < len)
+ len = n;
+
+ new = malloc(len + 1);
+ if (new == NULL)
+ return NULL;
+
+ strncpy(new, s, len);
+ new[len] = '\0';
+
+ return new;
+}
+
#ifndef __HAVE_ARCH_STRSPN
/**
* strspn - Calculate the length of the initial substring of @s which only
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 4/5] pico-imx7d: Convert DM MMC
This patch enable convert DM MMC for imx7d-pico board and variant.
Before the DM conversion only usdhc3 was enabled and therefore it appeared
as MMC 0 to u-boot. After enabling MMC DM though usdhc3 defaults to MMC 2,
which left unattended would drive changes to existing pico-pi bootscripts and
environment variables that rely on mmc 0.
Setup the alias of mmc0 and usdhc3 so that existing pico-imx7d boot code will
work unmodified.
When converting to DM_MMC it is necessary that SPL initializes eMMC
by itself, so move the original eMMC initialization from U-Boot
proper to SPL.
Signed-off-by: Joris Offouga
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx7d-pico.dtsi | 4
board/technexion/pico-imx7d/pico-imx7d.c | 38
board/technexion/pico-imx7d/spl.c| 38
configs/pico-hobbit-imx7d_defconfig | 1 +
configs/pico-imx7d_defconfig | 1 +
configs/pico-pi-imx7d_defconfig | 1 +
6 files changed, 45 insertions(+), 38 deletions(-)
diff --git a/arch/arm/dts/imx7d-pico.dtsi b/arch/arm/dts/imx7d-pico.dtsi
index d1a4079..9f1fe68 100644
--- a/arch/arm/dts/imx7d-pico.dtsi
+++ b/arch/arm/dts/imx7d-pico.dtsi
@@ -8,6 +8,10 @@
/ {
+ aliases {
+ mmc0 =
+ };
+
/* Will be filled by the bootloader */
memory@8000 {
device_type = "memory";
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c
b/board/technexion/pico-imx7d/pico-imx7d.c
index 3b9be45..e63b19d 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -13,10 +13,8 @@
#include
#include
#include
-#include
#include
#include
-#include
#include
#include
#include
@@ -28,9 +26,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | \
PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
-#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
- PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
-
#define ENET_PAD_CTRL (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
#define ENET_PAD_CTRL_MII (PAD_CTL_DSE_3P3V_32OHM)
@@ -126,20 +121,6 @@ static iomux_v3_cfg_t const uart5_pads[] = {
MX7D_PAD_I2C4_SDA__UART5_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
};
-static iomux_v3_cfg_t const usdhc3_emmc_pads[] = {
- MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_GPIO1_IO14__GPIO1_IO14 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-};
-
#ifdef CONFIG_FEC_MXC
static iomux_v3_cfg_t const fec1_pads[] = {
MX7D_PAD_SD2_CD_B__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
@@ -224,25 +205,6 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart5_pads, ARRAY_SIZE(uart5_pads));
}
-static struct fsl_esdhc_cfg usdhc_cfg[1] = {
- {USDHC3_BASE_ADDR},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- /* Assume uSDHC3 emmc is always present */
- return 1;
-}
-
-int board_mmc_init(bd_t *bis)
-{
- imx_iomux_v3_setup_multiple_pads(
- usdhc3_emmc_pads, ARRAY_SIZE(usdhc3_emmc_pads));
- usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
-
- return fsl_esdhc_initialize(bis, _cfg[0]);
-}
-
int board_early_init_f(void)
{
setup_iomux_uart();
diff --git a/board/technexion/pico-imx7d/spl.c
b/board/technexion/pico-imx7d/spl.c
index 8c34438..92a4646 100644
--- a/board/technexion/pico-imx7d/spl.c
+++ b/board/technexion/pico-imx7d/spl.c
@@ -5,11 +5,15 @@
* Author: Richard Hu
*/
+#include
#include
#include
+#include
#include
#include
+#include
#include
+#include
#include
#if defined(CONFIG_SPL_BUILD)
@@ -119,4 +123,38 @@ void board_init_f(ulong dummy)
void reset_cpu(ulong addr)
{
}
+
+#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
+ PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
+
+static iomux_v3_cfg_t const usdhc3_pads[] = {
+ MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 |
[U-Boot] [PATCH v4 15/19] ARM: tegra: Enable position independent build for 64-bit
From: Thierry Reding Note that U-Boot is always chainloaded from cboot starting with L4T release 28. cboot always loads U-Boot to a fixed address, so making the builds position independent isn't strictly necessary. However, position independent builds can be convenient because if U-Boot is ever loaded to an address different from its link address, it will still be able to boot. Signed-off-by: Thierry Reding --- arch/arm/mach-tegra/Kconfig | 1 + configs/e2220-1170_defconfig | 2 +- configs/p2371-_defconfig | 2 +- configs/p2371-2180_defconfig | 2 +- configs/p2571_defconfig | 2 +- 5 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index faa73559fd42..97e22ead5985 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -87,6 +87,7 @@ config TEGRA_ARMV8_COMMON bool "Tegra 64-bit common options" select ARM64 select LINUX_KERNEL_IMAGE_HEADER + select POSITION_INDEPENDENT select TEGRA_COMMON if TEGRA_ARMV8_COMMON diff --git a/configs/e2220-1170_defconfig b/configs/e2220-1170_defconfig index af3f80edb117..baabb0ccf8cc 100644 --- a/configs/e2220-1170_defconfig +++ b/configs/e2220-1170_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_TEGRA=y -CONFIG_SYS_TEXT_BASE=0x8011 +CONFIG_SYS_TEXT_BASE=0x8008 CONFIG_TEGRA210=y CONFIG_NR_DRAM_BANKS=2 CONFIG_OF_SYSTEM_SETUP=y diff --git a/configs/p2371-_defconfig b/configs/p2371-_defconfig index 6b564366a825..aa8b73a2ba08 100644 --- a/configs/p2371-_defconfig +++ b/configs/p2371-_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_TEGRA=y -CONFIG_SYS_TEXT_BASE=0x8011 +CONFIG_SYS_TEXT_BASE=0x8008 CONFIG_TEGRA210=y CONFIG_TARGET_P2371_=y CONFIG_NR_DRAM_BANKS=2 diff --git a/configs/p2371-2180_defconfig b/configs/p2371-2180_defconfig index a790cd83b82d..4923d330de6c 100644 --- a/configs/p2371-2180_defconfig +++ b/configs/p2371-2180_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_TEGRA=y -CONFIG_SYS_TEXT_BASE=0x8011 +CONFIG_SYS_TEXT_BASE=0x8008 CONFIG_TEGRA210=y CONFIG_TARGET_P2371_2180=y CONFIG_NR_DRAM_BANKS=2 diff --git a/configs/p2571_defconfig b/configs/p2571_defconfig index e48e0a1a14ec..8e9c45690dce 100644 --- a/configs/p2571_defconfig +++ b/configs/p2571_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_TEGRA=y -CONFIG_SYS_TEXT_BASE=0x8011 +CONFIG_SYS_TEXT_BASE=0x8008 CONFIG_TEGRA210=y CONFIG_TARGET_P2571=y CONFIG_NR_DRAM_BANKS=2 -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 13/19] ARM: tegra: Implement cboot_save_boot_params() in C
From: Thierry Reding
This is easier to deal with and works just as well for this simple
function.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/Makefile | 2 +-
arch/arm/mach-tegra/cboot.c| 12
arch/arm/mach-tegra/cboot_ll.S | 20
3 files changed, 13 insertions(+), 21 deletions(-)
delete mode 100644 arch/arm/mach-tegra/cboot_ll.S
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 41ba674edff4..7165d70a60da 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
obj-$(CONFIG_TEGRA_PMC) += powergate.o
obj-y += xusb-padctl-dummy.o
-obj-$(CONFIG_ARM64) += arm64-mmu.o cboot_ll.o cboot.o
+obj-$(CONFIG_ARM64) += arm64-mmu.o cboot.o
obj-y += dt-setup.o
obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
obj-$(CONFIG_TEGRA_GPU) += gpu.o
diff --git a/arch/arm/mach-tegra/cboot.c b/arch/arm/mach-tegra/cboot.c
index 3ebf7b03..a302ca45f39b 100644
--- a/arch/arm/mach-tegra/cboot.c
+++ b/arch/arm/mach-tegra/cboot.c
@@ -52,6 +52,18 @@ static u64 ram_top __attribute__((section(".data")));
/* The base address of the region of RAM that ends at ram_top */
static u64 region_base __attribute__((section(".data")));
+/*
+ * Explicitly put this in the .data section because it is written before the
+ * .bss section is zeroed out but it needs to persist.
+ */
+unsigned long cboot_boot_x0 __attribute__((section(".data")));
+
+void cboot_save_boot_params(unsigned long x0, unsigned long x1,
+ unsigned long x2, unsigned long x3)
+{
+ cboot_boot_x0 = x0;
+}
+
int cboot_dram_init(void)
{
unsigned int na, ns;
diff --git a/arch/arm/mach-tegra/cboot_ll.S b/arch/arm/mach-tegra/cboot_ll.S
deleted file mode 100644
index 4c9ddacc2b39..
--- a/arch/arm/mach-tegra/cboot_ll.S
+++ /dev/null
@@ -1,20 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Save cboot-related boot-time CPU state
- *
- * (C) Copyright 2015-2016 NVIDIA Corporation
- */
-
-#include
-#include
-
-.align 8
-.globl cboot_boot_x0
-cboot_boot_x0:
- .dword 0
-
-ENTRY(cboot_save_boot_params)
- adr x8, cboot_boot_x0
- str x0, [x8]
- b save_boot_params_ret
-ENDPROC(cboot_save_boot_params)
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 17/19] p2771-0000: Pass Ethernet MAC to the kernel
From: Thierry Reding
Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.
Signed-off-by: Thierry Reding
---
board/nvidia/p2771-/p2771-.c | 43
configs/p2771--000_defconfig | 1 +
configs/p2771--500_defconfig | 1 +
3 files changed, 45 insertions(+)
diff --git a/board/nvidia/p2771-/p2771-.c
b/board/nvidia/p2771-/p2771-.c
index 6f88010c18c3..fe22067f6571 100644
--- a/board/nvidia/p2771-/p2771-.c
+++ b/board/nvidia/p2771-/p2771-.c
@@ -4,7 +4,10 @@
*/
#include
+#include
#include
+#include
+#include
#include "../p2571/max77620_init.h"
void pin_mux_mmc(void)
@@ -52,3 +55,43 @@ int tegra_pcie_board_init(void)
return 0;
}
#endif
+
+int ft_board_setup(void *fdt, bd_t *bd)
+{
+ const void *cboot_fdt = (const void *)cboot_boot_x0;
+ uint8_t mac[ETH_ALEN], local_mac[ETH_ALEN];
+ const char *path;
+ int offset, err;
+
+ err = cboot_get_ethaddr(cboot_fdt, local_mac);
+ if (err < 0)
+ memset(local_mac, 0, ETH_ALEN);
+
+ path = fdt_get_alias(fdt, "ethernet");
+ if (!path)
+ return 0;
+
+ debug("ethernet alias found: %s\n", path);
+
+ offset = fdt_path_offset(fdt, path);
+ if (offset < 0)
+ return 0;
+
+ if (is_valid_ethaddr(local_mac)) {
+ err = fdt_setprop(fdt, offset, "local-mac-address", local_mac,
+ ETH_ALEN);
+ if (!err)
+ debug("Local MAC address set: %pM\n", local_mac);
+ }
+
+ if (eth_env_get_enetaddr("ethaddr", mac)) {
+ if (memcmp(local_mac, mac, ETH_ALEN) != 0) {
+ err = fdt_setprop(fdt, offset, "mac-address", mac,
+ ETH_ALEN);
+ if (!err)
+ debug("MAC address set: %pM\n", mac);
+ }
+ }
+
+ return 0;
+}
diff --git a/configs/p2771--000_defconfig b/configs/p2771--000_defconfig
index ad0802067e73..91896e39a10f 100644
--- a/configs/p2771--000_defconfig
+++ b/configs/p2771--000_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x8008
CONFIG_TEGRA186=y
CONFIG_NR_DRAM_BANKS=1026
CONFIG_OF_SYSTEM_SETUP=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_CONSOLE_MUX=y
CONFIG_SYS_STDIO_DEREGISTER=y
CONFIG_SYS_PROMPT="Tegra186 (P2771--000) # "
diff --git a/configs/p2771--500_defconfig b/configs/p2771--500_defconfig
index 459b67fd195f..20d4393838d6 100644
--- a/configs/p2771--500_defconfig
+++ b/configs/p2771--500_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x8008
CONFIG_TEGRA186=y
CONFIG_NR_DRAM_BANKS=1026
CONFIG_OF_SYSTEM_SETUP=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_CONSOLE_MUX=y
CONFIG_SYS_STDIO_DEREGISTER=y
CONFIG_SYS_PROMPT="Tegra186 (P2771--500) # "
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 09/19] ARM: tegra: Support TZ-only access to PMC
From: Thierry Reding
Some devices may restrict access to the PMC to TrustZone software only.
Non-TZ software can detect this and use SMC calls to the firmware that
runs in the TrustZone to perform accesses to PMC registers.
Note that this also fixes reset_cpu() and the enterrcm command on
Tegra186 where they were previously trying to access the PMC at a wrong
physical address.
Based on work by Kalyani Chidambaram and Tom
Warren .
Signed-off-by: Thierry Reding
---
arch/arm/include/asm/arch-tegra/pmc.h | 20 +-
arch/arm/include/asm/arch-tegra/tegra.h | 6 ++
arch/arm/mach-tegra/Kconfig | 5 ++
arch/arm/mach-tegra/Makefile| 4 +-
arch/arm/mach-tegra/clock.c | 13 ++--
arch/arm/mach-tegra/cmd_enterrcm.c | 6 +-
arch/arm/mach-tegra/cpu.c | 20 +++---
arch/arm/mach-tegra/lowlevel_init.S | 39 ---
arch/arm/mach-tegra/pmc.c | 92 +
arch/arm/mach-tegra/powergate.c | 11 +--
10 files changed, 151 insertions(+), 65 deletions(-)
delete mode 100644 arch/arm/mach-tegra/lowlevel_init.S
create mode 100644 arch/arm/mach-tegra/pmc.c
diff --git a/arch/arm/include/asm/arch-tegra/pmc.h
b/arch/arm/include/asm/arch-tegra/pmc.h
index 34bbe75d5fdb..1524bf291164 100644
--- a/arch/arm/include/asm/arch-tegra/pmc.h
+++ b/arch/arm/include/asm/arch-tegra/pmc.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * (C) Copyright 2010-2015
+ * (C) Copyright 2010-2019
* NVIDIA Corporation
*/
@@ -388,4 +388,22 @@ struct pmc_ctlr {
/* APBDEV_PMC_CNTRL2_0 0x440 */
#define HOLD_CKE_LOW_EN(1 << 12)
+/* PMC read/write functions */
+u32 tegra_pmc_readl(unsigned long offset);
+void tegra_pmc_writel(u32 value, unsigned long offset);
+
+#define PMC_CNTRL 0x0
+#define PMC_CNTRL_MAIN_RSTBIT(4)
+
+#if IS_ENABLED(CONFIG_TEGRA186)
+# define PMC_SCRATCH0 0x32000
+#else
+# define PMC_SCRATCH0 0x00050
+#endif
+
+/* for secure PMC */
+#define TEGRA_SMC_PMC 0xc2fffe00
+#define TEGRA_SMC_PMC_READ0xaa
+#define TEGRA_SMC_PMC_WRITE 0xbb
+
#endif /* PMC_H */
diff --git a/arch/arm/include/asm/arch-tegra/tegra.h
b/arch/arm/include/asm/arch-tegra/tegra.h
index 7ae0129e2db3..7a4e0972fb76 100644
--- a/arch/arm/include/asm/arch-tegra/tegra.h
+++ b/arch/arm/include/asm/arch-tegra/tegra.h
@@ -30,7 +30,13 @@
#define NV_PA_SLINK5_BASE (NV_PA_APB_MISC_BASE + 0xDC00)
#define NV_PA_SLINK6_BASE (NV_PA_APB_MISC_BASE + 0xDE00)
#define TEGRA_DVC_BASE (NV_PA_APB_MISC_BASE + 0xD000)
+#if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30) || \
+ defined(CONFIG_TEGRA114) || defined(CONFIG_TEGRA124) || \
+ defined(CONFIG_TEGRA132) || defined(CONFIG_TEGRA210)
#define NV_PA_PMC_BASE (NV_PA_APB_MISC_BASE + 0xE400)
+#else
+#define NV_PA_PMC_BASE 0xc36
+#endif
#define NV_PA_EMC_BASE (NV_PA_APB_MISC_BASE + 0xF400)
#define NV_PA_FUSE_BASE(NV_PA_APB_MISC_BASE + 0xF800)
#if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30) || \
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index db9198348d3f..28914a34a1b5 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -35,6 +35,10 @@ config TEGRA_PINCTRL
config TEGRA_PMC
bool
+config TEGRA_PMC_SECURE
+ bool
+ depends on TEGRA_PMC
+
config TEGRA_COMMON
bool "Tegra common options"
select BINMAN
@@ -127,6 +131,7 @@ config TEGRA210
select TEGRA_NO_BPMP
select TEGRA_PINCTRL
select TEGRA_PMC
+ select TEGRA_PMC_SECURE
config TEGRA186
bool "Tegra186 family"
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 517be21ee5f5..f8bc65aa8b18 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-# (C) Copyright 2010-2015 Nvidia Corporation.
+# (C) Copyright 2010-2019 Nvidia Corporation.
#
# (C) Copyright 2000-2008
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
@@ -27,11 +27,11 @@ obj-y += dt-setup.o
obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
obj-$(CONFIG_TEGRA_GPU) += gpu.o
obj-$(CONFIG_TEGRA_IVC) += ivc.o
-obj-y += lowlevel_init.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_ARMV7_PSCI) += psci.o
endif
obj-$(CONFIG_DISPLAY_CPUINFO) += sys_info.o
+obj-y += pmc.o
obj-$(CONFIG_TEGRA20) += tegra20/
obj-$(CONFIG_TEGRA30) += tegra30/
diff --git a/arch/arm/mach-tegra/clock.c b/arch/arm/mach-tegra/clock.c
index 096330748f2b..c9cd4e6aaeb7 100644
--- a/arch/arm/mach-tegra/clock.c
+++ b/arch/arm/mach-tegra/clock.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) 2010-2015, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2010-2019, NVIDIA CORPORATION. All rights reserved.
*/
/* Tegra SoC common clock control functions */
@@ -814,11 +814,16 @@ void tegra30_set_up_pllp(void)
int
[U-Boot] [PATCH v4 11/19] ARM: tegra: Restore DRAM bank count
From: Thierry Reding
Commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") reduced
the number of DRAM banks supported by U-Boot from 1026 to 8 on P2771-000
boards.
However, as explained in commit a9819b9e33bd ("ARM: tegra: p2771-000:
increase max DRAM bank count"), the platform can have a large number of
unusable chunks of memory (up to 1024), so a total of 1026 DRAM banks
are needed to describe the worst-case situation.
In practice the number of DRAM banks needed will typically be much
lower, but we should be prepared to properly deal with the worst case.
Signed-off-by: Thierry Reding
---
configs/p2771--000_defconfig | 2 +-
configs/p2771--500_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/p2771--000_defconfig b/configs/p2771--000_defconfig
index ac85efa37b3b..ad0802067e73 100644
--- a/configs/p2771--000_defconfig
+++ b/configs/p2771--000_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
CONFIG_TEGRA=y
CONFIG_SYS_TEXT_BASE=0x8008
CONFIG_TEGRA186=y
-CONFIG_NR_DRAM_BANKS=8
+CONFIG_NR_DRAM_BANKS=1026
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_CONSOLE_MUX=y
CONFIG_SYS_STDIO_DEREGISTER=y
diff --git a/configs/p2771--500_defconfig b/configs/p2771--500_defconfig
index df4d914d85cf..459b67fd195f 100644
--- a/configs/p2771--500_defconfig
+++ b/configs/p2771--500_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
CONFIG_TEGRA=y
CONFIG_SYS_TEXT_BASE=0x8008
CONFIG_TEGRA186=y
-CONFIG_NR_DRAM_BANKS=8
+CONFIG_NR_DRAM_BANKS=1026
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_CONSOLE_MUX=y
CONFIG_SYS_STDIO_DEREGISTER=y
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 07/19] ARM: tegra: Fix save_boot_params() prototype
From: Thierry Reding
The save_boot_params() function takes as its first four arguments the
first four registers. On 32-bit ARM these are r0, r1, r2 and r3, all of
which are 32 bits wide. However, on 64-bit ARM thene registers are x0,
x1, x2 and x3, all of which are 64 bits wide. In order to allow reusing
the save_boot_params() implementation on 64-bit ARM, change it to take
unsigned long parameters rather than the fixed size 32-bit integers.
This ensures that the correct values are passed.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/board.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index b65bdde5a78d..59d2f347485d 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -42,7 +42,8 @@ enum {
static bool from_spl __attribute__ ((section(".data")));
#ifndef CONFIG_SPL_BUILD
-void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
+ unsigned long r3)
{
from_spl = r0 != UBOOT_NOT_LOADED_FROM_SPL;
save_boot_params_ret();
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 05/19] ARM: tegra: Guard pin controller code with a Kconfig symbol
From: Thierry Reding
Pin controller code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.
This is in preparation for unifying Tegra186 code with the code used on
older generations.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/Kconfig | 5 +
arch/arm/mach-tegra/Makefile | 2 +-
arch/arm/mach-tegra/board.c | 6 ++
arch/arm/mach-tegra/board2.c | 2 ++
4 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 5763c4ae3cd1..be20ac2e804e 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -29,6 +29,9 @@ config TEGRA_IVC
config TEGRA_MC
bool
+config TEGRA_PINCTRL
+ bool
+
config TEGRA_COMMON
bool "Tegra common options"
select BINMAN
@@ -70,6 +73,7 @@ config TEGRA_ARMV7_COMMON
select TEGRA_GP_PADCTRL
select TEGRA_MC
select TEGRA_NO_BPMP
+ select TEGRA_PINCTRL
config TEGRA_ARMV8_COMMON
bool "Tegra 64-bit common options"
@@ -117,6 +121,7 @@ config TEGRA210
select TEGRA_GP_PADCTRL
select TEGRA_MC
select TEGRA_NO_BPMP
+ select TEGRA_PINCTRL
config TEGRA186
bool "Tegra186 family"
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 69f802c01b45..395e0191a458 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_TEGRA_GP_PADCTRL) += ap.o
obj-y += board.o board2.o
obj-y += cache.o
obj-$(CONFIG_TEGRA_CLKRST) += clock.o
-obj-y += pinmux-common.o
+obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o
obj-y += powergate.o
obj-y += xusb-padctl-dummy.o
endif
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index 7ef5a67edd1f..b65bdde5a78d 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -12,7 +12,9 @@
#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
#include
#endif
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
#include
+#endif
#if IS_ENABLED(CONFIG_TEGRA_MC)
#include
#endif
@@ -132,6 +134,7 @@ int dram_init(void)
return 0;
}
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
static int uart_configs[] = {
#if defined(CONFIG_TEGRA20)
#if defined(CONFIG_TEGRA_UARTA_UAA_UAB)
@@ -199,9 +202,11 @@ static void setup_uarts(int uart_ids)
}
}
}
+#endif
void board_init_uart_f(void)
{
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
int uart_ids = 0; /* bit mask of which UART ids to enable */
#ifdef CONFIG_TEGRA_ENABLE_UARTA
@@ -220,6 +225,7 @@ void board_init_uart_f(void)
uart_ids |= UARTE;
#endif
setup_uarts(uart_ids);
+#endif
}
#if !CONFIG_IS_ENABLED(OF_CONTROL)
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index b94077221f77..ce1c9346959d 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -25,8 +25,10 @@
#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
#include
#endif
+#if IS_ENABLED(CONFIG_TEGRA_PINCTRL)
#include
#include
+#endif
#include
#ifdef CONFIG_TEGRA_CLOCK_SCALING
#include
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 08/19] ARM: tegra: Allow boards to override boot target devices
From: Thierry Reding Boards may not support all the boot target devices in the default list for Tegra devices. Allow a board to override the list and default to the standard list only if the board hasn't specified one itself. Signed-off-by: Thierry Reding --- include/configs/tegra-common-post.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index e54428ba43e2..9685ee5059ab 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -21,12 +21,14 @@ #define CONFIG_SYS_NONCACHED_MEMORY(1 << 20) /* 1 MiB */ #ifndef CONFIG_SPL_BUILD +#ifndef BOOT_TARGET_DEVICES #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 1) \ func(MMC, mmc, 0) \ func(USB, usb, 0) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) +#endif #include #else #define BOOTENV -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 06/19] ARM: tegra: Guard powergate code with a Kconfig symbol
From: Thierry Reding Powergate code is not relevant on all Tegra SoC generations, so guard it with a Kconfig symbol that can be selected by the generations that need it. This is in preparation for unifying Tegra186 code with the code used on older generations. Signed-off-by: Thierry Reding --- arch/arm/mach-tegra/Kconfig | 5 + arch/arm/mach-tegra/Makefile | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index be20ac2e804e..db9198348d3f 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -32,6 +32,9 @@ config TEGRA_MC config TEGRA_PINCTRL bool +config TEGRA_PMC + bool + config TEGRA_COMMON bool "Tegra common options" select BINMAN @@ -74,6 +77,7 @@ config TEGRA_ARMV7_COMMON select TEGRA_MC select TEGRA_NO_BPMP select TEGRA_PINCTRL + select TEGRA_PMC config TEGRA_ARMV8_COMMON bool "Tegra 64-bit common options" @@ -122,6 +126,7 @@ config TEGRA210 select TEGRA_MC select TEGRA_NO_BPMP select TEGRA_PINCTRL + select TEGRA_PMC config TEGRA186 bool "Tegra186 family" diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile index 395e0191a458..517be21ee5f5 100644 --- a/arch/arm/mach-tegra/Makefile +++ b/arch/arm/mach-tegra/Makefile @@ -18,7 +18,7 @@ obj-y += board.o board2.o obj-y += cache.o obj-$(CONFIG_TEGRA_CLKRST) += clock.o obj-$(CONFIG_TEGRA_PINCTRL) += pinmux-common.o -obj-y += powergate.o +obj-$(CONFIG_TEGRA_PMC) += powergate.o obj-y += xusb-padctl-dummy.o endif -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 10/19] ARM: tegra: Workaround UDC boot issues only if necessary
From: Thierry Reding Resetting the USB device controller on boot is only necessary if the SoC actually has a UDC controller and U-Boot enables support for it. All the Tegra boards support UDC via the ChipIdea UDC driver, so make the UDC on boot workaround depend on the ChipIdea UDC driver. This prevents a crash on Tegra186 which does not have the ChipIdea UDC. Signed-off-by: Thierry Reding --- arch/arm/mach-tegra/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index 28914a34a1b5..faa73559fd42 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -148,6 +148,7 @@ endchoice config TEGRA_DISCONNECT_UDC_ON_BOOT bool "Disconnect USB device mode controller on boot" + depends on CI_UDC default y help When loading U-Boot into RAM over USB protocols using tools such as -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 03/19] ARM: tegra: Guard GP pad control code with a Kconfig symbol
From: Thierry Reding The GP pad control code is not relevant on all Tegra SoC generations, so guard it with a Kconfig symbol that can be selected by the generations that need it. This is in preparation for unifying Tegra186 code with the code used on older generations. Signed-off-by: Thierry Reding --- arch/arm/mach-tegra/Kconfig | 5 + arch/arm/mach-tegra/Makefile | 2 +- arch/arm/mach-tegra/cache.c | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index ee078fec9adc..265051b18aaf 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -15,6 +15,9 @@ config SPL_SERIAL_SUPPORT config TEGRA_CLKRST bool +config TEGRA_GP_PADCTRL + bool + config TEGRA_IVC bool "Tegra IVC protocol" help @@ -61,6 +64,7 @@ config TEGRA_ARMV7_COMMON select TEGRA_CLKRST select TEGRA_COMMON select TEGRA_GPIO + select TEGRA_GP_PADCTRL select TEGRA_NO_BPMP config TEGRA_ARMV8_COMMON @@ -106,6 +110,7 @@ config TEGRA210 select TEGRA_ARMV8_COMMON select TEGRA_CLKRST select TEGRA_GPIO + select TEGRA_GP_PADCTRL select TEGRA_NO_BPMP config TEGRA186 diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile index 0e812818d7a2..69f802c01b45 100644 --- a/arch/arm/mach-tegra/Makefile +++ b/arch/arm/mach-tegra/Makefile @@ -13,7 +13,7 @@ else obj-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o endif -obj-y += ap.o +obj-$(CONFIG_TEGRA_GP_PADCTRL) += ap.o obj-y += board.o board2.o obj-y += cache.o obj-$(CONFIG_TEGRA_CLKRST) += clock.o diff --git a/arch/arm/mach-tegra/cache.c b/arch/arm/mach-tegra/cache.c index be414e4e4aca..d7063490e222 100644 --- a/arch/arm/mach-tegra/cache.c +++ b/arch/arm/mach-tegra/cache.c @@ -8,7 +8,9 @@ #include #include #include +#if IS_ENABLED(CONFIG_TEGRA_GP_PADCTRL) #include +#endif #ifndef CONFIG_ARM64 void config_cache(void) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 04/19] ARM: tegra: Guard memory controller code with a Kconfig symbol
From: Thierry Reding
Memory controller code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.
This is in preparation for unifying Tegra186 code with the code used on
older generations.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/Kconfig | 5 +
arch/arm/mach-tegra/board.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 265051b18aaf..5763c4ae3cd1 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -26,6 +26,9 @@ config TEGRA_IVC
U-Boot, it is typically used for communication between the main CPU
and various auxiliary processors.
+config TEGRA_MC
+ bool
+
config TEGRA_COMMON
bool "Tegra common options"
select BINMAN
@@ -65,6 +68,7 @@ config TEGRA_ARMV7_COMMON
select TEGRA_COMMON
select TEGRA_GPIO
select TEGRA_GP_PADCTRL
+ select TEGRA_MC
select TEGRA_NO_BPMP
config TEGRA_ARMV8_COMMON
@@ -111,6 +115,7 @@ config TEGRA210
select TEGRA_CLKRST
select TEGRA_GPIO
select TEGRA_GP_PADCTRL
+ select TEGRA_MC
select TEGRA_NO_BPMP
config TEGRA186
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index ecd5001de4c5..7ef5a67edd1f 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -13,7 +13,9 @@
#include
#endif
#include
+#if IS_ENABLED(CONFIG_TEGRA_MC)
#include
+#endif
#include
#include
#include
@@ -68,6 +70,7 @@ bool tegra_cpu_is_non_secure(void)
}
#endif
+#if IS_ENABLED(CONFIG_TEGRA_MC)
/* Read the RAM size directly from the memory controller */
static phys_size_t query_sdram_size(void)
{
@@ -117,11 +120,15 @@ static phys_size_t query_sdram_size(void)
return size_bytes;
}
+#endif
int dram_init(void)
{
+#if IS_ENABLED(CONFIG_TEGRA_MC)
/* We do not initialise DRAM here. We just query the size */
gd->ram_size = query_sdram_size();
+#endif
+
return 0;
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 02/19] ARM: tegra: Guard clock code with a Kconfig symbol
From: Thierry Reding
Clock code is not relevant on all Tegra SoC generations, so guard it
with a Kconfig symbol that can be selected by the generations that need
it.
This is in preparation for unifying Tegra186 code with the code used on
older generations.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/Kconfig | 5 +
arch/arm/mach-tegra/Makefile | 2 +-
arch/arm/mach-tegra/board.c | 2 ++
arch/arm/mach-tegra/board2.c | 12 ++--
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 86b1cd11f752..ee078fec9adc 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -12,6 +12,9 @@ config SPL_LIBGENERIC_SUPPORT
config SPL_SERIAL_SUPPORT
default y
+config TEGRA_CLKRST
+ bool
+
config TEGRA_IVC
bool "Tegra IVC protocol"
help
@@ -55,6 +58,7 @@ config TEGRA_ARMV7_COMMON
select SPL
select SPL_BOARD_INIT if SPL
select SUPPORT_SPL
+ select TEGRA_CLKRST
select TEGRA_COMMON
select TEGRA_GPIO
select TEGRA_NO_BPMP
@@ -100,6 +104,7 @@ config TEGRA124
config TEGRA210
bool "Tegra210 family"
select TEGRA_ARMV8_COMMON
+ select TEGRA_CLKRST
select TEGRA_GPIO
select TEGRA_NO_BPMP
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index d4b4666fb1e2..0e812818d7a2 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -16,7 +16,7 @@ endif
obj-y += ap.o
obj-y += board.o board2.o
obj-y += cache.o
-obj-y += clock.o
+obj-$(CONFIG_TEGRA_CLKRST) += clock.o
obj-y += pinmux-common.o
obj-y += powergate.o
obj-y += xusb-padctl-dummy.o
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index f8fc042a1dcc..ecd5001de4c5 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -9,7 +9,9 @@
#include
#include
#include
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
#include
+#endif
#include
#include
#include
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index b8d5ef0322cb..b94077221f77 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -22,7 +22,9 @@
#include
#include
#include
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
#include
+#endif
#include
#include
#include
@@ -109,8 +111,10 @@ int board_init(void)
__maybe_unused int board_id;
/* Do clocks and UART first so that printf() works */
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
clock_init();
clock_verify();
+#endif
tegra_gpu_config();
@@ -181,8 +185,10 @@ void gpio_early_init(void) __attribute__((weak,
alias("__gpio_early_init")));
int board_early_init_f(void)
{
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
if (!clock_early_init_done())
clock_early_init();
+#endif
#if defined(CONFIG_TEGRA_DISCONNECT_UDC_ON_BOOT)
#define USBCMD_FS2 (1 << 15)
@@ -193,10 +199,12 @@ int board_early_init_f(void)
#endif
/* Do any special system timer/TSC setup */
-#if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
+#if IS_ENABLED(CONFIG_TEGRA_CLKRST)
+# if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
if (!tegra_cpu_is_non_secure())
-#endif
+# endif
arch_timer_init();
+#endif
pinmux_init();
board_init_uart_f();
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 00/19] ARM: tegra: Miscellaneous improvements
From: Thierry Reding
The bulk of these changes are an effort to unify Tegra186 builds with
builds of prior 64-bit Tegra generations. On top of that there are
various improvements that allow data (such as the MAC address and boot
arguments) to be passed through from early firmware to the kernel on
boot.
The last two patches can be applied at a later time if the strndup()
addition can't be merged along with the rest of the patches through
the Tegra tree.
Thierry
Thierry Reding (19):
ARM: tegra: Use common header for PMU declarations
ARM: tegra: Guard clock code with a Kconfig symbol
ARM: tegra: Guard GP pad control code with a Kconfig symbol
ARM: tegra: Guard memory controller code with a Kconfig symbol
ARM: tegra: Guard pin controller code with a Kconfig symbol
ARM: tegra: Guard powergate code with a Kconfig symbol
ARM: tegra: Fix save_boot_params() prototype
ARM: tegra: Allow boards to override boot target devices
ARM: tegra: Support TZ-only access to PMC
ARM: tegra: Workaround UDC boot issues only if necessary
ARM: tegra: Restore DRAM bank count
ARM: tegra: Unify Tegra186 builds
ARM: tegra: Implement cboot_save_boot_params() in C
ARM: tegra: Implement cboot_get_ethaddr()
ARM: tegra: Enable position independent build for 64-bit
p2371-2180: Pass Ethernet MAC to the kernel
p2771-: Pass Ethernet MAC to the kernel
lib: Implement strndup()
ARM: tegra: Import cbootargs value from cboot DTB
arch/arm/include/asm/arch-tegra/cboot.h | 45 ++
arch/arm/include/asm/arch-tegra/pmc.h | 20 +-
.../asm/{arch-tegra20 => arch-tegra}/pmu.h| 6 +-
arch/arm/include/asm/arch-tegra/tegra.h | 6 +
arch/arm/include/asm/arch-tegra114/pmu.h | 12 -
arch/arm/include/asm/arch-tegra124/pmu.h | 13 -
arch/arm/include/asm/arch-tegra210/pmu.h | 13 -
arch/arm/include/asm/arch-tegra30/pmu.h | 12 -
arch/arm/mach-tegra/Kconfig | 32 +
arch/arm/mach-tegra/Makefile | 16 +-
arch/arm/mach-tegra/board.c | 41 +-
arch/arm/mach-tegra/board186.c| 32 -
arch/arm/mach-tegra/board2.c | 37 +-
arch/arm/mach-tegra/cache.c | 2 +
arch/arm/mach-tegra/cboot.c | 615 ++
arch/arm/mach-tegra/clock.c | 13 +-
arch/arm/mach-tegra/cmd_enterrcm.c| 6 +-
arch/arm/mach-tegra/cpu.c | 20 +-
arch/arm/mach-tegra/emc.c | 2 +-
arch/arm/mach-tegra/lowlevel_init.S | 39 --
arch/arm/mach-tegra/pmc.c | 92 +++
arch/arm/mach-tegra/powergate.c | 11 +-
arch/arm/mach-tegra/tegra186/Makefile | 4 -
arch/arm/mach-tegra/tegra186/nvtboot_board.c | 332 --
arch/arm/mach-tegra/tegra186/nvtboot_ll.S | 20 -
arch/arm/mach-tegra/tegra186/nvtboot_mem.c| 172 -
board/nvidia/p2371-2180/p2371-2180.c | 50 ++
board/nvidia/p2771-/p2771-.c | 53 +-
configs/e2220-1170_defconfig | 2 +-
configs/p2371-_defconfig | 2 +-
configs/p2371-2180_defconfig | 3 +-
configs/p2571_defconfig | 2 +-
configs/p2771--000_defconfig | 3 +-
configs/p2771--500_defconfig | 3 +-
include/configs/tegra-common-post.h | 2 +
include/linux/string.h| 1 +
lib/string.c | 23 +
37 files changed, 1056 insertions(+), 701 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra/cboot.h
rename arch/arm/include/asm/{arch-tegra20 => arch-tegra}/pmu.h (73%)
delete mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
delete mode 100644 arch/arm/include/asm/arch-tegra124/pmu.h
delete mode 100644 arch/arm/include/asm/arch-tegra210/pmu.h
delete mode 100644 arch/arm/include/asm/arch-tegra30/pmu.h
delete mode 100644 arch/arm/mach-tegra/board186.c
create mode 100644 arch/arm/mach-tegra/cboot.c
delete mode 100644 arch/arm/mach-tegra/lowlevel_init.S
create mode 100644 arch/arm/mach-tegra/pmc.c
delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_board.c
delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_ll.S
delete mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_mem.c
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 01/19] ARM: tegra: Use common header for PMU declarations
From: Thierry Reding
There's no need to replicate the pmu.h header file for every Tegra SoC
generation. Use a single header that is shared across generations.
Signed-off-by: Thierry Reding
---
.../include/asm/{arch-tegra20 => arch-tegra}/pmu.h | 6 +++---
arch/arm/include/asm/arch-tegra114/pmu.h| 12
arch/arm/include/asm/arch-tegra124/pmu.h| 13 -
arch/arm/include/asm/arch-tegra210/pmu.h| 13 -
arch/arm/include/asm/arch-tegra30/pmu.h | 12
arch/arm/mach-tegra/board2.c| 2 +-
arch/arm/mach-tegra/emc.c | 2 +-
7 files changed, 5 insertions(+), 55 deletions(-)
rename arch/arm/include/asm/{arch-tegra20 => arch-tegra}/pmu.h (73%)
delete mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
delete mode 100644 arch/arm/include/asm/arch-tegra124/pmu.h
delete mode 100644 arch/arm/include/asm/arch-tegra210/pmu.h
delete mode 100644 arch/arm/include/asm/arch-tegra30/pmu.h
diff --git a/arch/arm/include/asm/arch-tegra20/pmu.h
b/arch/arm/include/asm/arch-tegra/pmu.h
similarity index 73%
rename from arch/arm/include/asm/arch-tegra20/pmu.h
rename to arch/arm/include/asm/arch-tegra/pmu.h
index 18766dfed2bb..e850875d3166 100644
--- a/arch/arm/include/asm/arch-tegra20/pmu.h
+++ b/arch/arm/include/asm/arch-tegra/pmu.h
@@ -4,10 +4,10 @@
* NVIDIA Corporation
*/
-#ifndef _ARCH_PMU_H_
-#define _ARCH_PMU_H_
+#ifndef _TEGRA_PMU_H_
+#define _TEGRA_PMU_H_
/* Set core and CPU voltages to nominal levels */
int pmu_set_nominal(void);
-#endif /* _ARCH_PMU_H_ */
+#endif /* _TEGRA_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra114/pmu.h
b/arch/arm/include/asm/arch-tegra114/pmu.h
deleted file mode 100644
index 1e571ee7b317..
--- a/arch/arm/include/asm/arch-tegra114/pmu.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (c) 2010-2013, NVIDIA CORPORATION. All rights reserved.
- */
-
-#ifndef _TEGRA114_PMU_H_
-#define _TEGRA114_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA114_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra124/pmu.h
b/arch/arm/include/asm/arch-tegra124/pmu.h
deleted file mode 100644
index c38393edefda..
--- a/arch/arm/include/asm/arch-tegra124/pmu.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2010-2013
- * NVIDIA Corporation
- */
-
-#ifndef _TEGRA124_PMU_H_
-#define _TEGRA124_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA124_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra210/pmu.h
b/arch/arm/include/asm/arch-tegra210/pmu.h
deleted file mode 100644
index 6ea36aa41876..
--- a/arch/arm/include/asm/arch-tegra210/pmu.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2010-2015
- * NVIDIA Corporation
- */
-
-#ifndef _TEGRA210_PMU_H_
-#define _TEGRA210_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA210_PMU_H_ */
diff --git a/arch/arm/include/asm/arch-tegra30/pmu.h
b/arch/arm/include/asm/arch-tegra30/pmu.h
deleted file mode 100644
index a823f0fbfc61..
--- a/arch/arm/include/asm/arch-tegra30/pmu.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (c) 2010-2012, NVIDIA CORPORATION. All rights reserved.
- */
-
-#ifndef _TEGRA30_PMU_H_
-#define _TEGRA30_PMU_H_
-
-/* Set core and CPU voltages to nominal levels */
-int pmu_set_nominal(void);
-
-#endif /* _TEGRA30_PMU_H_ */
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index 12257a42b51b..b8d5ef0322cb 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,7 +25,6 @@
#include
#include
#include
-#include
#include
#ifdef CONFIG_TEGRA_CLOCK_SCALING
#include
diff --git a/arch/arm/mach-tegra/emc.c b/arch/arm/mach-tegra/emc.c
index 6697909d9a3e..66628933b653 100644
--- a/arch/arm/mach-tegra/emc.c
+++ b/arch/arm/mach-tegra/emc.c
@@ -8,10 +8,10 @@
#include
#include
#include
-#include
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 00/14] imx: Fully convert HSC|DDC K+P i.MX53 based boards to use DM/DTS
This patch series converts HSC and DDC to solely use Driver Model and
Device Tree.
(As a side effect the "removal warnings" are not present anymore).
Some notable changes:
- Converting ehci-mx5 to DM
- CONFIG_USB_EHCI_MX5 to Kconfig
- Use of esdhc with DM
- Cleanup of config
This patch series applies on top of u-boot-imx -next branch
SHA1: 9648463488735e13328f8738c56251e1fb941e51
Lukasz Majewski (14):
ARM: Remove HSC|DDC ETH PHY reset code after switching to DM/DTS
DTS: Add esdhc3 device tree description tuning for HSC|DDC boards
ARM: Enable CONFIG_DM_MMC and CONFIG_DM_BLK on HSC and DDC boards
ARM: defconfig: Move CONFIG_FSL_ESDHC to Kconfig
ARM: Remove non DM/DTS esdhc3 code from HSC|DDC board related files
ARM: kp_imx53: config: Do not use ${boardtype} to setup update wic
file
DTS: Provide USB host DTS description for i.MX53 devices
DTS: Enable USB host support (including regulators) on HSC|DDC boards
ARM: Remove EHCI specific code from HSC|DDC board file
USB: DM: Convert i.MX5 ehci code to driver model
ARM: defconfig: kp_imx53: Enable DM_USB support on HSC|DDC boards
ARM: config: Remove not needed CONFIG_MXC_USB_PORT define
Convert CONFIG_USB_EHCI_MX5 to Kconfig
boot.src: Provide dsa_core.blacklist bootarg when booting via NFS
arch/arm/dts/imx53-kp.dts | 59 +-
arch/arm/dts/imx53.dtsi | 10
arch/arm/mach-imx/mx5/Kconfig | 4 ++
board/k+p/bootscripts/tpcboot.cmd | 7 +++
board/k+p/kp_imx53/kp_imx53.c | 70 --
configs/kp_imx53_defconfig| 3 ++
configs/m53menlo_defconfig| 1 +
configs/mx51evk_defconfig | 1 +
configs/mx53loco_defconfig| 1 +
configs/mx53ppd_defconfig | 1 +
configs/usbarmory_defconfig | 1 +
drivers/usb/host/Kconfig | 7 +++
drivers/usb/host/ehci-mx5.c | 103 ++
include/configs/kp_imx53.h| 9 +---
include/configs/m53menlo.h| 1 -
include/configs/mx51evk.h | 1 -
include/configs/mx53cx9020.h | 1 -
include/configs/mx53loco.h| 1 -
include/configs/mx53ppd.h | 1 -
include/configs/usbarmory.h | 1 -
scripts/config_whitelist.txt | 1 -
21 files changed, 197 insertions(+), 87 deletions(-)
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 13/14] Convert CONFIG_USB_EHCI_MX5 to Kconfig
This converts the following to Kconfig: CONFIG_USB_EHCI_MX5 Signed-off-by: Lukasz Majewski --- configs/kp_imx53_defconfig | 1 + configs/m53menlo_defconfig | 1 + configs/mx51evk_defconfig| 1 + configs/mx53loco_defconfig | 1 + configs/mx53ppd_defconfig| 1 + configs/usbarmory_defconfig | 1 + drivers/usb/host/Kconfig | 7 +++ include/configs/kp_imx53.h | 1 - include/configs/m53menlo.h | 1 - include/configs/mx51evk.h| 1 - include/configs/mx53cx9020.h | 1 - include/configs/mx53loco.h | 1 - include/configs/mx53ppd.h| 1 - include/configs/usbarmory.h | 1 - scripts/config_whitelist.txt | 1 - 15 files changed, 13 insertions(+), 8 deletions(-) diff --git a/configs/kp_imx53_defconfig b/configs/kp_imx53_defconfig index 45227c26d2..225be66019 100644 --- a/configs/kp_imx53_defconfig +++ b/configs/kp_imx53_defconfig @@ -45,4 +45,5 @@ CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_CONS_INDEX=2 CONFIG_MXC_UART=y CONFIG_USB=y +CONFIG_USB_EHCI_MX5=y CONFIG_USB_STORAGE=y diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig index e830b2c92e..e10cb8ed8d 100644 --- a/configs/m53menlo_defconfig +++ b/configs/m53menlo_defconfig @@ -58,6 +58,7 @@ CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y CONFIG_RTC_M41T62=y CONFIG_USB=y +CONFIG_USB_EHCI_MX5=y CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/configs/mx51evk_defconfig b/configs/mx51evk_defconfig index dc0b3b3f77..78aa89d651 100644 --- a/configs/mx51evk_defconfig +++ b/configs/mx51evk_defconfig @@ -26,6 +26,7 @@ CONFIG_MII=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_USB=y +CONFIG_USB_EHCI_MX5=y CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/configs/mx53loco_defconfig b/configs/mx53loco_defconfig index 776fc8bab4..caf04ad894 100644 --- a/configs/mx53loco_defconfig +++ b/configs/mx53loco_defconfig @@ -26,6 +26,7 @@ CONFIG_DWC_AHSATA=y CONFIG_FSL_ESDHC=y CONFIG_MII=y CONFIG_USB=y +CONFIG_USB_EHCI_MX5=y CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/configs/mx53ppd_defconfig b/configs/mx53ppd_defconfig index 2a6183b77b..2379ab8c66 100644 --- a/configs/mx53ppd_defconfig +++ b/configs/mx53ppd_defconfig @@ -37,6 +37,7 @@ CONFIG_FSL_ESDHC=y CONFIG_MII=y CONFIG_RTC_S35392A=y CONFIG_USB=y +CONFIG_USB_EHCI_MX5=y CONFIG_USB_STORAGE=y CONFIG_VIDEO=y CONFIG_VIDEO_IPUV3=y diff --git a/configs/usbarmory_defconfig b/configs/usbarmory_defconfig index b1f872405b..46f9996e18 100644 --- a/configs/usbarmory_defconfig +++ b/configs/usbarmory_defconfig @@ -15,4 +15,5 @@ CONFIG_CMD_USB=y CONFIG_ENV_IS_IN_MMC=y CONFIG_FSL_ESDHC=y CONFIG_USB=y +CONFIG_USB_EHCI_MX5=y CONFIG_OF_LIBFDT=y diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 0fbc115801..1c2212f547 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -132,6 +132,13 @@ config USB_EHCI_MARVELL ---help--- Enables support for the on-chip EHCI controller on MVEBU SoCs. +config USB_EHCI_MX5 + bool "Support for i.MX5 on-chip EHCI USB controller" + depends on ARCH_MX5 + default n + help + Enables support for the on-chip EHCI controller on i.MX5 SoCs. + config USB_EHCI_MX6 bool "Support for i.MX6 on-chip EHCI USB controller" depends on ARCH_MX6 diff --git a/include/configs/kp_imx53.h b/include/configs/kp_imx53.h index d09608df35..a252e9003d 100644 --- a/include/configs/kp_imx53.h +++ b/include/configs/kp_imx53.h @@ -16,7 +16,6 @@ #define CONFIG_SYS_MALLOC_LEN (32 * SZ_1M) /* USB Configs */ -#define CONFIG_USB_EHCI_MX5 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) #define CONFIG_MXC_USB_FLAGS 0 diff --git a/include/configs/m53menlo.h b/include/configs/m53menlo.h index 84d061339e..82842d8426 100644 --- a/include/configs/m53menlo.h +++ b/include/configs/m53menlo.h @@ -118,7 +118,6 @@ * USB */ #ifdef CONFIG_CMD_USB -#define CONFIG_USB_EHCI_MX5 #define CONFIG_MXC_USB_PORT1 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) #define CONFIG_MXC_USB_FLAGS 0 diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h index 9bf9773c69..f5fd01de22 100644 --- a/include/configs/mx51evk.h +++ b/include/configs/mx51evk.h @@ -61,7 +61,6 @@ #define CONFIG_FEC_MXC_PHYADDR 0x1F /* USB Configs */ -#define CONFIG_USB_EHCI_MX5 #define CONFIG_MXC_USB_PORT1 #define CONFIG_MXC_USB_PORTSC PORT_PTS_ULPI #define CONFIG_MXC_USB_FLAGS MXC_EHCI_POWER_PINS_ENABLED diff --git a/include/configs/mx53cx9020.h b/include/configs/mx53cx9020.h index 1e3ea88b77..9bf5d9169b 100644 --- a/include/configs/mx53cx9020.h +++ b/include/configs/mx53cx9020.h @@ -41,7 +41,6 @@ #define CONFIG_FEC_MXC_PHYADDR 0x1F /* USB Configs */ -#define CONFIG_USB_EHCI_MX5 #define CONFIG_MXC_USB_PORT1 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) #define CONFIG_MXC_USB_FLAGS 0 diff --git
[U-Boot] arm: sunxi: Bananapi_M2_Ultra not working with DM_MMC
A few days ago I tried to boot my Bananapi_M2_Ultra with 2019.04rc, I found that it wasn't booting, 2019.01 was working ok. Bisecting indicated that the problem was after http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a7cca5793774ee139b75a704d6efaa4d29f09f93 Here's what I see when booting: U-Boot SPL 2019.04-rc4 (Apr 02 2019 - 16:17:43 +) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2019.04-rc4 (Apr 02 2019 - 16:17:43 +) Allwinner Technology CPU: Allwinner R40 (SUN8I 1701) Model: Banana Pi BPI-M2-Ultra I2C: ready DRAM: 2 GiB MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c1' mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1 Loading Environment from FAT... ** No valid partitions found ** In: serial@1c28000 Out: serial@1c28000 Err: serial@1c28000 SCSI: Target spinup took 0 ms. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: phy interface7 eth0: ethernet@1c5 starting USB... No controllers found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc1(part 0) is current device ** Invalid partition 1 ** scanning bus for devices... data abort pc : [] lr : [] reloc pc : [<4a01a6da>] lr : [<4a016991>] sp : bbf5d620 ip : 001c fp : 00c0 r10: r9 : bbf61ed8 r8 : r7 : bbf5d8a0 r6 : bffdbff0 r5 : bffdbff0 r4 : bffdbff0 r3 : r2 : r1 : ea16 r0 : bffdbff0 Flags: nZcv IRQs off FIQs off Mode SVC_32 Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604) Resetting CPU ... resetting ... Any pointers on what to text next? Thanks. Pablo. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Arm: imx7d-pico: Import all Linux device tree for Pico i.MX7D SOM
Le 04/04/2019 à 10:28, Joris Offouga a écrit : Le 03/04/2019 à 22:40, Otavio Salvador a écrit : On Mon, Mar 25, 2019 at 10:42 AM Fabio Estevam wrote: On Mon, Mar 25, 2019 at 9:52 AM Joris Offouga wrote: This patch imports the Linux kernel base board imx7d-pico.dtsi, pi board imx7d-pico-pi.dts and hobbit board imx7d-pico-hobbit.dts from Linux v5.1-rc1. Signed-off-by: Joris Offouga Tested-by: Fabio Estevam The dtb files are not included on the Makefile, so if we try to build the image it fails. This is not necessary since we are using the CONFIG_DEFAULT_FDT_FILE. Sorry indeed it must be added I will send a v2 with this change Best Regards, Joris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] board: pm9g45: Migrate to CONFIG_DM
On 03.04.2019 17:50, Ilko Iliev wrote: > Migrate the following options to CONFIG_DM: >CONFIG_DM_GPIO >CONFIG_DM_MMC >CONFIG_DM_ETH >CONFIG_DM_SERIAL >CONFIG_DM_USB > > Signed-off-by: Ilko Iliev Applied to u-boot-atmel/next Thanks ! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog: Implement generic watchdog_reset() version
On 04.04.19 13:23, Stefan Roese wrote: This patch tries to implement a generic watchdog_reset() function that can be used by all boards that want to service the watchdog device in U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG. Without this approach, new boards or platforms needed to implement a board specific version of this functionality, mostly copy'ing the same code over and over again into their board or platforms code base. With this new generic function, the scattered other functions are now removed to be replaced by the generic one. The new version also enables the configuration of the watchdog timeout via the DT "timeout-sec" property (if enabled via CONFIG_OF_CONTROL). This patch also adds a new flag to the GD flags, to flag that the watchdog is ready to use and adds the pointer to the watchdog device to the GD. This enables us to remove the global "watchdog_dev" variable, which was prone to cause problems because of its potentially very early use in watchdog_reset(), even before the BSS is cleared. Signed-off-by: Stefan Roese Cc: Tom Rini Cc: Simon Glass Cc: Heiko Schocher Cc: Michal Simek Cc: "Marek Behún" Cc: Daniel Schwierzeck --- This patch depends on the following patches: [1] watchdog: Move watchdog_dev to data section (BSS may not be cleared) https://patchwork.ozlabs.org/patch/1075500/ [2] watchdog: Handle SPL build with watchdog disabled https://patchwork.ozlabs.org/patch/1074098/ I would like to see [2] applied in this release, since its a real fix on some of the platforms with minimal chances of breakage. Sorry, this should be: "I would like to see [1] applied" (instead of [2]). Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] watchdog: Implement generic watchdog_reset() version
This patch tries to implement a generic watchdog_reset() function that
can be used by all boards that want to service the watchdog device in
U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG.
Without this approach, new boards or platforms needed to implement a
board specific version of this functionality, mostly copy'ing the same
code over and over again into their board or platforms code base.
With this new generic function, the scattered other functions are now
removed to be replaced by the generic one. The new version also enables
the configuration of the watchdog timeout via the DT "timeout-sec"
property (if enabled via CONFIG_OF_CONTROL).
This patch also adds a new flag to the GD flags, to flag that the
watchdog is ready to use and adds the pointer to the watchdog device
to the GD. This enables us to remove the global "watchdog_dev"
variable, which was prone to cause problems because of its potentially
very early use in watchdog_reset(), even before the BSS is cleared.
Signed-off-by: Stefan Roese
Cc: Tom Rini
Cc: Simon Glass
Cc: Heiko Schocher
Cc: Michal Simek
Cc: "Marek Behún"
Cc: Daniel Schwierzeck
---
This patch depends on the following patches:
[1] watchdog: Move watchdog_dev to data section (BSS may not be cleared)
https://patchwork.ozlabs.org/patch/1075500/
[2] watchdog: Handle SPL build with watchdog disabled
https://patchwork.ozlabs.org/patch/1074098/
I would like to see [2] applied in this release, since its a real fix on
some of the platforms with minimal chances of breakage.
This patch now is a bigger rework and is intended for the next merge
window. Please review and test if possible. Comments welcome.
Thanks,
Stefan
arch/mips/mach-mt7620/cpu.c | 36 -
board/CZ.NIC/turris_mox/turris_mox.c | 30
board/CZ.NIC/turris_omnia/turris_omnia.c | 35 -
.../microblaze-generic/microblaze-generic.c | 40 --
board/xilinx/zynq/board.c | 39 --
board/xilinx/zynqmp/zynqmp.c | 39 --
drivers/watchdog/wdt-uclass.c | 74 +++
include/asm-generic/global_data.h | 4 +
8 files changed, 78 insertions(+), 219 deletions(-)
diff --git a/arch/mips/mach-mt7620/cpu.c b/arch/mips/mach-mt7620/cpu.c
index fe74f26a54..fcd0484a6d 100644
--- a/arch/mips/mach-mt7620/cpu.c
+++ b/arch/mips/mach-mt7620/cpu.c
@@ -69,28 +69,6 @@ int print_cpuinfo(void)
return 0;
}
-#ifdef CONFIG_WATCHDOG
-static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
-
-/* Called by macro WATCHDOG_RESET */
-void watchdog_reset(void)
-{
- static ulong next_reset;
- ulong now;
-
- if (!watchdog_dev)
- return;
-
- now = get_timer(0);
-
- /* Do not reset the watchdog too often */
- if (now > next_reset) {
- next_reset = now + 1000;/* reset every 1000ms */
- wdt_reset(watchdog_dev);
- }
-}
-#endif
-
int arch_misc_init(void)
{
/*
@@ -103,19 +81,5 @@ int arch_misc_init(void)
flush_dcache_range(gd->bd->bi_memstart,
gd->bd->bi_memstart + gd->ram_size - 1);
-#ifdef CONFIG_WATCHDOG
- /* Init watchdog */
- if (uclass_get_device_by_seq(UCLASS_WDT, 0, _dev)) {
- debug("Watchdog: Not found by seq!\n");
- if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
- puts("Watchdog: Not found!\n");
- return 0;
- }
- }
-
- wdt_start(watchdog_dev, 6, 0); /* 60 seconds */
- printf("Watchdog: Started\n");
-#endif
-
return 0;
}
diff --git a/board/CZ.NIC/turris_mox/turris_mox.c
b/board/CZ.NIC/turris_mox/turris_mox.c
index 96cb9c7e5c..8a4872343b 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -119,41 +119,11 @@ int board_fix_fdt(void *blob)
}
#endif
-#ifdef CONFIG_WDT_ARMADA_37XX
-static struct udevice *watchdog_dev __attribute__((section(".data"))) = NULL;
-
-void watchdog_reset(void)
-{
- static ulong next_reset;
- ulong now;
-
- if (!watchdog_dev)
- return;
-
- now = timer_get_us();
-
- /* Do not reset the watchdog too often */
- if (now > next_reset) {
- wdt_reset(watchdog_dev);
- next_reset = now + 10;
- }
-}
-#endif
-
int board_init(void)
{
/* address of boot parameters */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
-#ifdef CONFIG_WDT_ARMADA_37XX
- if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
- printf("Cannot find Armada 3720 watchdog!\n");
- } else {
- printf("Enabling Armada 3720 watchdog (3 minutes timeout).\n");
- wdt_start(watchdog_dev, 18, 0);
- }
-#endif
-
return 0;
}
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
Re: [U-Boot] [PATCH 1/2] image: android: allow booting lz4-compressed kernels
Hi Marek and thanks for your swift comment,
On Thu, Apr 04, 2019 at 03:39:30AM +0200, Marek Vasut wrote:
> On 4/3/19 11:35 PM, Eugeniu Rosca wrote:
> > According to Android image format [1], kernel image resides at 1 page
> > offset from the boot image address. Grab the magic number from there
> > and allow U-Boot to handle LZ4-compressed KNL binaries instead of
> > hardcoding compression type to IH_COMP_NONE. Other compression types,
> > if needed, can be added later.
> >
[..]
> >
> > +#define LZ4F_MAGIC 0x184D2204
>
> Don't we already have this magic in some common header ?
Unfortunately not. It is present in lib/lz4_wrapper.c only.
Would it be OK to relocate it to include/image.h?
> > +ulong android_image_get_kcomp(const struct andr_img_hdr *hdr)
> > +{
> > + u32 *magic = (u32 *)((ulong)hdr + hdr->page_size);
>
> Should this be get_unaligned((uintptr_t)hdr + hdr->page_size) ?
> get_unaligned() because the image may be at unaligned address (although
> that's unlikely) [..]
Just out of curiosity I've copied the Android image to 0x4c01
instead of 0x4c00 in RAM and by calling 'bootm 0x4c01', the
compression type is still correctly identified and OS boots properly
(w/o get_unaligned).
But that's because the data cache is enabled. Booting from 0x4c01
after calling `dcache off` no longer works and generates a
"Synchronous Abort".
Actually having dcache enabled is a requirement for LZ4, since it
heavily relies on unaligned memory access and produces the same data
abort in case dcache is turned off (even if it is passed the image at
a properly aligned location in RAM).
So, bottom line, even if we use get_unaligned() here, the LZ4 kernel
still won't boot with data cache disabled. Anyway, I agree to use an
alignment-aware primitive here, as you suggested.
> and uintptr_t to cater for both 32 and 64bit pointers.
Worked for me.
[..]
> > @@ -1312,6 +1312,7 @@ int android_image_get_second(const struct
> > andr_img_hdr *hdr,
> > ulong *second_data, ulong *second_len);
> > ulong android_image_get_end(const struct andr_img_hdr *hdr);
> > ulong android_image_get_kload(const struct andr_img_hdr *hdr);
> > +ulong android_image_get_kcomp(const struct andr_img_hdr *hdr);
Would you like ulong/int here?
> > void android_print_contents(const struct andr_img_hdr *hdr);
> >
> > #endif /* CONFIG_ANDROID_BOOT_IMAGE */
> >
>
>
> --
> Best regards,
> Marek Vasut
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] DTS: imx53: Add imx53-kp-u-boot.dtsi file with u-boot specific property
This file adds the "u-boot,i2c-transaction-bytes" to mc34708 PMIC.
Signed-off-by: Lukasz Majewski
---
arch/arm/dts/imx53-kp-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 arch/arm/dts/imx53-kp-u-boot.dtsi
diff --git a/arch/arm/dts/imx53-kp-u-boot.dtsi
b/arch/arm/dts/imx53-kp-u-boot.dtsi
new file mode 100644
index 00..acab9b3657
--- /dev/null
+++ b/arch/arm/dts/imx53-kp-u-boot.dtsi
@@ -0,0 +1,10 @@
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * SPDX-License-Identifier: GPL-2.0+ or X11
+ */
+
+ {
+ u-boot,i2c-transaction-bytes = <3>;
+};
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] DM: I2C: Introduce 'u-boot, i2c-transaction-bytes' property
The 'u-boot,i2c-transaction-bytes' device tree property provides
information regarding number of bytes transferred by a device in a
single transaction.
This change is necessary to avoid hanging devices after soft reset.
One notable example is communication with MC34708 device:
1. Reset when communicating with MC34708 via I2C.
2. The u-boot (after reboot -f) tries to setup the I2C and then calls
force_idle_bus. In the same time MC34708 still has some data to be sent
(as it transfers data in 24 bits chunks).
3. The force_idle_bus() is not able to make the bus idle as 8 SCL
clocks may be not enough to have the full transmission.
4. We end up with I2C inconsistency with MC34708.
This PMIC device requires 24+ SCL cycles to make finish any pending I2C
transmission.
Signed-off-by: Lukasz Majewski
---
doc/device-tree-bindings/i2c/i2c.txt | 5 +
drivers/i2c/i2c-uclass.c | 24
drivers/i2c/mxc_i2c.c| 19 +--
include/i2c.h| 2 ++
4 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/doc/device-tree-bindings/i2c/i2c.txt
b/doc/device-tree-bindings/i2c/i2c.txt
index de818d4713..9698e4899b 100644
--- a/doc/device-tree-bindings/i2c/i2c.txt
+++ b/doc/device-tree-bindings/i2c/i2c.txt
@@ -12,6 +12,10 @@ property which allows the chip offset length to be selected.
Optional properties:
- u-boot,i2c-offset-len - length of chip offset in bytes. If omitted the
default value of 1 is used.
+- u-boot,i2c-transaction-bytes - the length of single I2C transaction on
+the bus. Some devices require more than single byte transmission
+(e.g. mc34708 mfd). This information is necessary to correctly
+ initialize (put into idle state) I2C bus after soft reset.
- gpios = , ;
pinctrl-names = "default", "gpio";
pinctrl-0 = <_xfer>;
@@ -28,6 +32,7 @@ i2c4: i2c@12ca {
compatible = "google,cros-ec";
i2c-max-frequency = <10>;
u-boot,i2c-offset-len = <0>;
+ u-boot,i2c-transaction-bytes = <3>;
ec-interrupt = < 6 GPIO_ACTIVE_LOW>;
};
};
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 49e23a0a4b..e47abf1833 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -593,6 +593,29 @@ int i2c_chip_ofdata_to_platdata(struct udevice *dev,
struct dm_i2c_chip *chip)
}
#endif
+static int i2c_pre_probe(struct udevice *dev)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
+ struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);
+ unsigned int max = 0;
+ ofnode node;
+ int ret;
+
+ i2c->max_transaction_bytes = 0;
+ dev_for_each_subnode(node, dev) {
+ ret = ofnode_read_u32(node,
+ "u-boot,i2c-transaction-bytes",
+ );
+ if (!ret && max > i2c->max_transaction_bytes)
+ i2c->max_transaction_bytes = max;
+ }
+
+ debug("%s: I2C bus: %s max transaction bytes: %d\n", __func__,
+ dev->name, i2c->max_transaction_bytes);
+#endif
+ return 0;
+}
+
static int i2c_post_probe(struct udevice *dev)
{
#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
@@ -674,6 +697,7 @@ UCLASS_DRIVER(i2c) = {
.post_bind = i2c_post_bind,
.init = i2c_uclass_init,
.priv_auto_alloc_size = sizeof(struct i2c_priv),
+ .pre_probe = i2c_pre_probe,
.post_probe = i2c_post_probe,
.per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
.per_child_platdata_auto_alloc_size = sizeof(struct dm_i2c_chip),
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index d9fe5e..5420afbc8e 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -354,9 +354,10 @@ int i2c_idle_bus(struct mxc_i2c_bus *i2c_bus)
int i2c_idle_bus(struct mxc_i2c_bus *i2c_bus)
{
struct udevice *bus = i2c_bus->bus;
+ struct dm_i2c_bus *i2c = dev_get_uclass_priv(bus);
struct gpio_desc *scl_gpio = _bus->scl_gpio;
struct gpio_desc *sda_gpio = _bus->sda_gpio;
- int sda, scl;
+ int sda, scl, idle_sclks;
int i, ret = 0;
ulong elapsed, start_time;
@@ -380,8 +381,22 @@ int i2c_idle_bus(struct mxc_i2c_bus *i2c_bus)
if ((sda & scl) == 1)
goto exit; /* Bus is idle already */
+ /*
+* In most cases it is just enough to generate 8 + 1 SCLK
+* clocks to recover I2C slave device from 'stuck' state
+* (when for example SW reset was performed, in the middle of
+* I2C transmission).
+*
+* However, there are devices which send data in packets of
+* N bytes (N > 1). In such case we do need N * 8 + 1 SCLK
+* clocks.
+*/
+ idle_sclks = 8 + 1;
+
+ if (i2c->max_transaction_bytes > 0)
+
[U-Boot] [imx-next PATCH v1 09/14] ARM: Remove EHCI specific code from HSC|DDC board file
As EHCI on i.MX5 has been converted to driver model, the board specific
code, necessary for VBUS USB power supply setup is not needed anymore.
Signed-off-by: Lukasz Majewski
---
board/k+p/kp_imx53/kp_imx53.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/board/k+p/kp_imx53/kp_imx53.c b/board/k+p/kp_imx53/kp_imx53.c
index f4d0ad0ef6..57d97153dd 100644
--- a/board/k+p/kp_imx53/kp_imx53.c
+++ b/board/k+p/kp_imx53/kp_imx53.c
@@ -17,7 +17,6 @@
#include
#include "kp_id_rev.h"
-#define VBUS_PWR_EN IMX_GPIO_NR(7, 8)
#define BOOSTER_OFF IMX_GPIO_NR(2, 23)
#define LCD_BACKLIGHT IMX_GPIO_NR(1, 1)
#define KEY1 IMX_GPIO_NR(2, 26)
@@ -42,15 +41,6 @@ int dram_init_banksize(void)
return 0;
}
-#ifdef CONFIG_USB_EHCI_MX5
-int board_ehci_hcd_init(int port)
-{
- gpio_request(VBUS_PWR_EN, "VBUS_PWR_EN");
- gpio_direction_output(VBUS_PWR_EN, 1);
- return 0;
-}
-#endif
-
static int power_init(void)
{
struct udevice *dev;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 14/14] boot.src: Provide dsa_core.blacklist bootarg when booting via NFS
This setup is a bit special as Linux kernel (4.19) is not supporting
in-kernel NFS rootfs mount and Distributed Switch Architecture (DSA)
operation.
For that reason it was necessary to provide a bootarg to allow userspace
enable it afterwards if needed.
Signed-off-by: Lukasz Majewski
---
board/k+p/bootscripts/tpcboot.cmd | 7 +++
1 file changed, 7 insertions(+)
diff --git a/board/k+p/bootscripts/tpcboot.cmd
b/board/k+p/bootscripts/tpcboot.cmd
index 0576e81140..b81494dd1b 100644
--- a/board/k+p/bootscripts/tpcboot.cmd
+++ b/board/k+p/bootscripts/tpcboot.cmd
@@ -27,6 +27,12 @@ setenv miscadj "
if test '${boardsoc}' = 'imx53'; then
setenv bootargs '${bootargs} di=${dig_in} key1=${key1}';
fi;"
+setenv nfsadj "
+if test '${boardsoc}' = 'imx53'; then
+ if test '${boardtype}' = 'hsc'; then
+ setenv bootargs '${bootargs} dsa_core.blacklist=yes';
+ fi;
+fi;"
setenv boot_fitImage "
setenv fdt_conf 'conf@${boardsoc}-${boardname}.dtb';
setenv itbcfg "\"#\${fdt_conf}\"";
@@ -72,6 +78,7 @@ setenv boot_nfs "
if run download_kernel; then
run nfsargs;
run addip;
+ run nfsadj;
setenv bootargs '${bootargs}' console=${console};
run boot_fitImage;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 12/14] ARM: config: Remove not needed CONFIG_MXC_USB_PORT define
After i.MX5's EHCI conversion to DM, the CONFIG_MXC_USB_PORT is not needed anymore and should be removed. Signed-off-by: Lukasz Majewski --- include/configs/kp_imx53.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/kp_imx53.h b/include/configs/kp_imx53.h index 9bbf590b72..d09608df35 100644 --- a/include/configs/kp_imx53.h +++ b/include/configs/kp_imx53.h @@ -17,7 +17,6 @@ /* USB Configs */ #define CONFIG_USB_EHCI_MX5 -#define CONFIG_MXC_USB_PORT1 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) #define CONFIG_MXC_USB_FLAGS 0 -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 10/14] USB: DM: Convert i.MX5 ehci code to driver model
This commit converts i.MX5's EHCI USB host driver to driver model (DM_USB).
It is a straightforward conversion (to reuse as much code as possible),
based on ehci-mx6.c code.
Signed-off-by: Lukasz Majewski
---
drivers/usb/host/ehci-mx5.c | 103
1 file changed, 103 insertions(+)
diff --git a/drivers/usb/host/ehci-mx5.c b/drivers/usb/host/ehci-mx5.c
index 60f1470860..0b32728c57 100644
--- a/drivers/usb/host/ehci-mx5.c
+++ b/drivers/usb/host/ehci-mx5.c
@@ -12,6 +12,8 @@
#include
#include
#include
+#include
+#include
#include "ehci.h"
@@ -223,6 +225,7 @@ __weak void mx5_ehci_powerup_fixup(struct ehci_ctrl *ctrl,
uint32_t *status_reg,
mdelay(50);
}
+#if !CONFIG_IS_ENABLED(DM_USB)
static const struct ehci_ops mx5_ehci_ops = {
.powerup_fixup = mx5_ehci_powerup_fixup,
};
@@ -267,3 +270,103 @@ int ehci_hcd_stop(int index)
{
return 0;
}
+#else /* CONFIG_IS_ENABLED(DM_USB) */
+struct ehci_mx5_priv_data {
+ struct ehci_ctrl ctrl;
+ struct usb_ehci *ehci;
+ struct udevice *vbus_supply;
+ enum usb_init_type init_type;
+ int portnr;
+};
+
+static const struct ehci_ops mx5_ehci_ops = {
+ .powerup_fixup = mx5_ehci_powerup_fixup,
+};
+
+static int ehci_usb_ofdata_to_platdata(struct udevice *dev)
+{
+ struct usb_platdata *plat = dev_get_platdata(dev);
+ const char *mode;
+
+ mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "dr_mode", NULL);
+ if (mode) {
+ if (strcmp(mode, "peripheral") == 0)
+ plat->init_type = USB_INIT_DEVICE;
+ else if (strcmp(mode, "host") == 0)
+ plat->init_type = USB_INIT_HOST;
+ else
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int ehci_usb_probe(struct udevice *dev)
+{
+ struct usb_platdata *plat = dev_get_platdata(dev);
+ struct usb_ehci *ehci = (struct usb_ehci *)devfdt_get_addr(dev);
+ struct ehci_mx5_priv_data *priv = dev_get_priv(dev);
+ enum usb_init_type type = plat->init_type;
+ struct ehci_hccr *hccr;
+ struct ehci_hcor *hcor;
+ int ret;
+
+ set_usboh3_clk();
+ enable_usboh3_clk(true);
+ set_usb_phy_clk();
+ enable_usb_phy1_clk(true);
+ enable_usb_phy2_clk(true);
+ mdelay(1);
+
+ priv->ehci = ehci;
+ priv->portnr = dev->seq;
+ priv->init_type = type;
+
+ ret = device_get_supply_regulator(dev, "vbus-supply",
+ >vbus_supply);
+ if (ret)
+ debug("%s: No vbus supply\n", dev->name);
+
+ if (!ret && priv->vbus_supply) {
+ ret = regulator_set_enable(priv->vbus_supply,
+ (type == USB_INIT_DEVICE) ?
+ false : true);
+ if (ret) {
+ puts("Error enabling VBUS supply\n");
+ return ret;
+ }
+ }
+
+ hccr = (struct ehci_hccr *)((uint32_t)>caplength);
+ hcor = (struct ehci_hcor *)((uint32_t)hccr +
+ HC_LENGTH(ehci_readl(&(hccr)->cr_capbase)));
+ setbits_le32(>usbmode, CM_HOST);
+
+ __raw_writel(CONFIG_MXC_USB_PORTSC, >portsc);
+ setbits_le32(>portsc, USB_EN);
+
+ mxc_set_usbcontrol(priv->portnr, CONFIG_MXC_USB_FLAGS);
+ mdelay(10);
+
+ return ehci_register(dev, hccr, hcor, _ehci_ops, 0,
+priv->init_type);
+}
+
+static const struct udevice_id mx5_usb_ids[] = {
+ { .compatible = "fsl,imx53-usb" },
+ { }
+};
+
+U_BOOT_DRIVER(usb_mx5) = {
+ .name = "ehci_mx5",
+ .id = UCLASS_USB,
+ .of_match = mx5_usb_ids,
+ .ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
+ .probe = ehci_usb_probe,
+ .remove = ehci_deregister,
+ .ops= _usb_ops,
+ .platdata_auto_alloc_size = sizeof(struct usb_platdata),
+ .priv_auto_alloc_size = sizeof(struct ehci_mx5_priv_data),
+ .flags = DM_FLAG_ALLOC_PRIV_DMA,
+};
+#endif /* !CONFIG_IS_ENABLED(DM_USB) */
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 11/14] ARM: defconfig: kp_imx53: Enable DM_USB support on HSC|DDC boards
This commit enables the DM_USB on HSC|DDC i.MX53 based boards. Signed-off-by: Lukasz Majewski --- arch/arm/mach-imx/mx5/Kconfig | 2 ++ configs/kp_imx53_defconfig| 1 + 2 files changed, 3 insertions(+) diff --git a/arch/arm/mach-imx/mx5/Kconfig b/arch/arm/mach-imx/mx5/Kconfig index cbffdaeed1..bde37bb97e 100644 --- a/arch/arm/mach-imx/mx5/Kconfig +++ b/arch/arm/mach-imx/mx5/Kconfig @@ -29,6 +29,8 @@ config TARGET_KP_IMX53 select DM_SERIAL select DM_MMC select BLK + select DM_USB + select DM_REGULATOR select MX53 imply CMD_DM diff --git a/configs/kp_imx53_defconfig b/configs/kp_imx53_defconfig index 4be67d1736..45227c26d2 100644 --- a/configs/kp_imx53_defconfig +++ b/configs/kp_imx53_defconfig @@ -40,6 +40,7 @@ CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX5=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_DM_PMIC_MC34708=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_CONS_INDEX=2 CONFIG_MXC_UART=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 03/14] ARM: Enable CONFIG_DM_MMC and CONFIG_DM_BLK on HSC and DDC boards
This commit enables DM_MMC and DM_BLK on imx53 based HSC and DDC boards. Signed-off-by: Lukasz Majewski --- arch/arm/mach-imx/mx5/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-imx/mx5/Kconfig b/arch/arm/mach-imx/mx5/Kconfig index 29051c40f3..cbffdaeed1 100644 --- a/arch/arm/mach-imx/mx5/Kconfig +++ b/arch/arm/mach-imx/mx5/Kconfig @@ -27,6 +27,8 @@ config TARGET_KP_IMX53 select DM_I2C select DM_PMIC select DM_SERIAL + select DM_MMC + select BLK select MX53 imply CMD_DM -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 08/14] DTS: Enable USB host support (including regulators) on HSC|DDC boards
This commit enables the support for K's HSC|DDC imx53 based boards.
It was also necessary to provide device tree description for regulators
to avoid board specific code definition.
The GPIO pin description responsible for VBUS control has been moved from
"hog" group to usbh1 dedicated one.
Signed-off-by: Lukasz Majewski
---
arch/arm/dts/imx53-kp.dts | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx53-kp.dts b/arch/arm/dts/imx53-kp.dts
index a551fc945b..af4ab5d9f8 100644
--- a/arch/arm/dts/imx53-kp.dts
+++ b/arch/arm/dts/imx53-kp.dts
@@ -21,6 +21,22 @@
aliases {
mmc0 =
};
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usbh1_vbus: regulator-usbh1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usbh1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+ };
+
};
{
@@ -109,8 +125,6 @@
fsl,pins = <
/* PHY RESET */
MX53_PAD_PATA_DA_0__GPIO7_6 0x182
- /* VBUS_PWR_EN */
- MX53_PAD_PATA_DA_2__GPIO7_8 0x1e4
/* BOOSTER_OFF */
MX53_PAD_EIM_CS0__GPIO2_23 0x1e4
/* LCD BACKLIGHT */
@@ -158,6 +172,13 @@
MX53_PAD_PATA_DMARQ__UART2_TXD_MUX 0x1e4
>;
};
+
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ /* VBUS_PWR_EN */
+ MX53_PAD_PATA_DA_2__GPIO7_8 0x1e4
+ >;
+ };
};
};
@@ -166,3 +187,10 @@
pinctrl-0 = <_uart2>;
status = "okay";
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usbh1>;
+ vbus-supply = <_usbh1_vbus>;
+ status = "okay";
+};
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 05/14] ARM: Remove non DM/DTS esdhc3 code from HSC|DDC board related files
After switching to DM/DTS support of esdhc3 - the code in this patch
can be removed.
Signed-off-by: Lukasz Majewski
---
board/k+p/kp_imx53/kp_imx53.c | 46 ---
include/configs/kp_imx53.h| 4
2 files changed, 50 deletions(-)
diff --git a/board/k+p/kp_imx53/kp_imx53.c b/board/k+p/kp_imx53/kp_imx53.c
index 3f21d0b4af..f4d0ad0ef6 100644
--- a/board/k+p/kp_imx53/kp_imx53.c
+++ b/board/k+p/kp_imx53/kp_imx53.c
@@ -13,8 +13,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include "kp_id_rev.h"
@@ -53,50 +51,6 @@ int board_ehci_hcd_init(int port)
}
#endif
-#ifdef CONFIG_FSL_ESDHC
-struct fsl_esdhc_cfg esdhc_cfg[] = {
- {MMC_SDHC3_BASE_ADDR},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- return 1; /* eMMC is always present */
-}
-
-#define SD_CMD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_DSE_HIGH | \
-PAD_CTL_PUS_100K_UP)
-#define SD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_47K_UP | \
-PAD_CTL_DSE_HIGH)
-
-int board_mmc_init(bd_t *bis)
-{
- int ret;
-
- static const iomux_v3_cfg_t sd3_pads[] = {
- NEW_PAD_CTRL(MX53_PAD_PATA_RESET_B__ESDHC3_CMD,
-SD_CMD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_IORDY__ESDHC3_CLK, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA8__ESDHC3_DAT0, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA9__ESDHC3_DAT1, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA10__ESDHC3_DAT2, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA11__ESDHC3_DAT3, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA0__ESDHC3_DAT4, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA1__ESDHC3_DAT5, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA2__ESDHC3_DAT6, SD_PAD_CTRL),
- NEW_PAD_CTRL(MX53_PAD_PATA_DATA3__ESDHC3_DAT7, SD_PAD_CTRL),
- };
-
- esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
- imx_iomux_v3_setup_multiple_pads(sd3_pads, ARRAY_SIZE(sd3_pads));
-
- ret = fsl_esdhc_initialize(bis, _cfg[0]);
- if (ret)
- return ret;
-
- return 0;
-}
-#endif
-
static int power_init(void)
{
struct udevice *dev;
diff --git a/include/configs/kp_imx53.h b/include/configs/kp_imx53.h
index f82dcd8426..ca6ab0fabc 100644
--- a/include/configs/kp_imx53.h
+++ b/include/configs/kp_imx53.h
@@ -15,10 +15,6 @@
/* Size of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN (32 * SZ_1M)
-/* MMC Configs */
-#define CONFIG_SYS_FSL_ESDHC_ADDR 0
-#define CONFIG_SYS_FSL_ESDHC_NUM 1
-
/* USB Configs */
#define CONFIG_USB_EHCI_MX5
#define CONFIG_MXC_USB_PORT1
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 04/14] ARM: defconfig: Move CONFIG_FSL_ESDHC to Kconfig
The CONFIG_FSL_ESDHC is now enabled and defined in Kconfig, not in include/configs/kp_imx53.h Signed-off-by: Lukasz Majewski --- configs/kp_imx53_defconfig | 1 + include/configs/kp_imx53.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/kp_imx53_defconfig b/configs/kp_imx53_defconfig index cfe96fcce5..4be67d1736 100644 --- a/configs/kp_imx53_defconfig +++ b/configs/kp_imx53_defconfig @@ -31,6 +31,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx53-kp" CONFIG_ENV_IS_IN_MMC=y CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_I2C_DEFAULT_BUS_NUMBER=0x1 +CONFIG_FSL_ESDHC=y CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y CONFIG_FEC_MXC=y diff --git a/include/configs/kp_imx53.h b/include/configs/kp_imx53.h index 3ea75fa120..f82dcd8426 100644 --- a/include/configs/kp_imx53.h +++ b/include/configs/kp_imx53.h @@ -16,7 +16,6 @@ #define CONFIG_SYS_MALLOC_LEN (32 * SZ_1M) /* MMC Configs */ -#define CONFIG_FSL_ESDHC #define CONFIG_SYS_FSL_ESDHC_ADDR 0 #define CONFIG_SYS_FSL_ESDHC_NUM 1 -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 07/14] DTS: Provide USB host DTS description for i.MX53 devices
This code has been ported from Linux kernel - tag v5.1-rc2.
The difference from the kernel is the removal of:
fsl,usbmisc = < 1>;
fsl,usbphy = <>;
properties, which are not needed for correct u-boot operation (as PHY
setup is done in ehci-mx5.c file itself).
Signed-off-by: Lukasz Majewski
---
arch/arm/dts/imx53.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/imx53.dtsi b/arch/arm/dts/imx53.dtsi
index 0fd4acc6f5..5ba6174789 100644
--- a/arch/arm/dts/imx53.dtsi
+++ b/arch/arm/dts/imx53.dtsi
@@ -35,6 +35,7 @@
mmc1 =
mmc2 =
mmc3 =
+ usb1 =
};
tzic: tz-interrupt-controller@fffc000 {
@@ -136,6 +137,15 @@
status = "disabled";
};
+ usbh1: usb@53f80200 {
+ compatible = "fsl,imx53-usb", "fsl,imx27-usb";
+ reg = <0x53f80200 0x0200>;
+ interrupts = <14>;
+ clocks = < IMX5_CLK_USBOH3_GATE>;
+ dr_mode = "host";
+ status = "disabled";
+ };
+
clks: ccm@53fd4000{
compatible = "fsl,imx53-ccm";
reg = <0x53fd4000 0x4000>;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 02/14] DTS: Add esdhc3 device tree description tuning for HSC|DDC boards
In this commit the esdhc3 controller is enabled as well as it is remaped
to mmc0 to not break legacy code.
The pinctrl setup (e.g. 0x1e4) is the same as one from in-board file
definition.
Signed-off-by: Lukasz Majewski
---
arch/arm/dts/imx53-kp.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/dts/imx53-kp.dts b/arch/arm/dts/imx53-kp.dts
index 3ce4445c18..a551fc945b 100644
--- a/arch/arm/dts/imx53-kp.dts
+++ b/arch/arm/dts/imx53-kp.dts
@@ -17,6 +17,18 @@
chosen {
stdout-path =
};
+
+ aliases {
+ mmc0 =
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_esdhc3>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
};
{
@@ -61,6 +73,21 @@
pinctrl-0 = <_hog>;
imx53-kp {
+ pinctrl_esdhc3: esdhc3grp {
+ fsl,pins = <
+ MX53_PAD_PATA_DATA8__ESDHC3_DAT00x1d4
+ MX53_PAD_PATA_DATA9__ESDHC3_DAT10x1d4
+ MX53_PAD_PATA_DATA10__ESDHC3_DAT2 0x1d4
+ MX53_PAD_PATA_DATA11__ESDHC3_DAT3 0x1d4
+ MX53_PAD_PATA_DATA0__ESDHC3_DAT40x1d4
+ MX53_PAD_PATA_DATA1__ESDHC3_DAT50x1d4
+ MX53_PAD_PATA_DATA2__ESDHC3_DAT60x1d4
+ MX53_PAD_PATA_DATA3__ESDHC3_DAT70x1d4
+ MX53_PAD_PATA_RESET_B__ESDHC3_CMD 0x1e4
+ MX53_PAD_PATA_IORDY__ESDHC3_CLK 0x1d4
+ >;
+ };
+
pinctrl_eth: ethgrp {
fsl,pins = <
MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 06/14] ARM: kp_imx53: config: Do not use ${boardtype} to setup update wic file
After unification of the rootfs for both HSC and DDC devices, only one,
common wic file is necessary - without the distinction of specific board.
Signed-off-by: Lukasz Majewski
---
include/configs/kp_imx53.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/kp_imx53.h b/include/configs/kp_imx53.h
index ca6ab0fabc..9bbf590b72 100644
--- a/include/configs/kp_imx53.h
+++ b/include/configs/kp_imx53.h
@@ -52,7 +52,7 @@
"setexpr blkc ${blkc} + 1; " \
"mmc write ${loadaddr} 0x2 ${blkc}" \
"; fi\0" \
- "upwic=setenv wic_file kp-image-kp${boardsoc}${boardtype}.wic; "\
+ "upwic=setenv wic_file kp-image-kp${boardsoc}.wic; "\
"if tftp ${loadaddr} ${wic_file}; then " \
"setexpr blkc ${filesize} / 0x200; " \
"setexpr blkc ${blkc} + 1; " \
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [imx-next PATCH v1 01/14] ARM: Remove HSC|DDC ETH PHY reset code after switching to DM/DTS
After commit efd0b791069a ("eth: dm: fec: Add gpio phy reset binding")
the in-board file definition of ETH PHY reset can be removed.
Signed-off-by: Lukasz Majewski
---
board/k+p/kp_imx53/kp_imx53.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/board/k+p/kp_imx53/kp_imx53.c b/board/k+p/kp_imx53/kp_imx53.c
index a12ab9107f..3f21d0b4af 100644
--- a/board/k+p/kp_imx53/kp_imx53.c
+++ b/board/k+p/kp_imx53/kp_imx53.c
@@ -20,7 +20,6 @@
#include "kp_id_rev.h"
#define VBUS_PWR_EN IMX_GPIO_NR(7, 8)
-#define PHY_nRST IMX_GPIO_NR(7, 6)
#define BOOSTER_OFF IMX_GPIO_NR(2, 23)
#define LCD_BACKLIGHT IMX_GPIO_NR(1, 1)
#define KEY1 IMX_GPIO_NR(2, 26)
@@ -211,17 +210,6 @@ int board_init(void)
return 0;
}
-void eth_phy_reset(void)
-{
- gpio_request(PHY_nRST, "PHY_nRST");
- gpio_direction_output(PHY_nRST, 1);
- udelay(50);
- gpio_set_value(PHY_nRST, 0);
- udelay(400);
- gpio_set_value(PHY_nRST, 1);
- udelay(50);
-}
-
void board_disable_display(void)
{
gpio_request(LCD_BACKLIGHT, "LCD_BACKLIGHT");
@@ -258,8 +246,6 @@ int board_late_init(void)
if (ret)
printf("Error %d reading EEPROM content!\n", ret);
- eth_phy_reset();
-
show_eeprom();
read_board_id();
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
On 04-04-19 09:56, Michal Simek wrote:
> On 04. 04. 19 9:52, Luca Ceresoli wrote:
>> Hi Mike, Michal,
>>
>> On 04/04/19 08:49, Michal Simek wrote:
>> [...]
> +#ifdef ZYNQMP_LOAD_PM_CFG_OBJ
> +#include CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE
> +#endif
> +
> int board_early_init_f(void)
> {
> int ret = 0;
> @@ -332,6 +338,11 @@ int board_early_init_f(void)
>
> int board_init(void)
> {
> +#if defined(CONFIG_SPL_BUILD) && defined(ZYNQMP_LOAD_PM_CFG_OBJ)
> + zynqmp_pmufw_load_config_object(XPm_ConfigObject,
> + sizeof(XPm_ConfigObject));
> +#endif
As we discussed over IRC. I think that this should be simply bin
firmware file compare to C built by u-boot.
>>>
>>> Sure. I have a working prototype that uses a binary blob. It still needs
>>> a decent way to produce a blob and to be updated according to your
>>> review.
>>
>> It should be doable to write a Python script to parse the C file and
>> create an
>> equivalent binary (using "struct" module) which is just an array of
>> integers
>> in the end. That avoids the need for a microblaze C compiler...
>
> There's no need for a microblaze compiler. pm_cfg_obj.c is simply
> declaring a u32 array and some #defines, any C compiler is enough.
>
> That said, my current solution (a trivial main.c that compiles the u32
> array and outputs it to a binary file) is not nice at all, and it
> requires a pm_defs.h file.
>
> The python script you mention looks way better from a user perspective,
> although the parsing might be a bit fragile. I'll consider it, thanks
> for the suggestion.
>
> In the past I even prototyped a python script that parses the Vivado
> .xpr project file and produces a pm_cfg_obj.c. It avoided the need to
> run the Xilinx XSDK just to generate pm_cfg_obj.c. It might also be
> extended to produce a .bin directly, or a self-standing .c file that
> doesn't need pm_defs.h, thus removing any licensing issue. But it never
> grew complete to handle all cases. Obvious, since *I* don't even know
> all of the cases. :)
Another approach would be to simply create and include a "god mode" config
object that just allows access to all periferals. As far as I can see,
such a
config object would just work on all boards. There's nothing really board
specific in the config object, and it's rather lame anyway to have to go
and
compile a new bootloader just because you want to use a SPI controller...
The config object I compile into the pmu firmware is of that type anyway.
>>
>> Oh, that's interesting, but read below.
>>
>>> Most of that stuff should be the same for all boards. But there are some
>>> stuff which can be just board specific.
>>
>> Mike, I think Michal refers to boards like Ultra96 which need special
>> GPIO handling for their boot sequence, whose pm_cfg_obj.c have a final
>> section similar to this:
>>
>> /* GPO SECTION */
>> PM_CONFIG_GPO_SECTION_ID, /* GPO Section ID */
>> PM_CONFIG_GPO1_BIT_2_MASK |
>> PM_CONFIG_GPO1_MIO_PIN_34_MAP |
>> 0, /* State of GPO pins */
>>
>> I suspect a "god mode" config cannot handle such cases.
>
> That's ultra96 is one of that exception but it depends on your MIO
> configs too. It means you simply not assigned that gpo pins to PMU. You
> loose functionality but you should be able to fix it differently later
> in boot.
I have no clue what those bits do. If it's something like setting a pinmux or
gpio state, that'd be easy enough to do in u-boot or kernel, they both can
send commands to the PMU anyway.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Thu, 4 Apr 2019 14:56:36 +0530 Jagan Teki wrote: > On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski wrote: > > > > On Tue, 2 Apr 2019 16:58:33 +0530 > > Jagan Teki wrote: > > > > > This is revised version of previous i.MX6 clock management [1]. > > > > > > The main difference between previous version is > > > - Group the i.MX6 ccm clocks into gates and tree instead of > > > handling the clocks in simple way using case statement. > > > - use gate clocks for enable/disable management. > > > - use tree clocks for get/set rate or parent traverse management. > > > - parent clock handling via clock type. > > > - traverse the parent clock using recursive functionlaity. > > > > > > The main motive behind this tree framework is to make the clock > > > tree management simple and useful for U-Boot requirements instead > > > of garbing Linux clock management code. > > > > > > We are trying to manage the Allwinner clocks with similar kind, so > > > having this would really help i.MX6 as well. > > > > > > Added simple names for clock macros, but will update it in future > > > version. > > > > > > I have skipped ENET clocks from previous series, will add it in > > > future patches. > > > > > > Changes for v2: > > > - changed framework patches. > > > - add support for imx6qdl and imx6ul boards > > > - add clock gates, tree. > > > > > > [1] https://patchwork.ozlabs.org/cover/950964/ > > > > > > Any inputs? > > > > Hmm It looks like we are doing some development in parallel. > > > > Please look into following commit [1]: > > https://patchwork.ozlabs.org/patch/1034051/ > > > > It ports from Linux 5.0 the CCF framework for iMX6Q, which IMHO in > > the long term is a better approach. > > The code is kept simple and resembles the code from Barebox. > > > > Please correct me if I'm wrong, but the code from your work is not > > modeling muxes, gates and other components from Linux CCF. > > The U-Boot implementation of CLK would require as minimal and simple > as possible due to requirement of U-Boot itself. Hope you agree this > point? Now i.MX6 is using clock.c CLK implementation. If we decide to replace it - we shall do it in a way, which would allow us to follow Linux kernel. (the barebox implementation is a stripped CCF from Linux, the same is in patch [1]). > if yes having CCF stack code to handle all clock with > respective separate drivers management is may not require as of now, > IMHO. I do have a gut feeling, that we will end up with the need to have the CCF framework ported anyway. As for example imx7/8 can re-use muxes, gates code. However, those are only my "feelings" after a glimpse look - I will look into your code more thoroughly and provide feedback. > > This series is using recursive calls for handling parenting stuff to > handle get or set rates, which is fine for handling clock tree > management as far as U-Boot point-of-view. We have faced similar > situation as I explained in commit message about Allwinner clocks [2] > and we ended up going this way. I'm not Allwinner expert - but if I may ask - how far away is this implementation from mainline Linux kernel? How difficult is it to port the new code (or update it)? > > The patches where I get introduced clock tree is based on muxes, gates > which were similar like Linux but I've managed to update according to > U-Boot need. > I have tried enet, enet_ref clocks as well and those are > working out-of-box. > > Feel free to comments, I have no intention to block anything. let's > have a proper discussion. Fabio, Stefano what do you think? As we change the clock.c code, IMHO we shall do the new port properly. > > [2] https://patchwork.ozlabs.org/patch/1019673/ Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpkIZ6MgUre6.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Thu, Apr 4, 2019 at 2:31 PM Lukasz Majewski wrote: > > On Tue, 2 Apr 2019 16:58:33 +0530 > Jagan Teki wrote: > > > This is revised version of previous i.MX6 clock management [1]. > > > > The main difference between previous version is > > - Group the i.MX6 ccm clocks into gates and tree instead of handling > > the clocks in simple way using case statement. > > - use gate clocks for enable/disable management. > > - use tree clocks for get/set rate or parent traverse management. > > - parent clock handling via clock type. > > - traverse the parent clock using recursive functionlaity. > > > > The main motive behind this tree framework is to make the clock tree > > management simple and useful for U-Boot requirements instead of > > garbing Linux clock management code. > > > > We are trying to manage the Allwinner clocks with similar kind, so > > having this would really help i.MX6 as well. > > > > Added simple names for clock macros, but will update it in future > > version. > > > > I have skipped ENET clocks from previous series, will add it in future > > patches. > > > > Changes for v2: > > - changed framework patches. > > - add support for imx6qdl and imx6ul boards > > - add clock gates, tree. > > > > [1] https://patchwork.ozlabs.org/cover/950964/ > > > > Any inputs? > > Hmm It looks like we are doing some development in parallel. > > Please look into following commit [1]: > https://patchwork.ozlabs.org/patch/1034051/ > > It ports from Linux 5.0 the CCF framework for iMX6Q, which IMHO in the > long term is a better approach. > The code is kept simple and resembles the code from Barebox. > > Please correct me if I'm wrong, but the code from your work is not > modeling muxes, gates and other components from Linux CCF. The U-Boot implementation of CLK would require as minimal and simple as possible due to requirement of U-Boot itself. Hope you agree this point? if yes having CCF stack code to handle all clock with respective separate drivers management is may not require as of now, IMHO. This series is using recursive calls for handling parenting stuff to handle get or set rates, which is fine for handling clock tree management as far as U-Boot point-of-view. We have faced similar situation as I explained in commit message about Allwinner clocks [2] and we ended up going this way. The patches where I get introduced clock tree is based on muxes, gates which were similar like Linux but I've managed to update according to U-Boot need. I have tried enet, enet_ref clocks as well and those are working out-of-box. Feel free to comments, I have no intention to block anything. let's have a proper discussion. [2] https://patchwork.ozlabs.org/patch/1019673/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] clk: imx: Add i.MX6 CLK support
On Tue, 2 Apr 2019 16:58:33 +0530 Jagan Teki wrote: > This is revised version of previous i.MX6 clock management [1]. > > The main difference between previous version is > - Group the i.MX6 ccm clocks into gates and tree instead of handling > the clocks in simple way using case statement. > - use gate clocks for enable/disable management. > - use tree clocks for get/set rate or parent traverse management. > - parent clock handling via clock type. > - traverse the parent clock using recursive functionlaity. > > The main motive behind this tree framework is to make the clock tree > management simple and useful for U-Boot requirements instead of > garbing Linux clock management code. > > We are trying to manage the Allwinner clocks with similar kind, so > having this would really help i.MX6 as well. > > Added simple names for clock macros, but will update it in future > version. > > I have skipped ENET clocks from previous series, will add it in future > patches. > > Changes for v2: > - changed framework patches. > - add support for imx6qdl and imx6ul boards > - add clock gates, tree. > > [1] https://patchwork.ozlabs.org/cover/950964/ > > Any inputs? Hmm It looks like we are doing some development in parallel. Please look into following commit [1]: https://patchwork.ozlabs.org/patch/1034051/ It ports from Linux 5.0 the CCF framework for iMX6Q, which IMHO in the long term is a better approach. The code is kept simple and resembles the code from Barebox. Please correct me if I'm wrong, but the code from your work is not modeling muxes, gates and other components from Linux CCF. Unfortunately for [1] - I did not have time recently to finish it ... (address Simon's comments about uclass). > Jagan. > > Jagan Teki (10): > clk: imx: Kconfig: Make CONFIG_CLK available for selection > clk: imx: Add i.MX6Q clock driver > clk: imx: Add i.MX6UL clock driver > clk: Add clk_div_mask helper > clk: imx: Add imx6q clock tree support > clk: imx6: Add imx6ul clock tree support > ARM: dts: i.MX6QDL: Add u-boot,dm-spl for clks > ARM: dts: i.MX6UL: Add u-boot,dm-spl for clks > configs: icore_mipi: Enable CLK > ARM: imx6: Enable CLK for Engicam i.MX6UL boards > > arch/arm/dts/imx6qdl-u-boot.dtsi | 4 + > arch/arm/dts/imx6ul-u-boot.dtsi | 4 + > arch/arm/include/asm/arch-mx6/clock.h | 109 > arch/arm/mach-imx/mx6/Kconfig | 2 + > configs/imx6qdl_icore_mipi_defconfig | 2 + > configs/imx8qxp_mek_defconfig | 2 +- > drivers/clk/imx/Kconfig | 29 - > drivers/clk/imx/Makefile | 6 + > drivers/clk/imx/clk-imx6-common.c | 172 > ++ drivers/clk/imx/clk-imx6q.c | > 109 drivers/clk/imx/clk-imx6ul.c | 85 > + include/clk-uclass.h | 2 + > 12 files changed, 523 insertions(+), 3 deletions(-) > create mode 100644 drivers/clk/imx/clk-imx6-common.c > create mode 100644 drivers/clk/imx/clk-imx6q.c > create mode 100644 drivers/clk/imx/clk-imx6ul.c > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpxVlphskq6j.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: imx8m_image: Fix 'unexpected operator' error
Hi Anatolji, On 04/04/19 10:29, Anatolij Gustschin wrote: > Hi Stefano, > > On Wed, 3 Apr 2019 17:07:04 +0200 > Stefano Babic sba...@denx.de wrote: > ... >> Yes, it is in u-boot-imx, I am just checking around if there are some >> other patches that cannot wait and must go into 2019.04. I plan to send >> my PR to Tom for the end of the week. > > Then you probably can apply two tested patches with FEC fixes for > i.mx8qxp MEK? > > http://patchwork.ozlabs.org/patch/1050177 > http://patchwork.ozlabs.org/patch/1050178 > > These were part of the last u-boot-net pull request, but this pull > request was rejected due to issues with other patches, so we still > have broken Ethernet support on MEK board. > I can do it if Joe agree because after merging in u-boot-imx, he needs to rebase his tree. Joe, what do you mind ? > Thanks! > Regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support
Hi, Le jeudi 04 avril 2019 à 14:12 +0530, Jagan Teki a écrit : > On Thu, Apr 4, 2019 at 1:43 PM Paul Kocialkowski wrote: > > Hi, > > > > On Sat, 2018-11-03 at 16:58 +0530, Akash Gajjar wrote: > > > Rockpro64 is rk3399 based board from pine64.org. add initial board > > > support for > > > Rockpro64. complete board support will be added later in upcoming > > > patchsets. > > > > Thanks for contributing this initial support patchset! > > > > Now that the dts has landed in Linux, do you have plans for making a > > new revision of this series? > > > > I plan on using the board soon-ish and I'd like to get an upstream U- > > Boot + Linux setup on it, so I'm definitely interested in this series. > > > > Feel free to let me know if I could help with anything when I get the > > board! > > It is paused because of LPDDR4 code dependency, right now we are > working on it. Will update once the code gets ready to push it on > Mainline. Sound great, thanks for the update! Cheers, Paul ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/10] pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' iomux
Am Donnerstag, 4. April 2019, 10:16:02 CEST schrieb David Wu:
> Hi Philipp,
>
> 在 2019/4/4 下午3:19, Philipp Tomsich 写道:
> >
> >
> >> On 04.04.2019, at 05:51, David Wu wrote:
> >>
> >> RK3288 pmu_gpio0 iomux setting have no higher 16 writing corresponding
> >> bits, need to read before write the register.
> >>
> >> Signed-off-by: David Wu
> >> ---
> >>
> >> drivers/pinctrl/rockchip/pinctrl-rk3288.c | 8 +++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> >> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> >> index 1fa601d954..d66ffdf24b 100644
> >> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> >> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> >> @@ -54,7 +54,13 @@ static int rk3288_set_mux(struct rockchip_pin_bank
> >> *bank, int pin, int mux)
> >>}
> >>}
> >>
> >> - data = (mask << (bit + 16));
> >> + if (bank->bank_num == 0) {
> >> + regmap_read(regmap, reg, );
> >
> > Could you pull the regmap_read out of the if and make it common for all
> > cases, so the differences between the paths are in data-manipulation only?
>
> Yes, the difference between the gpio0 and other pins is the
> data-manipulation, and i think the others don't need the regmap_read,
> so it is not a common case.
yep ... the other pinmuxes are using hiword-mask registers
while only gpio0 (in the pmu-area) needs the to get the
read-modify-write scheme.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support
On Thu, Apr 4, 2019 at 1:43 PM Paul Kocialkowski wrote: > > Hi, > > On Sat, 2018-11-03 at 16:58 +0530, Akash Gajjar wrote: > > Rockpro64 is rk3399 based board from pine64.org. add initial board support > > for > > Rockpro64. complete board support will be added later in upcoming patchsets. > > Thanks for contributing this initial support patchset! > > Now that the dts has landed in Linux, do you have plans for making a > new revision of this series? > > I plan on using the board soon-ish and I'd like to get an upstream U- > Boot + Linux setup on it, so I'm definitely interested in this series. > > Feel free to let me know if I could help with anything when I get the > board! It is paused because of LPDDR4 code dependency, right now we are working on it. Will update once the code gets ready to push it on Mainline. Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: cadence_qspi: Add quad write support
On Wed, Apr 3, 2019 at 5:22 PM Marek Vasut wrote: > > On 4/3/19 8:13 AM, Jagan Teki wrote: > > On Wed, Feb 27, 2019 at 11:06 AM Ley Foon Tan > > wrote: > >> > >> Use quad write if SPI_TX_QUAD flag is set. > >> > >> Tested quad write on Stratix 10 SoC board (Micron > >> serial NOR flash, mt25qu02g) > >> > >> Signed-off-by: Ley Foon Tan > >> > >> --- > > > > Applied to u-boot-spi/master > > That means it goes into THIS release ? If so, NAK. for next release. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 3/3] arm: sunxi: Enable DRAM ODT by default on H3/H5
On Wed, Apr 3, 2019 at 1:23 PM Paul Kocialkowski wrote: > > Hi, > > Le mercredi 03 avril 2019 à 13:09 +0530, Jagan Teki a écrit : > > On Thu, Mar 14, 2019 at 4:07 PM Paul Kocialkowski > > wrote: > > > Most of the boards we support with H3/H5 enable DRAM on-die termination, > > > which is consistent with the high DRAM clocks that are used. > > > > > > Make it the default (like it's done for other similar platforms) instead > > > of defining it in each defconfig. > > > > > > Signed-off-by: Paul Kocialkowski > > > --- > > > arch/arm/mach-sunxi/Kconfig | 1 + > > > configs/bananapi_m2_plus_h3_defconfig | 1 - > > > configs/bananapi_m2_plus_h5_defconfig | 1 - > > > configs/bananapi_m2_zero_defconfig| 1 - > > > configs/emlid_neutis_n5_devboard_defconfig| 1 + > > > configs/libretech_all_h3_cc_h2_plus_defconfig | 1 - > > > configs/libretech_all_h3_cc_h3_defconfig | 1 - > > > configs/libretech_all_h3_cc_h5_defconfig | 1 - > > > configs/nanopi_m1_defconfig | 1 - > > > configs/nanopi_m1_plus_defconfig | 1 - > > > configs/nanopi_neo2_defconfig | 1 + > > > configs/nanopi_neo_air_defconfig | 1 - > > > configs/nanopi_neo_defconfig | 1 - > > > configs/nanopi_neo_plus2_defconfig| 1 + > > > configs/orangepi_2_defconfig | 1 - > > > configs/orangepi_lite_defconfig | 1 - > > > configs/orangepi_one_defconfig| 1 - > > > configs/orangepi_pc2_defconfig| 1 + > > > configs/orangepi_pc_defconfig | 1 - > > > configs/orangepi_pc_plus_defconfig| 1 - > > > configs/orangepi_plus2e_defconfig | 1 - > > > configs/orangepi_plus_defconfig | 1 - > > > configs/orangepi_prime_defconfig | 1 + > > > configs/orangepi_r1_defconfig | 1 - > > > configs/orangepi_zero_defconfig | 1 - > > > configs/orangepi_zero_plus2_defconfig | 1 + > > > configs/orangepi_zero_plus_defconfig | 1 + > > > 27 files changed, 8 insertions(+), 19 deletions(-) > > [...] > > > > diff --git a/configs/orangepi_zero_plus_defconfig > > > b/configs/orangepi_zero_plus_defconfig > > > index cc8b8c7f9ab9..37ca6dff374f 100644 > > > --- a/configs/orangepi_zero_plus_defconfig > > > +++ b/configs/orangepi_zero_plus_defconfig > > > @@ -4,6 +4,7 @@ CONFIG_SPL=y > > > CONFIG_MACH_SUN50I_H5=y > > > CONFIG_DRAM_CLK=624 > > > CONFIG_DRAM_ZQ=3881977 > > > +# CONFIG_DRAM_ODT_EN is not set > > > > Why ODT not enabled these boards? > > Because the config wasn't set before on these boards and I don't want > to change the DRAM configuration of any board without testing. > > It's very likely that enabling ODT would be a good idea on these boards > too, but someone needs to test that before making the change. OK, let me test check it from my end. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: imx8m_image: Fix 'unexpected operator' error
Hi Stefano, On Wed, 3 Apr 2019 17:07:04 +0200 Stefano Babic sba...@denx.de wrote: ... > Yes, it is in u-boot-imx, I am just checking around if there are some > other patches that cannot wait and must go into 2019.04. I plan to send > my PR to Tom for the end of the week. Then you probably can apply two tested patches with FEC fixes for i.mx8qxp MEK? http://patchwork.ozlabs.org/patch/1050177 http://patchwork.ozlabs.org/patch/1050178 These were part of the last u-boot-net pull request, but this pull request was rejected due to issues with other patches, so we still have broken Ethernet support on MEK board. Thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Arm: imx7d-pico: Import all Linux device tree for Pico i.MX7D SOM
Le 03/04/2019 à 22:40, Otavio Salvador a écrit : On Mon, Mar 25, 2019 at 10:42 AM Fabio Estevam wrote: On Mon, Mar 25, 2019 at 9:52 AM Joris Offouga wrote: This patch imports the Linux kernel base board imx7d-pico.dtsi, pi board imx7d-pico-pi.dts and hobbit board imx7d-pico-hobbit.dts from Linux v5.1-rc1. Signed-off-by: Joris Offouga Tested-by: Fabio Estevam The dtb files are not included on the Makefile, so if we try to build the image it fails. This is not necessary since we are using the CONFIG_DEFAULT_FDT_FILE. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/10] pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' iomux
Hi Philipp,
在 2019/4/4 下午3:19, Philipp Tomsich 写道:
On 04.04.2019, at 05:51, David Wu wrote:
RK3288 pmu_gpio0 iomux setting have no higher 16 writing corresponding
bits, need to read before write the register.
Signed-off-by: David Wu
---
drivers/pinctrl/rockchip/pinctrl-rk3288.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
index 1fa601d954..d66ffdf24b 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
@@ -54,7 +54,13 @@ static int rk3288_set_mux(struct rockchip_pin_bank *bank,
int pin, int mux)
}
}
- data = (mask << (bit + 16));
+ if (bank->bank_num == 0) {
+ regmap_read(regmap, reg, );
Could you pull the regmap_read out of the if and make it common for all cases,
so the differences between the paths are in data-manipulation only?
Yes, the difference between the gpio0 and other pins is the
data-manipulation, and i think the others don't need the regmap_read,
so it is not a common case.
+ data &= ~(mask << bit);
+ } else {
+ data = (mask << (bit + 16));
+ }
+
Please add a comment, so readers will be able to understand what is happening
(and why) without referring to the TRM
data |= (mux & mask) << bit;
ret = regmap_write(regmap, reg, data);
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support
Hi,
On Sat, 2018-11-03 at 16:58 +0530, Akash Gajjar wrote:
> Rockpro64 is rk3399 based board from pine64.org. add initial board support for
> Rockpro64. complete board support will be added later in upcoming patchsets.
Thanks for contributing this initial support patchset!
Now that the dts has landed in Linux, do you have plans for making a
new revision of this series?
I plan on using the board soon-ish and I'd like to get an upstream U-
Boot + Linux setup on it, so I'm definitely interested in this series.
Feel free to let me know if I could help with anything when I get the
board!
Cheers,
Paul
> Signed-off-by: Akash Gajjar
> ---
> arch/arm/dts/Makefile |1 +
> arch/arm/dts/rk3399-rockpro64.dts | 519 +++
> arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi | 1535
> arch/arm/mach-rockchip/rk3399/Kconfig | 10 +
> board/rockchip/rockpro64/Kconfig | 15 +
> board/rockchip/rockpro64/MAINTAINERS |6 +
> board/rockchip/rockpro64/Makefile |7 +
> board/rockchip/rockpro64/rockpro64.c | 94 ++
> configs/rockpro64-rk3399_defconfig | 78 +
> include/configs/rockpro64.h| 15 +
> 10 files changed, 2280 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
> create mode 100644 arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi
> create mode 100644 board/rockchip/rockpro64/Kconfig
> create mode 100644 board/rockchip/rockpro64/MAINTAINERS
> create mode 100644 board/rockchip/rockpro64/Makefile
> create mode 100644 board/rockchip/rockpro64/rockpro64.c
> create mode 100644 configs/rockpro64-rk3399_defconfig
> create mode 100644 include/configs/rockpro64.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d36447d18d..8a84cf55a3 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-rockpro64.dtb \
> rv1108-evb.dtb
> dtb-$(CONFIG_ARCH_MESON) += \
> meson-gxbb-nanopi-k2.dtb \
> diff --git a/arch/arm/dts/rk3399-rockpro64.dts
> b/arch/arm/dts/rk3399-rockpro64.dts
> new file mode 100644
> index 00..8497a1124b
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-rockpro64.dts
> @@ -0,0 +1,519 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2018 Akash Gajjar
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include "rk3399.dtsi"
> +#include "rk3399-sdram-lpddr4-1600.dtsi"
> +
> +/ {
> + model = "Pine64 Rockpro64-RK3399 Board";
> + compatible = "pine64,rockpro64", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path =
> + u-boot,spl-boot-order = ,
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + vcc5v0_host: vcc5v0-host-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < RK_PD2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_vbus_drv>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + };
> +
> + vcc5v0_sys: vcc5v0-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_log: vdd-log {
> + compatible = "pwm-regulator";
> + pwms = < 0 25000 1>;
> + regulator-name = "vdd_log";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <43>;
> + regulator-max-microvolt = <140>;
> + regulator-init-microvolt = <95>;
> + };
> +
> + vccadc_ref: vccadc-ref {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + };
> +};
> +
Re: [U-Boot] [PATCH v2] pico-imx6ul, pico-imx7d: Explain how to use eMMC user partition
Hi Otavio, Fabio, On 04/04/19 02:22, Fabio Estevam wrote: > Hi Otavio, > > On Wed, Apr 3, 2019 at 3:45 PM Otavio Salvador > wrote: >> >> Stefano, >> >> On Fri, Mar 22, 2019 at 2:53 PM Otavio Salvador >> wrote: >>> The default U-Boot environment expects the use of eMMC user >>> partition. To ensure we are using the proper eMMC partition for boot >>> we need to run the `mmc partconf` command. >>> >>> This patch updates the README instructions to avoid users to follow >>> misleading instructions. >>> >>> Signed-off-by: Otavio Salvador >> >> Could this to be applied? > I have seen the patch but I have not picked it up. Fabio is reporting that these instructions are not working for him - IMHO it is better to have no instructions else not working instructions. I am really relying on your both judge, I have not the board and no way to test myself. > The instructions on this patch did not work for me. > > It only worked if I called 'mmc partconf 0 0 0 0' after the DFU command. > Indeed. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
