Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Sat, Feb 09, 2019 at 10:56:40PM +0100, Simon Goldschmidt wrote: > On Fri, Feb 8, 2019 at 10:20 PM Tom Rini wrote: > > > > On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote: > > > On Fri, Feb 8, 2019 at 8:46 PM Tom Rini wrote: > > > > > > > > On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote: > > > > > > > > > SPL currently does not check uImage CRCs when loading U-Boot. > > > > > > > > > > This patch adds checking the uImage CRC when SPL loads U-Boot. It does > > > > > this by reusing the existing config option SPL_CRC32_SUPPORT to allow > > > > > leaving out the CRC check on boards where the additional code size or > > > > > boot time is a problem (adding the CRC check currently adds ~1.4 kByte > > > > > to flash). > > > > > > > > > > The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL > > > > > support for legacy images is enabled to check the CRC on all boards > > > > > that don't actively take countermeasures. > > > > > > > > > > Signed-off-by: Simon Goldschmidt > > > > > Reviewed-by: Simon Glass > > > > > > > > Really sorry for the delay on this, especially as I've found one or two > > > > problems. The first problem is that with this vyasa-rk3288 and a few > > > > others fail to build due to a number of errors such as: > > > > ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member > > > > named 'dcrc_data' > > > > > > Hmm, let me check what's wrong there. > > OK, so the vyasa-rk3288 uses TPL, that's what I got wrong. > > > > > > > > > Second, I believe this is causing a number of platforms with very tight > > > > SPL constraints, namely all of 64bit sunxi, to fail to link as they > > > > overflow SRAM now. This can be fixed at least by making the new > > > > behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks > > > > in advance! > > > > > > Well, I thought it would be better to have it default to 'y' since I > > > think it > > > is what is expected. Shouldn't we explicitly work on those platforms? > > > I must say I was pretty shocked to see that SPL did not detect an invalid > > > CRC... > > > > > > Can you point me to a config that fails? > > > > In general, pine64_plus_defconfig is one that might (as I re-run my > > build without this patch, I still see some failures but they've scrolled > > off screen, but 64bit sunxi _is_ very sensitive to SPL growth). > > And I also did compile that one but I don't see any error message. How > am I supposed to detect the SRAM overflowing? > > I assume it's .text or .rodata which makes it grow too big? If so, we could > still check the CRC by using a smaller algorithm that does not rely on a > precalculated table... That could have been the other patch then. Does all of sunxi build for you? If so, we're good then. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: fix EFI entry counting
`bootefi selftest` fails on qemu-x86_defconfig if efi_selftest() is not invoked using EFI_CALL(). Likewise we call the entry point of EFI payloads with EFI_CALL(efi_start_image()). entry_count indicates if we are in U-Boot (1) or in EFI payload code (0). As we start in U-Boot code the initial value has to be 1. Signed-off-by: Heinrich Schuchardt --- cmd/bootefi.c | 2 +- lib/efi_loader/efi_boottime.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 9d9ccdd31a..3619a20e64 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -445,7 +445,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return CMD_RET_FAILURE; /* Execute the test */ - r = efi_selftest(_obj->header, ); + r = EFI_CALL(efi_selftest(_obj->header, )); bootefi_run_finish(image_obj, loaded_image_info); return r != EFI_SUCCESS; } else diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 0b13c79b76..ed0e926646 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -44,7 +44,8 @@ static bool efi_is_direct_boot = true; static volatile void *efi_gd, *app_gd; #endif -static int entry_count; +/* 1 if inside U-Boot code, 0 if inside EFI payload code */ +static int entry_count = 1; static int nesting_level; /* GUID of the device tree table */ const efi_guid_t efi_guid_fdt = EFI_FDT_GUID; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] lib: vsprintf: avoid overflow printing UTF16 strings
We have to ensure while printing UTF16 strings that we do not exceed the
end of the print buffer.
Signed-off-by: Heinrich Schuchardt
---
lib/vsprintf.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 4213441fbf..48304607b7 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -279,13 +279,17 @@ static char *string(char *buf, char *end, char *s, int
field_width,
static char *string16(char *buf, char *end, u16 *s, int field_width,
int precision, int flags)
{
- u16 *str = s ? s : L"";
- ssize_t len = utf16_strnlen(str, precision);
+ const u16 *str = s ? s : L"";
+ ssize_t i, len = utf16_strnlen(str, precision);
if (!(flags & LEFT))
for (; len < field_width; --field_width)
ADDCH(buf, ' ');
- utf16_utf8_strncpy(, str, len);
+ for (i = 0; i < len && buf <= end - MAX_UTF8_PER_UTF16; ++i) {
+ s32 s = utf16_get();
+
+ utf8_put(s, );
+ }
for (; len < field_width; --field_width)
ADDCH(buf, ' ');
return buf;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
Here are the four fixes which do not trigger the sunxi breakage. The following changes since commit 97276a91db8e98f081a40ddf9dc8f81d4032a756: Prepare v2019.04-rc1 (2019-02-07 21:32:19 -0500) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to e531c6731b697fc524b54697caebf235a4a69e8d: fs: ext4: Unmount FS in do_fs_type() (2019-02-09 11:08:40 +0100) Marek Vasut (4): mmc: tmio: Make DMA transfer end bit configurable mmc: tmio: renesas: Add 1uS delay after DMA completion on older IPs mmc: Do not poll using CMD13 when changing timing fs: ext4: Unmount FS in do_fs_type() drivers/mmc/mmc.c | 28 drivers/mmc/renesas-sdhi.c | 10 ++ drivers/mmc/tmio-common.c | 11 ++- drivers/mmc/tmio-common.h | 1 + drivers/mmc/uniphier-sd.c | 1 + fs/fs.c| 2 ++ 6 files changed, 40 insertions(+), 13 deletions(-) -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 00/15] dm, efi: integrate efi objects into DM
Hi Takahiro, On Fri, 8 Feb 2019 at 02:14, AKASHI Takahiro wrote: > > # bootefi doesn't work with this patch set yet > > This patch set came from the past discussion[1] on my "removable device > support" patch and is intended to be an attempt to integrate efi objects > into u-boot's Driver Model as much seamlessly as possible. > > [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html Some general comments: protocol_list: Can you use DM_GET_DRIVER? It should be more efficient efi_open_protocol_information: - rename of protocol to protocol_guid should be in a separate patch u-boot - please use 'U-Boot' consistently Your patch to rename UCLASS_EFI -> UCLASS_EFI_DRIVER still leaves UCLASS_EFI remaining. Can you mention why> It says efi_root is for backward compatibility. Just temporary? I could not quite figure that out. Use if (IS_ENABLED()) instead of #ifdef where you can. I am very encouraged by this series as it genuinely unifies EFI with DM. Re your comment about wrapper code, I suspect that might become clearer once the data structures are unified. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 00/15] dm, efi: integrate efi objects into DM
Hi Heinrich, On Fri, 8 Feb 2019 at 03:36, Heinrich Schuchardt wrote: > > > > On 2/8/19 9:15 AM, AKASHI Takahiro wrote: > > # bootefi doesn't work with this patch set yet > > > > This patch set came from the past discussion[1] on my "removable device > > support" patch and is intended to be an attempt to integrate efi objects > > into u-boot's Driver Model as much seamlessly as possible. > > > > [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html > > > > Since this patch is a prototype (or POC, Proof-Of-Concept), the aim here > > is to discuss further about how in a better shape we will be able to > > merge the two worlds. > > > > After RFC, Simon suggested that efi protocols could be also presented > > as DM devices. This is a major change in RFC v2. > > > Hello Takahiro, > > thanks a lot for laying out your thoughts about a possible integration of > the EFI subsystem and the driver model. Thanks also for providing a first > implementation. Yes indeed. It is very clever what you have been able to do Takahiro. > > > Basic idea is > > * efi_root is a DM device > > * Any efi object, refered to by efi_handle_t in UEFI world, > > has a corresponding DM device. > > EFI applications and drivers will create handles having no relation to > the U-Boot world. I suggest that we change that, i.e. that all devices in existence have a struct udevice. That way DM knows about everything and we don't have the strange parallel 'EFI' world. I don't see any need for it. > > > - define efi_handle_t as "struct udevice *" > > An EFI handle does not necessarily relate to any U-Boot device. Why > should a handle which has not backing device carry the extra fields of > struct udevice? Because this is the U-Boot driver model. We should not have an EFI parallel to DM and certainly not just to save a few dozen bytes of data space. If you were trying to save data space, you would not use EFI :-) > > > - for efi_disk, > > * add "struct efi_disk_obj" to blk_desc > > struct efi_disk_obj * is currently the handle of the block device. So > you only some fields may be moved to blk_desc. But I guess I will find > that in one of the patches. > > > - for the objects below, there is only one instance for each and so > > they are currently global data: > > efi_gop_obj, > > efi_net_obj, > > efi_net_obj * is the handle of the network device. In future we should > support multiple network devices. > > > simple_text_output_mode > > - for loaded_image, > > * link efi_loaded_image_obj to device's platdata > > An EFI application can create an image out of "nothing". Just create a > handle with InstallProtocolInterface() and then call LoadImage() with a > pointer to some place in memory. > > Many images loaded from the same device may be present at the same time, > e.g. iPXE, GRUB, and Linux. > > > > > * Any efi protocol has a corresponding DM device. > > Protocol implementations are not only provided by U-Boot but also by EFI > applications and driver binaries. And of cause the EFI binaries will > implement a lot of protocols completely unknown to U-Boot. So what > should be the meaning of the above sentence in this context? Can we instead add a uclass for each EFI protocol? Then U-Boot does know about them. > > Above you suggested that struct udevice * would be used as a handle. > So on which handle is the protocol now installed in your model? > > For a protocol like the device path protocol which is only a data > structure with no related function modules I do not understand the > benefit of creating a separate sub-device. I think it is only a matter of convenience and to keep things regular. > > > - link "struct efi_handler" to device's uclass_platdata > > struct efi_handler is an item in the list of protocols installed on a > handle. For some of the protocols installed by an EFI application there > will not be any corresponding uclass. As above, perhaps we should fix that? > > > - be a child of a efi object (hence DM device) in DM device hierarchy > > so that enumerating protocols belonging to efi object is done by > > traversing the tree. > > > > Above you said a struct udevice * would be a handle. So here you imply > that for each protocol interface you will create an extra handle. That > does not fit the EFI model. > > > * Any efi object which has a backing DM device should be created > > when that DM device is detected (and probed). > > Detected or probed? This is not the same. > > > * For efi_disk (or any object with EFI_BLOCK_IO_PROTOCOL), > > - add UCLASS_PARTITION > > - put partitions under a raw block device > > - partitions as well as raw devices can be efi_disk > > Agreed. > > > > > With those extensive changes, there still exists plenty of > > "wrapper" code. Do you have any idea to reduce it? > > > > The concept presented does not cover: > > - device, drivers, protocols created by EFI applications and > driver binaries Can we create uclasses
Re: [U-Boot] [PATCH v4 00/20] mx6sabre: Add DM and SPL FIT support
On Sat, Feb 9, 2019 at 8:48 PM Abel Vesa wrote: > So, do I need to resend this with all the R-bs ? Just realized that you missed to Cc Stefano Babic on this series. Stefano, Should Abel resend this series with you on Cc or can you get review it from patchwork? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 4/8] regulator: Add support for ramp delay
Changing voltage and enabling regulator might require delays so the
regulator stabilizes at expected level.
Add support for "regulator-ramp-delay" binding which can introduce
required time to both enabling the regulator and to changing the
voltage.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/regulator/regulator-uclass.c | 45 +-
include/power/regulator.h | 2 +
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 39e46279d533..4119f244c74b 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -35,10 +35,22 @@ int regulator_get_value(struct udevice *dev)
return ops->get_value(dev);
}
+static void regulator_set_value_delay(struct udevice *dev, int old_uV,
+ int new_uV, unsigned int ramp_delay)
+{
+ int delay = DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay);
+
+ debug("regulator %s: delay %u us (%d uV -> %d uV)\n", dev->name,
+ delay, old_uV, new_uV);
+
+ udelay(delay);
+}
+
int regulator_set_value(struct udevice *dev, int uV)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
struct dm_regulator_uclass_platdata *uc_pdata;
+ int ret, old_uV = uV;
uc_pdata = dev_get_uclass_platdata(dev);
if (uc_pdata->min_uV != -ENODATA && uV < uc_pdata->min_uV)
@@ -49,7 +61,18 @@ int regulator_set_value(struct udevice *dev, int uV)
if (!ops || !ops->set_value)
return -ENOSYS;
- return ops->set_value(dev, uV);
+ if (uc_pdata->ramp_delay)
+ old_uV = regulator_get_value(dev);
+
+ ret = ops->set_value(dev, uV);
+
+ if (!ret) {
+ if (uc_pdata->ramp_delay && old_uV > 0)
+ regulator_set_value_delay(dev, old_uV, uV,
+ uc_pdata->ramp_delay);
+ }
+
+ return ret;
}
/*
@@ -107,6 +130,7 @@ int regulator_set_enable(struct udevice *dev, bool enable)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
struct dm_regulator_uclass_platdata *uc_pdata;
+ int ret, old_enable = 0;
if (!ops || !ops->set_enable)
return -ENOSYS;
@@ -115,7 +139,22 @@ int regulator_set_enable(struct udevice *dev, bool enable)
if (!enable && uc_pdata->always_on)
return 0;
- return ops->set_enable(dev, enable);
+ if (uc_pdata->ramp_delay)
+ old_enable = regulator_get_enable(dev);
+
+ ret = ops->set_enable(dev, enable);
+ if (!ret) {
+ if (uc_pdata->ramp_delay && !old_enable) {
+ int uV = regulator_get_value(dev);
+
+ if (uV > 0) {
+ regulator_set_value_delay(dev, 0, uV,
+ uc_pdata->ramp_delay);
+ }
+ }
+ }
+
+ return ret;
}
int regulator_get_mode(struct udevice *dev)
@@ -324,6 +363,8 @@ static int regulator_pre_probe(struct udevice *dev)
-ENODATA);
uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on");
uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
+ uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
+ 0);
/* Those values are optional (-ENODATA if unset) */
if ((uc_pdata->min_uV != -ENODATA) &&
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 5318ab3acece..c13fa1f336e5 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -149,6 +149,7 @@ enum regulator_flag {
* @max_uA*- maximum amperage (micro Amps)
* @always_on* - bool type, true or false
* @boot_on* - bool type, true or false
+ * @ramp_delay - Time to settle down after voltage change (unit: uV/us)
* TODO(s...@chromium.org): Consider putting the above two into @flags
* @flags: - flags value (see REGULATOR_FLAG_...)
* @name** - fdt regulator name - should be taken from the device tree
@@ -169,6 +170,7 @@ struct dm_regulator_uclass_platdata {
int max_uV;
int min_uA;
int max_uA;
+ unsigned int ramp_delay;
bool always_on;
bool boot_on;
const char *name;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 8/8] arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid XU3 family
Add startup time to LDO regulators of S2MPS11 PMIC on Odroid XU3/XU4/HC1
family of boards to be sure the voltage is proper before relying on the
regulator.
The datasheet for all the S2MPS1x family is inconsistent here and does
not specify unambiguously the value of ramp delay for LDO. It mentions
30 mV/us in one timing diagram but then omits it completely in LDO
regulator characteristics table (it is specified for bucks).
However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12
mV/us or 24 mV/us.
Without the ramp delay value the consumers do not wait for voltage
settle after changing it. Although the proper value of ramp delay for
LDOs is unknown, it seems safer to use at least some value from
reference kernel than to leave it unset.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/dts/exynos5422-odroidxu3.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
index 9dfae90667cf..04ecc404f907 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -45,6 +45,7 @@
regulator-name = "vdd_ldo1";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+ regulator-ramp-delay = <12000>;
regulator-always-on;
};
@@ -52,18 +53,21 @@
regulator-name = "vddq_mmc0";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-ramp-delay = <12000>;
};
ldo4_reg: LDO4 {
regulator-name = "vdd_adc";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-ramp-delay = <12000>;
};
ldo5_reg: LDO5 {
regulator-name = "vdd_ldo5";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-ramp-delay = <12000>;
regulator-always-on;
};
@@ -71,6 +75,7 @@
regulator-name = "vdd_ldo6";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+ regulator-ramp-delay = <12000>;
regulator-always-on;
};
@@ -78,6 +83,7 @@
regulator-name = "vdd_ldo7";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-ramp-delay = <12000>;
regulator-always-on;
};
@@ -85,6 +91,7 @@
regulator-name = "vdd_ldo8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-ramp-delay = <12000>;
regulator-always-on;
};
@@ -92,6 +99,7 @@
regulator-name = "vdd_ldo9";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
+ regulator-ramp-delay = <12000>;
regulator-always-on;
};
@@ -99,6 +107,7 @@
regulator-name = "vdd_ldo10";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-ramp-delay = <12000>;
regulator-always-on;
};
@@ -106,6 +115,7 @@
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <100>;
regulator-max-microvolt
[U-Boot] [RFT 5/8] power: regulator: s2mps11: Fix step for LDO27 and LDO35
LDO27 and LDO35 have 25 mV step, not 50 mV. Signed-off-by: Krzysztof Kozlowski --- drivers/power/regulator/s2mps11_regulator.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/power/regulator/s2mps11_regulator.c b/drivers/power/regulator/s2mps11_regulator.c index ced504eb1476..723d27f67c9a 100644 --- a/drivers/power/regulator/s2mps11_regulator.c +++ b/drivers/power/regulator/s2mps11_regulator.c @@ -346,6 +346,8 @@ static int s2mps11_ldo_hex2volt(int ldo, int hex) case 11: case 22: case 23: + case 27: + case 35: uV = hex * S2MPS11_LDO_STEP + S2MPS11_LDO_UV_MIN; break; default: @@ -366,6 +368,8 @@ static int s2mps11_ldo_volt2hex(int ldo, int uV) case 11: case 22: case 23: + case 27: + case 35: hex = (uV - S2MPS11_LDO_UV_MIN) / S2MPS11_LDO_STEP; break; default: -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 6/8] power: regulator: s2mps11: Add enable delay
According to datasheet, the output on LDO regulators will start
appearing after 10-15 us.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/regulator/s2mps11_regulator.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/power/regulator/s2mps11_regulator.c
b/drivers/power/regulator/s2mps11_regulator.c
index 723d27f67c9a..1f1581852ee2 100644
--- a/drivers/power/regulator/s2mps11_regulator.c
+++ b/drivers/power/regulator/s2mps11_regulator.c
@@ -551,7 +551,14 @@ static int ldo_get_enable(struct udevice *dev)
static int ldo_set_enable(struct udevice *dev, bool enable)
{
- return s2mps11_ldo_enable(dev, PMIC_OP_SET, );
+ int ret;
+
+ ret = s2mps11_ldo_enable(dev, PMIC_OP_SET, );
+
+ /* Wait the "enable delay" for voltage to start to rise */
+ udelay(15);
+
+ return ret;
}
static int ldo_get_mode(struct udevice *dev)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 7/8] arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
The ADC block requires VDD supply to be on so provide one.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/dts/exynos5422-odroidxu3.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
index e859dd1b981a..9dfae90667cf 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -32,6 +32,7 @@
adc@12D1 {
u-boot,dm-pre-reloc;
+ vdd-supply = <_reg>;
status = "okay";
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 2/8] exynos: Wait till ADC stabilizes before checking Odroid HC1 revision
Fix detection of Odroid HC1 (Exynos5422) after reboot if kernel disabled
the LDO4/VDD_ADC regulator.
The LDO4 supplies both ADC block and the ADC input AIN9. Voltage on
AIN9 will rise slowly, so be patient and wait for it to stabilize.
First reads on Odroid HC1 return 305, 1207, 1297 and finally 1308
(reference value is 1309).
Signed-off-by: Krzysztof Kozlowski
---
board/samsung/common/exynos5-dt-types.c | 34 -
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/board/samsung/common/exynos5-dt-types.c
b/board/samsung/common/exynos5-dt-types.c
index 7a86e9187768..ba8584f1a5d8 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -57,12 +57,44 @@ static unsigned int odroid_get_rev(void)
return 0;
}
+/*
+ * Read ADC at least twice and check the resuls. If regulator providing
voltage
+ * on to measured point was just turned on, first reads might require time
+ * to stabilize.
+ */
+static int odroid_get_adc_val(unsigned int *adcval)
+{
+ unsigned int adcval_prev = 0;
+ int ret, retries = 20;
+
+ ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
+ _prev);
+ if (ret)
+ return ret;
+
+ while (retries--) {
+ mdelay(5);
+
+ ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
+ adcval);
+ if (ret)
+ return ret;
+
+ if ((100 * abs(*adcval - adcval_prev) / adcval_prev) < 3)
+ return ret;
+
+ adcval_prev = *adcval;
+ }
+
+ return ret;
+}
+
static int odroid_get_board_type(void)
{
unsigned int adcval;
int ret, i;
- ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN, );
+ ret = odroid_get_adc_val();
if (ret)
goto rev_default;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 3/8] adc: exynos-adc: Fix wrong bit operation used to stop the ADC
When stopping the ADC_V2_CON1_STC_EN should be cleared. Signed-off-by: Krzysztof Kozlowski --- drivers/adc/exynos-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/adc/exynos-adc.c b/drivers/adc/exynos-adc.c index d33e3d632afc..12c49fc8cefb 100644 --- a/drivers/adc/exynos-adc.c +++ b/drivers/adc/exynos-adc.c @@ -62,7 +62,7 @@ int exynos_adc_stop(struct udevice *dev) /* Stop conversion */ cfg = readl(>con1); - cfg |= ~ADC_V2_CON1_STC_EN; + cfg &= ~ADC_V2_CON1_STC_EN; writel(cfg, >con1); -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 0/8] exynos: Fix reboot on Odroid HC1
Hi, Odroid HC1 does not reboot properly (at least from SD card but I do not expect difference on eMMC), if LDO4/VDD_ADC was turned off by Linux kernel. This condition is so far always, because Linux kernel did not enable ADC on ODroid HC1, therefore the VDD_ADC regulator was turned off as unused. The issue is in detection of revision which later is used to load proper DTB. The revision is obtained by ADC read of a voltage depending on VDD_ADC. Therefore: 1. VDD_ADC has to be turned on (but board detection happens before power is initialized), 2. Turning VDD_ADC should wait with ramp delay, 3. Reading the value from ADC should wait for it to stabilize. I must admit I did not test it on other boards because latest U-Boot does not boot from SD card. Commends and testing are welcomed. Best regards, Krzysztof Krzysztof Kozlowski (8): exynos: Redo detection of revision when all resources are ready exynos: Wait till ADC stabilizes before checking Odroid HC1 revision adc: exynos-adc: Fix wrong bit operation used to stop the ADC regulator: Add support for ramp delay power: regulator: s2mps11: Fix step for LDO27 and LDO35 power: regulator: s2mps11: Add enable delay arm: dts: exynos: Add supply for ADC block to Odroid XU3 family arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid XU3 family arch/arm/dts/exynos5422-odroidxu3.dts | 20 + board/samsung/common/board.c| 19 - board/samsung/common/exynos5-dt-types.c | 34 +++- drivers/adc/exynos-adc.c| 2 +- drivers/power/regulator/regulator-uclass.c | 45 - drivers/power/regulator/s2mps11_regulator.c | 13 +- include/power/regulator.h | 2 + 7 files changed, 129 insertions(+), 6 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFT 1/8] exynos: Redo detection of revision when all resources are ready
Detection of board type is done early - before power setup. In case of
Odroid XU3/XU4/HC1 family, the detection is done using ADC which
is supplied by LDO4/VDD_ADC regulator. This regulator could be turned
off (e.g. by kernel before reboot); If ADC is used early, the
regulators are not yet available and the detection won't work.
Try to detect the revision again, once power is brought up.
This is necessary to fix the detection of Odroid HC1 after reboot, if
kernel turned off the LDO4 regulator. Otherwise the board is not
detected
Signed-off-by: Krzysztof Kozlowski
---
board/samsung/common/board.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 6fd26a3a9198..1e2dabe68d11 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -147,6 +147,11 @@ int board_early_init_f(void)
{
int err;
#ifdef CONFIG_BOARD_TYPES
+ /*
+* It is done early so power might not be set up yet. In such case
+* specific revision detection with ADC might not work and need to me
+* redone later.
+*/
set_board_type();
#endif
err = board_uart_init();
@@ -166,9 +171,21 @@ int board_early_init_f(void)
#if defined(CONFIG_POWER) || defined(CONFIG_DM_PMIC)
int power_init_board(void)
{
+ int ret;
+
set_ps_hold_ctrl();
- return exynos_power_init();
+ ret = exynos_power_init();
+
+#ifdef CONFIG_BOARD_TYPES
+ /*
+* Since power is on, redo the board detection (external peripherals
+* are on).
+*/
+ set_board_type();
+#endif
+
+ return ret;
}
#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/20] mx6sabre: Add DM and SPL FIT support
On 19-02-04 08:19:23, Tom Rini wrote: > On Mon, Feb 04, 2019 at 09:03:43AM -0200, Fabio Estevam wrote: > > On Mon, Feb 4, 2019 at 7:55 AM Abel Vesa wrote: > > > > > If the SPL size (without the dtb appended) is larger then yes, the build > > > fails. > > > Trouble is if the SPL (without the dtb appended) is, lets say, 63kB and > > > then the dtb is larger than 1kB. Then there is no mechanism in place to > > > check that > > > and it will just fail to boot without giving any clues why. But this is a > > > totally > > > unrelated problem from this patchset's point of view and I think it > > > impacts all > > > the platforms that support SPL with DM. > > > > Yes, it is unrelated to this series and should be treated separately. > > I also agree. But, don't we have a mechanism for that? It sounds like > some additional targets need to call $(BOARD_SIZE_CHECK) at the end. Or > am I missing something? > So, do I need to resend this with all the R-bs ? > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] spl: implement CRC check on U-Boot uImage
On Fri, Feb 8, 2019 at 10:20 PM Tom Rini wrote: > > On Fri, Feb 08, 2019 at 10:05:41PM +0100, Simon Goldschmidt wrote: > > On Fri, Feb 8, 2019 at 8:46 PM Tom Rini wrote: > > > > > > On Wed, Nov 28, 2018 at 09:52:45PM +0100, Simon Goldschmidt wrote: > > > > > > > SPL currently does not check uImage CRCs when loading U-Boot. > > > > > > > > This patch adds checking the uImage CRC when SPL loads U-Boot. It does > > > > this by reusing the existing config option SPL_CRC32_SUPPORT to allow > > > > leaving out the CRC check on boards where the additional code size or > > > > boot time is a problem (adding the CRC check currently adds ~1.4 kByte > > > > to flash). > > > > > > > > The SPL_CRC32_SUPPORT config option now gets enabled by default if SPL > > > > support for legacy images is enabled to check the CRC on all boards > > > > that don't actively take countermeasures. > > > > > > > > Signed-off-by: Simon Goldschmidt > > > > Reviewed-by: Simon Glass > > > > > > Really sorry for the delay on this, especially as I've found one or two > > > problems. The first problem is that with this vyasa-rk3288 and a few > > > others fail to build due to a number of errors such as: > > > ../common/spl/spl.c:269:12: error: 'struct spl_image_info' has no member > > > named 'dcrc_data' > > > > Hmm, let me check what's wrong there. OK, so the vyasa-rk3288 uses TPL, that's what I got wrong. > > > > > > Second, I believe this is causing a number of platforms with very tight > > > SPL constraints, namely all of 64bit sunxi, to fail to link as they > > > overflow SRAM now. This can be fixed at least by making the new > > > behavior opt-in, but I would fix the vyasa-rk3288 problem first. Thanks > > > in advance! > > > > Well, I thought it would be better to have it default to 'y' since I think > > it > > is what is expected. Shouldn't we explicitly work on those platforms? > > I must say I was pretty shocked to see that SPL did not detect an invalid > > CRC... > > > > Can you point me to a config that fails? > > In general, pine64_plus_defconfig is one that might (as I re-run my > build without this patch, I still see some failures but they've scrolled > off screen, but 64bit sunxi _is_ very sensitive to SPL growth). And I also did compile that one but I don't see any error message. How am I supposed to detect the SRAM overflowing? I assume it's .text or .rodata which makes it grow too big? If so, we could still check the CRC by using a smaller algorithm that does not rely on a precalculated table... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: fix EFI_FILE_PROTOCOL.GetInfo()
We check the existence of files with fs_exist(). This function calls
fs_close(). If we do not set the active block device again fs_opendir()
fails and we do not set the flag EFI_FILE_DIRECTORY. Due to this error the
`cd` command in the EFI shell fails.
So let's add the missing set_blk_dev(fh) call.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_file.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 1341f1b456..c949275ae2 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -200,6 +200,10 @@ static struct efi_file_handle *file_open(struct
file_system *fs,
fs_exists(fh->path)))
goto error;
+ /* fs_exists() calls fs_close(), so open file system again */
+ if (set_blk_dev(fh))
+ goto error;
+
/* figure out if file is a directory: */
fh->isdir = is_dir(fh);
} else {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 00/15] dm, efi: integrate efi objects into DM
Hi, On Fri, 8 Feb 2019 at 01:14, AKASHI Takahiro wrote: > > # bootefi doesn't work with this patch set yet > > This patch set came from the past discussion[1] on my "removable device > support" patch and is intended to be an attempt to integrate efi objects > into u-boot's Driver Model as much seamlessly as possible. > > [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html Is this pushed to a tree somewhere? If not, what commit does this series apply on top of? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken
> On 09.02.2019, at 17:39, Heinrich Schuchardt wrote: > > On 2/9/19 4:24 PM, Philipp Tomsich wrote: >> >> >>> On 09.02.2019, at 16:08, Philipp Tomsich >>> wrote: >>> >>> Heinrich, >>> >>> My guess is that this is fallout from David Wu’s new pinctrl driver >>> (which has really been the bulk of changes in this cycle). I can’t >>> test or debug on the rk3288 due to a lack of hardware. >> >> If you want to start digging, that the changes in >> >>> commit 08c817c39908f9d120df1e4c90ddad4a11fc3891 >>> Author: David Wu >>> Date: Wed Jan 2 20:51:00 2019 +0800 >>> >>>ARM: rockchip: Remove the pinctrl request at rk3288-board-spl >>> >>>If we use the new pinctrl driver, the pinctrl setup will be done >>>by device probe. Remove the pinctrl setup at rk3288-board-spl. >>> >>>Signed-off-by: David Wu >>>Reviewed-by: Kever Yang >>>Reviewed-by: Philipp Tomsich >> >> >> look like they have the potential to break everything, including the >> UART pinctrl. >> >> Thanks, >> Philipp., >> > Hello Philipp, > > I would not know how to analyze the bug if there isn't even a console. > If David or you send me a git branch to compile I will test it. We’ll have to wait for David to come back from CNY, apparently. > Has any of the rk3288 boards been tested before merging? I would assume so, as this patchset is coming from Rockchips and Kever gave his Reviewed-by… That said, I have been fighting issues from this patchset when trying to read from devices on the i2c0 bus on a RK3399—which had me add a “simple” pinctrl device again, as pulling all the dependencies into the SPL is a pain. Unfortunately, in this merge I had to make a judgement call between insisting on code-quality and getting the full pinctrl-driver merged. With this release cycle being longer and having 5 RCs, I figured we’ll have time to iron out any wrinkles... > I think we should keep Simon in CC as he is one of the ROCKCHIP maintainers. I didn’t intentionally drop him. It was either clumsy fingers or Reply-All not replying to all. Cheers, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sunxi: Sync Bananapi M2+ device tree from Linux v5.0-rc1
On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai wrote:
>
> As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> device tree for the Bananapi M2+ has been split into a common dtsi file,
> and an SoC-specific board device tree file that includes both the shared
> dtsi file and the soc dtsi file. This was done to support both the H3
> and H5 variants of the same board. This is similar to what was doen for
s/doen/done
> the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: Split
> out common board design for ALL-H3-CC device tree").
>
> The newly split files are directly synced from Linux tag v5.0-rc1.
Better sync all dts(i) files on this relevant SoC, this would help to
track and use for rest of SoC's are inline to the same version later.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: qspi: Fix issue when booting with DDR mode
On Mon, Jan 7, 2019 at 2:15 PM Ye Li wrote: > > When booting from QSPI NOR with DDR mode enabled on i.MX7D/6UL, the > FLSHCR TDH bit is set to 1 by ROM along with MCR DDR_EN bit set. But > the read/write/readid/erase operations in the driver will overwrite > the MCR register, and cause the bits like DDR_EN are cleared. > If the DDR_EN is cleared but TDH is set, there is no clk2x output for > TX data shift. So these operations above will fail. > > Fix the issue in two aspects: > 1. In read/write/readid/erase operations, only set useful bit to MCR, >not overwrite the whole register. > 2. Set the TDH to 1 in qspi_enable_ddr_mode, so that DDR_EN and TDH will >be correctly set by this function. > > Signed-off-by: Ye Li > --- > drivers/spi/fsl_qspi.c | 20 +--- > 1 file changed, 13 insertions(+), 7 deletions(-) > > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c > index 1598c4f..1987a72 100644 > --- a/drivers/spi/fsl_qspi.c > +++ b/drivers/spi/fsl_qspi.c > @@ -405,7 +405,7 @@ static inline void qspi_ahb_read(struct fsl_qspi_priv > *priv, u8 *rxbuf, int len) > > qspi_write32(priv->flags, >mcr, > QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | > -QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); > +mcr_reg); > > rx_addr = (void *)(uintptr_t)(priv->cur_amba_base + priv->sf_addr); > /* Read out the data directly from the AHB buffer. */ > @@ -435,6 +435,12 @@ static void qspi_enable_ddr_mode(struct fsl_qspi_priv > *priv) > reg |= BIT(29); > > qspi_write32(priv->flags, >mcr, reg); > + > + /* Enable the TDH to 1 for i.mx6ul and mx7d, it is reserved on other > platforms */ > + reg = qspi_read32(priv->flags, >flshcr); > + reg &= ~(BIT(17)); > + reg |= BIT(16); Add proper macros for these bits. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: qspi: support read the flag status in fspi driver
On Mon, Jan 7, 2019 at 2:24 PM Ye Li wrote: > > From: Han Xu > > Support to read the flag status in driver to avoid the spi-nor framework > wait_for_ready hang issue. > > Signed-off-by: Han Xu > --- > drivers/spi/fsl_qspi.c | 47 +++ > 1 file changed, 47 insertions(+) > > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c > index 1987a72..ed0e649 100644 > --- a/drivers/spi/fsl_qspi.c > +++ b/drivers/spi/fsl_qspi.c > @@ -47,6 +47,7 @@ DECLARE_GLOBAL_DATA_PTR; > #endif > #define SEQID_WRAR 13 > #define SEQID_RDAR 14 > +#define SEQID_RDFSR15 > > /* QSPI CMD */ > #define QSPI_CMD_PP0x02/* Page program (up to 256 bytes) */ > @@ -57,6 +58,7 @@ DECLARE_GLOBAL_DATA_PTR; > #define QSPI_CMD_CHIP_ERASE0xc7/* Erase whole flash chip */ > #define QSPI_CMD_SE0xd8/* Sector erase (usually 64KiB) */ > #define QSPI_CMD_RDID 0x9f/* Read JEDEC ID */ > +#define QSPI_CMD_FLAG_SR 0x70/* Read FLAG STATUS*/ NAK, need to handle this from flash side. better keep working on that front. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards
On 2/7/19 6:19 PM, Oleksandr wrote:
[...]
> + /* Update registers with correct frequency */
> + writel(freq, TIMER_BASE + TIMER_CNTFID0);
> + asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
> +
> + /* Make sure arch timer is started by setting bit 0 of
> CNTCR */
> + writel(1, TIMER_BASE + TIMER_CNTCR);
Shouldn't this be in the timer driver instead ?
>>> Which timer driver? Probably, I missed something, but I didn't find any
>>> arch timer driver being used for Gen2.
>>>
>>> I see that TMU timer (arch/sh/lib/time.c) is used as a system timer, but
>>> it is yet another IP.
>>>
>>> Would it be correct, if I move arch timer updating code to
>>> arch/arm/mach-rmobile directory?
>>>
>>> Actually, at the same location the corresponding code lives in Linux:
>>>
>>> https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/setup-rcar-gen2.c#L61
>>>
>> Presumably if this is something else than TMU, it needs proper driver
>> that goes into drivers/ .
>
> Did I get your point correctly that new driver (specially for Gen2 arch
> timer) should be introduced in U-Boot and
>
> the only one thing it is intended to do is to configure that timer for
> the future use by Linux/Hypervisor?
>
> If yes, the only question I have is how that new driver is going to be
> populated? There is no corresponding node for arch timer in the device
> tree.
>
> https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/boot/dts/r8a7790.dtsi
>
>
> So, do I need specially for this case add arch timer node with reg and
> compatible properties?
>
> Sorry if I ask obvious questions, not familiar enough with U-Boot.
You would need a DT entry and a bit of code to start the timer in case
the PSCI is enabled, yes. This would then fit into the DM/DT paradigm.
> + }
> +}
> +
> +/*
> + * In order not to break compilation if someone decides to build
> with PSCI
> + * support disabled, keep these dummy functions.
> + */
That's currently the only use-case.
>>> Shall I drop this comment and dummy functions below?
>> Since there is no PSCI support, yes.
>
> Understand.
>
>>
>> [...]
>>
>> I'd like to have a cover letter go with V2, which describes what you're
>> trying to achieve here.
>
> Yes, sure. Cover letter is present for the current V1 as well.
>
> I thought that I had CC-ed all.
>
> This is a link to it:
>
> http://u-boot.10912.n7.nabble.com/PATCH-0-3-PSCI-support-for-r8a7790-SoC-Lager-Stout-boards-td357352.html
Thanks
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards
On 2/8/19 12:40 PM, Oleksandr wrote: > > On 07.02.19 19:19, Oleksandr wrote: >> >> On 07.02.19 17:49, Marek Vasut wrote: >>> On 2/7/19 4:28 PM, Oleksandr wrote: On 05.02.19 20:48, Marek Vasut wrote: Hi Marek >>> Hi, >> >> Hi, >> >>> > On 1/31/19 6:38 PM, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko >> >> Both Lager and Stout boards are based on r8a7790 SoC. >> >> Leave platform specific functions for bringing seconadary CPUs up >> empty, >> since our target is to use PSCI for that. >> >> Also take care of updating arch timer while we are in secure mode. >> >> Signed-off-by: Oleksandr Tyshchenko >> --- >> arch/arm/mach-rmobile/Kconfig.32 | 4 >> board/renesas/lager/lager.c | 51 >> >> board/renesas/stout/stout.c | 51 >> >> include/configs/lager.h | 3 +++ >> include/configs/stout.h | 3 +++ >> 5 files changed, 112 insertions(+) >> >> diff --git a/arch/arm/mach-rmobile/Kconfig.32 >> b/arch/arm/mach-rmobile/Kconfig.32 >> index 076a019..a2e9e3d 100644 >> --- a/arch/arm/mach-rmobile/Kconfig.32 >> +++ b/arch/arm/mach-rmobile/Kconfig.32 >> @@ -76,6 +76,8 @@ config TARGET_LAGER >> select SUPPORT_SPL >> select USE_TINY_PRINTF >> imply CMD_DM >> + select CPU_V7_HAS_NONSEC >> + select CPU_V7_HAS_VIRT > Shouldn't this be a H2 CPU property instead of a board property ? Probably yes, sounds reasonable. I will move these options under "config R8A7790". > Does this apply to M2* too , since it has CA15 cores as well ? I think, yes. But, without PSCI support being implemented for M2*, I think it is not worth to select these options for it as well. >>> It's basically the same SoC with two CPU cores less, how would that PSCI >>> be any different on M2 ? >> I need some time to investigate. I will come up with an answer later. > > From the first look: > > 1. It should be different total number of CPUs: > > For R8A7790 we have the following: > > #define R8A7790_PSCI_NR_CPUS 8 > > But for R8A7791 it seems we need to use: > > #define R8A7791_PSCI_NR_CPUS 2 This information should be in the DT for each SoC, so you should extract it from there. > 2. It should be new pm-r8a7791.c file which will don't have any CA7 > related stuff (CPU cores, SCU, etc). I'd like to have a generic pm-gen2.c file , which parses the DT and figures the configuration out that way. We are trying to get rid of all the ad-hoc hardcoded configuration stuff in favor of DT. > Or it should be the single pm-r8a779x.c which must distinguish what SoC > is being used and do proper things. Right [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC
On 2/8/19 11:52 AM, Oleksandr wrote:
>
> On 05.02.19 20:55, Marek Vasut wrote:
>
> Hi Marek
Hi,
>> On 1/31/19 6:38 PM, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> Also enable PSCI support for Stout and Lager boards where
>>> actually the r8a7790 SoC is installed.
>>>
>>> All secondary CPUs will be switched to a non-secure HYP mode
>>> after booting.
>>>
>>> Signed-off-by: Oleksandr Tyshchenko
>>> ---
>>> arch/arm/mach-rmobile/Kconfig.32 | 2 +
>>> arch/arm/mach-rmobile/Makefile | 6 +
>>> arch/arm/mach-rmobile/pm-r8a7790.c | 408
>>> +
>>> arch/arm/mach-rmobile/pm-r8a7790.h | 72 +++
>>> arch/arm/mach-rmobile/psci.c | 193 ++
>>> include/configs/lager.h | 2 +
>>> include/configs/stout.h | 2 +
>>> 7 files changed, 685 insertions(+)
>>> create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.c
>>> create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.h
>>> create mode 100644 arch/arm/mach-rmobile/psci.c
>>>
>>> diff --git a/arch/arm/mach-rmobile/Kconfig.32
>>> b/arch/arm/mach-rmobile/Kconfig.32
>>> index a2e9e3d..728c323 100644
>>> --- a/arch/arm/mach-rmobile/Kconfig.32
>>> +++ b/arch/arm/mach-rmobile/Kconfig.32
>>> @@ -78,6 +78,7 @@ config TARGET_LAGER
>>> imply CMD_DM
>>> select CPU_V7_HAS_NONSEC
>>> select CPU_V7_HAS_VIRT
>>> + select ARCH_SUPPORT_PSCI
>>> config TARGET_KZM9G
>>> bool "KZM9D board"
>>> @@ -119,6 +120,7 @@ config TARGET_STOUT
>>> imply CMD_DM
>>> select CPU_V7_HAS_NONSEC
>>> select CPU_V7_HAS_VIRT
>>> + select ARCH_SUPPORT_PSCI
>
> To myself: Move this option under "config R8A7790".
>
>>> endchoice
>>> diff --git a/arch/arm/mach-rmobile/Makefile
>>> b/arch/arm/mach-rmobile/Makefile
>>> index 1f26ada..6f4c513 100644
>>> --- a/arch/arm/mach-rmobile/Makefile
>>> +++ b/arch/arm/mach-rmobile/Makefile
>>> @@ -13,3 +13,9 @@ obj-$(CONFIG_SH73A0) += lowlevel_init.o
>>> cpu_info-sh73a0.o pfc-sh73a0.o
>>> obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o
>>> pfc-r8a7740.o
>>> obj-$(CONFIG_RCAR_GEN2) += lowlevel_init_ca15.o cpu_info-rcar.o
>>> obj-$(CONFIG_RCAR_GEN3) += lowlevel_init_gen3.o cpu_info-rcar.o
>>> memmap-gen3.o
>>> +
>>> +ifndef CONFIG_SPL_BUILD
>>> +ifdef CONFIG_R8A7790
>>> +obj-$(CONFIG_ARMV7_PSCI) += psci.o pm-r8a7790.o
>>> +endif
>>> +endif
>>> diff --git a/arch/arm/mach-rmobile/pm-r8a7790.c
>>> b/arch/arm/mach-rmobile/pm-r8a7790.c
>>> new file mode 100644
>>> index 000..c635cf6
>>> --- /dev/null
>>> +++ b/arch/arm/mach-rmobile/pm-r8a7790.c
>>> @@ -0,0 +1,408 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * CPU power management support for Renesas r8a7790 SoC
>>> + *
>>> + * Contains functions to control ARM Cortex A15/A7 cores and
>>> + * related peripherals basically used for PSCI.
>>> + *
>>> + * Copyright (C) 2018 EPAM Systems Inc.
>>> + *
>>> + * Mainly based on Renesas R-Car Gen2 platform code from Linux:
>>> + * arch/arm/mach-shmobile/...
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#include "pm-r8a7790.h"
>>> +
>>> +/*
>>>
>> I'd expect checkpatch to complain about these long lines of asterisks.
>
> No, there was no complain about it. I have checked. Anyway, I can remove
> them if required.
Yes please, keep the comment style consistent with the rest of the
codebase, which is also the kernel comment style.
>>> + * APMU definitions
>>> +
>>> */
>>>
>>> +#define CA15_APMU_BASE 0xe6152000
>>> +#define CA7_APMU_BASE 0xe6151000
>> All these addresses should come from DT. And the driver should be DM
>> capable and live in drivers/
>>
>> [...]
>
> All PSCI backends for ARMV7 in U-Boot which I was able to found, are
> located either in arch/arm/cpu/armv7/
>
> or in arch/arm/mach-X. As well as other PSCI backends, this one will be
> located in a separate secure section and acts as secure monitor,
>
> so it will be still alive, when U-Boot is gone away. Do we really want
> this one to go into drivers?
I'd much prefer it if we stopped adding more stuff to arch/arm/mach-* ,
but I think we cannot avoid that in this case, can we ?
>>> +/*
>>>
>>> + * Functions which intended to be called from PSCI handlers. These
>>> functions
>>> + * marked as __secure and are placed in .secure section.
>>> +
>>> */
>>>
>>> +void __secure r8a7790_apmu_power_on(int cpu)
>>> +{
>>> + int cluster = r8a7790_cluster_id(cpu);
>>> + u32 apmu_base;
>>> +
>>> + apmu_base = cluster == 0 ? CA15_APMU_BASE : CA7_APMU_BASE;
>>> +
>>> + /* Request power on */
>>> + writel(BIT(r8a7790_core_id(cpu)), apmu_base + WUPCR_OFFS);
>> wait_for_bit
Re: [U-Boot] [PATCH 3/3] ARM: rmobile: Add possibility to debug main PSCI commands
On 2/8/19 1:47 PM, Oleksandr wrote:
>
> On 05.02.19 20:56, Marek Vasut wrote:
>
> Hi Marek
Hi,
>> On 1/31/19 6:38 PM, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> Also take care of the fact that Lager and Stout boards use
>>> different serial interface for console.
>> This describes something else than $subject , please split the patchset
>> such that one patch does one thing and describes that one thing in the
>> commit message.
>
> Yes, make sense. Will split.
>
>>> Signed-off-by: Oleksandr Tyshchenko
>>> ---
>>> arch/arm/mach-rmobile/debug.h | 91
>>> +++
>>> arch/arm/mach-rmobile/psci.c | 23 +++
>>> 2 files changed, 114 insertions(+)
>>> create mode 100644 arch/arm/mach-rmobile/debug.h
>>>
>>> diff --git a/arch/arm/mach-rmobile/debug.h
>>> b/arch/arm/mach-rmobile/debug.h
>>> new file mode 100644
>>> index 000..5d4ec77
>>> --- /dev/null
>>> +++ b/arch/arm/mach-rmobile/debug.h
>>> @@ -0,0 +1,91 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Contains functions used for PSCI debug.
>>> + *
>>> + * Copyright (C) 2018 EPAM Systems Inc.
>>> + *
>>> + * Based on arch/arm/mach-uniphier/debug.h
>>> + */
>>> +
>>> +#ifndef __DEBUG_H__
>>> +#define __DEBUG_H__
>>> +
>>> +#include
>>> +
>>> +/* SCIFA definitions */
>>> +#define SCIFA_BASE 0xe6c4
>> Should come from DT
>
> I have just found that rcar-base.h already contains #define-s for all
> SCIF(A)s.
So does the DT, and the addresses should come from DT, not from ad-hoc
constants in U-Boot. Those will likely be removed at some point.
>>> +#define SCIFA_SCASSR 0x14 /* Serial status register */
>>> +#define SCIFA_SCAFTDR 0x20 /* Transmit FIFO data register */
>>> +
>>> +/* SCIF definitions */
>>> +#define SCIF_BASE 0xe6e6
>>> +
>>> +#define SCIF_SCFSR 0x10 /* Serial status register */
>>> +#define SCIF_SCFTDR 0x0c /* Transmit FIFO data register */
>>> +
>>> +/* Common for both interfaces definitions */
>>> +#define SCFSR_TDFE BIT(5) /* Transmit FIFO Data Empty */
>>> +#define SCFSR_TEND BIT(6) /* Transmission End */
>>> +
>>> +#ifdef CONFIG_SCIF_A
>>> +#define UART_BASE SCIFA_BASE
>>> +#define UART_STATUS_REG SCIFA_SCASSR
>>> +#define UART_TX_FIFO_REG SCIFA_SCAFTDR
>>> +#else
>>> +#define UART_BASE SCIF_BASE
>>> +#define UART_STATUS_REG SCIF_SCFSR
>>> +#define UART_TX_FIFO_REG SCIF_SCFTDR
>>> +#endif
>>> +
>>> +/* All functions are inline so that they can be called from .secure
>>> section. */
>>> +
>>> +#ifdef DEBUG
>>> +static inline void debug_putc(int c)
>>> +{
>>> + void __iomem *base = (void __iomem *)UART_BASE;
>>> +
>>> + while (!(readw(base + UART_STATUS_REG) & SCFSR_TDFE))
>>> + ;
>>> +
>>> + writeb(c, base + UART_TX_FIFO_REG);
>>> + writew(readw(base + UART_STATUS_REG) & ~(SCFSR_TEND | SCFSR_TDFE),
>>> + base + UART_STATUS_REG);
>> Is this some implementation of debug uart API or is this a
>> reimplementation of the serial driver ?
>
> I would say it is some implementation of debug uart API.
>
> Let me explain why it is needed. We need something very simple to be
> called from the PSCI backend
>
> in order to have possibility for debugging it. Actually the only thing
> we need is a simple function to write a char into uart TX register.
>
> Actually I borrowed that idea from the implementation for mach-uniphier
> and modified according to the SCIF(A) usage.
>
> These are examples, how it looks like:
>
> 1.
>
> [ 3.193974] psci_checker: Trying to turn off and on again group 1
> (CPUs 4-7)
> [U-Boot PSCI] cpu_off: cpu=0004
> [ 3.233648] Retrying again to check for CPU kill
> [ 3.238269] CPU4 killed.
> [U-Boot PSCI] cpu_off: cpu=0005
> [ 3.263678] Retrying again to check for CPU kill
> [ 3.268298] CPU5 killed.
> [U-Boot PSCI] cpu_off: cpu=0006
> [ 3.293648] Retrying again to check for CPU kill
> [ 3.298268] CPU6 killed.
> [U-Boot PSCI] cpu_off: cpu=0007
> [ 3.323691] Retrying again to check for CPU kill
> [ 3.328310] CPU7 killed.
> [U-Boot PSCI] cpu_on: cpu=0001, target_cpu=0100,
> entry_point=48102440, context_id=
> [U-Boot PSCI] cpu_on: cpu=0002, target_cpu=0101,
> entry_point=48102440, context_id=
> [U-Boot PSCI] cpu_on: cpu=0001, target_cpu=0102,
> entry_point=48102440, context_id=
> [U-Boot PSCI] cpu_on: cpu=0001, target_cpu=0103,
> entry_point=48102440, context_id=
>
>
> 2.
> (XEN) Bringing up CPU4
> [U-Boot PSCI] cpu_on: cpu=, target_cpu=0100,
> entry_point=484c, context_id=0030e208
> - CPU 0100 booting -
> - Xen starting in Hyp mode -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Adding cpu 4 to runqueue 0
> (XEN) CPU 4 booted.
> (XEN) Bringing up CPU5
> [U-Boot PSCI] cpu_on: cpu=, target_cpu=0101,
> entry_point=484c,
Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken
On 2/9/19 4:24 PM, Philipp Tomsich wrote: > > >> On 09.02.2019, at 16:08, Philipp Tomsich >> wrote: >> >> Heinrich, >> >> My guess is that this is fallout from David Wu’s new pinctrl driver >> (which has really been the bulk of changes in this cycle). I can’t >> test or debug on the rk3288 due to a lack of hardware. > > If you want to start digging, that the changes in > >> commit 08c817c39908f9d120df1e4c90ddad4a11fc3891 >> Author: David Wu >> Date: Wed Jan 2 20:51:00 2019 +0800 >> >> ARM: rockchip: Remove the pinctrl request at rk3288-board-spl >> >> If we use the new pinctrl driver, the pinctrl setup will be done >> by device probe. Remove the pinctrl setup at rk3288-board-spl. >> >> Signed-off-by: David Wu >> Reviewed-by: Kever Yang >> Reviewed-by: Philipp Tomsich > > > look like they have the potential to break everything, including the > UART pinctrl. > > Thanks, > Philipp., > Hello Philipp, I would not know how to analyze the bug if there isn't even a console. If David or you send me a git branch to compile I will test it. Has any of the rk3288 boards been tested before merging? I think we should keep Simon in CC as he is one of the ROCKCHIP maintainers. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT
On Mon, Jan 28, 2019 at 2:37 PM Patrick Delaunay
wrote:
>
> This patch update the behavior introduced by
> commit 96907c0fe50a ("dm: spi: Read default speed and mode values from DT")
>
> In case of DT boot, don't read default speed and mode for SPI from
> CONFIG_* but instead read from DT node. This will make sure that boards
> with multiple SPI/QSPI controllers can be probed at different
> bus frequencies and SPI modes.
>
> DT values will be always used when available (full DM support of
> SPI slave with available DT node) even if speed and mode are requested;
> for example in splash screen support (in splash_sf_read_raw)
> or in SPL boot (in spl_spi_load_image).
> The caller of spi_get_bus_and_cs() no more need to force speed=0.
>
> But the current behavior don't change if the SPI slave is not
> present (device with generic driver is created automatically)
> or if platdata is used (CONFIG_OF_PLATDATA).
>
>
> Signed-off-by: Patrick Delaunay
> ---
>
> Changes in v3:
> - complete rework of the patch-set to avoid regression
>
> Changes in v2:
> - use variables to avoid duplicated code
>
> README | 3 +++
> cmd/sf.c | 3 +--
> common/spl/spl_spi.c | 2 ++
> drivers/spi/spi-uclass.c | 4 +++-
> include/spi.h| 9 +
> 5 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/README b/README
> index 17d56b8..f7fe74f 100644
> --- a/README
> +++ b/README
> @@ -2184,6 +2184,9 @@ The following options need to be configured:
> CONFIG_SF_DEFAULT_MODE (see include/spi.h)
> CONFIG_SF_DEFAULT_SPEED in Hz
>
> + In case of DT boot, SPI don't read default speed and mode
> + from CONFIG_*, but from platdata values computed from
> available
> + DT node
This has to update in Kconfig help info.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/5] efi_loader: Initial HII database protocols
On 1/23/19 2:01 PM, Alexander Graf wrote: >> From: Leif Lindholm >> >> This patch provides enough implementation of the following protocols to >> run EDKII's Shell.efi and UEFI SCT: >> >> * EfiHiiDatabaseProtocol >> * EfiHiiStringProtocol >> >> Not implemented are: >> * ExportPackageLists() >> * RegisterPackageNotify()/UnregisterPackageNotify() >> * SetKeyboardLayout() (i.e. *current* keyboard layout) >> >> HII database protocol in this patch series can handle only: >> * GUID package >> * string package >> * keyboard layout package >> (The other packages, except Device path package, will be necessary >>for interactive and graphical UI.) >> >> Cc: Leif Lindholm >> Signed-off-by: Rob Clark >> Signed-off-by: AKASHI Takahiro > > Thanks, applied to efi-next > > Alex > > I have rebased the efi-next tree upon U-Boot master. My Odroid C2 crashes when booting via U-Boot -> iPXE -> GRUB -> Linux. Bisection points to this patch. The HII protocols are referenced by iPXE if available. An interesting comment in https://www.spinics.net/lists/arm-kernel/msg704238.html for a similar U-Boot related error is: "Looks like you're taking the SError as soon as we unmask them, so it could've been pending for ages. It would be interesting to see if it's actually caused by the kernel, or if the firmware triggers it beforehand." Booting via iPXE is described in doc/README.iscsi This patch and some follow up patches are included in the pull request for the EFI tree. I would prefer if we could remove the HII protocols from the pull request until the patches are thoroughly tested. Loading Linux 4.19.0-1-arm64 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] [0.00] Linux version 4.19.0-1-arm64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8) [0.00] Machine model: Hardkernel ODROID-C2 [0.00] earlycon: meson0 at MMIO 0xc81004c0 (options '115200n8') [0.00] bootconsole [meson0] enabled [0.00] SError Interrupt on CPU0, code 0xbf00 -- SError [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-1-arm64 #1 Debian 4.19.12-1 [0.00] Hardware name: Hardkernel ODROID-C2 (DT) [0.00] pstate: 0085 (nzcv daIf -PAN -UAO) [0.00] pc : setup_arch+0x104/0x570 [0.00] lr : setup_arch+0xfc/0x570 [0.00] sp : 09293f10 [0.00] x29: 09293f10 x28: 023d0018 [0.00] x27: 7c9b30c0 x26: [0.00] x25: x24: 7ca7e000 [0.00] x23: x22: 09299708 [0.00] x21: 7dfffe8000d4 x20: 092e3330 [0.00] x19: 0808 x18: 0010 [0.00] x17: x16: [0.00] x15: x14: 09299708 [0.00] x13: 8943937f x12: 0028 [0.00] x11: 0007 x10: 0101010101010101 [0.00] x9 : fffb x8 : 0008 [0.00] x7 : 0003 x6 : 0080 [0.00] x5 : 8000 x4 : 0065 [0.00] x3 : 0063 x2 : [0.00] x1 : x0 : 0080 [0.00] Kernel panic - not syncing: Asynchronous SError Interrupt [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-1-arm64 #1 Debian 4.19.12-1 [0.00] Hardware name: Hardkernel ODROID-C2 (DT) [0.00] Call trace: [0.00] dump_backtrace+0x0/0x180 [0.00] show_stack+0x24/0x30 [0.00] dump_stack+0x90/0xb4 [0.00] panic+0x128/0x290 [0.00] nmi_panic+0x7c/0x80 [0.00] arm64_serror_panic+0x80/0x8c [0.00] is_valid_bugaddr+0x0/0x1c [0.00] el1_error+0x7c/0xdc [0.00] setup_arch+0x104/0x570 [0.00] start_kernel+0x78/0x4c0 Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: tbs_a711: lower dram frequency
On Tue, Feb 5, 2019 at 7:27 PM Tomas Novotny wrote: > > The dram chip on the tablet was changed. The new one requires a lower > frequency, so change it. > > Frequency 564 was also stable in the tests, but use slightly lower one > to be on a safe side. New rate? How does it compatible with legacy devices? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] distro_bootcmd: add spi flash boot command
On Thu, Jan 31, 2019 at 12:51 AM Oskari Lemmela wrote: > > Add a boot command to distro boot to support load FIT image > from SPI flash. Add some info about why default offsets being used below. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: add spi flash id s25fl064l
On Fri, Feb 8, 2019 at 3:33 PM Heiko Schocher wrote: > > Add support for SPANSION s25fl064l > > Signed-off-by: Heiko Schocher > --- > > Changes in v2: > - s/s25f064l/s25fl064l > as Vignesh R suggested Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: Add support for Macronix mx25u12835f
On Wed, Dec 19, 2018 at 1:28 AM Vladimir Vid wrote:
>
> Add ID for Macronix mx25u12835f flash.
>
> Signed-off-by: Vladimir Vid
> ---
> drivers/mtd/spi/spi_flash_ids.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
> index ad0a0c8150..4876007ef6 100644
> --- a/drivers/mtd/spi/spi_flash_ids.c
> +++ b/drivers/mtd/spi/spi_flash_ids.c
> @@ -89,6 +89,7 @@ const struct spi_flash_info spi_flash_ids[] = {
> {"mx25l51235f",INFO(0xc2201a, 0x0, 64 * 1024, 1024, RD_FULL |
> WR_QPP) },
> {"mx25l1633e", INFO(0xc22415, 0x0, 64 * 1024,32, RD_FULL |
> WR_QPP | SECT_4K) },
> {"mx25u6435f", INFO(0xc22537, 0x0, 64 * 1024, 128, RD_FULL |
> WR_QPP) },
> + {"mx25u12835f",INFO(0xc22538, 0x0, 64 * 1024, 256, RD_FULL |
> WR_QPP) },
Chip use uniform 4K-byte erase, is it still working/stable w/o SECT_4K?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken
> On 09.02.2019, at 16:08, Philipp Tomsich > wrote: > > Heinrich, > > My guess is that this is fallout from David Wu’s new pinctrl driver > (which has really been the bulk of changes in this cycle). I can’t > test or debug on the rk3288 due to a lack of hardware. If you want to start digging, that the changes in > commit 08c817c39908f9d120df1e4c90ddad4a11fc3891 > Author: David Wu > Date: Wed Jan 2 20:51:00 2019 +0800 > > ARM: rockchip: Remove the pinctrl request at rk3288-board-spl > > If we use the new pinctrl driver, the pinctrl setup will be done > by device probe. Remove the pinctrl setup at rk3288-board-spl. > > Signed-off-by: David Wu > Reviewed-by: Kever Yang > Reviewed-by: Philipp Tomsich look like they have the potential to break everything, including the UART pinctrl. Thanks, Philipp., ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: sunxi: Enable SPL/SPI boot for Olinuxino Lime2-eMMC boards
On Thu, Jan 10, 2019 at 3:00 PM Priit Laes wrote: > > From: Priit Laes > > Starting from revision K the Olimex-Lime2-eMMC boards include > eMMC 5.x chip. Unfortunately, the internal brom in the A20 > cannot reliably initialize those chips resulting in random > boot failures on those boards. > > To overcome this, all the latest Lime2-eMMC boards are > populated with 16MB SPI flash and therefore enable support > for SPI SPL boot. > > For now, SPI flash can be managed using sunxi-fel's spiflash tools. > > Signed-off-by: Priit Laes > --- Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken
Heinrich, My guess is that this is fallout from David Wu’s new pinctrl driver (which has really been the bulk of changes in this cycle). I can’t test or debug on the rk3288 due to a lack of hardware. I did add fix some issues for the RK3399 (and have more to submit). The expectation is that I'll need to add further fixes for the RK3368 (the second platform I can test on) in later RCs. Thanks, Philipp. > On 09.02.2019, at 13:12, Heinrich Schuchardt wrote: > > Hello Simon, hello Philipp, > > since patch > > Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip > e5fd39c886485e3dec77f4438a6e364c2987cf5f > > booting on the Tinker Board (tinker-rk3288_defconfig) is broken. > > There is not even any UART output from SPL. > > Best regards > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] sunxi: Fix build when CONFIG_CMD_NET is disabled
From: Ondrej Jirman
Signed-off-by: Ondřej Jirman
---
board/sunxi/board.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 98bc3cd0c1..e918bdf36b 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -774,9 +774,12 @@ static void setup_environment(const void *fdt)
{
char serial_string[17] = { 0 };
unsigned int sid[4];
+#if defined CONFIG_CMD_NET
uint8_t mac_addr[6];
char ethaddr[16];
- int i, ret;
+ int i;
+#endif
+ int ret;
ret = sunxi_get_sid(sid);
if (ret == 0 && sid[0] != 0) {
@@ -801,6 +804,7 @@ static void setup_environment(const void *fdt)
if ((sid[3] & 0xff) == 0)
sid[3] |= 0x80;
+#if defined CONFIG_CMD_NET
for (i = 0; i < 4; i++) {
sprintf(ethaddr, "ethernet%d", i);
if (!fdt_get_alias(fdt, ethaddr))
@@ -824,6 +828,7 @@ static void setup_environment(const void *fdt)
eth_env_set_enetaddr(ethaddr, mac_addr);
}
+#endif
if (!env_get("serial#")) {
snprintf(serial_string, sizeof(serial_string),
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] power: axp818: Fix typo in axp_set_dldo
From: Ondrej Jirman Signed-off-by: Ondřej Jirman --- drivers/power/axp818.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/axp818.c b/drivers/power/axp818.c index c737da1180..834919ddd4 100644 --- a/drivers/power/axp818.c +++ b/drivers/power/axp818.c @@ -161,7 +161,7 @@ int axp_set_dldo(int dldo_num, unsigned int mvolt) cfg = axp818_mvolt_to_cfg(mvolt, 700, 3300, 100); if (dldo_num == 2 && mvolt > 3300) cfg += 1 + axp818_mvolt_to_cfg(mvolt, 3400, 4200, 200); - ret = pmic_bus_write(AXP818_ELDO1_CTRL + (dldo_num - 1), cfg); + ret = pmic_bus_write(AXP818_DLDO1_CTRL + (dldo_num - 1), cfg); if (ret) return ret; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] sunxi: Fix build when CONFIG_CMD_PXE or CONFIG_CMD_DHCP are disabled
From: Ondrej Jirman Signed-off-by: Ondřej Jirman --- include/configs/sunxi-common.h | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index b01d1c3c84..d421b93509 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -399,6 +399,18 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_CMD_PXE +#define BOOT_TARGET_DEVICES_PXE(func) func(PXE, pxe, na) +#else +#define BOOT_TARGET_DEVICES_PXE(func) +#endif + +#ifdef CONFIG_CMD_DHCP +#define BOOT_TARGET_DEVICES_DHCP(func) func(DHCP, dhcp, na) +#else +#define BOOT_TARGET_DEVICES_DHCP(func) +#endif + /* FEL boot support, auto-execute boot.scr if a script address was provided */ #define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \ "bootcmd_fel=" \ @@ -414,8 +426,8 @@ extern int soft_i2c_gpio_scl; BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ - func(PXE, pxe, na) \ - func(DHCP, dhcp, na) + BOOT_TARGET_DEVICES_PXE(func) \ + BOOT_TARGET_DEVICES_DHCP(func) #ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT #define BOOTCMD_SUNXI_COMPAT \ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] lib: decode_timing_property should return -NOENT when proprty is not found
From: Ondrej Jirman
Length may be unitialized when fdt_getprop fails.
Signed-off-by: Ondřej Jirman
---
lib/fdtdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 18663ce6bd..3510de78e1 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -980,7 +980,7 @@ static int decode_timing_property(const void *blob, int
node, const char *name,
if (!prop) {
debug("%s: could not find property %s\n",
fdt_get_name(blob, node, NULL), name);
- return length;
+ return -ENOENT;
}
if (length == sizeof(u32)) {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] Random small sunxi fixes
From: Ondrej Jirman Patch 1 and 2 are fixes for compilation failures with disabled network support on sunxi platform. Patch 3 is a fix for error path bug in decode_timing_property(), I've found while debugging a missing LCD panel output. Patch 4 is typo fix. regards, Ondřej Jirman Ondrej Jirman (4): sunxi: Fix build when CONFIG_CMD_NET is disabled sunxi: Fix build when CONFIG_CMD_PXE or CONFIG_CMD_DHCP are disabled lib: decode_timing_property should return -NOENT when proprty is not found power: axp818: Fix typo in axp_set_dldo board/sunxi/board.c| 7 ++- drivers/power/axp818.c | 2 +- include/configs/sunxi-common.h | 16 ++-- lib/fdtdec.c | 2 +- 4 files changed, 22 insertions(+), 5 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] warp7: README: Adjust the binary name after DM conversion
After the conversion to DM the U-Boot binary is called u-boot-dtb.imx, so fix the README file accordingly. Signed-off-by: Fabio Estevam --- Changes since v1: - Fix all occurrances board/warp7/README | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/board/warp7/README b/board/warp7/README index 60339da543..579bb2de38 100644 --- a/board/warp7/README +++ b/board/warp7/README @@ -17,7 +17,7 @@ $ make mrproper $ make warp7_config $ make -This will generate the U-Boot binary called u-boot.imx. +This will generate the U-Boot binary called u-boot-dtb.imx. Put warp7 board in USB download mode: @@ -28,11 +28,11 @@ Connect a USB to serial adapter between the host PC and warp7 Connect a USB cable between the OTG warp7 port and the host PC -Copy u-boot.imx to the imx_usb_loader folder. +Copy u-boot-dtb.imx to the imx_usb_loader folder. -Load u-boot.imx via USB: +Load u-boot-dtb.imx via USB: -$ sudo ./imx_usb u-boot.imx +$ sudo ./imx_usb u-boot-dtb.imx Then U-Boot should start and its messages will appear in the console program. @@ -46,9 +46,9 @@ Use the default environment variables: Run the DFU command: => dfu 0 mmc 0 -Transfer u-boot.imx that will be flashed into the eMMC: +Transfer u-boot-dtb.imx that will be flashed into the eMMC: -$ sudo dfu-util -D u-boot.imx -a boot +$ sudo dfu-util -D u-boot-dtb.imx -a boot Then on the U-Boot prompt the following message should be seen after a successful upgrade: -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] warp7: README: Adjust the binary name after DM conversion
After the conversion to DM the U-Boot binary is called u-boot-dtb.imx, so fix the README file accordingly. Signed-off-by: Fabio Estevam --- board/warp7/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/warp7/README b/board/warp7/README index 60339da543..dcad61fd3d 100644 --- a/board/warp7/README +++ b/board/warp7/README @@ -48,7 +48,7 @@ Run the DFU command: Transfer u-boot.imx that will be flashed into the eMMC: -$ sudo dfu-util -D u-boot.imx -a boot +$ sudo dfu-util -D u-boot-dtb.imx -a boot Then on the U-Boot prompt the following message should be seen after a successful upgrade: -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On 2/9/19 1:46 PM, Tom Rini wrote:
> On Sat, Feb 09, 2019 at 11:04:15AM +0100, Marek Vasut wrote:
>> On 2/9/19 1:17 AM, Tom Rini wrote:
>>> On Fri, Feb 08, 2019 at 11:19:46AM +0100, Marek Vasut wrote:
>>>
SD/MMC and filesystem fixes below ...
The following changes since commit
e5fd39c886485e3dec77f4438a6e364c2987cf5f:
Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip
(2019-02-02 10:11:20 -0500)
are available in the Git repository at:
git://git.denx.de/u-boot-sh.git master
for you to fetch changes up to 49f331023e1d6f804c4226b862af1f2a05a2ea2e:
fs: ext4: Unmount FS in do_fs_type() (2019-02-06 14:07:12 +0100)
>>>
>>> NAK. The change:
>>> commit 09a89b86d48a19598750f05f69412ec9ddbefba4
>>> Author: Marek Vasut
>>> Date: Tue Jan 29 04:45:51 2019 +0100
>>>
>>> mmc: Export {sd,mmc}_select_mode_and_width()
>>>
>>> breaks pine_h64 as SPL now overflows sram by 104 bytes.
>>
>> How is that even possible ?
>
> OK, lets hack sunxi until it links again with these new functions, and
> then use buildman to report code growth:
>spl-u-boot-spl: add: 2/0, grow: 0/-1 bytes: 1264/-1100 (164)
> function old new
> delta
> sd_select_mode_and_width - 696
> +696
> mmc_select_mode_and_width- 568
> +568
> mmc_init 22801180
> -1100
I'm not sure I understand what you're trying to show or tell me. Can you
elaborate on this ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/10] spi: sun4: Add A31 spi controller support
Add A31 spi controller support for existing sun4i_spi driver via driver
data, this would simply add A31 register along with proper register bits
via enum sets.
Signed-off-by: Jagan Teki
---
drivers/spi/Kconfig | 4 +-
drivers/spi/sun4i_spi.c | 84 -
2 files changed, 85 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ac7fbab841..15207d23c1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -223,9 +223,9 @@ config STM32_QSPI
this ST IP core.
config SUN4I_SPI
- bool "Allwinner A10 SoCs SPI controller"
+ bool "Allwinner A10/A31 SoCs SPI controller"
help
- SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
+ This enables using the SPI controller on the Allwinner A10/A31 SoCs.
config TEGRA114_SPI
bool "nVidia Tegra114 SPI driver"
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index aeed68764c..36f2215f7d 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -84,6 +85,18 @@
#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
#define SUN4I_FIFO_STA_TF_CNT_BITS 16
+/* sun6i spi registers */
+#define SUN6I_GBL_CTL_REG 0x04
+#define SUN6I_TFR_CTL_REG 0x08
+#define SUN6I_FIFO_CTL_REG 0x18
+#define SUN6I_FIFO_STA_REG 0x1c
+#define SUN6I_CLK_CTL_REG 0x24
+#define SUN6I_BURST_CNT_REG0x30
+#define SUN6I_XMIT_CNT_REG 0x34
+#define SUN6I_BURST_CTL_REG0x38
+#define SUN6I_TXDATA_REG 0x200
+#define SUN6I_RXDATA_REG 0x300
+
#define SUN4I_SPI_MAX_RATE 2400
#define SUN4I_SPI_MIN_RATE 3000
#define SUN4I_SPI_DEFAULT_RATE 100
@@ -106,6 +119,7 @@ enum sun4i_spi_regs {
/* sun spi register bits */
enum sun4i_spi_bits {
SPI_GCR_TP,
+ SPI_GCR_SRST,
SPI_TCR_CPHA,
SPI_TCR_CPOL,
SPI_TCR_CS_ACTIVE_LOW,
@@ -133,6 +147,7 @@ struct sun4i_spi_platdata {
struct sun4i_spi_priv {
struct sun4i_spi_variant *variant;
struct clk clk_ahb, clk_mod;
+ struct reset_ctl reset;
u32 base_addr;
u32 freq;
u32 mode;
@@ -255,7 +270,10 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
if (pin < 0)
break;
- sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
+ if (IS_ENABLED(CONFIG_MACH_SUN50I))
+ sunxi_gpio_set_cfgpin(pin, SUN50I_GPC_SPI0);
+ else
+ sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
sunxi_gpio_set_drv(pin, drive);
sunxi_gpio_set_pull(pin, pull);
}
@@ -271,6 +289,8 @@ static inline int sun4i_spi_set_clock(struct udevice *dev,
bool enable)
if (!enable) {
clk_disable(>clk_ahb);
clk_disable(>clk_mod);
+ if (reset_valid(>reset))
+ reset_assert(>reset);
return 0;
}
@@ -286,8 +306,18 @@ static inline int sun4i_spi_set_clock(struct udevice *dev,
bool enable)
goto err_ahb;
}
+ if (reset_valid(>reset)) {
+ ret = reset_deassert(>reset);
+ if (ret) {
+ dev_err(dev, "failed to deassert reset\n");
+ goto err_mod;
+ }
+ }
+
return 0;
+err_mod:
+ clk_disable(>clk_mod);
err_ahb:
clk_disable(>clk_ahb);
return ret;
@@ -328,6 +358,12 @@ static int sun4i_spi_probe(struct udevice *bus)
return ret;
}
+ ret = reset_get_by_index(bus, 0, >reset);
+ if (ret && ret != -ENOENT) {
+ dev_err(dev, "failed to get reset\n");
+ return ret;
+ }
+
sun4i_spi_parse_pins(bus);
priv->variant = plat->variant;
@@ -351,6 +387,10 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER |
variant->bits[SPI_GCR_TP]);
+ if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I))
+ setbits_le32(priv->base_addr + variant->regs[SPI_GCR],
+variant->bits[SPI_GCR_SRST]);
+
setbits_le32(priv->base_addr + variant->regs[SPI_TCR],
variant->bits[SPI_TCR_CS_MANUAL] |
variant->bits[SPI_TCR_CS_ACTIVE_LOW]);
@@ -409,6 +449,9 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int
bitlen,
priv->base_addr + variant->regs[SPI_BC]);
writel(SUN4I_XMIT_CNT(nbytes),
priv->base_addr + variant->regs[SPI_TC]);
+ if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I))
+
[U-Boot] [PATCH 08/10] spi: sun4i: Driver cleanup
- drop unused macros.
- use base instead of base_addr, for better code readability
- move .probe and .ofdata_to_platdata functions in required
places to add platdata support in future.
- use sentinel sun4i_spi_ids.
Signed-off-by: Jagan Teki
---
drivers/spi/sun4i_spi.c | 224 +---
1 file changed, 97 insertions(+), 127 deletions(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 36f2215f7d..a32f511245 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -33,57 +33,16 @@
#include
-#define SUN4I_RXDATA_REG 0x00
-
-#define SUN4I_TXDATA_REG 0x04
-
-#define SUN4I_CTL_REG 0x08
-#define SUN4I_CTL_ENABLE BIT(0)
-#define SUN4I_CTL_MASTER BIT(1)
-#define SUN4I_CTL_CPHA BIT(2)
-#define SUN4I_CTL_CPOL BIT(3)
-#define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
-#define SUN4I_CTL_LMTF BIT(6)
-#define SUN4I_CTL_TF_RST BIT(8)
-#define SUN4I_CTL_RF_RST BIT(9)
-#define SUN4I_CTL_XCH BIT(10)
-#define SUN4I_CTL_CS_MASK 0x3000
-#define SUN4I_CTL_CS(cs) (((cs) << 12) & SUN4I_CTL_CS_MASK)
-#define SUN4I_CTL_DHB BIT(15)
-#define SUN4I_CTL_CS_MANUALBIT(16)
-#define SUN4I_CTL_CS_LEVEL BIT(17)
-#define SUN4I_CTL_TP BIT(18)
-
-#define SUN4I_INT_CTL_REG 0x0c
-#define SUN4I_INT_CTL_RF_F34 BIT(4)
-#define SUN4I_INT_CTL_TF_E34 BIT(12)
-#define SUN4I_INT_CTL_TC BIT(16)
-
-#define SUN4I_INT_STA_REG 0x10
-
-#define SUN4I_DMA_CTL_REG 0x14
-
-#define SUN4I_WAIT_REG 0x18
-
-#define SUN4I_CLK_CTL_REG 0x1c
-#define SUN4I_CLK_CTL_CDR2_MASK0xff
-#define SUN4I_CLK_CTL_CDR2(div)((div) &
SUN4I_CLK_CTL_CDR2_MASK)
-#define SUN4I_CLK_CTL_CDR1_MASK0xf
-#define SUN4I_CLK_CTL_CDR1(div)(((div) &
SUN4I_CLK_CTL_CDR1_MASK) << 8)
-#define SUN4I_CLK_CTL_DRS BIT(12)
-
-#define SUN4I_MAX_XFER_SIZE0xff
-
-#define SUN4I_BURST_CNT_REG0x20
-#define SUN4I_BURST_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
-
-#define SUN4I_XMIT_CNT_REG 0x24
-#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
+DECLARE_GLOBAL_DATA_PTR;
-#define SUN4I_FIFO_STA_REG 0x28
-#define SUN4I_FIFO_STA_RF_CNT_BITS 0
-#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
-#define SUN4I_FIFO_STA_TF_CNT_BITS 16
+/* sun4i spi registers */
+#define SUN4I_RXDATA_REG 0x00
+#define SUN4I_TXDATA_REG 0x04
+#define SUN4I_CTL_REG 0x08
+#define SUN4I_CLK_CTL_REG 0x1c
+#define SUN4I_BURST_CNT_REG0x20
+#define SUN4I_XMIT_CNT_REG 0x24
+#define SUN4I_FIFO_STA_REG 0x28
/* sun6i spi registers */
#define SUN6I_GBL_CTL_REG 0x04
@@ -97,10 +56,23 @@
#define SUN6I_TXDATA_REG 0x200
#define SUN6I_RXDATA_REG 0x300
-#define SUN4I_SPI_MAX_RATE 2400
-#define SUN4I_SPI_MIN_RATE 3000
-#define SUN4I_SPI_DEFAULT_RATE 100
-#define SUN4I_SPI_TIMEOUT_US 100
+/* sun spi bits */
+#define SUN4I_CTL_ENABLE BIT(0)
+#define SUN4I_CTL_MASTER BIT(1)
+#define SUN4I_CLK_CTL_CDR2_MASK0xff
+#define SUN4I_CLK_CTL_CDR2(div)((div) &
SUN4I_CLK_CTL_CDR2_MASK)
+#define SUN4I_CLK_CTL_CDR1_MASK0xf
+#define SUN4I_CLK_CTL_CDR1(div)(((div) &
SUN4I_CLK_CTL_CDR1_MASK) << 8)
+#define SUN4I_CLK_CTL_DRS BIT(12)
+#define SUN4I_MAX_XFER_SIZE0xff
+#define SUN4I_BURST_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
+#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
+#define SUN4I_FIFO_STA_RF_CNT_BITS 0
+
+#define SUN4I_SPI_MAX_RATE 2400
+#define SUN4I_SPI_MIN_RATE 3000
+#define SUN4I_SPI_DEFAULT_RATE 100
+#define SUN4I_SPI_TIMEOUT_US 100
/* sun spi register set */
enum sun4i_spi_regs {
@@ -140,7 +112,7 @@ struct sun4i_spi_variant {
struct sun4i_spi_platdata {
struct sun4i_spi_variant *variant;
- u32 base_addr;
+ u32 base;
u32 max_hz;
};
@@ -148,7 +120,7 @@ struct sun4i_spi_priv {
struct sun4i_spi_variant *variant;
struct clk clk_ahb, clk_mod;
struct reset_ctl reset;
- u32 base_addr;
+ u32 base;
u32 freq;
u32 mode;
@@ -156,15 +128,13 @@ struct sun4i_spi_priv {
u8 *rx_buf;
};
-DECLARE_GLOBAL_DATA_PTR;
-
static inline void sun4i_spi_drain_fifo(struct sun4i_spi_priv *priv, int len)
{
struct sun4i_spi_variant *variant = priv->variant;
u8 byte;
while (len--) {
- byte = readb(priv->base_addr + variant->regs[SPI_RXD]);
+ byte = readb(priv->base +
[U-Boot] [PATCH 06/10] spi: sun4i: Add CLK support
Add CLK support to enable AHB and MOD SPI clocks on sun4i_spi driver.
Note, that the code will enable and disable clock in claim and release
calls to make proper clock and reset handling between claiming and
releasing SPI bus.
Signed-off-by: Jagan Teki
---
drivers/spi/sun4i_spi.c | 56 +++--
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index d3cf25db6f..aeed68764c 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -19,6 +19,7 @@
*/
#include
+#include
#include
#include
#include
@@ -29,8 +30,6 @@
#include
#include
-#include
-
#include
#define SUN4I_RXDATA_REG 0x00
@@ -133,6 +132,7 @@ struct sun4i_spi_platdata {
struct sun4i_spi_priv {
struct sun4i_spi_variant *variant;
+ struct clk clk_ahb, clk_mod;
u32 base_addr;
u32 freq;
u32 mode;
@@ -263,13 +263,34 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
return 0;
}
-static inline void sun4i_spi_enable_clock(void)
+static inline int sun4i_spi_set_clock(struct udevice *dev, bool enable)
{
- struct sunxi_ccm_reg *const ccm =
- (struct sunxi_ccm_reg *const)SUNXI_CCM_BASE;
+ struct sun4i_spi_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ if (!enable) {
+ clk_disable(>clk_ahb);
+ clk_disable(>clk_mod);
+ return 0;
+ }
- setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_SPI0));
- writel((1 << 31), >spi0_clk_cfg);
+ ret = clk_enable(>clk_ahb);
+ if (ret) {
+ dev_err(dev, "failed to enable ahb clock (ret=%d)\n", ret);
+ return ret;
+ }
+
+ ret = clk_enable(>clk_mod);
+ if (ret) {
+ dev_err(dev, "failed to enable mod clock (ret=%d)\n", ret);
+ goto err_ahb;
+ }
+
+ return 0;
+
+err_ahb:
+ clk_disable(>clk_ahb);
+ return ret;
}
static int sun4i_spi_ofdata_to_platdata(struct udevice *bus)
@@ -293,8 +314,20 @@ static int sun4i_spi_probe(struct udevice *bus)
{
struct sun4i_spi_platdata *plat = dev_get_platdata(bus);
struct sun4i_spi_priv *priv = dev_get_priv(bus);
+ int ret;
+
+ ret = clk_get_by_name(bus, "ahb", >clk_ahb);
+ if (ret) {
+ dev_err(dev, "failed to get ahb clock\n");
+ return ret;
+ }
+
+ ret = clk_get_by_name(bus, "mod", >clk_mod);
+ if (ret) {
+ dev_err(dev, "failed to get mod clock\n");
+ return ret;
+ }
- sun4i_spi_enable_clock();
sun4i_spi_parse_pins(bus);
priv->variant = plat->variant;
@@ -308,6 +341,11 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
{
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
struct sun4i_spi_variant *variant = priv->variant;
+ int ret;
+
+ ret = sun4i_spi_set_clock(dev->parent, true);
+ if (ret)
+ return ret;
setbits_le32(priv->base_addr + variant->regs[SPI_GCR],
SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER |
@@ -328,6 +366,8 @@ static int sun4i_spi_release_bus(struct udevice *dev)
clrbits_le32(priv->base_addr + variant->regs[SPI_GCR],
SUN4I_CTL_ENABLE);
+ sun4i_spi_set_clock(dev->parent, false);
+
return 0;
}
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/10] spi: kconfig: Enable SUN4I_SPI by default if ARCH_SUNXI
Enable SUN4I_SPI by default for ARCH_SUNXI, so that board that would require to enable DM_SPI that eventually enable the SUN4I_SPI driver. Signed-off-by: Jagan Teki --- drivers/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 15207d23c1..2fb4862c4a 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -224,6 +224,7 @@ config STM32_QSPI config SUN4I_SPI bool "Allwinner A10/A31 SoCs SPI controller" + default ARCH_SUNXI help This enables using the SPI controller on the Allwinner A10/A31 SoCs. -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/10] spi: sun4i: Simplify reg writes using set/clrbits_le32
Update the existing register writes using setbits_le32 and
clrbits_le32 in required places.
Signed-off-by: Jagan Teki
---
drivers/spi/sun4i_spi.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 87b396a96e..5446cebe7c 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -283,20 +283,18 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
{
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
- writel(SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER | SUN4I_CTL_TP |
- SUN4I_CTL_CS_MANUAL | SUN4I_CTL_CS_ACTIVE_LOW,
- >regs->ctl);
+ setbits_le32(>regs->ctl, SUN4I_CTL_ENABLE |
+SUN4I_CTL_MASTER | SUN4I_CTL_TP |
+SUN4I_CTL_CS_MANUAL | SUN4I_CTL_CS_ACTIVE_LOW);
+
return 0;
}
static int sun4i_spi_release_bus(struct udevice *dev)
{
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
- u32 reg;
- reg = readl(>regs->ctl);
- reg &= ~SUN4I_CTL_ENABLE;
- writel(reg, >regs->ctl);
+ clrbits_le32(>regs->ctl, SUN4I_CTL_ENABLE);
return 0;
}
@@ -309,7 +307,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int
bitlen,
struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
u32 len = bitlen / 8;
- u32 reg, rx_fifocnt;
+ u32 rx_fifocnt;
u8 nbytes;
int ret;
@@ -324,10 +322,8 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned
int bitlen,
if (flags & SPI_XFER_BEGIN)
sun4i_spi_set_cs(bus, slave_plat->cs, true);
- reg = readl(>regs->ctl);
-
/* Reset FIFOs */
- writel(reg | SUN4I_CTL_RF_RST | SUN4I_CTL_TF_RST, >regs->ctl);
+ setbits_le32(>regs->ctl, SUN4I_CTL_RF_RST | SUN4I_CTL_TF_RST);
while (len) {
/* Setup the transfer now... */
@@ -341,8 +337,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int
bitlen,
sun4i_spi_fill_fifo(priv, nbytes);
/* Start the transfer */
- reg = readl(>regs->ctl);
- writel(reg | SUN4I_CTL_XCH, >regs->ctl);
+ setbits_le32(>regs->ctl, SUN4I_CTL_XCH);
/* Wait till RX FIFO to be empty */
ret = readl_poll_timeout(>regs->ctl, rx_fifocnt,
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/10] spi: sun4i: Support fifo_depth via drvdata
Support fifo_depth via drvdata instead of macro definition, this would
eventually reduce another macro definition for new SPI controller fifo
depth support addition.
Signed-off-by: Jagan Teki
---
drivers/spi/sun4i_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index c06028890b..d3cf25db6f 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -33,8 +33,6 @@
#include
-#define SUN4I_FIFO_DEPTH 64
-
#define SUN4I_RXDATA_REG 0x00
#define SUN4I_TXDATA_REG 0x04
@@ -124,6 +122,7 @@ enum sun4i_spi_bits {
struct sun4i_spi_variant {
const unsigned long *regs, *bits;
+ u32 fifo_depth;
};
struct sun4i_spi_platdata {
@@ -363,7 +362,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int
bitlen,
while (len) {
/* Setup the transfer now... */
- nbytes = min(len, (u32)(SUN4I_FIFO_DEPTH - 1));
+ nbytes = min(len, (priv->variant->fifo_depth - 1));
/* Setup the counters */
writel(SUN4I_BURST_CNT(nbytes),
@@ -511,6 +510,7 @@ static const unsigned long sun4i_spi_bits[] = {
static const struct sun4i_spi_variant sun4i_a10_spi_variant = {
.regs = sun4i_spi_regs,
.bits = sun4i_spi_bits,
+ .fifo_depth = 64,
};
static const struct udevice_id sun4i_spi_ids[] = {
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/10] board: sopine: Enable SPI/SPI-FLASH
Sopine has Winbond SPI flash, so enable the same to use
flash on Sopine board.
Signed-off-by: Jagan Teki
---
arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi | 12
configs/sopine_baseboard_defconfig | 4
2 files changed, 16 insertions(+)
create mode 100644 arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
b/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
new file mode 100644
index 00..02b1ae046e
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Jagan Teki
+ */
+
+#include "sunxi-u-boot.dtsi"
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/configs/sopine_baseboard_defconfig
b/configs/sopine_baseboard_defconfig
index 9d7e3a2b6c..a94e3c21fd 100644
--- a/configs/sopine_baseboard_defconfig
+++ b/configs/sopine_baseboard_defconfig
@@ -10,11 +10,15 @@ CONFIG_MMC0_CD_PIN=""
CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_SPL_SPI_SUNXI=y
CONFIG_NR_DRAM_BANKS=1
+CONFIG_CMD_SF=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
# CONFIG_CMD_FLASH is not set
# CONFIG_SPL_DOS_PARTITION is not set
# CONFIG_SPL_EFI_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-sopine-baseboard"
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_WINBOND=y
CONFIG_SUN8I_EMAC=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/10] spi: sun4i: Access registers and bits via enum offsets
Allwinner support two different SPI controllers one for A10 and
another for A31 with minimal changes in register offsets and
respective register bits, but the logic for accessing the SPI
master via SPI slave remains nearly similar.
Add enum offsets for register set and register bits, so-that
it can access both classes of SPI controllers.
Assign same control register for global, transfer and fifo control
registers to make the same code compatible with A31 SPI controller.
Signed-off-by: Jagan Teki
---
drivers/spi/sun4i_spi.c | 162 +---
1 file changed, 120 insertions(+), 42 deletions(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 5446cebe7c..c06028890b 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -83,7 +83,6 @@
#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
#define SUN4I_FIFO_STA_REG 0x28
-#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
#define SUN4I_FIFO_STA_RF_CNT_BITS 0
#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
#define SUN4I_FIFO_STA_TF_CNT_BITS 16
@@ -93,28 +92,49 @@
#define SUN4I_SPI_DEFAULT_RATE 100
#define SUN4I_SPI_TIMEOUT_US 100
-/* sun4i spi register set */
-struct sun4i_spi_regs {
- u32 rxdata;
- u32 txdata;
- u32 ctl;
- u32 intctl;
- u32 st;
- u32 dmactl;
- u32 wait;
- u32 cctl;
- u32 bc;
- u32 tc;
- u32 fifo_sta;
+/* sun spi register set */
+enum sun4i_spi_regs {
+ SPI_GCR,
+ SPI_TCR,
+ SPI_FCR,
+ SPI_FSR,
+ SPI_CCR,
+ SPI_BC,
+ SPI_TC,
+ SPI_BCTL,
+ SPI_TXD,
+ SPI_RXD,
+};
+
+/* sun spi register bits */
+enum sun4i_spi_bits {
+ SPI_GCR_TP,
+ SPI_TCR_CPHA,
+ SPI_TCR_CPOL,
+ SPI_TCR_CS_ACTIVE_LOW,
+ SPI_TCR_CS_SEL,
+ SPI_TCR_CS_MASK,
+ SPI_TCR_XCH,
+ SPI_TCR_CS_MANUAL,
+ SPI_TCR_CS_LEVEL,
+ SPI_FCR_TF_RST,
+ SPI_FCR_RF_RST,
+ SPI_FSR_RF_CNT_MASK,
+};
+
+struct sun4i_spi_variant {
+ const unsigned long *regs, *bits;
};
struct sun4i_spi_platdata {
+ struct sun4i_spi_variant *variant;
u32 base_addr;
u32 max_hz;
};
struct sun4i_spi_priv {
- struct sun4i_spi_regs *regs;
+ struct sun4i_spi_variant *variant;
+ u32 base_addr;
u32 freq;
u32 mode;
@@ -126,10 +146,11 @@ DECLARE_GLOBAL_DATA_PTR;
static inline void sun4i_spi_drain_fifo(struct sun4i_spi_priv *priv, int len)
{
+ struct sun4i_spi_variant *variant = priv->variant;
u8 byte;
while (len--) {
- byte = readb(>regs->rxdata);
+ byte = readb(priv->base_addr + variant->regs[SPI_RXD]);
if (priv->rx_buf)
*priv->rx_buf++ = byte;
}
@@ -137,30 +158,33 @@ static inline void sun4i_spi_drain_fifo(struct
sun4i_spi_priv *priv, int len)
static inline void sun4i_spi_fill_fifo(struct sun4i_spi_priv *priv, int len)
{
+ struct sun4i_spi_variant *variant = priv->variant;
u8 byte;
while (len--) {
byte = priv->tx_buf ? *priv->tx_buf++ : 0;
- writeb(byte, >regs->txdata);
+ writeb(byte, priv->base_addr + variant->regs[SPI_TXD]);
}
}
static void sun4i_spi_set_cs(struct udevice *bus, u8 cs, bool enable)
{
struct sun4i_spi_priv *priv = dev_get_priv(bus);
+ struct sun4i_spi_variant *variant = priv->variant;
u32 reg;
- reg = readl(>regs->ctl);
+ reg = readl(priv->base_addr + variant->regs[SPI_TCR]);
- reg &= ~SUN4I_CTL_CS_MASK;
- reg |= SUN4I_CTL_CS(cs);
+ reg &= ~variant->bits[SPI_TCR_CS_MASK];
+ reg |= ((cs << variant->bits[SPI_TCR_CS_SEL]) &
+ variant->bits[SPI_TCR_CS_MASK]);
if (enable)
- reg &= ~SUN4I_CTL_CS_LEVEL;
+ reg &= ~variant->bits[SPI_TCR_CS_LEVEL];
else
- reg |= SUN4I_CTL_CS_LEVEL;
+ reg |= variant->bits[SPI_TCR_CS_LEVEL];
- writel(reg, >regs->ctl);
+ writel(reg, priv->base_addr + variant->regs[SPI_TCR]);
}
static int sun4i_spi_parse_pins(struct udevice *dev)
@@ -255,6 +279,7 @@ static int sun4i_spi_ofdata_to_platdata(struct udevice *bus)
int node = dev_of_offset(bus);
plat->base_addr = devfdt_get_addr(bus);
+ plat->variant = (struct sun4i_spi_variant *)dev_get_driver_data(bus);
plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
"spi-max-frequency",
SUN4I_SPI_DEFAULT_RATE);
@@ -273,7 +298,8 @@ static int sun4i_spi_probe(struct udevice *bus)
sun4i_spi_enable_clock();
sun4i_spi_parse_pins(bus);
- priv->regs = (struct sun4i_spi_regs *)(uintptr_t)plat->base_addr;
+ priv->variant = plat->variant;
+ priv->base_addr = plat->base_addr;
priv->freq = plat->max_hz;
[U-Boot] [PATCH 01/10] spi: sun4i: Poll for rxfifo empty
To drain rx fifo the fifo need to poll till the fifo
count become empty.
The current code is using wait_for_bit logic on control
register with exchange burst mode mask, which is not a
proper way of waiting for draining fifo.
So, add code for polling fifo status register till rxfifo
count become empty.
Signed-off-by: Jagan Teki
---
drivers/spi/sun4i_spi.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 38cc743c61..87b396a96e 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -31,6 +31,8 @@
#include
+#include
+
#define SUN4I_FIFO_DEPTH 64
#define SUN4I_RXDATA_REG 0x00
@@ -46,7 +48,6 @@
#define SUN4I_CTL_LMTF BIT(6)
#define SUN4I_CTL_TF_RST BIT(8)
#define SUN4I_CTL_RF_RST BIT(9)
-#define SUN4I_CTL_XCH_MASK 0x0400
#define SUN4I_CTL_XCH BIT(10)
#define SUN4I_CTL_CS_MASK 0x3000
#define SUN4I_CTL_CS(cs) (((cs) << 12) & SUN4I_CTL_CS_MASK)
@@ -308,7 +309,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int
bitlen,
struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
u32 len = bitlen / 8;
- u32 reg;
+ u32 reg, rx_fifocnt;
u8 nbytes;
int ret;
@@ -343,10 +344,12 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned
int bitlen,
reg = readl(>regs->ctl);
writel(reg | SUN4I_CTL_XCH, >regs->ctl);
- /* Wait transfer to complete */
- ret = wait_for_bit_le32(>regs->ctl, SUN4I_CTL_XCH_MASK,
- false, SUN4I_SPI_TIMEOUT_US, false);
- if (ret) {
+ /* Wait till RX FIFO to be empty */
+ ret = readl_poll_timeout(>regs->ctl, rx_fifocnt,
+!(((rx_fifocnt &
SUN4I_FIFO_STA_RF_CNT_MASK) >>
+SUN4I_FIFO_STA_RF_CNT_BITS) < nbytes),
+SUN4I_SPI_TIMEOUT_US);
+ if (ret < 0) {
printf("ERROR: sun4i_spi: Timeout transferring data\n");
sun4i_spi_set_cs(bus, slave_plat->cs, false);
return ret;
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/10] clk: sunxi: Implement SPI clocks, resets
- Implement SPI AHB, MOD clocks via ccu_clk_gate for all
supported Allwinner SoCs
- Implement SPI resets via ccu_reset for all supported
Allwinner SoCs.
Signed-off-by: Jagan Teki
---
drivers/clk/sunxi/clk_a10.c | 10 ++
drivers/clk/sunxi/clk_a10s.c | 7 +++
drivers/clk/sunxi/clk_a23.c | 7 +++
drivers/clk/sunxi/clk_a31.c | 13 +
drivers/clk/sunxi/clk_a64.c | 7 +++
drivers/clk/sunxi/clk_a80.c | 13 +
drivers/clk/sunxi/clk_a83t.c | 7 +++
drivers/clk/sunxi/clk_h3.c | 7 +++
drivers/clk/sunxi/clk_h6.c | 9 +
drivers/clk/sunxi/clk_r40.c | 13 +
drivers/clk/sunxi/clk_v3s.c | 4
11 files changed, 97 insertions(+)
diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index 2aa41efe17..b8b57e2b31 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -22,6 +22,10 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_MMC1] = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2] = GATE(0x060, BIT(10)),
[CLK_AHB_MMC3] = GATE(0x060, BIT(11)),
+ [CLK_AHB_SPI0] = GATE(0x060, BIT(20)),
+ [CLK_AHB_SPI1] = GATE(0x060, BIT(21)),
+ [CLK_AHB_SPI2] = GATE(0x060, BIT(22)),
+ [CLK_AHB_SPI3] = GATE(0x060, BIT(23)),
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
@@ -32,9 +36,15 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
[CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
+ [CLK_SPI0] = GATE(0x0a0, BIT(31)),
+ [CLK_SPI1] = GATE(0x0a4, BIT(31)),
+ [CLK_SPI2] = GATE(0x0a8, BIT(31)),
+
[CLK_USB_OHCI0] = GATE(0x0cc, BIT(6)),
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(7)),
[CLK_USB_PHY] = GATE(0x0cc, BIT(8)),
+
+ [CLK_SPI3] = GATE(0x0d4, BIT(31)),
};
static struct ccu_reset a10_resets[] = {
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
index 87b74e52dc..c6fcede822 100644
--- a/drivers/clk/sunxi/clk_a10s.c
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -19,12 +19,19 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_AHB_MMC0] = GATE(0x060, BIT(8)),
[CLK_AHB_MMC1] = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2] = GATE(0x060, BIT(10)),
+ [CLK_AHB_SPI0] = GATE(0x060, BIT(20)),
+ [CLK_AHB_SPI1] = GATE(0x060, BIT(21)),
+ [CLK_AHB_SPI2] = GATE(0x060, BIT(22)),
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
[CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
[CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
+ [CLK_SPI0] = GATE(0x0a0, BIT(31)),
+ [CLK_SPI1] = GATE(0x0a4, BIT(31)),
+ [CLK_SPI2] = GATE(0x0a8, BIT(31)),
+
[CLK_USB_OHCI] = GATE(0x0cc, BIT(6)),
[CLK_USB_PHY0] = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1] = GATE(0x0cc, BIT(9)),
diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
index 1ef2359286..c16019215e 100644
--- a/drivers/clk/sunxi/clk_a23.c
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -16,6 +16,8 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_MMC0] = GATE(0x060, BIT(8)),
[CLK_BUS_MMC1] = GATE(0x060, BIT(9)),
[CLK_BUS_MMC2] = GATE(0x060, BIT(10)),
+ [CLK_BUS_SPI0] = GATE(0x060, BIT(20)),
+ [CLK_BUS_SPI1] = GATE(0x060, BIT(21)),
[CLK_BUS_OTG] = GATE(0x060, BIT(24)),
[CLK_BUS_EHCI] = GATE(0x060, BIT(26)),
[CLK_BUS_OHCI] = GATE(0x060, BIT(29)),
@@ -26,6 +28,9 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
[CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
+ [CLK_SPI0] = GATE(0x0a0, BIT(31)),
+ [CLK_SPI1] = GATE(0x0a4, BIT(31)),
+
[CLK_USB_PHY0] = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1] = GATE(0x0cc, BIT(9)),
[CLK_USB_HSIC] = GATE(0x0cc, BIT(10)),
@@ -41,6 +46,8 @@ static struct ccu_reset a23_resets[] = {
[RST_BUS_MMC0] = RESET(0x2c0, BIT(8)),
[RST_BUS_MMC1] = RESET(0x2c0, BIT(9)),
[RST_BUS_MMC2] = RESET(0x2c0, BIT(10)),
+ [RST_BUS_SPI0] = RESET(0x2c0, BIT(20)),
+ [RST_BUS_SPI1] = RESET(0x2c0, BIT(21)),
[RST_BUS_OTG] = RESET(0x2c0, BIT(24)),
[RST_BUS_EHCI] = RESET(0x2c0, BIT(26)),
[RST_BUS_OHCI] = RESET(0x2c0, BIT(29)),
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index 5bd8b7dccc..fa6e3eeef0 100644
---
[U-Boot] [PATCH 00/10] spi: Add Allwinner A31 SPI driver
This series add support for Allwinner A31 SPI controller driver. Compared to previous version[1] separate driver for A31, this patchset is trying to tune the existing sun4i_spi code by adding register set, register bits to support both A10, A31 SPI controllers. Any inputs? Jagan. Jagan Teki (10): spi: sun4i: Poll for rxfifo empty clk: sunxi: Implement SPI clocks, resets spi: sun4i: Simplify reg writes using set/clrbits_le32 spi: sun4i: Access registers and bits via enum offsets spi: sun4i: Support fifo_depth via drvdata spi: sun4i: Add CLK support spi: sun4: Add A31 spi controller support spi: sun4i: Driver cleanup spi: kconfig: Enable SUN4I_SPI by default if ARCH_SUNXI board: sopine: Enable SPI/SPI-FLASH .../sun50i-a64-sopine-baseboard-u-boot.dtsi | 12 + configs/sopine_baseboard_defconfig| 4 + drivers/clk/sunxi/clk_a10.c | 10 + drivers/clk/sunxi/clk_a10s.c | 7 + drivers/clk/sunxi/clk_a23.c | 7 + drivers/clk/sunxi/clk_a31.c | 13 + drivers/clk/sunxi/clk_a64.c | 7 + drivers/clk/sunxi/clk_a80.c | 13 + drivers/clk/sunxi/clk_a83t.c | 7 + drivers/clk/sunxi/clk_h3.c| 7 + drivers/clk/sunxi/clk_h6.c| 9 + drivers/clk/sunxi/clk_r40.c | 13 + drivers/clk/sunxi/clk_v3s.c | 4 + drivers/spi/Kconfig | 5 +- drivers/spi/sun4i_spi.c | 436 -- 15 files changed, 418 insertions(+), 136 deletions(-) create mode 100644 arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
On Sun, Jan 27, 2019 at 04:34:05PM +0200, Igor Opaniuk wrote: > AVB version 1.1 introduces support for named persistent values > that must be tamper evident and allows AVB to store arbitrary key-value > pairs [1]. > > Introduce implementation of two additional AVB operations > read_persistent_value()/write_persistent_value() for retrieving/storing > named persistent values. > > Correspondent pull request in the OP-TEE OS project repo [2]. > > [1]: > https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22 > [2]: https://github.com/OP-TEE/optee_os/pull/2699 > > Signed-off-by: Igor Opaniuk > Reviewed-by: Simon Glass The test fails on some sandbox targets: https://travis-ci.org/trini/u-boot/jobs/490809872 -- 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] [PULL] u-boot-sh/master
On Sat, Feb 09, 2019 at 11:04:15AM +0100, Marek Vasut wrote:
> On 2/9/19 1:17 AM, Tom Rini wrote:
> > On Fri, Feb 08, 2019 at 11:19:46AM +0100, Marek Vasut wrote:
> >
> >> SD/MMC and filesystem fixes below ...
> >>
> >> The following changes since commit
> >> e5fd39c886485e3dec77f4438a6e364c2987cf5f:
> >>
> >> Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip
> >> (2019-02-02 10:11:20 -0500)
> >>
> >> are available in the Git repository at:
> >>
> >> git://git.denx.de/u-boot-sh.git master
> >>
> >> for you to fetch changes up to 49f331023e1d6f804c4226b862af1f2a05a2ea2e:
> >>
> >> fs: ext4: Unmount FS in do_fs_type() (2019-02-06 14:07:12 +0100)
> >>
> >
> > NAK. The change:
> > commit 09a89b86d48a19598750f05f69412ec9ddbefba4
> > Author: Marek Vasut
> > Date: Tue Jan 29 04:45:51 2019 +0100
> >
> > mmc: Export {sd,mmc}_select_mode_and_width()
> >
> > breaks pine_h64 as SPL now overflows sram by 104 bytes.
>
> How is that even possible ?
OK, lets hack sunxi until it links again with these new functions, and
then use buildman to report code growth:
spl-u-boot-spl: add: 2/0, grow: 0/-1 bytes: 1264/-1100 (164)
function old new delta
sd_select_mode_and_width - 696+696
mmc_select_mode_and_width- 568+568
mmc_init 22801180 -1100
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] mtd: spi: Kconfig: Select SPI_FLASH if DM_SPI_FLASH
DM_SPI_FLASH should require spi flash interface code for dm version, so select SPI_FLASH core by default if any board enabled DM_SPI_FLASH. This overcome the explicit enablement of CONFIG_SPI_FLASH on respective boards when DM_SPI_FLASH being used. Cc: Vignesh R Signed-off-by: Jagan Teki --- drivers/mtd/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index 605f60c713..43f597ec29 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -3,6 +3,7 @@ menu "SPI Flash Support" config DM_SPI_FLASH bool "Enable Driver Model for SPI flash" depends on DM && DM_SPI + select SPI_FLASH help Enable driver model for SPI flash. This SPI flash interface (spi_flash_probe(), spi_flash_write(), etc.) is then -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] mtd: spi: Kconfig: Update CONFIG_SPI_FLASH
1) CONFIG_SPI_FLASH is not just a legacy code, but it has common core code which handle both dm and non-dm spi flash code. So fix the info text to make it clear globally. 2) Since it's flash core it shouldn't depends on legacy SPI, so remove the 'depends on SPI' Cc: Vignesh R Signed-off-by: Jagan Teki --- drivers/mtd/spi/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index e3b40fc157..605f60c713 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -26,11 +26,10 @@ config SPI_FLASH_SANDBOX stored in a file on the host filesystem. config SPI_FLASH - bool "Legacy SPI Flash Interface support" - depends on SPI + bool "SPI Flash Core Interface support" select SPI_MEM help - Enable the legacy SPI flash support. This will include basic + Enable the SPI flash Core support. This will include basic standard support for things like probing, read / write, and erasing through cmd_sf interface. -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] spi: Kconfig: Mark CONFIG_SPI as Legacy spi support
CONFIG_SPI is mandatory for SPI support even if the given board has dm or non-dm versions, so mark CONFIG_SPI as non-dm config option and move the respective non-dm drivers below to that. This eventually reduce the explicit CONFIG_SPI enablement for dm version spi drivers. Cc: Vignesh R Signed-off-by: Jagan Teki --- drivers/spi/Kconfig | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 2fb4862c4a..bed279cbc4 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -1,7 +1,4 @@ -menuconfig SPI - bool "SPI Support" - -if SPI +menu "SPI Support" config DM_SPI bool "Enable Driver Model for SPI drivers" @@ -294,6 +291,14 @@ config ZYNQMP_GQSPI endif # if DM_SPI +config SPI + bool "Legacy SPI support" + help + Enable the legacy SPI support. This will include legacy SPI + interface code for non-dm SPI drivers. + +if SPI + config SOFT_SPI bool "Soft SPI driver" help @@ -387,4 +392,6 @@ config OMAP3_SPI (McSPI). This driver be used to access SPI chips on platforms embedding this OMAP3 McSPI IP core. -endif # menu "SPI Support" +endif # if SPI + +endmenu # menu "SPI Support" -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken
Hello Simon, hello Philipp, since patch Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip e5fd39c886485e3dec77f4438a6e364c2987cf5f booting on the Tinker Board (tinker-rk3288_defconfig) is broken. There is not even any UART output from SPL. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM
On Sat, Feb 9, 2019 at 11:25 AM Marek Vasut wrote: > > On 2/7/19 10:23 PM, Simon Goldschmidt wrote: > > To clean up reset handling for socfpga gen5, let's move the code snippet > > taking the DDR controller out of reset from SPL to the DDR driver. > > > > While at it, port the ddr driver to UCLASS_RAM and use dts. > > > > Signed-off-by: Simon Goldschmidt > > --- > > > > This is an RFC to show what the SDRAM driver moved to DM (UCLASS_RAM) would > > look like. It's RFC both because Dinh did not seem too fond of changing the > > register address of the SDR in devicetree to include what the undocumented > > registers 'sequencer.c' uses as well as because of my observed code growth. > > Dinh, if the SDRAM controller spans some addresses, it should be > described like so in the DT. Whether those registers are documented or > not does not matter, DT is a hardware description and should describe > hardware accurately. > > > Basically, I want to move this to UCLASS_RAM and I want to read the reset > > property for SDR from devicetree. What remains RFC is: do we want/need to > > read the base address from devicetree, or can we live with it being hard- > > coded (and maybe sanity-checked during probe)? > > > > Note that converting sequencer.c from hard-coded address to pointers read > > from devicetree and passed around to every function increased code size by > > ~700 bytes. Not too much, but enough to stop my socrates board working > > (yes, the SPL size check does not work :-( - I'll work on that). > > > > Also note that this is an integrated patch for SoCrates to show what it > > would look like. In the series I prepared, it's better separated and all > > boards are adjusted. > > I wonder, rather than passing $sdr around, could we have a static $sdr > and support only one single instance of the DRAM controller ? Would that > trim down the size growth ? Let me check that. It's worth trying. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM
On 2/8/19 11:51 PM, Dalon L Westergreen wrote: > On Fri, 2019-02-08 at 21:36 +0100, Simon Goldschmidt wrote: >> >> >> Am Fr., 8. Feb. 2019, 21:28 hat Dalon L Westergreen < >> dalon.westergr...@linux.intel.com> geschrieben: >>> On Thu, 2019-02-07 at 22:23 +0100, Simon Goldschmidt wrote: To clean up reset handling for socfpga gen5, let's move the code snippet taking the DDR controller out of reset from SPL to the DDR driver. While at it, port the ddr driver to UCLASS_RAM and use dts. Signed-off-by: Simon Goldschmidt --- This is an RFC to show what the SDRAM driver moved to DM (UCLASS_RAM) >>> would look like. It's RFC both because Dinh did not seem too fond of changing >>> the register address of the SDR in devicetree to include what the undocumented registers 'sequencer.c' uses as well as because of my observed code >>> growth. Basically, I want to move this to UCLASS_RAM and I want to read the reset property for SDR from devicetree. What remains RFC is: do we want/need to read the base address from devicetree, or can we live with it being hard- coded (and maybe sanity-checked during probe)? >>> >>> My 2 cents, i love the idea of moving all of the socfgpa sdram code to DM. >>> Looking at the code, i would suggest that we should handle the case where >>> there is no HPS sdram controller, and instead an FPGA based controller is >>> used. Although not common, it is a use case i have seen repeatedly. >> >> While I haven't used it like that (I did use an FPGA RAM controller, but that >> was with a NIOS and not Linux, not HPS), I guess it should work with my >> changed. Just disable the 'sdr' node in the devicetree. You'll need a driver >> for the FPGA based RAM controller though. >> >> Or, in the setup you mentioned, would the existing driver be the same? I.e. >> just use a different base address? Or is it a different IP? > > All you need is to have the h2f bridge enabled during the boot. We used to do > this for you if spl found that the FPGA was already configured. On the FPGA > side, a nios in the ddr controller runs the ddr calibration code. This is stratix10 you're talking about, isn't it ? I recall S10 has nios2 hard block to start up the DRAM, but Gen5 and A10 do not have that, do they ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On 2/9/19 1:17 AM, Tom Rini wrote:
> On Fri, Feb 08, 2019 at 11:19:46AM +0100, Marek Vasut wrote:
>
>> SD/MMC and filesystem fixes below ...
>>
>> The following changes since commit e5fd39c886485e3dec77f4438a6e364c2987cf5f:
>>
>> Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip
>> (2019-02-02 10:11:20 -0500)
>>
>> are available in the Git repository at:
>>
>> git://git.denx.de/u-boot-sh.git master
>>
>> for you to fetch changes up to 49f331023e1d6f804c4226b862af1f2a05a2ea2e:
>>
>> fs: ext4: Unmount FS in do_fs_type() (2019-02-06 14:07:12 +0100)
>>
>
> NAK. The change:
> commit 09a89b86d48a19598750f05f69412ec9ddbefba4
> Author: Marek Vasut
> Date: Tue Jan 29 04:45:51 2019 +0100
>
> mmc: Export {sd,mmc}_select_mode_and_width()
>
> breaks pine_h64 as SPL now overflows sram by 104 bytes.
How is that even possible ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
