Re: [U-Boot] [linux-sunxi] Re: [PATCH 3/5] sunxi: add 3GiB DRAM detection support in main U-Boot
在 2018-02-08 08:37，André Przywara 写道：
On 07/02/18 19:35, Icenowy Zheng wrote:
Hi,
Some Allwinner SoCs can use 3GiB DRAM (part of 4GiB or larger module).
As the common get_ram_size function cannot detect non-pow-of-2 memory,
add special detect code into the DRAM size code in main U-Boot.
The original get_ram_size() function is slightly dodgy already (as it
probes memory by writing). And in general we will never be able to
cover
ARMv7/LPAE machines easily with our current static identify mapping -
regardless of any probing hacks we pull up.
So I was wondering if we could either:
- somehow pass the result of sunxi_dram_init() to U-Boot proper, or
- call the DRAM size determination routine again
This would give us the definite answer, and would be correct in every
case. We just need to limit it to the memory map limit, if any.
Okay. Let me try.
But his function below looks really like a hack. If at all, it should
be
part of the get_ram_size() routine itself, as this is not sunxi
specific.
This hack is too immature to be a common hack, it just consider 4GiB as
3GiB,
so it's still a sunxi specific hack.
Cheers,
Andre.
Signed-off-by: Icenowy Zheng
---
board/sunxi/board.c| 23 +++
include/configs/sunxi-common.h | 2 +-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 8891961dcc..8d707cbac2 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -256,7 +256,30 @@ int board_init(void)
int dram_init(void)
{
+#if PHYS_SDRAM_0_SIZE == (SZ_2G + SZ_1G)
+ /*
+ * get_ram_size() doesn't support non-pow-of-2 sizes, so the
detection
+* of 3GiB DRAM is implemented here.
+* It just checks whether the DRAM is bigger than 2GiB, as the DRAM
+* module is usually 4GiB in this case (and 1GiB is not accessible).
+*/
+ u32 save_0, save_2g;
+ gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, SZ_2G);
+ if (gd->ram_size == SZ_2G) {
+ save_0 = readl(PHYS_SDRAM_0);
+ save_2g = readl(PHYS_SDRAM_0 + SZ_2G);
+ writel(0, PHYS_SDRAM_0);
+ writel(0xaa55aa55, PHYS_SDRAM_0 + SZ_2G);
+ dsb();
+ if (readl(PHYS_SDRAM_0) != readl(PHYS_SDRAM_0 + SZ_2G)) {
+ gd->ram_size = SZ_2G + SZ_1G;
+ writel(save_2g, PHYS_SDRAM_0 + SZ_2G);
+ }
+ writel(save_0, PHYS_SDRAM_0);
+ }
+#else
gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0,
PHYS_SDRAM_0_SIZE);
+#endif
return 0;
}
diff --git a/include/configs/sunxi-common.h
b/include/configs/sunxi-common.h
index 9b3944ad13..177647e009 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -111,7 +111,7 @@
#define CONFIG_NR_DRAM_BANKS 1
#define PHYS_SDRAM_0 CONFIG_SYS_SDRAM_BASE
-#define PHYS_SDRAM_0_SIZE 0x8000 /* 2 GiB */
+#define PHYS_SDRAM_0_SIZE CONFIG_SUNXI_DRAM_MAX_SIZE
#ifdef CONFIG_AHCI
#define CONFIG_SCSI_AHCI_PLAT
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] Enable test case with A20-OLinuXino-Lime2
On Thu, Feb 8, 2018 at 11:54 AM, Stefan Mavrodiev
wrote:
> On 02/07/2018 07:19 PM, Maxime Ripard wrote:
>>
>> On Wed, Feb 07, 2018 at 12:55:54PM +0530, Jagan Teki wrote:
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins_b>, <&spi0_cs0_pins_b>;
+ status = "okay";
+
+ flash: w25q128@0 {
>>>
>>> Was it sync from Linux?
>>
>> No, this isn't in the linux dts.
>
> But we have to, please send it to Linux first.
We've already commented this issue. In the v2 [1], I've explained that
this
won't go mainline, since it's optional feature. Rather it will be
managed
with overlays.
>>>
>>> Thought this was already in ML, and ready to merge. So this never go
>>> to Linux tree since it's optional? then add u-boot.dtsi for this
>>> atleast since we always sync dts from Linux.
>>
>> This is an optional feature on that board. We should be making it as
>> easy as possible to enable it, but a defconfig is a *default*
>> configuration, and if the board doesn't have it by default, it
>> shouldn't be enabled in the defconfig.
>>
>> Maxime
>>
> Sorry, but I'm really confused. In the first patch Jagan said to make
> separate patch
> "just to test" the driver. Then I've made patch "just to test", and it's
> turn out it wasn't not OK,
> because it should be compatible with linux, u-boot and etc. What's the point
> since it's just for testing...?
>
> Sorry again, but can someone explain to me, that to do?
> I'm not trying to pick on you guys. Just want to do the right thing.
I think we're in out-of-sync for some reason.
Here is my suggestion:
Since it is "optional feature however similar boards of this type
could not have it"?
How about separate defconfig file?
A20-OLinuXino-Lime2-spinor_defconfig and have same dts file with
/* Disable SPI NOR by default: it optional on A20-OLinuXino-Lime2 boards */
status = "disabled";
But the dts should accept by Linux as well.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] sunxi: let sunxi_dram_init return unsigned long long
在 2018-02-08 08:37，André Przywara 写道：
On 07/02/18 19:35, Icenowy Zheng wrote:
Hi,
As 4GiB capacity is above the range of 32-bit unsigned integer, raise
the return type of sunxi_dram_init() to unsigned long long, thus it
can
hold 4GiB capacity (or maybe more on A80).
Some controllers that are possible to use 4GiB+ memory module are
also changed to calculate its memory capacity in unsigned long long.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/dram.h | 2 +-
arch/arm/mach-sunxi/dram_sun6i.c | 2 +-
arch/arm/mach-sunxi/dram_sun8i_a23.c | 2 +-
arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
arch/arm/mach-sunxi/dram_sun8i_a83t.c | 2 +-
arch/arm/mach-sunxi/dram_sun9i.c | 4 ++--
arch/arm/mach-sunxi/dram_sunxi_dw.c| 4 ++--
board/sunxi/board.c| 2 +-
board/sunxi/dram_sun4i_auto.c | 2 +-
board/sunxi/dram_sun5i_auto.c | 2 +-
10 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
b/arch/arm/include/asm/arch-sunxi/dram.h
index 80abac95b8..d08b82371d 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -32,7 +32,7 @@
#include
#endif
-unsigned long sunxi_dram_init(void);
+unsigned long long sunxi_dram_init(void);
Since this is explicitly about > 4GB/32 bits, I would suggest we just
use uint64_t here, instead of guessing what long long means.
Seems OK. But is there any sure suffix for uint64_t? For unsigned long
long we can use ULL.
But can't we just change the semantics of sunxi_dram_init() to return
megabytes instead? sun9i already uses this internally, and just blows
it
up in the wrapper. I don't think we have anything with a granularity
smaller than 1MB?
Then we could just leave it at native bit size, and spare poor ARMv7
from struggling with 64 bit arithmetic.
The calculated size is just in byte.
The A80 code first shifted it to MiB in DRAMC_get_dram_size() and then
shifted it back to B in sunxi_dram_init(); however the code that shifts
it to MiB only applies to drivers which have shift operation.
The other target driver, dram_sunxi_dw, uses both bit shifts and
multiply
when calculating the size, and to have 4096MiB value we still need to
calculate the byte value as uint64_t and then shift it to MiB value.
(The multiply value can get as high as 4096, so it's highly possible
that the shift value could be less than 20.)
I think keeping the return value as byte will make the code more clear.
Cheers,
Andre.
void mctl_await_completion(u32 *reg, u32 mask, u32 val);
bool mctl_mem_matches(u32 offset);
diff --git a/arch/arm/mach-sunxi/dram_sun6i.c
b/arch/arm/mach-sunxi/dram_sun6i.c
index 5dbbf6186f..bdf52a2c38 100644
--- a/arch/arm/mach-sunxi/dram_sun6i.c
+++ b/arch/arm/mach-sunxi/dram_sun6i.c
@@ -326,7 +326,7 @@ static void mctl_port_cfg(void)
writel(0x0307, &mctl_com->mbagcr[5]);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun8i_a23.c
b/arch/arm/mach-sunxi/dram_sun8i_a23.c
index c53671a0e9..169ccff41a 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a23.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a23.c
@@ -264,7 +264,7 @@ static void mctl_init(u32 *bus_width)
writel(0x, &mctl_ctl->rfshctl3);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c
b/arch/arm/mach-sunxi/dram_sun8i_a33.c
index fa1620cb39..dfbbe6f39c 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
@@ -325,7 +325,7 @@ static void mctl_sys_init(struct dram_para *para)
udelay(250);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun8i_a83t.c
b/arch/arm/mach-sunxi/dram_sun8i_a83t.c
index 55df1b9d54..ec4bccd635 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a83t.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a83t.c
@@ -423,7 +423,7 @@ static void mctl_sys_init(struct dram_para *para)
udelay(250);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun9i.c
b/arch/arm/mach-sunxi/dram_sun9i.c
index 8c681f3541..dcb20f763e 100644
--- a/arch/arm/mach-sunxi/dram_sun9i.c
+++ b/arch/arm/mach-sunxi/dram_sun9i.c
@@ -854,7 +854,7 @@ signed int DRAMC_get_dram_size(void)
return 1 << dram_size;
Re: [U-Boot] [linux-sunxi] Re: [PATCH 2/5] sunxi: add Kconfig option for the maximum accessible DRAM
在 2018-02-08 10:14，Chen-Yu Tsai 写道： On Thu, Feb 8, 2018 at 8:35 AM, André Przywara wrote: On 07/02/18 19:35, Icenowy Zheng wrote: Allwinner 64-bit SoCs can use 4GiB DRAM chip, however their memory map has only allocated 3GiB for DRAM, so only 3GiB of the DRAM is accessible. Add a Kconfig option for the maximum accessible DRAM. That looks fine to me, but have you checked CONFIG_MAX_MEM_MAPPED? get_effective_memsize() in common/memsize.c looks like it's solving this very problem. get_effective_memsize() restricts memory size from gd->ram_size. gd->ram_size is defined as phys_size_t, which should be 32-bit on Allwinner SoCs except A80. (Although currently CONFIG_ARM64 selects CONFIG_PHYS_64BIT which makes phys_size_t 64-bit, the high 32-bit doesn't physically exist on those SoCs, and it's possible for a 32-bit SoC with 3GiB DRAM space to appear). A 32-bit data type cannot store a size of 4GiB. This is the first reason that I doesn't rely on get_effective_memsize(). For A80 it should be a much higher value (8GiB), but as I have no A80 device to test and originally U-Boot only supports 2GiB DRAM on A80, it currently still falls under the 2GiB situation. Well, that depends on how we will use SUNXI_DRAM_SIZE. If that's to limit the size we eventually report in the DT, that should be indeed 8GB on the A80. But U-Boot itself can't use more than 3GB on sunxi/ARMv7 (due to the static 1:1 mapping). I think we should separate those two numbers (actual DRAM size and U-Boot's own DRAM size), if we really want to support >3GB on the A80. Yes, and the CONFIG_MAX_MEM_MAPPED should be used in A80 case, and the CONFIG_PHYS_64BIT option should be selected, as the internal bus of A80 is bigger than 4GiB. So that the meaning of CONFIG_MAX_MEM_MAPPED is "maximum memory mapped in U-Boot", in A80 case only 3.5G is mapped in U-Boot, but Linux can use the other 4.5G. (In this case another U-Boot stage code that doesn't scan DRAM size but calculate it from memory controller is needed.) In A64/H5/H6 case the whole 3G accessible memory is mapped to U-Boot, and there's no memory that U-Boot cannot access but some other software can. So the gd->ram_size should be restricted at 3GiB. (The 1GiB is installed to the system, but it's not part of the system memory due to it's totally not accessible.) But maybe we should not get carried away by something that doesn't really exist. That was the first thing that popped up in my mind after seeing this series. A80 supports LPAE. However, the A80 is out of production, and no one produced any boards with more than 2GB of RAM. So >3GB on sunxi is going to go untested for a long time, if not forever. ChenYu Thanks, Andre. Signed-off-by: Icenowy Zheng --- arch/arm/mach-sunxi/Kconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 1fededd0a3..32739e0f33 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -63,6 +63,13 @@ config MACH_SUNXI_H3_H5 select SUNXI_GEN_SUN6I select SUPPORT_SPL +# TODO: try out A80's 8GiB DRAM space +config SUNXI_DRAM_MAX_SIZE + hex + default 0xC000 if MACH_SUN50I + default 0xC000 if MACH_SUN50I_H5 + default 0x8000 + choice prompt "Sunxi SoC Variant" optional -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mtd: ubi: Fix worker handling
From: Richard Weinberger
Fixes a bug found on thuban boards, which were for 2 years in
a long-term test with varying temperatures. They showed
problems in u-boot when attaching the ubi partition:
U-Boot# run flash_self_test
Booting from nand
set A...
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
data abort
pc : [<87f97c3c>] lr : [<87f97c28>]
reloc pc : [<8012cc3c>]lr : [<8012cc28>]
sp : 85f686e8 ip : 0020 fp : 01f7
r10: 8605ce40 r9 : 85f68ef8 r8 : 0001f000
r7 : 0001 r6 : 0006 r5 : 0001f000 r4 : 85f6ecc0
r3 : r2 : 44e35000 r1 : 87fcbcd4 r0 : 87fc755b
Flags: nZCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
Reason is, that accidentially the U-Boot implementation
from __schedule_ubi_work() did not check the flag
ubi->thread_enabled and started with wearleveling work,
but ubi did not have setup all structures at this point
and crashes.
Solve this problem by splitting work scheduling and processing.
Signed-off-by: Richard Weinberger
Signed-off-by: Heiko Schocher
---
drivers/mtd/ubi/build.c | 10 +-
drivers/mtd/ubi/ubi.h | 2 +-
drivers/mtd/ubi/wl.c| 53 +++--
3 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index baf4e2d25b..d81bd434ac 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -1060,15 +1060,7 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
#ifndef __UBOOT__
wake_up_process(ubi->bgt_thread);
#else
- /*
-* U-Boot special: We have no bgt_thread in U-Boot!
-* So just call do_work() here directly.
-*/
- err = do_work(ubi);
- if (err) {
- ubi_err(ubi, "%s: work failed with error code %d",
- ubi->bgt_name, err);
- }
+ ubi_do_worker(ubi);
#endif
spin_unlock(&ubi->wl_lock);
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index 540f721e1b..3337201fb0 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -1119,6 +1119,6 @@ static inline int idx2vol_id(const struct ubi_device
*ubi, int idx)
}
#ifdef __UBOOT__
-int do_work(struct ubi_device *ubi);
+void ubi_do_worker(struct ubi_device *ubi);
#endif
#endif /* !__UBI_UBI_H__ */
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index e823ca56f2..0de2a4a5f8 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -191,11 +191,7 @@ static void wl_entry_destroy(struct ubi_device *ubi,
struct ubi_wl_entry *e)
* This function returns zero in case of success and a negative error code in
* case of failure.
*/
-#ifndef __UBOOT__
static int do_work(struct ubi_device *ubi)
-#else
-int do_work(struct ubi_device *ubi)
-#endif
{
int err;
struct ubi_work *wrk;
@@ -528,6 +524,33 @@ repeat:
spin_unlock(&ubi->wl_lock);
}
+#ifdef __UBOOT__
+void ubi_do_worker(struct ubi_device *ubi)
+{
+ int err;
+
+ if (list_empty(&ubi->works) || ubi->ro_mode ||
+ !ubi->thread_enabled || ubi_dbg_is_bgt_disabled(ubi))
+ return;
+
+ spin_lock(&ubi->wl_lock);
+ while (!list_empty(&ubi->works)) {
+ /*
+* call do_work, which executes exactly one work form the queue,
+* including removeing it from the work queue.
+*/
+ spin_unlock(&ubi->wl_lock);
+ err = do_work(ubi);
+ spin_lock(&ubi->wl_lock);
+ if (err) {
+ ubi_err(ubi, "%s: work failed with error code %d",
+ ubi->bgt_name, err);
+ }
+ }
+ spin_unlock(&ubi->wl_lock);
+}
+#endif
+
/**
* __schedule_ubi_work - schedule a work.
* @ubi: UBI device description object
@@ -545,17 +568,6 @@ static void __schedule_ubi_work(struct ubi_device *ubi,
struct ubi_work *wrk)
#ifndef __UBOOT__
if (ubi->thread_enabled && !ubi_dbg_is_bgt_disabled(ubi))
wake_up_process(ubi->bgt_thread);
-#else
- int err;
- /*
-* U-Boot special: We have no bgt_thread in U-Boot!
-* So just call do_work() here directly.
-*/
- err = do_work(ubi);
- if (err) {
- ubi_err(ubi, "%s: work failed with error code %d",
- ubi->bgt_name, err);
- }
#endif
spin_unlock(&ubi->wl_lock);
}
@@ -610,6 +622,10 @@ static int schedule_erase(struct ubi_device *ubi, struct
ubi_wl_entry *e,
wl_wrk->torture = torture;
schedule_ubi_work(ubi, wl_wrk);
+
+#ifdef __UBOOT__
+ ubi_do_worker(ubi);
+#endif
return 0;
}
@@ -1011,8 +1027,15 @@ static int ensure_wear_leveling(struct ubi_device *ubi,
int nested)
wrk->func = &wear_leveling_worker;
if (nested)
__schedule_ubi_work(ubi, wrk);
+#ifndef __UBOOT__
else
schedule_ubi_work(ubi, wrk);
+#else
+
Re: [U-Boot] [PATCH v2] Kconfig: Select networking commands only when NET is enabled
Hi Michal, On Wednesday 07 February 2018 01:14 PM, Michal Simek wrote: > Hi Lokesh, > > On 6.2.2018 13:28, Michal Simek wrote: >> There is no reason to unconditially select network commands as distro >> defaults without networking enable. >> >> Signed-off-by: Michal Simek >> --- >> >> Changes in v2: >> - Use if NET instead of imply (suggested by Tom) >> - Change patch subject and description >> >> Kconfig | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/Kconfig b/Kconfig >> index f713c6a9b188..166e7841b11f 100644 >> --- a/Kconfig >> +++ b/Kconfig >> @@ -69,14 +69,14 @@ config DISTRO_DEFAULTS >> imply USE_BOOTCOMMAND >> select CMD_BOOTZ if ARM && !ARM64 >> select CMD_BOOTI if ARM64 >> -select CMD_DHCP >> -select CMD_PXE >> +select CMD_DHCP if NET >> +select CMD_PXE if NET >> select CMD_EXT2 >> select CMD_EXT4 >> select CMD_FAT >> select CMD_FS_GENERIC >> -select CMD_MII >> -select CMD_PING >> +select CMD_MII if NET >> +select CMD_PING if NET >> select CMD_PART >> select HUSH_PARSER >> help >> > > Based on > https://travis-ci.org/michalsimek/u-boot/jobs/338051973 > > Lokesh: > There is an issue with omap4_sdp4430_defconfig where CONFIG_NET is not > enabled but PXE and DHCP configs are present. > This is quite weird and IMHO CONFIG_NET should be enabled for this target. > This can be one resolution. Yeah, resolution looks good to me. Tom, any comments? > > diff --git a/configs/omap4_sdp4430_defconfig > b/configs/omap4_sdp4430_defconfig > index ac495710633c..59526fd1dc35 100644 > --- a/configs/omap4_sdp4430_defconfig > +++ b/configs/omap4_sdp4430_defconfig > @@ -23,7 +23,10 @@ CONFIG_CMD_SPI=y > # CONFIG_CMD_NET is not set > # CONFIG_CMD_NFS is not set > CONFIG_CMD_EXT4_WRITE=y > +# CONFIG_EFI_PARTITION is not set > +CONFIG_SPL_PARTITION_UUIDS=y > CONFIG_ENV_IS_IN_MMC=y > +CONFIG_NET=y > CONFIG_MMC_OMAP_HS=y > CONFIG_SYS_NS16550=y > CONFIG_OMAP3_SPI=y > @@ -31,4 +34,6 @@ CONFIG_USB=y > CONFIG_USB_MUSB_UDC=y > CONFIG_USB_OMAP3=y > CONFIG_FAT_WRITE=y > +# CONFIG_REGEX is not set > CONFIG_OF_LIBFDT=y > +# CONFIG_EFI_LOADER is not set Thanks and regards, Lokesh > > > Thanks, > Michal > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x_evm: Consolidate eMMC partitions with DFU info
On Thursday 08 February 2018 12:11 AM, Sam Protsenko wrote:
> From DFU_ALT_INFO_EMMC (include/environment/ti/dfu.h) we can see that
> rootfs will be flashed to second partition on eMMC. But at the moment we
> have only one partition in $partitions environment variable. Let's add
> "bootloader" partition prior to "rootfs", so that DFU works correctly.
> This also fixes eMMC boot, which looks for rootfs on second partition.
>
> "bootloader" partition start corresponds to "u-boot.img.raw" in DFU
> eMMC info, which is 0x300 sector (384 KiB offset from eMMC start).
>
> rootfs start address can be also found from DFU eMMC info.
> bootloader-related area is finished at 0x1500 sector (2688 KiB offset
> from eMMC start). This should be the start address for rootfs in
> $partitions environment variable.
>
> While at it, fix U-Boot environment address to be the same as for
> AM57x EVM, so that it doesn't clash with other partitions.
>
> So now eMMC layout looks like this:
>
> ===
>
> 0 ++
> | MBR/GPT header | 128 -
> 128 ++
> | MLO| 256 -
> 384 ++
> | u-boot.img | 1792 bootloader
> 2176++
> | hole | 256 -
> 2432++
> | U-Boot environment | 128 -
> 2560++
> | U-Boot environment | 128 -
> | (redundant)|
> 2688++
> | rootfs | remaining rootfs
> end ++
>
> ===
>
> "hole" area can be used further for storing U-Boot environment (like
> it's done in AM57x EVM config file) or for increasing u-boot.img area
> (in case u-boot.img size increased, e.g. if new dtbs were added).
>
> This commit conforms with Linux partition table from f6d245b8c56c
> ("arm: am57xx: Fix Linux boot from eMMC") commit, making things in
> uniform way.
>
> Signed-off-by: Sam Protsenko
Reviewed-by: Lokesh Vutla
Thanks and regards,
Lokesh
> ---
> include/configs/am335x_evm.h | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> index 31ab503dca..8c2dd2aac8 100644
> --- a/include/configs/am335x_evm.h
> +++ b/include/configs/am335x_evm.h
> @@ -17,12 +17,13 @@
> #define __CONFIG_AM335X_EVM_H
>
> #include
> +#include
>
> #ifndef CONFIG_SPL_BUILD
> # define CONFIG_TIMESTAMP
> #endif
>
> -#define CONFIG_SYS_BOOTM_LEN (16 << 20)
> +#define CONFIG_SYS_BOOTM_LEN SZ_16M
>
> #define CONFIG_MACH_TYPE MACH_TYPE_AM335XEVM
>
> @@ -34,7 +35,7 @@
> #define CONFIG_SYS_LDSCRIPT "board/ti/am335x/u-boot.lds"
>
> /* Always 128 KiB env size */
> -#define CONFIG_ENV_SIZE (128 << 10)
> +#define CONFIG_ENV_SIZE SZ_128K
>
> #ifdef CONFIG_NAND
> #define NANDARGS \
> @@ -99,7 +100,9 @@
> "console=ttyO0,115200n8\0" \
> "partitions=" \
> "uuid_disk=${uuid_gpt_disk};" \
> - "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}\0" \
> + "name=bootloader,start=384K,size=1792K," \
> + "uuid=${uuid_gpt_bootloader};" \
> + "name=rootfs,start=2688K,size=-,uuid=${uuid_gpt_rootfs}\0" \
> "optargs=\0" \
> "ramroot=/dev/ram0 rw\0" \
> "ramrootfstype=ext2\0" \
> @@ -280,8 +283,8 @@
> #define CONFIG_ENV_OFFSET_REDUND (896 << 10) /* 896 KiB in */
> #elif defined(CONFIG_EMMC_BOOT)
> #define CONFIG_SYS_MMC_ENV_DEV 1
> -#define CONFIG_SYS_MMC_ENV_PART 2
> -#define CONFIG_ENV_OFFSET0x0
> +#define CONFIG_SYS_MMC_ENV_PART 0
> +#define CONFIG_ENV_OFFSET0x26
> #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_SYS_MMC_MAX_DEVICE2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> > Date: Mon, 5 Feb 2018 21:06:59 +1100
> > From: Jonathan Gray
> >
> > > > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > > > failed(6). will try /bsd
> > >
> > > How do you find out that it's sd0a instead of sd1a?
> >
> > The loaded image protocol I believe.
>
> Actually the OpenBSD bootloader currently only supports loading the
> bsd kernel from the same device as the bootloader. It will always
> call that device sd0. It invokes the device path protocol on the
> loaded image handle and then matches that path to a device that
> supports the block io protocol.
Perhaps the problem is elsewhere as U-Boot master also broke
vexpress_ca15_tc2 and mx6cuboxi targets:
$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb
/usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel
/usr/local/share/u-boot/vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and
probing guessed raw.
Automatically detecting the format is dangerous for raw images, write
operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
U-Boot 2018.01 (Feb 06 2018 - 23:26:43 -0700)
DRAM: 1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC: MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: smc911x-0
Hit any key to stop autoboot: 0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
reading fdt.dtb
13384 bytes read in 2153 ms (5.9 KiB/s)
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
76528 bytes read in 51 ms (1.4 MiB/s)
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 3 disks
WARNING: Invalid device tree, expect boot to fail
>> OpenBSD/armv7 BOOTARM 1.0
boot>
cannot open sd0a:/etc/random.seed: No such file or directory
booting sd0a:/bsd: 2648671+8030940+445060 [168774+90+179792+153619]=0xb1812c
$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb
/usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel
vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and
probing guessed raw.
Automatically detecting the format is dangerous for raw images, write
operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 18:24:11 +1300)
DRAM: 1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC: MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: smc911x-0
Hit any key to stop autoboot: 0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
unable to select a mode
mmc_init: -524, time 22
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
unable to select a mode
mmc_init: -524, time 21
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disks on mmc...
unable to select a mode
mmc_init: -524, time 21
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 2147483646
U-Boot SPL 2018.01 (Feb 06 2018 - 23:13:29)
Trying to boot from MMC1
U-Boot 2018.01 (Feb 06 2018 - 23:13:29 -0700)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 54C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM: 2 GiB
MMC: FSL_SDHC: 0
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out: serial
Err: serial
Net: FEC
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /imx6q-cubox-i.dtb
37503 bytes read in 19 ms (1.9 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Scanning disks on sata...
Found 8 disks
reading efi/boot/bootarm.efi
76528 bytes read in 32 ms (2.3 MiB/s)
## Starting EFI application at 1200 ...
>> OpenBSD/armv7 BOOTARM 1.0
boot>
booting sd0a:/bsd: 4531856+203028+560156\[277405+90+281904+244582]=0x5d6b88
U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:54:19 +1300)
Trying to boot from MMC1
U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:54:19 +1300)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 53C
Reset cause:
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On 07.02.2018 22:18, York Sun wrote: On 02/07/2018 12:45 PM, Goldschmidt Simon wrote: On 02/07/2018 21:18, York Sun wrote: On 02/07/2018 12:43 AM, Maxime Ripard wrote: Hi, On Tue, Jan 30, 2018 at 11:02:49PM +, York Sun wrote: On 01/30/2018 12:16 PM, York Sun wrote: On 01/30/2018 11:40 AM, York Sun wrote: On 01/30/2018 12:19 AM, Simon Goldschmidt wrote: On 23.01.2018 21:16, Maxime Ripard wrote: Now that we have everything in place to support multiple environment, let's make sure the current code can use it. The priority used between the various environment is the same one that was used in the code previously. At read / init times, the highest priority environment is going to be detected, Does priority handling really work here? Most env drivers seem to ignore the return value of env_import and may thus return success although importing the environment failed (only reading the data from the device succeeded). This is from reading the code, I haven't had a chance to test this, yet. It is broken on my LS1043ARDB with simply NOR flash. I am trying to determine what went wrong. I found the problem. The variable "env_load_location" is static. It is probably not write-able during booting from flash. It is expected to be set during ENVOP_INIT. But if I print this variable, it has ENVL_UNKNOWN. I can make it work by moving env_load_location to global data structure. That would work for me. Actually I am not a big fun to using global data. It increases size for everybody. But I don't see a way you can save the variable before relocation. That being said, this addition of multiple environments really slows down the booting process for me. I see every time env_get_char() is called, env_driver_lookup() runs. A simple call of env_get_f() gets slowed down dramatically. I didn't find out where the most time is spent yet. Does anyone else experience this unbearable slowness? I found the problem. In patch #3 in this series, the default get_char() was dropped so there is no driver for a plain NOR flash. A quick (and maybe dirty) fix is this diff --git a/env/env.c b/env/env.c index edfb575..210bae2 100644 --- a/env/env.c +++ b/env/env.c @@ -159,7 +159,7 @@ int env_get_char(int index) int ret; if (!drv->get_char) - continue; + return *(uchar *)(gd->env_addr + index); if (!env_has_inited(drv->location)) continue; And this too. If you agree with this fix (actually revert your change earlier), I can send out a patch. I still think we should get rid of the 'get_char' callback for the env drivers. While that could have made sense for some boards before the conversion to multiple environments (although I doubt that, as the environment is *not* checked for validity in this call), its meaning is totally lost when having multiple env drivers active. The whole purpose of multiple env drivers is that we select a valid driver in the 'load' callback. How could we possibly know that the 'get_char' callback of the highest prio env driver is what we want? I'd rather make 'env_get_char' weak and let boards decide if they really want this behaviour. A quick search through the current code base shows me *no* usage of 'get_char' in nvram.c (CONFIG_SYS_NVRAM_ACCESS_ROUTINE is never defined) and only 7 defconfigs that use ENV_IS_IN_EEPROM: imx31_phycore_defconfig imx31_phycore_eet_defconfig km_kirkwood_128m16_defconfig km_kirkwood_defconfig km_kirkwood_pci_defconfig mgcoge3un_defconfig portl2_defconfig Are these seven boards worth keeping this feature? Simon, Adding multiple environments seems to be an improvement. But this fell through the cracks. I don't know if other boards also read env before relocation. All my boards reads hwconfig before relocation. Having to create a new function for all of them doesn't look appealing to me. The change I proposed would be to restore the old behavior but kick out the byte-by-byte reading from eeprom and nvram. My understanding was you are using flash and were reading from environment in ram, not in nvram or eeprom. Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] TCP & Overrrun
I'm gettin overrun on the raspberry pi. Which ethernet drived does it use? I need to determine if it uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the "net_rx_packets" buffer pool defined in net/net.c grep suggests it is not using net_rx_packets. Here's a list of a grep of the u-boot source directory rch/mips/mach-au1x00/au1x00_eth.c arch/powerpc/cpu/mpc85xx/ether_fcc.c net/net.c drivers/usb/gadget/ether.c drivers/net/ep93xx_eth.c drivers/net/cs8900.c drivers/net/ftgmac100.c drivers/net/ks8851_mll.c drivers/net/dc2114x.c drivers/net/dm9000x.c drivers/net/xilinx_ll_temac_fifo.c drivers/net/ax88180.c drivers/net/tsec.c drivers/net/mcffec.c drivers/net/dnet.c drivers/net/ftmac100.c drivers/net/xilinx_ll_temac_sdma.c drivers/net/sandbox-raw.c drivers/net/cpsw.c drivers/net/sandbox.c drivers/net/smc911x.c drivers/net/lan91c96.c drivers/net/uli526x.c drivers/net/tsi108_eth.c drivers/net/mpc8xx_fec.c drivers/net/at91_emac.c drivers/net/ethoc.c drivers/net/fsl_mcdmafec.c drivers/net/bcm-sf2-eth.c drivers/net/enc28j60.c drivers/net/smc9.c drivers/net/macb.c drivers/net/pic32_eth.c Thanks Duncan Hare ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH 2/5] sunxi: add Kconfig option for the maximum accessible DRAM
On Thu, Feb 8, 2018 at 8:35 AM, André Przywara wrote: > On 07/02/18 19:35, Icenowy Zheng wrote: >> Allwinner 64-bit SoCs can use 4GiB DRAM chip, however their memory map >> has only allocated 3GiB for DRAM, so only 3GiB of the DRAM is >> accessible. >> >> Add a Kconfig option for the maximum accessible DRAM. > > That looks fine to me, but have you checked CONFIG_MAX_MEM_MAPPED? > get_effective_memsize() in common/memsize.c looks like it's solving this > very problem. > >> For A80 it should be a much higher value (8GiB), but as I have no A80 >> device to test and originally U-Boot only supports 2GiB DRAM on A80, it >> currently still falls under the 2GiB situation. > > Well, that depends on how we will use SUNXI_DRAM_SIZE. If that's to > limit the size we eventually report in the DT, that should be indeed 8GB > on the A80. But U-Boot itself can't use more than 3GB on sunxi/ARMv7 > (due to the static 1:1 mapping). > I think we should separate those two numbers (actual DRAM size and > U-Boot's own DRAM size), if we really want to support >3GB on the A80. > > But maybe we should not get carried away by something that doesn't > really exist. That was the first thing that popped up in my mind after seeing this series. A80 supports LPAE. However, the A80 is out of production, and no one produced any boards with more than 2GB of RAM. So >3GB on sunxi is going to go untested for a long time, if not forever. ChenYu > > Thanks, > Andre. > >> >> Signed-off-by: Icenowy Zheng >> --- >> arch/arm/mach-sunxi/Kconfig | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig >> index 1fededd0a3..32739e0f33 100644 >> --- a/arch/arm/mach-sunxi/Kconfig >> +++ b/arch/arm/mach-sunxi/Kconfig >> @@ -63,6 +63,13 @@ config MACH_SUNXI_H3_H5 >> select SUNXI_GEN_SUN6I >> select SUPPORT_SPL >> >> +# TODO: try out A80's 8GiB DRAM space >> +config SUNXI_DRAM_MAX_SIZE >> + hex >> + default 0xC000 if MACH_SUN50I >> + default 0xC000 if MACH_SUN50I_H5 >> + default 0x8000 >> + >> choice >> prompt "Sunxi SoC Variant" >> optional >> > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 01/12] riscv: cpu: Add nx25 to support RISC-V
2018-02-02 16:20 GMT+08:00 陳建志 : >> Actually I have checked with checkpatch.pl and cleaned most before >> sending patchs. >> But it seem still left some, I will keep fixing them. >> >> Thanks for Tom and Wolfgang's help. >> >> Rick >> >> 2018-01-15 21:52 GMT+08:00 Tom Rini : >>> On Tue, Dec 26, 2017 at 01:55:48PM +0800, Andes wrote: >>> From: Rick Chen Add Andes nx25 cpu core (called AndesStar V5) to support RISC-V arch Verifications: 1. startup and relocation ok. 2. boot from rom or ram both ok. 2. timer driver ok. 3. uart driver ok 4. mmc driver ok 5. spi driver ok. 6. 32/64 bit both ok. Detail verification message please see doc/README.ae250. Signed-off-by: Rick Chen Signed-off-by: Rick Chen Signed-off-by: Greentime Hu Cc: Padmarao Begari >>> >>> Applied to u-boot/master. >>> >>> But that said, the whole of arch/riscv/ and board/AndesTech/nx25-ae250/ >>> introduces some checkpatch.pl issues, please investigate and fix >>> appropriate ones, thanks! >>> >>> -- >>> Tom > > Hi Tom > > I am trying to fix this checkpatch.pl issue. > > Though I download mainline by > git clone http://git.denx.de/u-boot.git > It can be seen /arch/riscv folder there. > > But when I try to download riscv repository by > git clone http://git.denx.de/u-boot-riscv.git > and it fail. > > Below is the error messge: > Cloning into 'u-boot-riscv'... > fatal: http://git.denx.de/u-boot-riscv.git/info/refs not found: did > you run git update-server-info on the server? > > Download nds32 repo by > git clone http://git.denx.de/u-boot-nds32.git > is ok. > > May I ask have this riscv repo been created ? > or > did I do something wrong ? > > It seem that after I finish fixing the checkpatch.pl issue, I can not do > git push ssh://gu-ri...@git.denx.de/u-boot-riscv.git master > without riscv repo for contribution. > > Rick Hi Tom It can be downloaded now. Please ignore it. Rick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] sunxi: let sunxi_dram_init return unsigned long long
On 07/02/18 19:35, Icenowy Zheng wrote:
Hi,
> As 4GiB capacity is above the range of 32-bit unsigned integer, raise
> the return type of sunxi_dram_init() to unsigned long long, thus it can
> hold 4GiB capacity (or maybe more on A80).
> Some controllers that are possible to use 4GiB+ memory module are
> also changed to calculate its memory capacity in unsigned long long.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/include/asm/arch-sunxi/dram.h | 2 +-
> arch/arm/mach-sunxi/dram_sun6i.c | 2 +-
> arch/arm/mach-sunxi/dram_sun8i_a23.c | 2 +-
> arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
> arch/arm/mach-sunxi/dram_sun8i_a83t.c | 2 +-
> arch/arm/mach-sunxi/dram_sun9i.c | 4 ++--
> arch/arm/mach-sunxi/dram_sunxi_dw.c| 4 ++--
> board/sunxi/board.c| 2 +-
> board/sunxi/dram_sun4i_auto.c | 2 +-
> board/sunxi/dram_sun5i_auto.c | 2 +-
> 10 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
> b/arch/arm/include/asm/arch-sunxi/dram.h
> index 80abac95b8..d08b82371d 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> @@ -32,7 +32,7 @@
> #include
> #endif
>
> -unsigned long sunxi_dram_init(void);
> +unsigned long long sunxi_dram_init(void);
Since this is explicitly about > 4GB/32 bits, I would suggest we just
use uint64_t here, instead of guessing what long long means.
But can't we just change the semantics of sunxi_dram_init() to return
megabytes instead? sun9i already uses this internally, and just blows it
up in the wrapper. I don't think we have anything with a granularity
smaller than 1MB?
Then we could just leave it at native bit size, and spare poor ARMv7
from struggling with 64 bit arithmetic.
Cheers,
Andre.
> void mctl_await_completion(u32 *reg, u32 mask, u32 val);
> bool mctl_mem_matches(u32 offset);
>
> diff --git a/arch/arm/mach-sunxi/dram_sun6i.c
> b/arch/arm/mach-sunxi/dram_sun6i.c
> index 5dbbf6186f..bdf52a2c38 100644
> --- a/arch/arm/mach-sunxi/dram_sun6i.c
> +++ b/arch/arm/mach-sunxi/dram_sun6i.c
> @@ -326,7 +326,7 @@ static void mctl_port_cfg(void)
> writel(0x0307, &mctl_com->mbagcr[5]);
> }
>
> -unsigned long sunxi_dram_init(void)
> +unsigned long long sunxi_dram_init(void)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_a23.c
> b/arch/arm/mach-sunxi/dram_sun8i_a23.c
> index c53671a0e9..169ccff41a 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_a23.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_a23.c
> @@ -264,7 +264,7 @@ static void mctl_init(u32 *bus_width)
> writel(0x, &mctl_ctl->rfshctl3);
> }
>
> -unsigned long sunxi_dram_init(void)
> +unsigned long long sunxi_dram_init(void)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c
> b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> index fa1620cb39..dfbbe6f39c 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> @@ -325,7 +325,7 @@ static void mctl_sys_init(struct dram_para *para)
> udelay(250);
> }
>
> -unsigned long sunxi_dram_init(void)
> +unsigned long long sunxi_dram_init(void)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_a83t.c
> b/arch/arm/mach-sunxi/dram_sun8i_a83t.c
> index 55df1b9d54..ec4bccd635 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_a83t.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_a83t.c
> @@ -423,7 +423,7 @@ static void mctl_sys_init(struct dram_para *para)
> udelay(250);
> }
>
> -unsigned long sunxi_dram_init(void)
> +unsigned long long sunxi_dram_init(void)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> diff --git a/arch/arm/mach-sunxi/dram_sun9i.c
> b/arch/arm/mach-sunxi/dram_sun9i.c
> index 8c681f3541..dcb20f763e 100644
> --- a/arch/arm/mach-sunxi/dram_sun9i.c
> +++ b/arch/arm/mach-sunxi/dram_sun9i.c
> @@ -854,7 +854,7 @@ signed int DRAMC_get_dram_size(void)
> return 1 << dram_size;
> }
>
> -unsigned long sunxi_dram_init(void)
> +unsigned long long sunxi_dram_init(void)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> @@ -957,5 +957,5 @@ unsigned long sunxi_dram_init(void)
> mctl_com_init(¶);
>
> /* return the proper RAM size */
> - return DRAMC_get_dram_size() << 20;
> + return ((unsigned long long)DRAMC_get_dram_size()) << 20;
> }
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 78b4ffb9c3..3bff1c46cd 100644
> --- a/arch/arm/mach-sunxi/dram_sun
Re: [U-Boot] [PATCH 3/5] sunxi: add 3GiB DRAM detection support in main U-Boot
On 07/02/18 19:35, Icenowy Zheng wrote:
Hi,
> Some Allwinner SoCs can use 3GiB DRAM (part of 4GiB or larger module).
>
> As the common get_ram_size function cannot detect non-pow-of-2 memory,
> add special detect code into the DRAM size code in main U-Boot.
The original get_ram_size() function is slightly dodgy already (as it
probes memory by writing). And in general we will never be able to cover
ARMv7/LPAE machines easily with our current static identify mapping -
regardless of any probing hacks we pull up.
So I was wondering if we could either:
- somehow pass the result of sunxi_dram_init() to U-Boot proper, or
- call the DRAM size determination routine again
This would give us the definite answer, and would be correct in every
case. We just need to limit it to the memory map limit, if any.
But his function below looks really like a hack. If at all, it should be
part of the get_ram_size() routine itself, as this is not sunxi specific.
Cheers,
Andre.
> Signed-off-by: Icenowy Zheng
> ---
> board/sunxi/board.c| 23 +++
> include/configs/sunxi-common.h | 2 +-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 8891961dcc..8d707cbac2 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -256,7 +256,30 @@ int board_init(void)
>
> int dram_init(void)
> {
> +#if PHYS_SDRAM_0_SIZE == (SZ_2G + SZ_1G)
> + /*
> + * get_ram_size() doesn't support non-pow-of-2 sizes, so the detection
> + * of 3GiB DRAM is implemented here.
> + * It just checks whether the DRAM is bigger than 2GiB, as the DRAM
> + * module is usually 4GiB in this case (and 1GiB is not accessible).
> + */
> + u32 save_0, save_2g;
> + gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, SZ_2G);
> + if (gd->ram_size == SZ_2G) {
> + save_0 = readl(PHYS_SDRAM_0);
> + save_2g = readl(PHYS_SDRAM_0 + SZ_2G);
> + writel(0, PHYS_SDRAM_0);
> + writel(0xaa55aa55, PHYS_SDRAM_0 + SZ_2G);
> + dsb();
> + if (readl(PHYS_SDRAM_0) != readl(PHYS_SDRAM_0 + SZ_2G)) {
> + gd->ram_size = SZ_2G + SZ_1G;
> + writel(save_2g, PHYS_SDRAM_0 + SZ_2G);
> + }
> + writel(save_0, PHYS_SDRAM_0);
> + }
> +#else
> gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, PHYS_SDRAM_0_SIZE);
> +#endif
>
> return 0;
> }
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 9b3944ad13..177647e009 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -111,7 +111,7 @@
>
> #define CONFIG_NR_DRAM_BANKS 1
> #define PHYS_SDRAM_0 CONFIG_SYS_SDRAM_BASE
> -#define PHYS_SDRAM_0_SIZE0x8000 /* 2 GiB */
> +#define PHYS_SDRAM_0_SIZECONFIG_SUNXI_DRAM_MAX_SIZE
>
> #ifdef CONFIG_AHCI
> #define CONFIG_SCSI_AHCI_PLAT
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] sunxi: add Kconfig option for the maximum accessible DRAM
On 07/02/18 19:35, Icenowy Zheng wrote: > Allwinner 64-bit SoCs can use 4GiB DRAM chip, however their memory map > has only allocated 3GiB for DRAM, so only 3GiB of the DRAM is > accessible. > > Add a Kconfig option for the maximum accessible DRAM. That looks fine to me, but have you checked CONFIG_MAX_MEM_MAPPED? get_effective_memsize() in common/memsize.c looks like it's solving this very problem. > For A80 it should be a much higher value (8GiB), but as I have no A80 > device to test and originally U-Boot only supports 2GiB DRAM on A80, it > currently still falls under the 2GiB situation. Well, that depends on how we will use SUNXI_DRAM_SIZE. If that's to limit the size we eventually report in the DT, that should be indeed 8GB on the A80. But U-Boot itself can't use more than 3GB on sunxi/ARMv7 (due to the static 1:1 mapping). I think we should separate those two numbers (actual DRAM size and U-Boot's own DRAM size), if we really want to support >3GB on the A80. But maybe we should not get carried away by something that doesn't really exist. Thanks, Andre. > > Signed-off-by: Icenowy Zheng > --- > arch/arm/mach-sunxi/Kconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 1fededd0a3..32739e0f33 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -63,6 +63,13 @@ config MACH_SUNXI_H3_H5 > select SUNXI_GEN_SUN6I > select SUPPORT_SPL > > +# TODO: try out A80's 8GiB DRAM space > +config SUNXI_DRAM_MAX_SIZE > + hex > + default 0xC000 if MACH_SUN50I > + default 0xC000 if MACH_SUN50I_H5 > + default 0x8000 > + > choice > prompt "Sunxi SoC Variant" > optional > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] sunxi: map DRAM part with 3G size
On 07/02/18 19:35, Icenowy Zheng wrote:
Hi,
> All Allwinner 64-bit SoCs now are known to be able to access 3GiB of
> external DRAM, however the size of DRAM part in the MMU translation
> table is still 2GiB.
>
> Change the size of DRAM part in MMU table to 3GiB.
This is needed for the (new) get_ram_size() to work, isn't it?
I don't like this routine very much, but I guess this change here is
fine anyway:
Reviewed-by: Andre Przywara
Cheers,
Andre.
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/mach-sunxi/board.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 0c60ee04da..4ee1040ac9 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -53,7 +53,7 @@ static struct mm_region sunxi_mem_map[] = {
> /* RAM */
> .virt = 0x4000UL,
> .phys = 0x4000UL,
> - .size = 0x8000UL,
> + .size = 0xC000UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>PTE_BLOCK_INNER_SHARE
> }, {
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] .travis.yml: download xtensa prebuilt toolchain
xtensa toolchains are core-specific, so give full toolchain name and
download corresponding prebuilt toolchain from the github release.
Signed-off-by: Max Filippov
---
.travis.yml | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 2a98c4bb11cc..8e96a269299f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -72,7 +72,11 @@ before_script:
wget
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2016.09-release/arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
&&
tar -C /tmp -xf
arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz;
fi
- - if [[ "${TOOLCHAIN}" == *xtensa* ]]; then ./tools/buildman/buildman
--fetch-arch xtensa ; fi
+ - if [[ "${TOOLCHAIN}" == *xtensa* ]]; then
+ wget
https://github.com/foss-xtensa/toolchain/releases/download/2018.02/x86_64-2018.02-${TOOLCHAIN}.tar.gz
&&
+ tar -C /tmp -xf x86_64-2018.02-${TOOLCHAIN}.tar.gz &&
+ echo -e "\n[toolchain-prefix]\nxtensa =
/tmp/2018.02/${TOOLCHAIN}/bin/${TOOLCHAIN}-" >> ~/.buildman;
+fi
# If TOOLCHAIN is unset, we're on some flavour of ARM.
- if [[ "${TOOLCHAIN}" == "" ]]; then
wget
http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/aarch64-linux-gnu/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz
&&
@@ -272,7 +276,7 @@ matrix:
BUILDMAN="xilinx -x microblaze"
- env:
- BUILDMAN="xtensa"
- TOOLCHAIN="xtensa"
+ TOOLCHAIN="xtensa-dc233c-elf"
- env:
- BUILDMAN="riscv"
TOOLCHAIN="riscv"
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] .travis.yml: test xtensa xtfpga board in QEMU
This allows running tests on emulated KC705 board with DC233C xtensa core. It expects to find conf.xtfpga_qemu in the uboot-test-hooks. Signed-off-by: Max Filippov --- .travis.yml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/.travis.yml b/.travis.yml index 8e96a269299f..2c1b11dd81d9 100644 --- a/.travis.yml +++ b/.travis.yml @@ -389,5 +389,12 @@ matrix: QEMU_TARGET="arm-softmmu" TEST_PY_ID="--id qemu" BUILDMAN="^zynq_zc702$" +- env: +- TEST_PY_BD="xtfpga" + TEST_PY_TEST_SPEC="not sleep" + QEMU_TARGET="xtensa-softmmu" + TEST_PY_ID="--id qemu" + BUILDMAN="^xtfpga$" + TOOLCHAIN="xtensa-dc233c-elf" # TODO make it perfect ;-r -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] .travis.yml changes for building/testing xtensa port
Hi Tom, the following patches allow building and running U-Boot for xtensa in Travis CI. The test results are the following: 73 passed, 31 skipped, 1 deselected Changes v1->v2: - add patch that enables hush parser for xtfpga_defconfig. The size increase is tolerable and now there are no falures in the testsuite. Max Filippov (3): .travis.yml: download xtensa prebuilt toolchain xtfpga: enable hush parser .travis.yml: test xtensa xtfpga board in QEMU .travis.yml | 15 +-- configs/xtfpga_defconfig | 1 + include/configs/xtfpga.h | 2 -- 3 files changed, 14 insertions(+), 4 deletions(-) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] xtfpga: enable hush parser
Remove CONFIG_BOOT_RETRY_TIME as it doesn't do much good and enable CONFIG_HUSH_PARSER in xtfpga_defconfig. Signed-off-by: Max Filippov --- Changes v1->v2: - new patch configs/xtfpga_defconfig | 1 + include/configs/xtfpga.h | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/xtfpga_defconfig b/configs/xtfpga_defconfig index 4f77e23ef5c5..759b4a5524f7 100644 --- a/configs/xtfpga_defconfig +++ b/configs/xtfpga_defconfig @@ -3,6 +3,7 @@ CONFIG_SYS_CPU="dc233c" CONFIG_XTFPGA_KC705=y CONFIG_BOOTDELAY=10 CONFIG_VERSION_VARIABLE=y +CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="U-Boot> " CONFIG_AUTOBOOT_KEYED=y CONFIG_AUTOBOOT_PROMPT="Autobooting in %d seconds, press to stop\n" diff --git a/include/configs/xtfpga.h b/include/configs/xtfpga.h index 3119f007971e..79cc1e8fc1b8 100644 --- a/include/configs/xtfpga.h +++ b/include/configs/xtfpga.h @@ -122,8 +122,6 @@ /* U-Boot autoboot configuration */ /*==*/ -#define CONFIG_BOOT_RETRY_TIME 60 /* retry after 60 secs */ - #define CONFIG_AUTO_COMPLETE /* Support tab autocompletion */ #define CONFIG_CMDLINE_EDITING #define CONFIG_SYS_LONGHELP -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] drivers/ddr/fsl: Fix DDR4 RDIMM support
On 02/04/2018 05:40 AM, Simon Glass wrote: > Hi York, > > On 24 January 2018 at 12:04, York Sun wrote: >> For DDR4, command/address delay in mode registers and parity latency >> in timing config register are only needed for UDIMMs, but not RDIMMs. >> Add additional register rcw_3 for DDR4 RDIMM. Fix mirrored bit for >> dual rank RDIMMs. Set sdram_cfg_3[DIS_MRS_PAR] for RDIMMs. Use >> hexadecimal format for printing RCW (register control word) registers. >> >> Signed-off-by: York Sun >> --- >> >> Changes in v3: None >> Changes in v2: None >> >> drivers/ddr/fsl/ctrl_regs.c| 32 +--- >> drivers/ddr/fsl/ddr4_dimm_params.c | 2 ++ >> drivers/ddr/fsl/interactive.c | 9 +++-- >> include/fsl_ddr_sdram.h| 1 + >> 4 files changed, 35 insertions(+), 9 deletions(-) > > What do you think about moving this into drivers/ram (separate from > this patch)? Do you think it could use the uclass? Simon, Moving to drivers/ram is not a problem. My concern is it is worth the effort. Legacy PowerPC-based SoCs are still alive but I don't see any new products coming. ARM-based SoCs will move to ATF (or alike) boots first model. Once ATF boots first, U-Boot will no longer need this driver (PowerPC SoCs still use it though). Let's discuss this again a few months later when I may have a better vision. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] env: Add back default action of get_char in env_get_char()
Commit 8a3a7e2270b3 ("env: Pass additional parameters to the env
lookup function") dropped the default action if driver doesn't have
get_char() defined. This causes failure to get environmental
variables from NOR flash. Add back this default action for now.
Signed-off-by: York Sun
CC: Maxime Ripard
---
Limited test on LS1043ARDB.
env/env.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/env/env.c b/env/env.c
index edfb575..210bae2 100644
--- a/env/env.c
+++ b/env/env.c
@@ -159,7 +159,7 @@ int env_get_char(int index)
int ret;
if (!drv->get_char)
- continue;
+ return *(uchar *)(gd->env_addr + index);
if (!env_has_inited(drv->location))
continue;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] env: Fix env_load_location
Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.
Signed-off-by: York Sun
CC: Maxime Ripard
---
Limited test on LS1043ARDB.
env/env.c | 8 +++-
include/asm-generic/global_data.h | 1 +
include/environment.h | 2 +-
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/env/env.c b/env/env.c
index 9a89832..edfb575 100644
--- a/env/env.c
+++ b/env/env.c
@@ -62,8 +62,6 @@ static enum env_location env_locations[] = {
#endif
};
-static enum env_location env_load_location = ENVL_UNKNOWN;
-
static bool env_has_inited(enum env_location location)
{
return gd->env_has_init & BIT(location);
@@ -108,11 +106,11 @@ __weak enum env_location env_get_location(enum
env_operation op, int prio)
if (prio >= ARRAY_SIZE(env_locations))
return ENVL_UNKNOWN;
- env_load_location = env_locations[prio];
- return env_load_location;
+ gd->env_load_location = env_locations[prio];
+ return gd->env_load_location;
case ENVOP_SAVE:
- return env_load_location;
+ return gd->env_load_location;
}
return ENVL_UNKNOWN;
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index fd8cd45..10f1441 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -51,6 +51,7 @@ typedef struct global_data {
unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid;/* Environment valid? enum env_valid */
unsigned long env_has_init; /* Bitmask of boolean of struct
env_location offsets */
+ int env_load_location;
unsigned long ram_top; /* Top address of RAM used by U-Boot */
unsigned long relocaddr;/* Start address of U-Boot in RAM */
diff --git a/include/environment.h b/include/environment.h
index a406050..0f339da 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -188,6 +188,7 @@ enum env_valid {
};
enum env_location {
+ ENVL_UNKNOWN,
ENVL_EEPROM,
ENVL_EXT4,
ENVL_FAT,
@@ -202,7 +203,6 @@ enum env_location {
ENVL_NOWHERE,
ENVL_COUNT,
- ENVL_UNKNOWN,
};
/* value for the various operations we want to perform on the env */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] .travis.yml: download xtensa prebuilt toolchain
xtensa toolchains are core-specific, so give full toolchain name and
download corresponding prebuilt toolchain from the github release.
Signed-off-by: Max Filippov
---
.travis.yml | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 2a98c4bb11cc..8e96a269299f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -72,7 +72,11 @@ before_script:
wget
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2016.09-release/arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
&&
tar -C /tmp -xf
arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz;
fi
- - if [[ "${TOOLCHAIN}" == *xtensa* ]]; then ./tools/buildman/buildman
--fetch-arch xtensa ; fi
+ - if [[ "${TOOLCHAIN}" == *xtensa* ]]; then
+ wget
https://github.com/foss-xtensa/toolchain/releases/download/2018.02/x86_64-2018.02-${TOOLCHAIN}.tar.gz
&&
+ tar -C /tmp -xf x86_64-2018.02-${TOOLCHAIN}.tar.gz &&
+ echo -e "\n[toolchain-prefix]\nxtensa =
/tmp/2018.02/${TOOLCHAIN}/bin/${TOOLCHAIN}-" >> ~/.buildman;
+fi
# If TOOLCHAIN is unset, we're on some flavour of ARM.
- if [[ "${TOOLCHAIN}" == "" ]]; then
wget
http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/aarch64-linux-gnu/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz
&&
@@ -272,7 +276,7 @@ matrix:
BUILDMAN="xilinx -x microblaze"
- env:
- BUILDMAN="xtensa"
- TOOLCHAIN="xtensa"
+ TOOLCHAIN="xtensa-dc233c-elf"
- env:
- BUILDMAN="riscv"
TOOLCHAIN="riscv"
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] .travis.yml: test xtensa xtfpga board in QEMU
This allows running tests on emulated KC705 board with DC233C xtensa core. It expects to find conf.xtfpga_qemu in the uboot-test-hooks. Signed-off-by: Max Filippov --- .travis.yml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/.travis.yml b/.travis.yml index 8e96a269299f..2c1b11dd81d9 100644 --- a/.travis.yml +++ b/.travis.yml @@ -389,5 +389,12 @@ matrix: QEMU_TARGET="arm-softmmu" TEST_PY_ID="--id qemu" BUILDMAN="^zynq_zc702$" +- env: +- TEST_PY_BD="xtfpga" + TEST_PY_TEST_SPEC="not sleep" + QEMU_TARGET="xtensa-softmmu" + TEST_PY_ID="--id qemu" + BUILDMAN="^xtfpga$" + TOOLCHAIN="xtensa-dc233c-elf" # TODO make it perfect ;-r -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] .travis.yml changes for building/testing xtensa port
Hi Tom, the following two patches allow building and running U-Boot for xtensa in Travis CI. The test results are the following: 4 failed, 14 passed, 86 skipped, 1 deselected Failures are in the environment manipulation tests and skipped tests are mostly the hush ones. I guess that's because hush is not enabled in the xtfpga_defconfig. Max Filippov (2): .travis.yml: download xtensa prebuilt toolchain .travis.yml: test xtensa xtfpga board in QEMU .travis.yml | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On 02/07/2018 12:45 PM, Goldschmidt Simon wrote: > On 02/07/2018 21:18, York Sun wrote: >> On 02/07/2018 12:43 AM, Maxime Ripard wrote: >>> Hi, >>> >>> On Tue, Jan 30, 2018 at 11:02:49PM +, York Sun wrote: On 01/30/2018 12:16 PM, York Sun wrote: > On 01/30/2018 11:40 AM, York Sun wrote: >> On 01/30/2018 12:19 AM, Simon Goldschmidt wrote: >>> On 23.01.2018 21:16, Maxime Ripard wrote: Now that we have everything in place to support multiple environment, let's make sure the current code can use it. The priority used between the various environment is the same one that was used in the code previously. At read / init times, the highest priority environment is going to be detected, >>> >>> Does priority handling really work here? Most env drivers seem to ignore >>> the return value of env_import and may thus return success although >>> importing the environment failed (only reading the data from the device >>> succeeded). >>> >>> This is from reading the code, I haven't had a chance to test this, yet. >> >> It is broken on my LS1043ARDB with simply NOR flash. I am trying to >> determine what went wrong. >> > > I found the problem. The variable "env_load_location" is static. It is > probably not write-able during booting from flash. It is expected to be > set during ENVOP_INIT. But if I print this variable, it has > ENVL_UNKNOWN. I can make it work by moving env_load_location to global > data structure. >>> >>> That would work for me. Actually I am not a big fun to using global data. It increases size for everybody. But I don't see a way you can save the variable before relocation. >>> > That being said, this addition of multiple environments really slows > down the booting process for me. I see every time env_get_char() is > called, env_driver_lookup() runs. A simple call of env_get_f() gets > slowed down dramatically. I didn't find out where the most time is spent > yet. > > Does anyone else experience this unbearable slowness? > I found the problem. In patch #3 in this series, the default get_char() was dropped so there is no driver for a plain NOR flash. A quick (and maybe dirty) fix is this diff --git a/env/env.c b/env/env.c index edfb575..210bae2 100644 --- a/env/env.c +++ b/env/env.c @@ -159,7 +159,7 @@ int env_get_char(int index) int ret; if (!drv->get_char) - continue; + return *(uchar *)(gd->env_addr + index); if (!env_has_inited(drv->location)) continue; >>> >>> And this too. >> >> If you agree with this fix (actually revert your change earlier), I can >> send out a patch. > > I still think we should get rid of the 'get_char' callback for > the env drivers. While that could have made sense for some boards > before the conversion to multiple environments (although I > doubt that, as the environment is *not* checked for > validity in this call), its meaning is totally lost when having > multiple env drivers active. > > The whole purpose of multiple env drivers is that we select a > valid driver in the 'load' callback. How could we possibly know > that the 'get_char' callback of the highest prio env driver is > what we want? > > I'd rather make 'env_get_char' weak and let boards decide if they > really want this behaviour. > > A quick search through the current code base shows me *no* usage > of 'get_char' in nvram.c (CONFIG_SYS_NVRAM_ACCESS_ROUTINE is never > defined) and only 7 defconfigs that use ENV_IS_IN_EEPROM: > > imx31_phycore_defconfig > imx31_phycore_eet_defconfig > km_kirkwood_128m16_defconfig > km_kirkwood_defconfig > km_kirkwood_pci_defconfig > mgcoge3un_defconfig > portl2_defconfig > > Are these seven boards worth keeping this feature? > Simon, Adding multiple environments seems to be an improvement. But this fell through the cracks. I don't know if other boards also read env before relocation. All my boards reads hwconfig before relocation. Having to create a new function for all of them doesn't look appealing to me. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] efi_selftest: test gop bitblt
The test checks all block image transfer operations of the graphical output
protocol. An animated submarine is shown.
To run the test:
setenv efi_selftest bock image transfer
bootefi selftest
Signed-off-by: Heinrich Schuchardt
---
v2
correct commit message
---
lib/efi_selftest/Makefile | 1 +
lib/efi_selftest/efi_selftest_bitblt.c | 311 +
2 files changed, 312 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_bitblt.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 88c44840d52..b975da2955c 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -14,6 +14,7 @@ CFLAGS_REMOVE_efi_selftest_miniapp_return.o :=
$(CFLAGS_NON_EFI) -Os
obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += \
efi_selftest.o \
+efi_selftest_bitblt.o \
efi_selftest_controllers.o \
efi_selftest_console.o \
efi_selftest_devicepath.o \
diff --git a/lib/efi_selftest/efi_selftest_bitblt.c
b/lib/efi_selftest/efi_selftest_bitblt.c
new file mode 100644
index 000..53cc633acc6
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_bitblt.c
@@ -0,0 +1,311 @@
+/*
+ * efi_selftest_bitblt
+ *
+ * Copyright (c) 2017 Heinrich Schuchardt
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ *
+ * Test the block image transfer in the graphical output protocol.
+ * An animated submarine is shown.
+ */
+
+#include
+
+#define WIDTH 200
+#define HEIGHT 120
+#define DEPTH 60
+
+static const struct efi_gop_pixel BLACK = { 0, 0, 0, 0};
+static const struct efi_gop_pixel RED ={ 0, 0, 255, 0};
+static const struct efi_gop_pixel ORANGE = { 0, 128, 255, 0};
+static const struct efi_gop_pixel YELLOW = { 0, 255, 255, 0};
+static const struct efi_gop_pixel GREEN = { 0, 255, 0, 0};
+static const struct efi_gop_pixel DARK_BLUE = {128, 0, 0, 0};
+static const struct efi_gop_pixel LIGHT_BLUE = {255, 192, 192, 0};
+
+static struct efi_boot_services *boottime;
+static efi_guid_t efi_gop_guid = EFI_GOP_GUID;
+static struct efi_gop *gop;
+static struct efi_gop_pixel *bitmap;
+static struct efi_event *event;
+static efi_uintn_t xpos;
+
+static void ellipse(efi_uintn_t x, efi_uintn_t y,
+ efi_uintn_t x0, efi_uintn_t y0,
+ efi_uintn_t x1, efi_uintn_t y1,
+ const struct efi_gop_pixel col, struct efi_gop_pixel *pix)
+{
+ efi_uintn_t xm = x0 + x1;
+ efi_uintn_t ym = y0 + y1;
+ efi_uintn_t dx = x1 - x0 + 1;
+ efi_uintn_t dy = y1 - y0 + 1;
+
+ if (dy * dy * (2 * x - xm) * (2 * x - xm) +
+ dx * dx * (2 * y - ym) * (2 * y - ym) <= dx * dx * dy * dy)
+ *pix = col;
+}
+
+static void rectangle(efi_uintn_t x, efi_uintn_t y,
+ efi_uintn_t x0, efi_uintn_t y0,
+ efi_uintn_t x1, efi_uintn_t y1,
+ const struct efi_gop_pixel col, struct efi_gop_pixel *pix)
+{
+ if (x >= x0 && y >= y0 && x <= x1 && y <= y1)
+ *pix = col;
+}
+
+/*
+ * Notification function, copies image to video.
+ * The position is incremented in each call.
+ *
+ * @event notified event
+ * @contextpointer to the notification count
+ */
+static void EFIAPI notify(struct efi_event *event, void *context)
+{
+ efi_uintn_t *pos = context;
+ efi_uintn_t dx, sx, width;
+
+ if (!pos)
+ return;
+
+ /* Increment position */
+ *pos += 5;
+ if (*pos >= WIDTH + gop->mode->info->width)
+ *pos = 0;
+
+ width = WIDTH;
+ dx = *pos - WIDTH;
+ sx = 0;
+ if (*pos >= gop->mode->info->width) {
+ width = WIDTH + gop->mode->info->width - *pos;
+ } else if (*pos < WIDTH) {
+ dx = 0;
+ sx = WIDTH - *pos;
+ width = *pos;
+ }
+
+ /* Copy image to video */
+ gop->blt(gop, bitmap, EFI_BLT_BUFFER_TO_VIDEO, sx, 0, dx, DEPTH,
+width, HEIGHT, WIDTH);
+}
+
+/*
+ * Setup unit test.
+ *
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int setup(const efi_handle_t handle,
+const struct efi_system_table *systable)
+{
+ efi_status_t ret;
+ struct efi_gop_pixel pix;
+ efi_uintn_t x, y;
+
+ boottime = systable->boottime;
+
+ /* Create event */
+ ret = boottime->create_event(EVT_TIMER | EVT_NOTIFY_SIGNAL,
+TPL_CALLBACK, notify, (void *)&xpos,
+&event);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("could not create event\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /* Get graphical output protocol */
+ ret = boottime->locate_protocol(&efi_gop_guid, NULL, (void **)&gop);
+ if (ret != EFI_SUCCESS) {
+ gop = NULL;
+ efi_st_printf("Graphical output protocol is not
[U-Boot] [PATCH v2 1/2] efi_loader: implement missing bit blit operations in gop
With the patch all block image transfer operations of the
EFI_GRAPHICS_OUTPUT_PROTOCOL are supported.
Signed-off-by: Heinrich Schuchardt
---
v2
no change
---
include/efi_api.h| 10 ++-
lib/efi_loader/efi_gop.c | 158 ---
2 files changed, 131 insertions(+), 37 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index 993e8231fca..2c7814aabe7 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -645,6 +645,13 @@ struct efi_gop_mode
unsigned long fb_size;
};
+struct efi_gop_pixel {
+ u8 blue;
+ u8 green;
+ u8 red;
+ u8 reserved;
+};
+
#define EFI_BLT_VIDEO_FILL 0
#define EFI_BLT_VIDEO_TO_BLT_BUFFER1
#define EFI_BLT_BUFFER_TO_VIDEO2
@@ -656,7 +663,8 @@ struct efi_gop
efi_uintn_t *size_of_info,
struct efi_gop_mode_info **info);
efi_status_t (EFIAPI *set_mode)(struct efi_gop *this, u32 mode_number);
- efi_status_t (EFIAPI *blt)(struct efi_gop *this, void *buffer,
+ efi_status_t (EFIAPI *blt)(struct efi_gop *this,
+ struct efi_gop_pixel *buffer,
u32 operation, efi_uintn_t sx,
efi_uintn_t sy, efi_uintn_t dx,
efi_uintn_t dy, efi_uintn_t width,
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 3caddd5f844..d47d91387f1 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -56,64 +56,150 @@ static efi_status_t EFIAPI gop_set_mode(struct efi_gop
*this, u32 mode_number)
return EFI_EXIT(EFI_SUCCESS);
}
-efi_status_t EFIAPI gop_blt(struct efi_gop *this, void *buffer,
+static inline struct efi_gop_pixel efi_vid16_to_blt_col(u16 vid)
+{
+ struct efi_gop_pixel blt = {
+ .reserved = 0,
+ };
+
+ blt.blue = (vid & 0x1f) << 3;
+ vid >>= 5;
+ blt.green = (vid & 0x3f) << 2;
+ vid >>= 6;
+ blt.red = (vid & 0x1f) << 3;
+ return blt;
+}
+
+static inline u16 efi_blt_col_to_vid16(struct efi_gop_pixel *blt)
+{
+ return (u16)(blt->red >> 3) << 11 |
+ (u16)(blt->green >> 2) << 5 |
+ (u16)(blt->blue >> 3);
+}
+
+efi_status_t EFIAPI gop_blt(struct efi_gop *this, struct efi_gop_pixel *buffer,
u32 operation, efi_uintn_t sx,
efi_uintn_t sy, efi_uintn_t dx,
efi_uintn_t dy, efi_uintn_t width,
efi_uintn_t height, efi_uintn_t delta)
{
struct efi_gop_obj *gopobj = container_of(this, struct efi_gop_obj,
ops);
- int i, j, line_len16, line_len32;
- void *fb;
+ efi_uintn_t i, j, linelen;
+ u32 *fb32 = gopobj->fb;
+ u16 *fb16 = gopobj->fb;
+
+ if (delta)
+ linelen = delta;
+ else
+ linelen = width;
EFI_ENTRY("%p, %p, %u, %zu, %zu, %zu, %zu, %zu, %zu, %zu", this,
buffer, operation, sx, sy, dx, dy, width, height, delta);
- if (operation != EFI_BLT_BUFFER_TO_VIDEO)
+ /* Check source rectangle */
+ switch (operation) {
+ case EFI_BLT_VIDEO_FILL:
+ break;
+ case EFI_BLT_BUFFER_TO_VIDEO:
+ if (sx + width > linelen)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ case EFI_BLT_VIDEO_TO_BLT_BUFFER:
+ case EFI_BLT_VIDEO_TO_VIDEO:
+ if (sx + width > gopobj->info.width ||
+ sy + height > gopobj->info.height)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ default:
return EFI_EXIT(EFI_INVALID_PARAMETER);
+ }
- fb = gopobj->fb;
- line_len16 = gopobj->info.width * sizeof(u16);
- line_len32 = gopobj->info.width * sizeof(u32);
+ /* Check destination rectangle */
+ switch (operation) {
+ case EFI_BLT_VIDEO_FILL:
+ case EFI_BLT_BUFFER_TO_VIDEO:
+ case EFI_BLT_VIDEO_TO_VIDEO:
+ if (dx + width > gopobj->info.width ||
+ dy + height > gopobj->info.height)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ case EFI_BLT_VIDEO_TO_BLT_BUFFER:
+ if (dx + width > linelen)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ }
- /* Copy the contents line by line */
+ for (i = 0; i < height; i++) {
+ for (j = 0; j < width; j++) {
+ struct efi_gop_pixel pix;
+
+ /* Read source pixel */
+ switch (operation) {
+ case EFI_BLT_VIDEO_FILL:
+ pix = *buffer;
+ break;
+
[U-Boot] [PATCH v2 0/2] efi_loader: implement missing bit blit operations in gop
The patch series implements the missing block image transfer operations of the graphical output protocol A unit test is provided. --- v2 correct commit message --- Heinrich Schuchardt (2): efi_loader: implement missing bit blit operations in gop efi_selftest: test gop bitblt include/efi_api.h | 10 +- lib/efi_loader/efi_gop.c | 158 + lib/efi_selftest/Makefile | 1 + lib/efi_selftest/efi_selftest_bitblt.c | 311 + 4 files changed, 443 insertions(+), 37 deletions(-) create mode 100644 lib/efi_selftest/efi_selftest_bitblt.c -- 2.14.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] efi_selftest: test gop bitblt
The test dr
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/Makefile | 1 +
lib/efi_selftest/efi_selftest_bitblt.c | 311 +
2 files changed, 312 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_bitblt.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 88c44840d52..b975da2955c 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -14,6 +14,7 @@ CFLAGS_REMOVE_efi_selftest_miniapp_return.o :=
$(CFLAGS_NON_EFI) -Os
obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += \
efi_selftest.o \
+efi_selftest_bitblt.o \
efi_selftest_controllers.o \
efi_selftest_console.o \
efi_selftest_devicepath.o \
diff --git a/lib/efi_selftest/efi_selftest_bitblt.c
b/lib/efi_selftest/efi_selftest_bitblt.c
new file mode 100644
index 000..53cc633acc6
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_bitblt.c
@@ -0,0 +1,311 @@
+/*
+ * efi_selftest_bitblt
+ *
+ * Copyright (c) 2017 Heinrich Schuchardt
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ *
+ * Test the block image transfer in the graphical output protocol.
+ * An animated submarine is shown.
+ */
+
+#include
+
+#define WIDTH 200
+#define HEIGHT 120
+#define DEPTH 60
+
+static const struct efi_gop_pixel BLACK = { 0, 0, 0, 0};
+static const struct efi_gop_pixel RED ={ 0, 0, 255, 0};
+static const struct efi_gop_pixel ORANGE = { 0, 128, 255, 0};
+static const struct efi_gop_pixel YELLOW = { 0, 255, 255, 0};
+static const struct efi_gop_pixel GREEN = { 0, 255, 0, 0};
+static const struct efi_gop_pixel DARK_BLUE = {128, 0, 0, 0};
+static const struct efi_gop_pixel LIGHT_BLUE = {255, 192, 192, 0};
+
+static struct efi_boot_services *boottime;
+static efi_guid_t efi_gop_guid = EFI_GOP_GUID;
+static struct efi_gop *gop;
+static struct efi_gop_pixel *bitmap;
+static struct efi_event *event;
+static efi_uintn_t xpos;
+
+static void ellipse(efi_uintn_t x, efi_uintn_t y,
+ efi_uintn_t x0, efi_uintn_t y0,
+ efi_uintn_t x1, efi_uintn_t y1,
+ const struct efi_gop_pixel col, struct efi_gop_pixel *pix)
+{
+ efi_uintn_t xm = x0 + x1;
+ efi_uintn_t ym = y0 + y1;
+ efi_uintn_t dx = x1 - x0 + 1;
+ efi_uintn_t dy = y1 - y0 + 1;
+
+ if (dy * dy * (2 * x - xm) * (2 * x - xm) +
+ dx * dx * (2 * y - ym) * (2 * y - ym) <= dx * dx * dy * dy)
+ *pix = col;
+}
+
+static void rectangle(efi_uintn_t x, efi_uintn_t y,
+ efi_uintn_t x0, efi_uintn_t y0,
+ efi_uintn_t x1, efi_uintn_t y1,
+ const struct efi_gop_pixel col, struct efi_gop_pixel *pix)
+{
+ if (x >= x0 && y >= y0 && x <= x1 && y <= y1)
+ *pix = col;
+}
+
+/*
+ * Notification function, copies image to video.
+ * The position is incremented in each call.
+ *
+ * @event notified event
+ * @contextpointer to the notification count
+ */
+static void EFIAPI notify(struct efi_event *event, void *context)
+{
+ efi_uintn_t *pos = context;
+ efi_uintn_t dx, sx, width;
+
+ if (!pos)
+ return;
+
+ /* Increment position */
+ *pos += 5;
+ if (*pos >= WIDTH + gop->mode->info->width)
+ *pos = 0;
+
+ width = WIDTH;
+ dx = *pos - WIDTH;
+ sx = 0;
+ if (*pos >= gop->mode->info->width) {
+ width = WIDTH + gop->mode->info->width - *pos;
+ } else if (*pos < WIDTH) {
+ dx = 0;
+ sx = WIDTH - *pos;
+ width = *pos;
+ }
+
+ /* Copy image to video */
+ gop->blt(gop, bitmap, EFI_BLT_BUFFER_TO_VIDEO, sx, 0, dx, DEPTH,
+width, HEIGHT, WIDTH);
+}
+
+/*
+ * Setup unit test.
+ *
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int setup(const efi_handle_t handle,
+const struct efi_system_table *systable)
+{
+ efi_status_t ret;
+ struct efi_gop_pixel pix;
+ efi_uintn_t x, y;
+
+ boottime = systable->boottime;
+
+ /* Create event */
+ ret = boottime->create_event(EVT_TIMER | EVT_NOTIFY_SIGNAL,
+TPL_CALLBACK, notify, (void *)&xpos,
+&event);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("could not create event\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /* Get graphical output protocol */
+ ret = boottime->locate_protocol(&efi_gop_guid, NULL, (void **)&gop);
+ if (ret != EFI_SUCCESS) {
+ gop = NULL;
+ efi_st_printf("Graphical output protocol is not available.\n");
+ return EFI_ST_SUCCESS;
+ }
+
+ /* Prepare image of submarine */
+ ret = boottime->allocate_pool(EFI_LOADER_DATA,
+ sizeof(struct efi_
[U-Boot] [PATCH 1/2] efi_loader: implement missing bit blit operations in gop
With the patch all block image transfer operations of the
EFI_GRAPHICS_OUTPUT_PROTOCOL are supported.
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h| 10 ++-
lib/efi_loader/efi_gop.c | 158 ---
2 files changed, 131 insertions(+), 37 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index 993e8231fca..2c7814aabe7 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -645,6 +645,13 @@ struct efi_gop_mode
unsigned long fb_size;
};
+struct efi_gop_pixel {
+ u8 blue;
+ u8 green;
+ u8 red;
+ u8 reserved;
+};
+
#define EFI_BLT_VIDEO_FILL 0
#define EFI_BLT_VIDEO_TO_BLT_BUFFER1
#define EFI_BLT_BUFFER_TO_VIDEO2
@@ -656,7 +663,8 @@ struct efi_gop
efi_uintn_t *size_of_info,
struct efi_gop_mode_info **info);
efi_status_t (EFIAPI *set_mode)(struct efi_gop *this, u32 mode_number);
- efi_status_t (EFIAPI *blt)(struct efi_gop *this, void *buffer,
+ efi_status_t (EFIAPI *blt)(struct efi_gop *this,
+ struct efi_gop_pixel *buffer,
u32 operation, efi_uintn_t sx,
efi_uintn_t sy, efi_uintn_t dx,
efi_uintn_t dy, efi_uintn_t width,
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 3caddd5f844..d47d91387f1 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -56,64 +56,150 @@ static efi_status_t EFIAPI gop_set_mode(struct efi_gop
*this, u32 mode_number)
return EFI_EXIT(EFI_SUCCESS);
}
-efi_status_t EFIAPI gop_blt(struct efi_gop *this, void *buffer,
+static inline struct efi_gop_pixel efi_vid16_to_blt_col(u16 vid)
+{
+ struct efi_gop_pixel blt = {
+ .reserved = 0,
+ };
+
+ blt.blue = (vid & 0x1f) << 3;
+ vid >>= 5;
+ blt.green = (vid & 0x3f) << 2;
+ vid >>= 6;
+ blt.red = (vid & 0x1f) << 3;
+ return blt;
+}
+
+static inline u16 efi_blt_col_to_vid16(struct efi_gop_pixel *blt)
+{
+ return (u16)(blt->red >> 3) << 11 |
+ (u16)(blt->green >> 2) << 5 |
+ (u16)(blt->blue >> 3);
+}
+
+efi_status_t EFIAPI gop_blt(struct efi_gop *this, struct efi_gop_pixel *buffer,
u32 operation, efi_uintn_t sx,
efi_uintn_t sy, efi_uintn_t dx,
efi_uintn_t dy, efi_uintn_t width,
efi_uintn_t height, efi_uintn_t delta)
{
struct efi_gop_obj *gopobj = container_of(this, struct efi_gop_obj,
ops);
- int i, j, line_len16, line_len32;
- void *fb;
+ efi_uintn_t i, j, linelen;
+ u32 *fb32 = gopobj->fb;
+ u16 *fb16 = gopobj->fb;
+
+ if (delta)
+ linelen = delta;
+ else
+ linelen = width;
EFI_ENTRY("%p, %p, %u, %zu, %zu, %zu, %zu, %zu, %zu, %zu", this,
buffer, operation, sx, sy, dx, dy, width, height, delta);
- if (operation != EFI_BLT_BUFFER_TO_VIDEO)
+ /* Check source rectangle */
+ switch (operation) {
+ case EFI_BLT_VIDEO_FILL:
+ break;
+ case EFI_BLT_BUFFER_TO_VIDEO:
+ if (sx + width > linelen)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ case EFI_BLT_VIDEO_TO_BLT_BUFFER:
+ case EFI_BLT_VIDEO_TO_VIDEO:
+ if (sx + width > gopobj->info.width ||
+ sy + height > gopobj->info.height)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ default:
return EFI_EXIT(EFI_INVALID_PARAMETER);
+ }
- fb = gopobj->fb;
- line_len16 = gopobj->info.width * sizeof(u16);
- line_len32 = gopobj->info.width * sizeof(u32);
+ /* Check destination rectangle */
+ switch (operation) {
+ case EFI_BLT_VIDEO_FILL:
+ case EFI_BLT_BUFFER_TO_VIDEO:
+ case EFI_BLT_VIDEO_TO_VIDEO:
+ if (dx + width > gopobj->info.width ||
+ dy + height > gopobj->info.height)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ case EFI_BLT_VIDEO_TO_BLT_BUFFER:
+ if (dx + width > linelen)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+ break;
+ }
- /* Copy the contents line by line */
+ for (i = 0; i < height; i++) {
+ for (j = 0; j < width; j++) {
+ struct efi_gop_pixel pix;
+
+ /* Read source pixel */
+ switch (operation) {
+ case EFI_BLT_VIDEO_FILL:
+ pix = *buffer;
+ break;
+ case EFI_BLT_
[U-Boot] [PATCH 0/2] efi_loader: implement missing bit blit operations in gop
The patch series implements the missing block image transfer operations of the graphical output protocol A unit test is provided. Heinrich Schuchardt (2): efi_loader: implement missing bit blit operations in gop efi_selftest: test gop bitblt include/efi_api.h | 10 +- lib/efi_loader/efi_gop.c | 158 + lib/efi_selftest/Makefile | 1 + lib/efi_selftest/efi_selftest_bitblt.c | 311 + 4 files changed, 443 insertions(+), 37 deletions(-) create mode 100644 lib/efi_selftest/efi_selftest_bitblt.c -- 2.14.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On 02/07/2018 21:18, York Sun wrote: > On 02/07/2018 12:43 AM, Maxime Ripard wrote: >> Hi, >> >> On Tue, Jan 30, 2018 at 11:02:49PM +, York Sun wrote: >>> On 01/30/2018 12:16 PM, York Sun wrote: On 01/30/2018 11:40 AM, York Sun wrote: > On 01/30/2018 12:19 AM, Simon Goldschmidt wrote: >> On 23.01.2018 21:16, Maxime Ripard wrote: >>> Now that we have everything in place to support multiple environment, >>> let's >>> make sure the current code can use it. >>> >>> The priority used between the various environment is the same one that >>> was >>> used in the code previously. >>> >>> At read / init times, the highest priority environment is going to be >>> detected, >> >> Does priority handling really work here? Most env drivers seem to ignore >> the return value of env_import and may thus return success although >> importing the environment failed (only reading the data from the device >> succeeded). >> >> This is from reading the code, I haven't had a chance to test this, yet. > > It is broken on my LS1043ARDB with simply NOR flash. I am trying to > determine what went wrong. > I found the problem. The variable "env_load_location" is static. It is probably not write-able during booting from flash. It is expected to be set during ENVOP_INIT. But if I print this variable, it has ENVL_UNKNOWN. I can make it work by moving env_load_location to global data structure. >> >> That would work for me. >> That being said, this addition of multiple environments really slows down the booting process for me. I see every time env_get_char() is called, env_driver_lookup() runs. A simple call of env_get_f() gets slowed down dramatically. I didn't find out where the most time is spent yet. Does anyone else experience this unbearable slowness? >>> >>> I found the problem. In patch #3 in this series, the default get_char() >>> was dropped so there is no driver for a plain NOR flash. A quick (and >>> maybe dirty) fix is this >>> >>> >>> diff --git a/env/env.c b/env/env.c >>> index edfb575..210bae2 100644 >>> --- a/env/env.c >>> +++ b/env/env.c >>> @@ -159,7 +159,7 @@ int env_get_char(int index) >>> int ret; >>> >>> if (!drv->get_char) >>> - continue; >>> + return *(uchar *)(gd->env_addr + index); >>> >>> if (!env_has_inited(drv->location)) >>> continue; >> >> And this too. > > If you agree with this fix (actually revert your change earlier), I can > send out a patch. I still think we should get rid of the 'get_char' callback for the env drivers. While that could have made sense for some boards before the conversion to multiple environments (although I doubt that, as the environment is *not* checked for validity in this call), its meaning is totally lost when having multiple env drivers active. The whole purpose of multiple env drivers is that we select a valid driver in the 'load' callback. How could we possibly know that the 'get_char' callback of the highest prio env driver is what we want? I'd rather make 'env_get_char' weak and let boards decide if they really want this behaviour. A quick search through the current code base shows me *no* usage of 'get_char' in nvram.c (CONFIG_SYS_NVRAM_ACCESS_ROUTINE is never defined) and only 7 defconfigs that use ENV_IS_IN_EEPROM: imx31_phycore_defconfig imx31_phycore_eet_defconfig km_kirkwood_128m16_defconfig km_kirkwood_defconfig km_kirkwood_pci_defconfig mgcoge3un_defconfig portl2_defconfig Are these seven boards worth keeping this feature? Simon >> >>> With this temporary fix, my flash chip works again and I can boot all >>> the way up in a timely manner. I still don't like to call >>> env_driver_lookup() thousands of times to get a simple env variable. >>> >>> Can Maxime post a quick post soon? >> >> Given that you already made all the debugging, and the patches, and I >> have no way to test, I guess it would make more sense if you did it :) > > Yes, I have tested on my boards. I will send out this patch. > > York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On 02/07/2018 12:43 AM, Maxime Ripard wrote: > Hi, > > On Tue, Jan 30, 2018 at 11:02:49PM +, York Sun wrote: >> On 01/30/2018 12:16 PM, York Sun wrote: >>> On 01/30/2018 11:40 AM, York Sun wrote: On 01/30/2018 12:19 AM, Simon Goldschmidt wrote: > On 23.01.2018 21:16, Maxime Ripard wrote: >> Now that we have everything in place to support multiple environment, >> let's >> make sure the current code can use it. >> >> The priority used between the various environment is the same one that >> was >> used in the code previously. >> >> At read / init times, the highest priority environment is going to be >> detected, > > Does priority handling really work here? Most env drivers seem to ignore > the return value of env_import and may thus return success although > importing the environment failed (only reading the data from the device > succeeded). > > This is from reading the code, I haven't had a chance to test this, yet. It is broken on my LS1043ARDB with simply NOR flash. I am trying to determine what went wrong. >>> >>> I found the problem. The variable "env_load_location" is static. It is >>> probably not write-able during booting from flash. It is expected to be >>> set during ENVOP_INIT. But if I print this variable, it has >>> ENVL_UNKNOWN. I can make it work by moving env_load_location to global >>> data structure. > > That would work for me. > >>> That being said, this addition of multiple environments really slows >>> down the booting process for me. I see every time env_get_char() is >>> called, env_driver_lookup() runs. A simple call of env_get_f() gets >>> slowed down dramatically. I didn't find out where the most time is spent >>> yet. >>> >>> Does anyone else experience this unbearable slowness? >>> >> >> I found the problem. In patch #3 in this series, the default get_char() >> was dropped so there is no driver for a plain NOR flash. A quick (and >> maybe dirty) fix is this >> >> >> diff --git a/env/env.c b/env/env.c >> index edfb575..210bae2 100644 >> --- a/env/env.c >> +++ b/env/env.c >> @@ -159,7 +159,7 @@ int env_get_char(int index) >> int ret; >> >> if (!drv->get_char) >> - continue; >> + return *(uchar *)(gd->env_addr + index); >> >> if (!env_has_inited(drv->location)) >> continue; > > And this too. If you agree with this fix (actually revert your change earlier), I can send out a patch. > >> With this temporary fix, my flash chip works again and I can boot all >> the way up in a timely manner. I still don't like to call >> env_driver_lookup() thousands of times to get a simple env variable. >> >> Can Maxime post a quick post soon? > > Given that you already made all the debugging, and the patches, and I > have no way to test, I guess it would make more sense if you did it :) Yes, I have tested on my boards. I will send out this patch. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Fix misaligned buffer in env_fat_save
When saving the environment on a platform which has DMA alignment
larger than the natural alignment, env_fat_save triggers a debug
message in file_fat_write:
Saving Environment to FAT... writing uboot.env
FAT: Misaligned buffer address (9df1c8e0)
OK
Signed-off-by: Alex Kiernan
---
env/fat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/env/fat.c b/env/fat.c
index 35f7ab5..e6bd1f9 100644
--- a/env/fat.c
+++ b/env/fat.c
@@ -36,7 +36,7 @@ DECLARE_GLOBAL_DATA_PTR;
#ifdef CMD_SAVEENV
static int env_fat_save(void)
{
- env_t env_new;
+ env_t __aligned(ARCH_DMA_MINALIGN) env_new;
struct blk_desc *dev_desc = NULL;
disk_partition_t info;
int dev, part;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] arch-stm32: Factorize stm32.h for STM32F4 and F7
Hi,
On 02/07/2018 07:50 AM, patrice.chot...@st.com wrote:
> From: Patrice Chotard
>
> For STM32F4 and F7 SoCx family, a specific stm32.h file exists.
> Some common defines are duplicated or even unused in each of
> these stm32.h.
>
> Factorize all common definition in arch/arm/include/asm/stm32f.h and keep
> specific definitions in each arch/arm/include/asm/arch-stm32fx/stm32.h.
>
> Signed-off-by: Patrice Chotard
> ---
> arch/arm/include/asm/arch-stm32f4/stm32.h | 14 ++
> arch/arm/include/asm/arch-stm32f7/stm32.h | 45
> +--
> arch/arm/include/asm/stm32f.h | 22 +++
> drivers/mtd/stm32_flash.c | 2 +-
> 4 files changed, 26 insertions(+), 57 deletions(-)
> create mode 100644 arch/arm/include/asm/stm32f.h
>
> diff --git a/arch/arm/include/asm/arch-stm32f4/stm32.h
> b/arch/arm/include/asm/arch-stm32f4/stm32.h
> index 763b18cb5412..86cca059075d 100644
> --- a/arch/arm/include/asm/arch-stm32f4/stm32.h
> +++ b/arch/arm/include/asm/arch-stm32f4/stm32.h
> @@ -11,17 +11,12 @@
> #ifndef _MACH_STM32_H_
> #define _MACH_STM32_H_
>
> +#include
> +
> /*
> * Peripheral memory map
> */
> #define STM32_SYSMEM_BASE0x1FFF
> -#define STM32_PERIPH_BASE0x4000
> -#define STM32_APB1PERIPH_BASE(STM32_PERIPH_BASE + 0x)
> -#define STM32_APB2PERIPH_BASE(STM32_PERIPH_BASE + 0x0001)
> -#define STM32_AHB1PERIPH_BASE(STM32_PERIPH_BASE + 0x0002)
> -#define STM32_AHB2PERIPH_BASE(STM32_PERIPH_BASE + 0x1000)
> -
> -#define STM32_BUS_MASK 0x
>
> /*
> * Register maps
> @@ -37,15 +32,10 @@ struct stm32_u_id_regs {
> */
> #define STM32_U_ID_BASE (STM32_SYSMEM_BASE + 0x7A10)
> #define STM32_U_ID ((struct stm32_u_id_regs *)STM32_U_ID_BASE)
> -
> -#define FLASH_CNTL_BASE (STM32_AHB1PERIPH_BASE + 0x3C00)
> -
> static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
> [0 ... 3] = 16 * 1024,
> [4] = 64 * 1024,
> [5 ... 11] =128 * 1024
> };
>
> -void stm32_flash_latency_cfg(int latency);
> -
> #endif /* _MACH_STM32_H_ */
> diff --git a/arch/arm/include/asm/arch-stm32f7/stm32.h
> b/arch/arm/include/asm/arch-stm32f7/stm32.h
> index 40df89142608..3f097548d374 100644
> --- a/arch/arm/include/asm/arch-stm32f7/stm32.h
> +++ b/arch/arm/include/asm/arch-stm32f7/stm32.h
> @@ -8,46 +8,7 @@
> #ifndef _ASM_ARCH_HARDWARE_H
> #define _ASM_ARCH_HARDWARE_H
>
> -/* STM32F746 */
> -#define ITCM_FLASH_BASE 0x0020UL
> -#define AXIM_FLASH_BASE 0x0800UL
> -
> -#define ITCM_SRAM_BASE 0xUL
> -#define DTCM_SRAM_BASE 0x2000UL
> -#define SRAM1_BASE 0x2001UL
> -#define SRAM2_BASE 0x2004C000UL
> -
> -#define PERIPH_BASE 0x4000UL
> -
> -#define APB1_PERIPH_BASE (PERIPH_BASE + 0x)
> -#define APB2_PERIPH_BASE (PERIPH_BASE + 0x0001)
> -#define AHB1_PERIPH_BASE (PERIPH_BASE + 0x0002)
> -#define AHB2_PERIPH_BASE (PERIPH_BASE + 0x1000)
> -#define AHB3_PERIPH_BASE (PERIPH_BASE + 0x2000)
> -
> -#define USART2_BASE (APB1_PERIPH_BASE + 0x4400)
> -#define USART3_BASE (APB1_PERIPH_BASE + 0x4800)
> -#define PWR_BASE (APB1_PERIPH_BASE + 0x7000)
> -
> -#define USART1_BASE (APB2_PERIPH_BASE + 0x1000)
> -#define USART6_BASE (APB2_PERIPH_BASE + 0x1400)
> -#define STM32_SYSCFG_BASE(APB2_PERIPH_BASE + 0x3800)
> -
> -#define STM32_GPIOA_BASE (AHB1_PERIPH_BASE + 0x)
> -#define STM32_GPIOB_BASE (AHB1_PERIPH_BASE + 0x0400)
> -#define STM32_GPIOC_BASE (AHB1_PERIPH_BASE + 0x0800)
> -#define STM32_GPIOD_BASE (AHB1_PERIPH_BASE + 0x0C00)
> -#define STM32_GPIOE_BASE (AHB1_PERIPH_BASE + 0x1000)
> -#define STM32_GPIOF_BASE (AHB1_PERIPH_BASE + 0x1400)
> -#define STM32_GPIOG_BASE (AHB1_PERIPH_BASE + 0x1800)
> -#define STM32_GPIOH_BASE (AHB1_PERIPH_BASE + 0x1C00)
> -#define STM32_GPIOI_BASE (AHB1_PERIPH_BASE + 0x2000)
> -#define STM32_GPIOJ_BASE (AHB1_PERIPH_BASE + 0x2400)
> -#define STM32_GPIOK_BASE (AHB1_PERIPH_BASE + 0x2800)
> -#define FLASH_CNTL_BASE (AHB1_PERIPH_BASE + 0x3C00)
> -
> -
> -#define SDRAM_FMC_BASE (AHB3_PERIPH_BASE + 0x4140)
> +#include
>
> static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
> [0 ... 3] = 32 * 1024,
> @@ -55,8 +16,4 @@ static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
> [5 ... 7] = 256 * 1024
> };
>
> -#define STM32_BUS_MASK GENMASK(31, 16)
> -
> -void stm32_flash_latency_cfg(int latency);
> -
> #endif /* _ASM_ARCH_HARDWARE_H */
> diff --git a/arch/arm/include/asm/stm32f.h b/arch/arm/include/asm/stm32f.h
same comment, location of this header should be arch-stm32/stm32f.h
Cheers,
Vikas
> new file mode 100644
> index ..7bea20b4d06a
> --- /dev/null
>
Re: [U-Boot] [PATCH 2/5] arch-stm32: Move gpio.h for STM32 SoCs in include/asm/
Hi Patrice,
On 02/07/2018 07:50 AM, patrice.chot...@st.com wrote:
> From: Patrice Chotard
>
> Instead to have 3 identical gpio.h for all STM32 SoCs,
> migrate them in one file in include/asm.
good move to consolidate these headers.
One comment below.
>
> Signed-off-by: Patrice Chotard
> ---
> arch/arm/include/asm/arch-stm32f4/gpio.h | 146
> +--
> arch/arm/include/asm/arch-stm32f7/gpio.h | 116 +---
> arch/arm/include/asm/arch-stm32h7/gpio.h | 115 +---
> arch/arm/include/asm/stm32_gpio.h| 115
> 4 files changed, 118 insertions(+), 374 deletions(-)
> create mode 100644 arch/arm/include/asm/stm32_gpio.h
>
> diff --git a/arch/arm/include/asm/arch-stm32f4/gpio.h
> b/arch/arm/include/asm/arch-stm32f4/gpio.h
> index 6173fa13..bb4427e6f4ac 100644
> --- a/arch/arm/include/asm/arch-stm32f4/gpio.h
> +++ b/arch/arm/include/asm/arch-stm32f4/gpio.h
> @@ -11,150 +11,6 @@
> #ifndef _STM32_GPIO_H_
> #define _STM32_GPIO_H_
>
> -#if (CONFIG_STM32_USART == 1)
> -#define STM32_GPIO_PORT_X STM32_GPIO_PORT_A
> -#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_9
> -#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_10
> -#define STM32_GPIO_USARTSTM32_GPIO_AF7
> -
> -#elif (CONFIG_STM32_USART == 2)
> -#define STM32_GPIO_PORT_X STM32_GPIO_PORT_D
> -#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_5
> -#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_6
> -#define STM32_GPIO_USARTSTM32_GPIO_AF7
> -
> -#elif (CONFIG_STM32_USART == 3)
> -#define STM32_GPIO_PORT_X STM32_GPIO_PORT_C
> -#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_10
> -#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_11
> -#define STM32_GPIO_USARTSTM32_GPIO_AF7
> -
> -#elif (CONFIG_STM32_USART == 6)
> -#define STM32_GPIO_PORT_X STM32_GPIO_PORT_G
> -#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_14
> -#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_9
> -#define STM32_GPIO_USARTSTM32_GPIO_AF8
> -
> -#else
> -#define STM32_GPIO_PORT_X STM32_GPIO_PORT_A
> -#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_9
> -#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_10
> -#define STM32_GPIO_USARTSTM32_GPIO_AF7
> -
> -#endif
> -
> -enum stm32_gpio_port {
> - STM32_GPIO_PORT_A = 0,
> - STM32_GPIO_PORT_B,
> - STM32_GPIO_PORT_C,
> - STM32_GPIO_PORT_D,
> - STM32_GPIO_PORT_E,
> - STM32_GPIO_PORT_F,
> - STM32_GPIO_PORT_G,
> - STM32_GPIO_PORT_H,
> - STM32_GPIO_PORT_I
> -};
> -
> -enum stm32_gpio_pin {
> - STM32_GPIO_PIN_0 = 0,
> - STM32_GPIO_PIN_1,
> - STM32_GPIO_PIN_2,
> - STM32_GPIO_PIN_3,
> - STM32_GPIO_PIN_4,
> - STM32_GPIO_PIN_5,
> - STM32_GPIO_PIN_6,
> - STM32_GPIO_PIN_7,
> - STM32_GPIO_PIN_8,
> - STM32_GPIO_PIN_9,
> - STM32_GPIO_PIN_10,
> - STM32_GPIO_PIN_11,
> - STM32_GPIO_PIN_12,
> - STM32_GPIO_PIN_13,
> - STM32_GPIO_PIN_14,
> - STM32_GPIO_PIN_15
> -};
> -
> -enum stm32_gpio_mode {
> - STM32_GPIO_MODE_IN = 0,
> - STM32_GPIO_MODE_OUT,
> - STM32_GPIO_MODE_AF,
> - STM32_GPIO_MODE_AN
> -};
> -
> -enum stm32_gpio_otype {
> - STM32_GPIO_OTYPE_PP = 0,
> - STM32_GPIO_OTYPE_OD
> -};
> -
> -enum stm32_gpio_speed {
> - STM32_GPIO_SPEED_2M = 0,
> - STM32_GPIO_SPEED_25M,
> - STM32_GPIO_SPEED_50M,
> - STM32_GPIO_SPEED_100M
> -};
> -
> -enum stm32_gpio_pupd {
> - STM32_GPIO_PUPD_NO = 0,
> - STM32_GPIO_PUPD_UP,
> - STM32_GPIO_PUPD_DOWN
> -};
> -
> -enum stm32_gpio_af {
> - STM32_GPIO_AF0 = 0,
> - STM32_GPIO_AF1,
> - STM32_GPIO_AF2,
> - STM32_GPIO_AF3,
> - STM32_GPIO_AF4,
> - STM32_GPIO_AF5,
> - STM32_GPIO_AF6,
> - STM32_GPIO_AF7,
> - STM32_GPIO_AF8,
> - STM32_GPIO_AF9,
> - STM32_GPIO_AF10,
> - STM32_GPIO_AF11,
> - STM32_GPIO_AF12,
> - STM32_GPIO_AF13,
> - STM32_GPIO_AF14,
> - STM32_GPIO_AF15
> -};
> -
> -struct stm32_gpio_dsc {
> - enum stm32_gpio_portport;
> - enum stm32_gpio_pin pin;
> -};
> -
> -struct stm32_gpio_ctl {
> - enum stm32_gpio_modemode;
> - enum stm32_gpio_otype otype;
> - enum stm32_gpio_speed speed;
> - enum stm32_gpio_pupdpupd;
> - enum stm32_gpio_af af;
> -};
> -
> -struct stm32_gpio_regs {
> - u32 moder; /* GPIO port mode */
> - u32 otyper; /* GPIO port output type */
> - u32 ospeedr;/* GPIO port output speed */
> - u32 pupdr; /* GPIO port pull-up/pull-down */
> - u32 idr;/* GPIO port input data */
> - u32 odr;/* GPIO port output data */
> - u32 bsrr; /* GPIO port bit set/reset */
> - u32 lckr; /* GPIO port configuration lock */
> - u32 afr[2]; /* GPIO alternate function */
> -};
> -
> -struct stm32_gpio_priv {
> - struct stm32_gpio_regs *regs;
> -};
> -
> -static inline unsigned stm32_gpio_to_port(unsigned gpio)
> -{
> - return gpio / 16;
> -}
> -
> -static inline unsigned stm32_gpio_to_pin(unsigned gpio)
> -{
> - return
[U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver
To make this driver easier to be reused, dual-license DDR driver. Signed-off-by: York Sun CC: Simon Glass CC: Tom Rini CC: Heinrich Schuchardt CC: Thomas Schaefer CC: Masahiro Yamada CC: Robert P. J. Day CC: Alexander Merkle CC: Joakim Tjernlund CC: Curt Brune CC: Valentin Longchamp CC: Wolfgang Denk CC: Anatolij Gustschin CC: Ira W. Snyder CC: Marek Vasut CC: Kyle Moffett CC: Sebastien Carlier CC: Stefan Roese CC: Peter Tyser CC: Paul Gortmaker CC: Peter Tyser CC: Jean-Christophe PLAGNIOL-VILLARD --- drivers/ddr/fsl/arm_ddr_gen3.c | 2 +- drivers/ddr/fsl/ctrl_regs.c | 2 +- drivers/ddr/fsl/ddr1_dimm_params.c | 2 +- drivers/ddr/fsl/ddr2_dimm_params.c | 2 +- drivers/ddr/fsl/ddr3_dimm_params.c | 2 +- drivers/ddr/fsl/ddr4_dimm_params.c | 2 +- drivers/ddr/fsl/fsl_ddr_gen4.c | 2 +- drivers/ddr/fsl/fsl_mmdc.c | 2 +- drivers/ddr/fsl/interactive.c | 2 +- drivers/ddr/fsl/lc_common_dimm_params.c | 2 +- drivers/ddr/fsl/main.c | 2 +- drivers/ddr/fsl/mpc85xx_ddr_gen1.c | 2 +- drivers/ddr/fsl/mpc85xx_ddr_gen2.c | 2 +- drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 2 +- drivers/ddr/fsl/mpc86xx_ddr.c | 2 +- drivers/ddr/fsl/options.c | 2 +- drivers/ddr/fsl/util.c | 2 +- include/common_timing_params.h | 2 +- include/fsl_ddr.h | 2 +- include/fsl_ddr_dimm_params.h | 2 +- include/fsl_ddrc_version.h | 2 +- include/fsl_immap.h | 2 +- include/fsl_mmdc.h | 2 +- 23 files changed, 23 insertions(+), 23 deletions(-) diff --git a/drivers/ddr/fsl/arm_ddr_gen3.c b/drivers/ddr/fsl/arm_ddr_gen3.c index aaf4dfb..4fa0d5d 100644 --- a/drivers/ddr/fsl/arm_ddr_gen3.c +++ b/drivers/ddr/fsl/arm_ddr_gen3.c @@ -1,7 +1,7 @@ /* * Copyright 2013 Freescale Semiconductor, Inc. * - * SPDX-License-Identifier:GPL-2.0+ + * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause * * Derived from mpc85xx_ddr_gen3.c, removed all workarounds */ diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c index 8b87271..7308309 100644 --- a/drivers/ddr/fsl/ctrl_regs.c +++ b/drivers/ddr/fsl/ctrl_regs.c @@ -2,7 +2,7 @@ * Copyright 2008-2016 Freescale Semiconductor, Inc. * Copyright 2017-2018 NXP Semiconductor * - * SPDX-License-Identifier:GPL-2.0+ + * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause */ /* diff --git a/drivers/ddr/fsl/ddr1_dimm_params.c b/drivers/ddr/fsl/ddr1_dimm_params.c index c02725e..8a8c17c 100644 --- a/drivers/ddr/fsl/ddr1_dimm_params.c +++ b/drivers/ddr/fsl/ddr1_dimm_params.c @@ -1,7 +1,7 @@ /* * Copyright 2008 Freescale Semiconductor, Inc. * - * SPDX-License-Identifier:GPL-2.0 + * SPDX-License-Identifier:GPL-2.0 BSD-3-Clause */ #include diff --git a/drivers/ddr/fsl/ddr2_dimm_params.c b/drivers/ddr/fsl/ddr2_dimm_params.c index 062c849..3ff35aa 100644 --- a/drivers/ddr/fsl/ddr2_dimm_params.c +++ b/drivers/ddr/fsl/ddr2_dimm_params.c @@ -1,7 +1,7 @@ /* * Copyright 2008 Freescale Semiconductor, Inc. * - * SPDX-License-Identifier:GPL-2.0 + * SPDX-License-Identifier:GPL-2.0 BSD-3-Clause */ #include diff --git a/drivers/ddr/fsl/ddr3_dimm_params.c b/drivers/ddr/fsl/ddr3_dimm_params.c index 8a0587a..d8f170e 100644 --- a/drivers/ddr/fsl/ddr3_dimm_params.c +++ b/drivers/ddr/fsl/ddr3_dimm_params.c @@ -6,7 +6,7 @@ * from ddr3 spd, please refer to the spec * JEDEC standard No.21-C 4_01_02_11R18.pdf * - * SPDX-License-Identifier:GPL-2.0 + * SPDX-License-Identifier:GPL-2.0 BSD-3-Clause */ #include diff --git a/drivers/ddr/fsl/ddr4_dimm_params.c b/drivers/ddr/fsl/ddr4_dimm_params.c index 4867fbc..343b0ff 100644 --- a/drivers/ddr/fsl/ddr4_dimm_params.c +++ b/drivers/ddr/fsl/ddr4_dimm_params.c @@ -2,7 +2,7 @@ * Copyright 2014-2016 Freescale Semiconductor, Inc. * Copyright 2017-2018 NXP Semiconductor * - * SPDX-License-Identifier:GPL-2.0+ + * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause * * calculate the organization and timing parameter * from ddr3 spd, please refer to the spec diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c b/drivers/ddr/fsl/fsl_ddr_gen4.c index c225c8e..1829aa4 100644 --- a/drivers/ddr/fsl/fsl_ddr_gen4.c +++ b/drivers/ddr/fsl/fsl_ddr_gen4.c @@ -1,7 +1,7 @@ /* * Copyright 2014-2015 Freescale Semiconductor, Inc. * - * SPDX-License-Identifier:GPL-2.0+ + * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause */ #include diff --git a/drivers/ddr/fsl/fsl_mmdc.c b/drivers/ddr/fsl/fsl_mmdc.c index 52eec0f..1312c08 100644 --- a/drivers/ddr/fsl/fsl_mmdc.c +++ b/drivers/ddr/fsl/fsl_mmdc.c @@ -1,7 +1,7 @@ /* * Copyright 2016 Freescale Semiconductor, Inc. * - * SPDX-License-Identifier: GPL-2.0+ + * SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */ /* diff --git a/drivers/ddr/fsl/interactive.c b/drivers/ddr/
[U-Boot] [PATCH 5/5] sunxi: restrict the ram_size to the accessible range in SPL
On newer Allwinner SoCs with the BROM start at 0x0 and the DRAM space at
<0x4000 0xc000>, some parts of DRAM will be inaccessible when
4GiB module is used.
Restrict the ram_size written to global_data in SPL.
Signed-off-by: Icenowy Zheng
---
board/sunxi/board.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 5828d47294..a6620f260a 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -541,6 +541,7 @@ int board_mmc_init(bd_t *bis)
void sunxi_board_init(void)
{
int power_failed = 0;
+ unsigned long long dram_real_size;
#ifdef CONFIG_SY8106A_POWER
power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
@@ -601,8 +602,16 @@ void sunxi_board_init(void)
#endif
#endif
printf("DRAM:");
- gd->ram_size = (phys_size_t)sunxi_dram_init();
- printf(" %d MiB\n", (int)(gd->ram_size >> 20));
+ dram_real_size = sunxi_dram_init();
+ printf(" %d MiB", (int)(dram_real_size >> 20));
+ if (dram_real_size > CONFIG_SUNXI_DRAM_MAX_SIZE) {
+ gd->ram_size = CONFIG_SUNXI_DRAM_MAX_SIZE;
+ printf(", %d MiB usable\n", (int)(gd->ram_size >> 20));
+ } else {
+ gd->ram_size = (phys_size_t) dram_real_size;
+ printf("\n");
+ }
+
if (!gd->ram_size)
hang();
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] sunxi: add 3GiB DRAM detection support in main U-Boot
Some Allwinner SoCs can use 3GiB DRAM (part of 4GiB or larger module).
As the common get_ram_size function cannot detect non-pow-of-2 memory,
add special detect code into the DRAM size code in main U-Boot.
Signed-off-by: Icenowy Zheng
---
board/sunxi/board.c| 23 +++
include/configs/sunxi-common.h | 2 +-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 8891961dcc..8d707cbac2 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -256,7 +256,30 @@ int board_init(void)
int dram_init(void)
{
+#if PHYS_SDRAM_0_SIZE == (SZ_2G + SZ_1G)
+ /*
+* get_ram_size() doesn't support non-pow-of-2 sizes, so the detection
+* of 3GiB DRAM is implemented here.
+* It just checks whether the DRAM is bigger than 2GiB, as the DRAM
+* module is usually 4GiB in this case (and 1GiB is not accessible).
+*/
+ u32 save_0, save_2g;
+ gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, SZ_2G);
+ if (gd->ram_size == SZ_2G) {
+ save_0 = readl(PHYS_SDRAM_0);
+ save_2g = readl(PHYS_SDRAM_0 + SZ_2G);
+ writel(0, PHYS_SDRAM_0);
+ writel(0xaa55aa55, PHYS_SDRAM_0 + SZ_2G);
+ dsb();
+ if (readl(PHYS_SDRAM_0) != readl(PHYS_SDRAM_0 + SZ_2G)) {
+ gd->ram_size = SZ_2G + SZ_1G;
+ writel(save_2g, PHYS_SDRAM_0 + SZ_2G);
+ }
+ writel(save_0, PHYS_SDRAM_0);
+ }
+#else
gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, PHYS_SDRAM_0_SIZE);
+#endif
return 0;
}
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 9b3944ad13..177647e009 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -111,7 +111,7 @@
#define CONFIG_NR_DRAM_BANKS 1
#define PHYS_SDRAM_0 CONFIG_SYS_SDRAM_BASE
-#define PHYS_SDRAM_0_SIZE 0x8000 /* 2 GiB */
+#define PHYS_SDRAM_0_SIZE CONFIG_SUNXI_DRAM_MAX_SIZE
#ifdef CONFIG_AHCI
#define CONFIG_SCSI_AHCI_PLAT
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] sunxi: let sunxi_dram_init return unsigned long long
As 4GiB capacity is above the range of 32-bit unsigned integer, raise
the return type of sunxi_dram_init() to unsigned long long, thus it can
hold 4GiB capacity (or maybe more on A80).
Some controllers that are possible to use 4GiB+ memory module are
also changed to calculate its memory capacity in unsigned long long.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/dram.h | 2 +-
arch/arm/mach-sunxi/dram_sun6i.c | 2 +-
arch/arm/mach-sunxi/dram_sun8i_a23.c | 2 +-
arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
arch/arm/mach-sunxi/dram_sun8i_a83t.c | 2 +-
arch/arm/mach-sunxi/dram_sun9i.c | 4 ++--
arch/arm/mach-sunxi/dram_sunxi_dw.c| 4 ++--
board/sunxi/board.c| 2 +-
board/sunxi/dram_sun4i_auto.c | 2 +-
board/sunxi/dram_sun5i_auto.c | 2 +-
10 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
b/arch/arm/include/asm/arch-sunxi/dram.h
index 80abac95b8..d08b82371d 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -32,7 +32,7 @@
#include
#endif
-unsigned long sunxi_dram_init(void);
+unsigned long long sunxi_dram_init(void);
void mctl_await_completion(u32 *reg, u32 mask, u32 val);
bool mctl_mem_matches(u32 offset);
diff --git a/arch/arm/mach-sunxi/dram_sun6i.c b/arch/arm/mach-sunxi/dram_sun6i.c
index 5dbbf6186f..bdf52a2c38 100644
--- a/arch/arm/mach-sunxi/dram_sun6i.c
+++ b/arch/arm/mach-sunxi/dram_sun6i.c
@@ -326,7 +326,7 @@ static void mctl_port_cfg(void)
writel(0x0307, &mctl_com->mbagcr[5]);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun8i_a23.c
b/arch/arm/mach-sunxi/dram_sun8i_a23.c
index c53671a0e9..169ccff41a 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a23.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a23.c
@@ -264,7 +264,7 @@ static void mctl_init(u32 *bus_width)
writel(0x, &mctl_ctl->rfshctl3);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c
b/arch/arm/mach-sunxi/dram_sun8i_a33.c
index fa1620cb39..dfbbe6f39c 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
@@ -325,7 +325,7 @@ static void mctl_sys_init(struct dram_para *para)
udelay(250);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun8i_a83t.c
b/arch/arm/mach-sunxi/dram_sun8i_a83t.c
index 55df1b9d54..ec4bccd635 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a83t.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a83t.c
@@ -423,7 +423,7 @@ static void mctl_sys_init(struct dram_para *para)
udelay(250);
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
diff --git a/arch/arm/mach-sunxi/dram_sun9i.c b/arch/arm/mach-sunxi/dram_sun9i.c
index 8c681f3541..dcb20f763e 100644
--- a/arch/arm/mach-sunxi/dram_sun9i.c
+++ b/arch/arm/mach-sunxi/dram_sun9i.c
@@ -854,7 +854,7 @@ signed int DRAMC_get_dram_size(void)
return 1 << dram_size;
}
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
@@ -957,5 +957,5 @@ unsigned long sunxi_dram_init(void)
mctl_com_init(¶);
/* return the proper RAM size */
- return DRAMC_get_dram_size() << 20;
+ return ((unsigned long long)DRAMC_get_dram_size()) << 20;
}
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index 78b4ffb9c3..3bff1c46cd 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -682,7 +682,7 @@ static void mctl_auto_detect_dram_size(uint16_t socid,
struct dram_para *para)
3, 3, 3, 3, 3, 3, 3, 3, \
3, 3, 3, 3, 2, 0, 0 }
-unsigned long sunxi_dram_init(void)
+unsigned long long sunxi_dram_init(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
(struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
@@ -763,6 +763,6 @@ unsigned long sunxi_dram_init(void)
mctl_auto_detect_dram_size(socid, ¶);
mctl_set_cr(socid, ¶);
- return (1UL << (para.row_bits + para.bank_bits)) * para.page_size *
+ return (1ULL << (para.row_bits + para.
[U-Boot] [PATCH 1/5] sunxi: map DRAM part with 3G size
All Allwinner 64-bit SoCs now are known to be able to access 3GiB of
external DRAM, however the size of DRAM part in the MMU translation
table is still 2GiB.
Change the size of DRAM part in MMU table to 3GiB.
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 0c60ee04da..4ee1040ac9 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -53,7 +53,7 @@ static struct mm_region sunxi_mem_map[] = {
/* RAM */
.virt = 0x4000UL,
.phys = 0x4000UL,
- .size = 0x8000UL,
+ .size = 0xC000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/5] sunxi: add Kconfig option for the maximum accessible DRAM
Allwinner 64-bit SoCs can use 4GiB DRAM chip, however their memory map has only allocated 3GiB for DRAM, so only 3GiB of the DRAM is accessible. Add a Kconfig option for the maximum accessible DRAM. For A80 it should be a much higher value (8GiB), but as I have no A80 device to test and originally U-Boot only supports 2GiB DRAM on A80, it currently still falls under the 2GiB situation. Signed-off-by: Icenowy Zheng --- arch/arm/mach-sunxi/Kconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 1fededd0a3..32739e0f33 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -63,6 +63,13 @@ config MACH_SUNXI_H3_H5 select SUNXI_GEN_SUN6I select SUPPORT_SPL +# TODO: try out A80's 8GiB DRAM space +config SUNXI_DRAM_MAX_SIZE + hex + default 0xC000 if MACH_SUN50I + default 0xC000 if MACH_SUN50I_H5 + default 0x8000 + choice prompt "Sunxi SoC Variant" optional -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/5] Add 3GiB DRAM support to 64-bit Allwinner SoCs
Allwinner 64-bit SoCs have allocated 3GiB space in the memory map for DRAM. If memory bigger than 3GiB is installed (as memory usually come as pow of 2 and they are not known to support 3GiB LPDDR3 modules, it means 4GiB memory is installed), the whole 3GiB space can be all used. However, in many situations we still only defined 2GiB for the DRAM. Add support for 3GiB DRAM. Tested on a customized Pine A64-LTS with 4GiB LPDDR3 memory installed. Icenowy Zheng (5): sunxi: map DRAM part with 3G size sunxi: add Kconfig option for the maximum accessible DRAM sunxi: add 3GiB DRAM detection support in main U-Boot sunxi: let sunxi_dram_init return unsigned long long sunxi: restrict the ram_size to the accessible range in SPL arch/arm/include/asm/arch-sunxi/dram.h | 2 +- arch/arm/mach-sunxi/Kconfig| 7 +++ arch/arm/mach-sunxi/board.c| 2 +- arch/arm/mach-sunxi/dram_sun6i.c | 2 +- arch/arm/mach-sunxi/dram_sun8i_a23.c | 2 +- arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +- arch/arm/mach-sunxi/dram_sun8i_a83t.c | 2 +- arch/arm/mach-sunxi/dram_sun9i.c | 4 ++-- arch/arm/mach-sunxi/dram_sunxi_dw.c| 4 ++-- board/sunxi/board.c| 36 -- board/sunxi/dram_sun4i_auto.c | 2 +- board/sunxi/dram_sun5i_auto.c | 2 +- include/configs/sunxi-common.h | 2 +- 13 files changed, 54 insertions(+), 15 deletions(-) -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
1;5002;0c On Wed, Feb 07, 2018 at 09:25:55AM +0100, Simon Goldschmidt wrote: > On 07.02.2018 09:19, Maxime Ripard wrote: > > On Tue, Feb 06, 2018 at 09:09:07AM +0100, Simon Goldschmidt wrote: > > > On 23.01.2018 21:16, Maxime Ripard wrote: > > > > Now that we have everything in place to support multiple environment, > > > > let's > > > > make sure the current code can use it. > > > I get more build errors testing this feature: there's a global variable > > > 'env_ptr' declared in flash, nand, nvram and remote env drivers (declared > > > as > > > extern in envrionment.h). From reading the code, it seems like these could > > > just be changed to static, since 'env_ptr' is not used outside these > > > drivers? > > Given Joakim's comment, I guess we should keep them !static, rename > > them to $env_env_ptr, and remove the definition in the > > include/environment that doesn't seem used anywhere. > > That's OK for me, I just wanted to point out the build error. > > However, I do think that having unnecessary non-static global variables is > not really good coding style as you risk name clashes. I'd really be > interested in a reason for this. If the relocation works with a static variable, I'm all for it. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Consolidate eMMC partitions with DFU info
From DFU_ALT_INFO_EMMC (include/environment/ti/dfu.h) we can see that
rootfs will be flashed to second partition on eMMC. But at the moment we
have only one partition in $partitions environment variable. Let's add
"bootloader" partition prior to "rootfs", so that DFU works correctly.
This also fixes eMMC boot, which looks for rootfs on second partition.
"bootloader" partition start corresponds to "u-boot.img.raw" in DFU
eMMC info, which is 0x300 sector (384 KiB offset from eMMC start).
rootfs start address can be also found from DFU eMMC info.
bootloader-related area is finished at 0x1500 sector (2688 KiB offset
from eMMC start). This should be the start address for rootfs in
$partitions environment variable.
While at it, fix U-Boot environment address to be the same as for
AM57x EVM, so that it doesn't clash with other partitions.
So now eMMC layout looks like this:
===
0 ++
| MBR/GPT header | 128 -
128 ++
| MLO| 256 -
384 ++
| u-boot.img | 1792 bootloader
2176++
| hole | 256 -
2432++
| U-Boot environment | 128 -
2560++
| U-Boot environment | 128 -
| (redundant)|
2688++
| rootfs | remaining rootfs
end ++
===
"hole" area can be used further for storing U-Boot environment (like
it's done in AM57x EVM config file) or for increasing u-boot.img area
(in case u-boot.img size increased, e.g. if new dtbs were added).
This commit conforms with Linux partition table from f6d245b8c56c
("arm: am57xx: Fix Linux boot from eMMC") commit, making things in
uniform way.
Signed-off-by: Sam Protsenko
---
include/configs/am335x_evm.h | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 31ab503dca..8c2dd2aac8 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -17,12 +17,13 @@
#define __CONFIG_AM335X_EVM_H
#include
+#include
#ifndef CONFIG_SPL_BUILD
# define CONFIG_TIMESTAMP
#endif
-#define CONFIG_SYS_BOOTM_LEN (16 << 20)
+#define CONFIG_SYS_BOOTM_LEN SZ_16M
#define CONFIG_MACH_TYPE MACH_TYPE_AM335XEVM
@@ -34,7 +35,7 @@
#define CONFIG_SYS_LDSCRIPT"board/ti/am335x/u-boot.lds"
/* Always 128 KiB env size */
-#define CONFIG_ENV_SIZE(128 << 10)
+#define CONFIG_ENV_SIZESZ_128K
#ifdef CONFIG_NAND
#define NANDARGS \
@@ -99,7 +100,9 @@
"console=ttyO0,115200n8\0" \
"partitions=" \
"uuid_disk=${uuid_gpt_disk};" \
- "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}\0" \
+ "name=bootloader,start=384K,size=1792K," \
+ "uuid=${uuid_gpt_bootloader};" \
+ "name=rootfs,start=2688K,size=-,uuid=${uuid_gpt_rootfs}\0" \
"optargs=\0" \
"ramroot=/dev/ram0 rw\0" \
"ramrootfstype=ext2\0" \
@@ -280,8 +283,8 @@
#define CONFIG_ENV_OFFSET_REDUND (896 << 10) /* 896 KiB in */
#elif defined(CONFIG_EMMC_BOOT)
#define CONFIG_SYS_MMC_ENV_DEV 1
-#define CONFIG_SYS_MMC_ENV_PART2
-#define CONFIG_ENV_OFFSET 0x0
+#define CONFIG_SYS_MMC_ENV_PART0
+#define CONFIG_ENV_OFFSET 0x26
#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_SYS_MMC_MAX_DEVICE 2
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On Wed, Feb 07, 2018 at 08:45:46AM +, Joakim Tjernlund wrote:
> On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
> > the content is safe.
> >
> >
> > On 06.02.2018 09:20, Joakim Tjernlund wrote:
> > > On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> > >
> > > .
> > > > > Reviewed-by: Andre Przywara
> > > > > Reviewed-by: Simon Glass
> > > > > Signed-off-by: Maxime Ripard
> > > > > ---
> > > > >env/env.c | 80
> > > > > +++-
> > > > >1 file changed, 50 insertions(+), 30 deletions(-)
> > > > >
> > > > > diff --git a/env/env.c b/env/env.c
> > > > > index 906f28ee50a1..1182fdb545db 100644
> > > > > --- a/env/env.c
> > > > > +++ b/env/env.c
> > > > > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum
> > > > > env_location loc)
> > > > >return NULL;
> > > > >}
> > > > >
> > > > > +static enum env_location env_locations[] = {
> > >
> > > Don't use static/global variables. They cause a lot of relocation
> > > work/size
> > > and is less flexible.
> >
> > In this specific case, I think this array should be const anyway, would
> > that prevent the relocation problems you see?
>
> >
> > > There is no way to #define ENVL_EEPROM to a function
> > > when a variable.
> >
> > ENVL_EEPROM is an enum value, why would you define it to a function?
>
> I got boards that very similar but differ in where/how env. is
> stored, like different flash so I need to be able to select at
> runtime how get my env., I haven't looked if this particular area is
> affected but ideally I would like if all env. related "constants"
> could be impl. with a function instead.
It's exactly the point of this entire serie though, and why we merged
it.
You just need to override env_get_location in your board, and return
the preferred location.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] Enable test case with A20-OLinuXino-Lime2
On Wed, Feb 07, 2018 at 12:55:54PM +0530, Jagan Teki wrote:
> > +&spi0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi0_pins_b>, <&spi0_cs0_pins_b>;
> > + status = "okay";
> > +
> > + flash: w25q128@0 {
>
> Was it sync from Linux?
> >>>
> >>> No, this isn't in the linux dts.
> >>
> >> But we have to, please send it to Linux first.
> >
> > We've already commented this issue. In the v2 [1], I've explained that this
> > won't go mainline, since it's optional feature. Rather it will be managed
> > with overlays.
>
> Thought this was already in ML, and ready to merge. So this never go
> to Linux tree since it's optional? then add u-boot.dtsi for this
> atleast since we always sync dts from Linux.
This is an optional feature on that board. We should be making it as
easy as possible to enable it, but a defconfig is a *default*
configuration, and if the board doesn't have it by default, it
shouldn't be enabled in the defconfig.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] i.MX6: nand: add nandbcb update command
Hi Jagan,
On 07.02.2018 17:03, Jagan Teki wrote:
> Writing/updating boot image in nand device is not
> straight forward in i.MX6 platform and it requires
> boot control block(BCB) to be configured.
>
> It becomes difficult to use uboot 'nand' command to
> write BCB since it requires platform specific attributes
> need to be taken care of.
>
> It is even difficult to use existing msx-nand.c driver by
> incorporating BCB attributes like mxs_dma_desc does
> because it requires change in mtd and nand command.
>
> So, cmd_nandbcb implemented in arch/arm/mach-imx
>
> BCB contains two data structures, Firmware Configuration Block(FCB)
> and Discovered Bad Block Table(DBBT). FCB has nand timings,
> DBBT search area, page address of primary and secondary firmware.
Thanks for working on that! We carry a similar command since a while
downstream and I hoped since quite a while to get some time to upstream
it:
http://git.toradex.com/cgit/u-boot-toradex.git/tree/arch/arm/imx-common/cmd_writebcb_mx7.c?h=2016.11-toradex
>
> On summary, nandbcb update will
> - erase the entire partition
> - create BCB by creating 4 FCB/BDDT block followed by
> 2 FW blocks based on partition size and erasesize.
> - fill FCB/DBBT structures
> - write FW/SPL in FW0 and FW1(same image in two times)
> - write FCB/DBBT in first 4 blocks
We used a simpler, more unix like design in that we only do the minimal
thing in that command. Maybe we should consider that upstream too:
writebcb takes one or optionally two firmware offsets and writes the
BCB/FCB/DTTB only. This allows to support one or two firmware images and
makes rewriting of the BCB unnecessary when updating the firmware (most
NAND chips guarantee only a few write cycles on the first NAND
block...). We then use U-Boot to write the firmware itself.
It seems that firmware size in the BCB is not strictly required.
Presumably the boot ROM uses the imx header to determine the size...
Any thoughts?
--
Stefan
>
> for nand boot, up on reset bootrom look for FCB structure in
> first block's if FCB found the nand timings are loaded for
> further reads. once FCB read done, DTTB will load and
> finally primary or secondary firmware will load which is boot image.
>
> See Section 4 from doc/README.imx6 for more usage information.
>
> Signed-off-by: Jagan Teki
> Signed-off-by: Sergey Kubushyn
> ---
> Changes for v3:
> - Fixed multi-line comments
> - Better error handling for failed allocations
> Changes for v2:
> - Fixed commit message notes
> - Updated proper commit message
> - Update doc/README.imx6 with NAND boot details
> - Fixed long length variable names.
> - Fixed Gigantic variable name.
> - NULL checks for kzalloc
> - Move Kconfig option in separate patch
> - Fixed checkpatch warninigs
>
> arch/arm/include/asm/mach-imx/imx-nandbcb.h | 111
> arch/arm/include/asm/mach-imx/mxs-nand.h| 15 ++
> arch/arm/mach-imx/Makefile | 1 +
> arch/arm/mach-imx/cmd_nandbcb.c | 379
>
> doc/README.imx6 | 77 ++
> drivers/mtd/nand/mxs_nand.c | 8 +-
> 6 files changed, 587 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/include/asm/mach-imx/imx-nandbcb.h
> create mode 100644 arch/arm/include/asm/mach-imx/mxs-nand.h
> create mode 100644 arch/arm/mach-imx/cmd_nandbcb.c
>
> diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> new file mode 100644
> index 000..759b588
> --- /dev/null
> +++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#ifndef _IMX_NAND_BCB_H_
> +#define _IMX_NAND_BCB_H_
> +
> +#define FCB_FINGERPRINT 0x20424346 /* 'FCB' */
> +#define FCB_VERSION_10x0100
> +
> +#define DBBT_FINGERPRINT20x54424244 /* 'DBBT' */
> +#define DBBT_VERSION_1 0x0100
> +
> +struct dbbt_block {
> + u32 checksum; /* reserved on i.MX6 */
> + u32 fingerprint;
> + u32 version;
> + u32 numberbb; /* reserved on i.MX6 */
> + u32 dbbtnumofpages;
> +};
> +
> +struct fcb_block {
> + u32 checksum; /* First fingerprint in first byte */
> + u32 fingerprint;/* 2nd fingerprint at byte 4 */
> + u32 version;/* 3rd fingerprint at byte 8 */
> + u8 datasetup;
> + u8 datahold;
> + u8 addresssetup;
> + u8 dsample_time;
> +
> + /* These are for application use only and not for ROM. */
> + u8 nandtiming;
> + u8 rea;
> + u8 rloh;
> + u8 rhoh;
> + u32 pagesize; /* 2048 for 2K pages, 4096 for 4K pages */
> + u32 oob_pagesize; /* 2112 for 2K pages, 4314 for 4K pages */
> + u32 sectors;/* Number of 2K sections per block */
> + u32 nr_nand;/* Total Number of NANDs - not used by ROM */
> + u32 nr_
[U-Boot] [PATCH 2/2] mmc: stm32: sdmmc2: add support for st, pin-ckinsdmmc_ckin
From: Patrick Delaunay
This patch adds "st,pin-ckin" support to activate sdmmc_ckin feature.
When using an external driver (a voltage switch transceiver),
it's advised to select SDMMC_CKIN feedback clock input to sample
the received data.
Signed-off-by: Patrick Delaunay
Signed-off-by: Patrice Chotard
---
drivers/mmc/stm32_sdmmc2.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
index 0fe6808e5dc8..05b421ddd112 100644
--- a/drivers/mmc/stm32_sdmmc2.c
+++ b/drivers/mmc/stm32_sdmmc2.c
@@ -72,7 +72,10 @@ struct stm32_sdmmc2_ctx {
#define SDMMC_CLKCR_HWFC_ENBIT(17)
#define SDMMC_CLKCR_DDRBIT(18)
#define SDMMC_CLKCR_BUSSPEED BIT(19)
-#define SDMMC_CLKCR_SELCLKRX GENMASK(21, 20)
+#define SDMMC_CLKCR_SELCLKRX_MASK GENMASK(21, 20)
+#define SDMMC_CLKCR_SELCLKRX_CK0
+#define SDMMC_CLKCR_SELCLKRX_CKIN BIT(20)
+#define SDMMC_CLKCR_SELCLKRX_FBCK BIT(21)
/* SDMMC_CMD register */
#define SDMMC_CMD_CMDINDEX GENMASK(5, 0)
@@ -535,6 +538,8 @@ static int stm32_sdmmc2_probe(struct udevice *dev)
priv->clk_reg_msk |= SDMMC_CLKCR_NEGEDGE;
if (dev_read_bool(dev, "st,dirpol"))
priv->pwr_reg_msk |= SDMMC_POWER_DIRPOL;
+ if (dev_read_bool(dev, "st,pin-ckin"))
+ priv->clk_reg_msk |= SDMMC_CLKCR_SELCLKRX_CKIN;
ret = clk_get_by_index(dev, 0, &priv->clk);
if (ret)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] stm32_sdmmc2 driver update
From: Patrice Chotard This series adds the following stm32_sdmmc2 driver update : _ Enable hardware flow control _ Add support for st,pin-ckinsdmmc_ckin to select "ckin" clock input to sample received data. Patrick Delaunay (2): mmc: stm32: sdmmc2: add hardware flow control support mmc: stm32: sdmmc2: add support for st,pin-ckinsdmmc_ckin drivers/mmc/stm32_sdmmc2.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] mmc: stm32: sdmmc2: add hardware flow control support
From: Patrick Delaunay The hardware flow control functionality is used to avoid FIFO underrun (TX mode) and overrun (RX mode) errors. The behavior is to stop SDMMC_CK during data transfer and freeze the SDMMC state machines. Signed-off-by: Patrick Delaunay Signed-off-by: Patrice Chotard --- drivers/mmc/stm32_sdmmc2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c index f3b77f512e85..0fe6808e5dc8 100644 --- a/drivers/mmc/stm32_sdmmc2.c +++ b/drivers/mmc/stm32_sdmmc2.c @@ -495,7 +495,8 @@ static int stm32_sdmmc2_set_ios(struct udevice *dev) if (mmc->bus_width == 8) clk |= SDMMC_CLKCR_WIDBUS_8; - writel(clk | priv->clk_reg_msk, priv->base + SDMMC_CLKCR); + writel(clk | priv->clk_reg_msk | SDMMC_CLKCR_HWFC_EN, + priv->base + SDMMC_CLKCR); return 0; } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] arm: i.MX: Add CMD_NANDBCB Kconfig entry
Add Kconfig entry for CMD_NANDBCB, and default y on i.MX6 platform with NAND_MXS defined. Signed-off-by: Jagan Teki --- Changes for v3: - Fixed Typo 'seprate' Changes for v2: - New patch arch/arm/mach-imx/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 3aec89d..1b9c275 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -71,6 +71,17 @@ config CMD_HDMIDETECT This enables the 'hdmidet' command which detects if an HDMI monitor is connected. +config CMD_NANDBCB + bool "i.MX6 NAND Boot Control Block(BCB) command" + depends on NAND && CMD_MTDPARTS + default y if ARCH_MX6 && NAND_MXS + help + Unlike normal 'nand write/erase' commands, this command update + Boot Control Block(BCB) for i.MX6 platform NAND IP's. + + This is similar to kobs-ng, which is used in Linux as separate + rootfs package. + config NXP_BOARD_REVISION bool "Read NXP board revision from fuses" depends on ARCH_MX6 || ARCH_MX7 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] i.MX6: nand: add nandbcb update command
Writing/updating boot image in nand device is not
straight forward in i.MX6 platform and it requires
boot control block(BCB) to be configured.
It becomes difficult to use uboot 'nand' command to
write BCB since it requires platform specific attributes
need to be taken care of.
It is even difficult to use existing msx-nand.c driver by
incorporating BCB attributes like mxs_dma_desc does
because it requires change in mtd and nand command.
So, cmd_nandbcb implemented in arch/arm/mach-imx
BCB contains two data structures, Firmware Configuration Block(FCB)
and Discovered Bad Block Table(DBBT). FCB has nand timings,
DBBT search area, page address of primary and secondary firmware.
On summary, nandbcb update will
- erase the entire partition
- create BCB by creating 4 FCB/BDDT block followed by
2 FW blocks based on partition size and erasesize.
- fill FCB/DBBT structures
- write FW/SPL in FW0 and FW1(same image in two times)
- write FCB/DBBT in first 4 blocks
for nand boot, up on reset bootrom look for FCB structure in
first block's if FCB found the nand timings are loaded for
further reads. once FCB read done, DTTB will load and
finally primary or secondary firmware will load which is boot image.
See Section 4 from doc/README.imx6 for more usage information.
Signed-off-by: Jagan Teki
Signed-off-by: Sergey Kubushyn
---
Changes for v3:
- Fixed multi-line comments
- Better error handling for failed allocations
Changes for v2:
- Fixed commit message notes
- Updated proper commit message
- Update doc/README.imx6 with NAND boot details
- Fixed long length variable names.
- Fixed Gigantic variable name.
- NULL checks for kzalloc
- Move Kconfig option in separate patch
- Fixed checkpatch warninigs
arch/arm/include/asm/mach-imx/imx-nandbcb.h | 111
arch/arm/include/asm/mach-imx/mxs-nand.h| 15 ++
arch/arm/mach-imx/Makefile | 1 +
arch/arm/mach-imx/cmd_nandbcb.c | 379
doc/README.imx6 | 77 ++
drivers/mtd/nand/mxs_nand.c | 8 +-
6 files changed, 587 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/include/asm/mach-imx/imx-nandbcb.h
create mode 100644 arch/arm/include/asm/mach-imx/mxs-nand.h
create mode 100644 arch/arm/mach-imx/cmd_nandbcb.c
diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h
b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
new file mode 100644
index 000..759b588
--- /dev/null
+++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
@@ -0,0 +1,111 @@
+/*
+ * Copyright (C) 2017 Jagan Teki
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _IMX_NAND_BCB_H_
+#define _IMX_NAND_BCB_H_
+
+#define FCB_FINGERPRINT0x20424346 /* 'FCB' */
+#define FCB_VERSION_1 0x0100
+
+#define DBBT_FINGERPRINT2 0x54424244 /* 'DBBT' */
+#define DBBT_VERSION_1 0x0100
+
+struct dbbt_block {
+ u32 checksum; /* reserved on i.MX6 */
+ u32 fingerprint;
+ u32 version;
+ u32 numberbb; /* reserved on i.MX6 */
+ u32 dbbtnumofpages;
+};
+
+struct fcb_block {
+ u32 checksum; /* First fingerprint in first byte */
+ u32 fingerprint;/* 2nd fingerprint at byte 4 */
+ u32 version;/* 3rd fingerprint at byte 8 */
+ u8 datasetup;
+ u8 datahold;
+ u8 addresssetup;
+ u8 dsample_time;
+
+ /* These are for application use only and not for ROM. */
+ u8 nandtiming;
+ u8 rea;
+ u8 rloh;
+ u8 rhoh;
+ u32 pagesize; /* 2048 for 2K pages, 4096 for 4K pages */
+ u32 oob_pagesize; /* 2112 for 2K pages, 4314 for 4K pages */
+ u32 sectors;/* Number of 2K sections per block */
+ u32 nr_nand;/* Total Number of NANDs - not used by ROM */
+ u32 nr_die; /* Number of separate chips in this NAND */
+ u32 celltype; /* MLC or SLC */
+ u32 ecc_type; /* Type of ECC, can be one of BCH-0-20 */
+ u32 ecc_nr; /* Number of bytes for Block0 - BCH */
+
+ /* Block size in bytes for all blocks other than Block0 - BCH */
+ u32 ecc_size;
+ u32 ecc_level; /* Ecc level for Block 0 - BCH */
+ u32 meta_size; /* Metadata size - BCH */
+ /* Number of blocks per page for ROM use - BCH */
+ u32 nr_blocks;
+ u32 ecc_type_sdk; /* Type of ECC, can be one of BCH-0-20 */
+ u32 ecc_nr_sdk; /* Number of bytes for Block0 - BCH */
+ /* Block size in bytes for all blocks other than Block0 - BCH */
+ u32 ecc_size_sdk;
+ u32 ecc_level_sdk; /* Ecc level for Block 0 - BCH */
+ /* Number of blocks per page for SDK use - BCH */
+ u32 nr_blocks_sdk;
+ u32 meta_size_sdk; /* Metadata size - BCH */
+ u32 erase_th; /* To set into BCH_MODE register */
+
+ /*
+* 0: normal boot
+* 1
[U-Boot] [PATCH 0/5] STM32: Clean unused and factorize .h files in arch-stm32
From: Patrice Chotard Removes unused .h files in arch/arm/include/asm/arch-stm32xx Factorize and clean some .h files to avoid to duplicate defines in separate .h files Patrice Chotard (5): arch-stm32f4: Remove fmc.h file arch-stm32: Move gpio.h for STM32 SoCs in include/asm/ arch-stm32: Factorize stm32.h for STM32F4 and F7 arch-stm32: Remove stm32_periph.h arch-stm32: Clean arch-stm32f7/syscfg.h arch/arm/include/asm/arch-stm32f4/fmc.h | 75 arch/arm/include/asm/arch-stm32f4/gpio.h | 146 +-- arch/arm/include/asm/arch-stm32f4/stm32.h| 14 +-- arch/arm/include/asm/arch-stm32f4/stm32_periph.h | 38 -- arch/arm/include/asm/arch-stm32f7/gpio.h | 116 +- arch/arm/include/asm/arch-stm32f7/stm32.h| 45 +-- arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 23 arch/arm/include/asm/arch-stm32f7/syscfg.h | 9 -- arch/arm/include/asm/arch-stm32h7/gpio.h | 115 +- arch/arm/include/asm/stm32_gpio.h| 115 ++ arch/arm/include/asm/stm32f.h| 22 board/st/stm32f746-disco/stm32f746-disco.c | 1 - drivers/mtd/stm32_flash.c| 2 +- 13 files changed, 144 insertions(+), 577 deletions(-) delete mode 100644 arch/arm/include/asm/arch-stm32f4/fmc.h delete mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_periph.h delete mode 100644 arch/arm/include/asm/arch-stm32f7/stm32_periph.h create mode 100644 arch/arm/include/asm/stm32_gpio.h create mode 100644 arch/arm/include/asm/stm32f.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] arch-stm32f4: Remove fmc.h file
From: Patrice Chotard
fmc.h file is no more used, remove it.
All FMC related defines are declared in drivers/ram/stm32_sdram.c
which is common to all STM32 SoCs.
Signed-off-by: Patrice Chotard
---
arch/arm/include/asm/arch-stm32f4/fmc.h | 75 -
1 file changed, 75 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-stm32f4/fmc.h
diff --git a/arch/arm/include/asm/arch-stm32f4/fmc.h
b/arch/arm/include/asm/arch-stm32f4/fmc.h
deleted file mode 100644
index 7dd5077d0c34..
--- a/arch/arm/include/asm/arch-stm32f4/fmc.h
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- * (C) Copyright 2013
- * Pavel Boldin, Emcraft Systems, pabol...@emcraft.com
- *
- * (C) Copyright 2015
- * Kamil Lulko,
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef _MACH_FMC_H_
-#define _MACH_FMC_H_
-
-struct stm32_fmc_regs {
- u32 sdcr1; /* Control register 1 */
- u32 sdcr2; /* Control register 2 */
- u32 sdtr1; /* Timing register 1 */
- u32 sdtr2; /* Timing register 2 */
- u32 sdcmr; /* Mode register */
- u32 sdrtr; /* Refresh timing register */
- u32 sdsr; /* Status register */
-};
-
-/*
- * FMC registers base
- */
-#define STM32_SDRAM_FMC_BASE 0xA140
-#define STM32_SDRAM_FMC((struct stm32_fmc_regs
*)STM32_SDRAM_FMC_BASE)
-
-/* Control register SDCR */
-#define FMC_SDCR_RPIPE_SHIFT 13 /* RPIPE bit shift */
-#define FMC_SDCR_RBURST_SHIFT 12 /* RBURST bit shift */
-#define FMC_SDCR_SDCLK_SHIFT 10 /* SDRAM clock divisor shift */
-#define FMC_SDCR_WP_SHIFT 9 /* Write protection shift */
-#define FMC_SDCR_CAS_SHIFT 7 /* CAS latency shift */
-#define FMC_SDCR_NB_SHIFT 6 /* Number of banks shift */
-#define FMC_SDCR_MWID_SHIFT4 /* Memory width shift */
-#define FMC_SDCR_NR_SHIFT 2 /* Number of row address bits shift */
-#define FMC_SDCR_NC_SHIFT 0 /* Number of col address bits shift */
-
-/* Timings register SDTR */
-#define FMC_SDTR_TMRD_SHIFT0 /* Load mode register to active */
-#define FMC_SDTR_TXSR_SHIFT4 /* Exit self-refresh time */
-#define FMC_SDTR_TRAS_SHIFT8 /* Self-refresh time */
-#define FMC_SDTR_TRC_SHIFT 12 /* Row cycle delay */
-#define FMC_SDTR_TWR_SHIFT 16 /* Recovery delay */
-#define FMC_SDTR_TRP_SHIFT 20 /* Row precharge delay */
-#define FMC_SDTR_TRCD_SHIFT24 /* Row-to-column delay */
-
-
-#define FMC_SDCMR_NRFS_SHIFT 5
-
-#define FMC_SDCMR_MODE_NORMAL 0
-#define FMC_SDCMR_MODE_START_CLOCK 1
-#define FMC_SDCMR_MODE_PRECHARGE 2
-#define FMC_SDCMR_MODE_AUTOREFRESH 3
-#define FMC_SDCMR_MODE_WRITE_MODE 4
-#define FMC_SDCMR_MODE_SELFREFRESH 5
-#define FMC_SDCMR_MODE_POWERDOWN 6
-
-#define FMC_SDCMR_BANK_1 (1 << 4)
-#define FMC_SDCMR_BANK_2 (1 << 3)
-
-#define FMC_SDCMR_MODE_REGISTER_SHIFT 9
-
-#define FMC_SDSR_BUSY (1 << 5)
-
-#define FMC_BUSY_WAIT()do { \
- __asm__ __volatile__ ("dsb" : : : "memory"); \
- while (STM32_SDRAM_FMC->sdsr & FMC_SDSR_BUSY) \
- ; \
- } while (0)
-
-
-#endif /* _MACH_FMC_H_ */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] arch-stm32: Remove stm32_periph.h
From: Patrice Chotard
Remove arch/arm/include/asm/arch-stm32fx/stm32_periph.h
as all defines or enums are no more used.
Signed-off-by: Patrice Chotard
---
arch/arm/include/asm/arch-stm32f4/stm32_periph.h | 38
arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 23 --
board/st/stm32f746-disco/stm32f746-disco.c | 1 -
3 files changed, 62 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_periph.h
delete mode 100644 arch/arm/include/asm/arch-stm32f7/stm32_periph.h
diff --git a/arch/arm/include/asm/arch-stm32f4/stm32_periph.h
b/arch/arm/include/asm/arch-stm32f4/stm32_periph.h
deleted file mode 100644
index fa45a5c0f1cb..
--- a/arch/arm/include/asm/arch-stm32f4/stm32_periph.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
- * Author(s): Vikas Manocha, for STMicroelectronics.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __ASM_ARM_ARCH_PERIPH_H
-#define __ASM_ARM_ARCH_PERIPH_H
-
-/*
- * Peripherals required for pinmux configuration. List will
- * grow with support for more devices getting added.
- * Numbering based on interrupt table.
- *
- */
-enum periph_id {
- UART1_GPIOA_9_10 = 0,
- UART2_GPIOD_5_6,
-};
-
-enum periph_clock {
- USART1_CLOCK_CFG = 0,
- USART2_CLOCK_CFG,
- GPIO_A_CLOCK_CFG,
- GPIO_B_CLOCK_CFG,
- GPIO_C_CLOCK_CFG,
- GPIO_D_CLOCK_CFG,
- GPIO_E_CLOCK_CFG,
- GPIO_F_CLOCK_CFG,
- GPIO_G_CLOCK_CFG,
- GPIO_H_CLOCK_CFG,
- GPIO_I_CLOCK_CFG,
- GPIO_J_CLOCK_CFG,
- GPIO_K_CLOCK_CFG,
-};
-
-#endif /* __ASM_ARM_ARCH_PERIPH_H */
diff --git a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
deleted file mode 100644
index 38d4ade13d2f..
--- a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
- * Author(s): Vikas Manocha, for STMicroelectronics.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __ASM_ARM_ARCH_PERIPH_H
-#define __ASM_ARM_ARCH_PERIPH_H
-
-/*
- * Peripherals required for pinmux configuration. List will
- * grow with support for more devices getting added.
- * Numbering based on interrupt table.
- *
- */
-enum periph_id {
- PERIPH_ID_USART1 = 37,
-
- PERIPH_ID_QUADSPI = 92,
-};
-
-#endif /* __ASM_ARM_ARCH_PERIPH_H */
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c
b/board/st/stm32f746-disco/stm32f746-disco.c
index ec39468fb8a2..05b316fe90a4 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] arch-stm32: Clean arch-stm32f7/syscfg.h
From: Patrice Chotard
Remove all unused defines
Signed-off-by: Patrice Chotard
---
arch/arm/include/asm/arch-stm32f7/syscfg.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/include/asm/arch-stm32f7/syscfg.h
b/arch/arm/include/asm/arch-stm32f7/syscfg.h
index 49e78f203dcd..310eec584f20 100644
--- a/arch/arm/include/asm/arch-stm32f7/syscfg.h
+++ b/arch/arm/include/asm/arch-stm32f7/syscfg.h
@@ -23,16 +23,7 @@ struct stm32_syscfg_regs {
*/
#define STM32_SYSCFG ((struct stm32_syscfg_regs *)STM32_SYSCFG_BASE)
-/* SYSCFG memory remap register */
-#define SYSCFG_MEMRMP_MEM_BOOT BIT(0)
-#define SYSCFG_MEMRMP_SWP_FMC BIT(10)
-
/* SYSCFG peripheral mode configuration register */
-#define SYSCFG_PMC_ADCXDC2 BIT(16)
#define SYSCFG_PMC_MII_RMII_SELBIT(23)
-/* Compensation cell control register */
-#define SYSCFG_CMPCR_CMP_PDBIT(0)
-#define SYSCFG_CMPCR_READY BIT(8)
-
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] arch-stm32: Factorize stm32.h for STM32F4 and F7
From: Patrice Chotard
For STM32F4 and F7 SoCx family, a specific stm32.h file exists.
Some common defines are duplicated or even unused in each of
these stm32.h.
Factorize all common definition in arch/arm/include/asm/stm32f.h and keep
specific definitions in each arch/arm/include/asm/arch-stm32fx/stm32.h.
Signed-off-by: Patrice Chotard
---
arch/arm/include/asm/arch-stm32f4/stm32.h | 14 ++
arch/arm/include/asm/arch-stm32f7/stm32.h | 45 +--
arch/arm/include/asm/stm32f.h | 22 +++
drivers/mtd/stm32_flash.c | 2 +-
4 files changed, 26 insertions(+), 57 deletions(-)
create mode 100644 arch/arm/include/asm/stm32f.h
diff --git a/arch/arm/include/asm/arch-stm32f4/stm32.h
b/arch/arm/include/asm/arch-stm32f4/stm32.h
index 763b18cb5412..86cca059075d 100644
--- a/arch/arm/include/asm/arch-stm32f4/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f4/stm32.h
@@ -11,17 +11,12 @@
#ifndef _MACH_STM32_H_
#define _MACH_STM32_H_
+#include
+
/*
* Peripheral memory map
*/
#define STM32_SYSMEM_BASE 0x1FFF
-#define STM32_PERIPH_BASE 0x4000
-#define STM32_APB1PERIPH_BASE (STM32_PERIPH_BASE + 0x)
-#define STM32_APB2PERIPH_BASE (STM32_PERIPH_BASE + 0x0001)
-#define STM32_AHB1PERIPH_BASE (STM32_PERIPH_BASE + 0x0002)
-#define STM32_AHB2PERIPH_BASE (STM32_PERIPH_BASE + 0x1000)
-
-#define STM32_BUS_MASK 0x
/*
* Register maps
@@ -37,15 +32,10 @@ struct stm32_u_id_regs {
*/
#define STM32_U_ID_BASE(STM32_SYSMEM_BASE + 0x7A10)
#define STM32_U_ID ((struct stm32_u_id_regs *)STM32_U_ID_BASE)
-
-#define FLASH_CNTL_BASE(STM32_AHB1PERIPH_BASE + 0x3C00)
-
static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
[0 ... 3] = 16 * 1024,
[4] = 64 * 1024,
[5 ... 11] =128 * 1024
};
-void stm32_flash_latency_cfg(int latency);
-
#endif /* _MACH_STM32_H_ */
diff --git a/arch/arm/include/asm/arch-stm32f7/stm32.h
b/arch/arm/include/asm/arch-stm32f7/stm32.h
index 40df89142608..3f097548d374 100644
--- a/arch/arm/include/asm/arch-stm32f7/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f7/stm32.h
@@ -8,46 +8,7 @@
#ifndef _ASM_ARCH_HARDWARE_H
#define _ASM_ARCH_HARDWARE_H
-/* STM32F746 */
-#define ITCM_FLASH_BASE0x0020UL
-#define AXIM_FLASH_BASE0x0800UL
-
-#define ITCM_SRAM_BASE 0xUL
-#define DTCM_SRAM_BASE 0x2000UL
-#define SRAM1_BASE 0x2001UL
-#define SRAM2_BASE 0x2004C000UL
-
-#define PERIPH_BASE0x4000UL
-
-#define APB1_PERIPH_BASE (PERIPH_BASE + 0x)
-#define APB2_PERIPH_BASE (PERIPH_BASE + 0x0001)
-#define AHB1_PERIPH_BASE (PERIPH_BASE + 0x0002)
-#define AHB2_PERIPH_BASE (PERIPH_BASE + 0x1000)
-#define AHB3_PERIPH_BASE (PERIPH_BASE + 0x2000)
-
-#define USART2_BASE(APB1_PERIPH_BASE + 0x4400)
-#define USART3_BASE(APB1_PERIPH_BASE + 0x4800)
-#define PWR_BASE (APB1_PERIPH_BASE + 0x7000)
-
-#define USART1_BASE(APB2_PERIPH_BASE + 0x1000)
-#define USART6_BASE(APB2_PERIPH_BASE + 0x1400)
-#define STM32_SYSCFG_BASE (APB2_PERIPH_BASE + 0x3800)
-
-#define STM32_GPIOA_BASE (AHB1_PERIPH_BASE + 0x)
-#define STM32_GPIOB_BASE (AHB1_PERIPH_BASE + 0x0400)
-#define STM32_GPIOC_BASE (AHB1_PERIPH_BASE + 0x0800)
-#define STM32_GPIOD_BASE (AHB1_PERIPH_BASE + 0x0C00)
-#define STM32_GPIOE_BASE (AHB1_PERIPH_BASE + 0x1000)
-#define STM32_GPIOF_BASE (AHB1_PERIPH_BASE + 0x1400)
-#define STM32_GPIOG_BASE (AHB1_PERIPH_BASE + 0x1800)
-#define STM32_GPIOH_BASE (AHB1_PERIPH_BASE + 0x1C00)
-#define STM32_GPIOI_BASE (AHB1_PERIPH_BASE + 0x2000)
-#define STM32_GPIOJ_BASE (AHB1_PERIPH_BASE + 0x2400)
-#define STM32_GPIOK_BASE (AHB1_PERIPH_BASE + 0x2800)
-#define FLASH_CNTL_BASE(AHB1_PERIPH_BASE + 0x3C00)
-
-
-#define SDRAM_FMC_BASE (AHB3_PERIPH_BASE + 0x4140)
+#include
static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
[0 ... 3] = 32 * 1024,
@@ -55,8 +16,4 @@ static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
[5 ... 7] = 256 * 1024
};
-#define STM32_BUS_MASK GENMASK(31, 16)
-
-void stm32_flash_latency_cfg(int latency);
-
#endif /* _ASM_ARCH_HARDWARE_H */
diff --git a/arch/arm/include/asm/stm32f.h b/arch/arm/include/asm/stm32f.h
new file mode 100644
index ..7bea20b4d06a
--- /dev/null
+++ b/arch/arm/include/asm/stm32f.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Patrice Chotard, for STMicroelectronics.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_ARCH_STM32F_H
+#define _ASM_ARCH_STM32F_H
+
+#define STM32_PERIPH_BASE 0x4000UL
+
+#define STM32_APB2_PERIPH_BASE (STM32_PERIPH
[U-Boot] [PATCH 2/5] arch-stm32: Move gpio.h for STM32 SoCs in include/asm/
From: Patrice Chotard
Instead to have 3 identical gpio.h for all STM32 SoCs,
migrate them in one file in include/asm.
Signed-off-by: Patrice Chotard
---
arch/arm/include/asm/arch-stm32f4/gpio.h | 146 +--
arch/arm/include/asm/arch-stm32f7/gpio.h | 116 +---
arch/arm/include/asm/arch-stm32h7/gpio.h | 115 +---
arch/arm/include/asm/stm32_gpio.h| 115
4 files changed, 118 insertions(+), 374 deletions(-)
create mode 100644 arch/arm/include/asm/stm32_gpio.h
diff --git a/arch/arm/include/asm/arch-stm32f4/gpio.h
b/arch/arm/include/asm/arch-stm32f4/gpio.h
index 6173fa13..bb4427e6f4ac 100644
--- a/arch/arm/include/asm/arch-stm32f4/gpio.h
+++ b/arch/arm/include/asm/arch-stm32f4/gpio.h
@@ -11,150 +11,6 @@
#ifndef _STM32_GPIO_H_
#define _STM32_GPIO_H_
-#if (CONFIG_STM32_USART == 1)
-#define STM32_GPIO_PORT_X STM32_GPIO_PORT_A
-#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_9
-#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_10
-#define STM32_GPIO_USARTSTM32_GPIO_AF7
-
-#elif (CONFIG_STM32_USART == 2)
-#define STM32_GPIO_PORT_X STM32_GPIO_PORT_D
-#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_5
-#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_6
-#define STM32_GPIO_USARTSTM32_GPIO_AF7
-
-#elif (CONFIG_STM32_USART == 3)
-#define STM32_GPIO_PORT_X STM32_GPIO_PORT_C
-#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_10
-#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_11
-#define STM32_GPIO_USARTSTM32_GPIO_AF7
-
-#elif (CONFIG_STM32_USART == 6)
-#define STM32_GPIO_PORT_X STM32_GPIO_PORT_G
-#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_14
-#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_9
-#define STM32_GPIO_USARTSTM32_GPIO_AF8
-
-#else
-#define STM32_GPIO_PORT_X STM32_GPIO_PORT_A
-#define STM32_GPIO_PIN_TX STM32_GPIO_PIN_9
-#define STM32_GPIO_PIN_RX STM32_GPIO_PIN_10
-#define STM32_GPIO_USARTSTM32_GPIO_AF7
-
-#endif
-
-enum stm32_gpio_port {
- STM32_GPIO_PORT_A = 0,
- STM32_GPIO_PORT_B,
- STM32_GPIO_PORT_C,
- STM32_GPIO_PORT_D,
- STM32_GPIO_PORT_E,
- STM32_GPIO_PORT_F,
- STM32_GPIO_PORT_G,
- STM32_GPIO_PORT_H,
- STM32_GPIO_PORT_I
-};
-
-enum stm32_gpio_pin {
- STM32_GPIO_PIN_0 = 0,
- STM32_GPIO_PIN_1,
- STM32_GPIO_PIN_2,
- STM32_GPIO_PIN_3,
- STM32_GPIO_PIN_4,
- STM32_GPIO_PIN_5,
- STM32_GPIO_PIN_6,
- STM32_GPIO_PIN_7,
- STM32_GPIO_PIN_8,
- STM32_GPIO_PIN_9,
- STM32_GPIO_PIN_10,
- STM32_GPIO_PIN_11,
- STM32_GPIO_PIN_12,
- STM32_GPIO_PIN_13,
- STM32_GPIO_PIN_14,
- STM32_GPIO_PIN_15
-};
-
-enum stm32_gpio_mode {
- STM32_GPIO_MODE_IN = 0,
- STM32_GPIO_MODE_OUT,
- STM32_GPIO_MODE_AF,
- STM32_GPIO_MODE_AN
-};
-
-enum stm32_gpio_otype {
- STM32_GPIO_OTYPE_PP = 0,
- STM32_GPIO_OTYPE_OD
-};
-
-enum stm32_gpio_speed {
- STM32_GPIO_SPEED_2M = 0,
- STM32_GPIO_SPEED_25M,
- STM32_GPIO_SPEED_50M,
- STM32_GPIO_SPEED_100M
-};
-
-enum stm32_gpio_pupd {
- STM32_GPIO_PUPD_NO = 0,
- STM32_GPIO_PUPD_UP,
- STM32_GPIO_PUPD_DOWN
-};
-
-enum stm32_gpio_af {
- STM32_GPIO_AF0 = 0,
- STM32_GPIO_AF1,
- STM32_GPIO_AF2,
- STM32_GPIO_AF3,
- STM32_GPIO_AF4,
- STM32_GPIO_AF5,
- STM32_GPIO_AF6,
- STM32_GPIO_AF7,
- STM32_GPIO_AF8,
- STM32_GPIO_AF9,
- STM32_GPIO_AF10,
- STM32_GPIO_AF11,
- STM32_GPIO_AF12,
- STM32_GPIO_AF13,
- STM32_GPIO_AF14,
- STM32_GPIO_AF15
-};
-
-struct stm32_gpio_dsc {
- enum stm32_gpio_portport;
- enum stm32_gpio_pin pin;
-};
-
-struct stm32_gpio_ctl {
- enum stm32_gpio_modemode;
- enum stm32_gpio_otype otype;
- enum stm32_gpio_speed speed;
- enum stm32_gpio_pupdpupd;
- enum stm32_gpio_af af;
-};
-
-struct stm32_gpio_regs {
- u32 moder; /* GPIO port mode */
- u32 otyper; /* GPIO port output type */
- u32 ospeedr;/* GPIO port output speed */
- u32 pupdr; /* GPIO port pull-up/pull-down */
- u32 idr;/* GPIO port input data */
- u32 odr;/* GPIO port output data */
- u32 bsrr; /* GPIO port bit set/reset */
- u32 lckr; /* GPIO port configuration lock */
- u32 afr[2]; /* GPIO alternate function */
-};
-
-struct stm32_gpio_priv {
- struct stm32_gpio_regs *regs;
-};
-
-static inline unsigned stm32_gpio_to_port(unsigned gpio)
-{
- return gpio / 16;
-}
-
-static inline unsigned stm32_gpio_to_pin(unsigned gpio)
-{
- return gpio % 16;
-}
+#include
#endif /* _STM32_GPIO_H_ */
diff --git a/arch/arm/include/asm/arch-stm32f7/gpio.h
b/arch/arm/include/asm/arch-stm32f7/gpio.h
index 68ecdc89e6f3..c5de7981c0d0 100644
--- a/arch/arm/include/asm/arch-stm32f7/gpio.h
+++ b/arch/arm/include/asm/arch-stm32f7/gpio.h
@@ -7,120 +7,6 @@
#ifndef _S
Re: [U-Boot] [PATCH v2 1/2] i.MX6: nand: add nandbcb update command
Hi Jagan,
On Tue, Feb 6, 2018 at 5:41 PM, Jagan Teki wrote:
> ---
> Changes for v2:
> - Fixed commit message notes
> - Updated proper commit message
> - Update doc/README.imx6 with NAND boot details
> - Fixed long length variable names.
> - Fixed Gigantic variable name.
> - NULL checks for kzalloc
> - Move Kconfig option in separate patch
> - Fixed checkpatch warninigs
Thanks for reworking this patch. It looks much better!
>
> arch/arm/include/asm/mach-imx/imx-nandbcb.h | 107
> arch/arm/include/asm/mach-imx/mxs-nand.h| 15 ++
> arch/arm/mach-imx/Makefile | 1 +
> arch/arm/mach-imx/cmd_nandbcb.c | 371
>
> doc/README.imx6 | 77 ++
> drivers/mtd/nand/mxs_nand.c | 8 +-
> 6 files changed, 575 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/include/asm/mach-imx/imx-nandbcb.h
> create mode 100644 arch/arm/include/asm/mach-imx/mxs-nand.h
> create mode 100644 arch/arm/mach-imx/cmd_nandbcb.c
>
> diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> new file mode 100644
> index 000..807b16b
> --- /dev/null
> +++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> @@ -0,0 +1,107 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef _IMX_NAND_BCB_H_
> +#define _IMX_NAND_BCB_H_
> +
> +#define FCB_FINGERPRINT0x20424346 /* 'FCB' */
> +#define FCB_VERSION_1 0x0100
> +
> +#define DBBT_FINGERPRINT2 0x54424244 /* 'DBBT' */
> +#define DBBT_VERSION_1 0x0100
> +
> +struct dbbt_block {
> + u32 checksum; /* reserved on i.MX6 */
> + u32 fingerprint;
> + u32 version;
> + u32 numberbb; /* reserved on i.MX6 */
> + u32 dbbtnumofpages;
> +};
> +
> +struct fcb_block {
> + u32 checksum; /* First fingerprint in first byte */
> + u32 fingerprint;/* 2nd fingerprint at byte 4 */
> + u32 version;/* 3rd fingerprint at byte 8 */
> + u8 datasetup;
> + u8 datahold;
> + u8 addresssetup;
> + u8 dsample_time;
> +
> + /* These are for application use only and not for ROM. */
> + u8 nandtiming;
> + u8 rea;
> + u8 rloh;
> + u8 rhoh;
> + u32 pagesize; /* 2048 for 2K pages, 4096 for 4K pages */
> + u32 oob_pagesize; /* 2112 for 2K pages, 4314 for 4K pages */
> + u32 sectors;/* Number of 2K sections per block */
> + u32 nr_nand;/* Total Number of NANDs - not used by ROM */
> + u32 nr_die; /* Number of separate chips in this NAND */
> + u32 celltype; /* MLC or SLC */
> + u32 ecc_type; /* Type of ECC, can be one of BCH-0-20 */
> + u32 ecc_nr; /* Number of bytes for Block0 - BCH */
> +
> + /* Block size in bytes for all blocks other than Block0 - BCH */
> + u32 ecc_size;
> + u32 ecc_level; /* Ecc level for Block 0 - BCH */
> + u32 meta_size; /* Metadata size - BCH */
> + /* Number of blocks per page for ROM use - BCH */
> + u32 nr_blocks;
> + u32 ecc_type_sdk; /* Type of ECC, can be one of BCH-0-20 */
> + u32 ecc_nr_sdk; /* Number of bytes for Block0 - BCH */
> + /* Block size in bytes for all blocks other than Block0 - BCH */
> + u32 ecc_size_sdk;
> + u32 ecc_level_sdk; /* Ecc level for Block 0 - BCH */
> + /* Number of blocks per page for SDK use - BCH */
> + u32 nr_blocks_sdk;
> + u32 meta_size_sdk; /* Metadata size - BCH */
> + u32 erase_th; /* To set into BCH_MODE register */
> +
> + /* 0: normal boot
> +* 1: to load patch starting next to FCB
> +*/
Multi-line style is wrong here.
> +static int nandbcb_update(struct mtd_info *mtd, loff_t off, size_t size,
> + size_t maxsize, const u_char *buf)
> +{
> + nand_erase_options_t opts;
> + struct fcb_block *fcb;
> + struct dbbt_block *dbbt;
> + loff_t fw1_off, fw2_off;
> + void *fwbuf, *fcb_raw_page, *dbbt_page, *dbbt_data_page;
> + int nr_blks, nr_blks_fcb, nr_blks_fw, fw1_blk, fw2_blk;
> + size_t fwsize, dummy;
> + int i, ret;
> +
> + /* erase */
> + memset(&opts, 0, sizeof(opts));
> + opts.offset = off;
> + opts.length = maxsize - 1;
> + ret = nand_erase_opts(mtd, &opts);
> + if (ret) {
> + printf("%s: erase failed\n", __func__);
You could also show the 'ret' value for helping debugging.
> + return ret;
> + }
> +
> + /*
> +* Reference documentation from i.MX6DQRM section 8.5.2.2
> +*
> +* Nand Boot Control Block(BCB) contains two data structures,
> +* - Firmware Configuration Block(FCB)
Re: [U-Boot] [PATCH v4 2/2] Enable test case with A20-OLinuXino-Lime2
On 02/07/2018 09:25 AM, Jagan Teki wrote: On Wed, Feb 7, 2018 at 12:35 PM, Stefan Mavrodiev wrote: On 02/07/2018 08:39 AM, Jagan Teki wrote: On Wed, Feb 7, 2018 at 12:00 PM, Stefan Mavrodiev wrote: On 02/06/2018 06:48 PM, Jagan Teki wrote: On Tue, Feb 6, 2018 at 6:44 PM, Stefan Mavrodiev wrote: Driver testing is done with A20-OLinuXino-Lime2. Testing requirements are: - Exposing spi0 alternative pins in the dts file - Add alias node, enabling driver probing - Add flash sub-node of spi - Enable spi flash related options in the defconfig file The testing log is: U-Boot SPL 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - 14:40:07 +0200) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from FEL Why FEL? can't it boot from SPI-FLASH? Because I previously erased the flash during testing. Here is same, booting from SPI: U-Boot SPL 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 +0200) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from sunxi SPI U-Boot 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Olimex A20-OLinuXino-LIME2 I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from SPI Flash... SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial Out: serial Err: serial Allwinner mUSB OTG (Peripheral) SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: No ethernet found. starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: U-Boot 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - 14:40:07 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Olimex A20-OLinuXino-LIME2 I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from SPI Flash... SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial Out: serial Err: serial Allwinner mUSB OTG (Peripheral) SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: No ethernet found. starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 # Probe device => sf probe SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB How did this resolved w/o sspi? I enabled both CONFIG_SPI_FLASH and CONFIG_DM_SPI_FLASH. The driver-model search for "spi-flash" compatible string, probe it and bind it to the spi driver. # Erase => sf erase 0x1000 0x100 SF: 256 bytes @ 0x1000 Erased: ERROR => sf erase 0x1000 0x1000 SF: 4096 bytes @ 0x1000 Erased: OK # Test => sf test 0 10 SPI flash test: 0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps 1 check: 8881 ticks, 115 KiB/s 0.920 Mbps 2 write: 10824 ticks, 94 KiB/s 0.752 Mbps 3 read: 8872 ticks, 115 KiB/s 0.920 Mbps Test passed 0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps 1 check: 8881 ticks, 115 KiB/s 0.920 Mbps 2 write: 10824 ticks, 94 KiB/s 0.752 Mbps 3 read: 8872 ticks, 115 KiB/s 0.920 Mbps # Try write/read => sf erase 0x1000 0x1000 SF: 4096 bytes @ 0x1000 Erased: OK => md.b 0x5000 0x100 5000: a9 4d b7 68 d2 48 69 c3 09 78 fa d3 33 66 e9 53 .M.h.Hi..x..3f.S 5010: b0 53 af 79 ad 33 79 b1 f1 e3 1d 09 2e ba dd dc .S.y.3y. 5020: 8c eb eb 53 f4 ef 66 89 b5 e9 f6 fb af 73 7f cb ...S..f..s.. 5030: b6 4b bf de c3 fd de bb 9a 53 ad 7d ef 38 6f bf .K...S.}.8o. 5040: fd fb e7 5e e9 db fc 0c fc f7 be 76 ad b9 fd eb ...^...v 5050: f3 ed 5f b5 bb bd ba 8f ff df 1f bf f3 ff fb d7 .._. 5060: b7 6e 9e 5f af 7a 62 ed 7f 66 1b 6d fd fb 47 f7 .n._.zb..f.m..G. 5070: b7 fa f4 db d5 b6 d5 ff 81 e6 f5 d9 8f ef ff db 5080: b7 dd bd fb f3 1d 9d 2f f6 db c8 7f fb cf b9 f3 .../ 5090: 3c ee da 2f b7 5e 6f bc f1 2f 2b cf 3f f2 fb ee <../.^o../+.?... 50a0: 6f 5e 99 c3 3b 51 bd d4 be 40 4e db ab ed f9 77 o^..;Q...@Nw 50b0: 9f f6 7d ed
[U-Boot] [PATCH] Make cmd_get_data_size() a dependency of setexpr
This commit broke the command setexpr. http://git.denx.de/?p=u-boot.git;a=commit;h=6f62d7c4f7a2242a76e19b09dccca6f68776e788 setexpr uses cmd_get_data_size(). If none of I2C, ITEST or PCI is chosen, setexpr will fail to be built. --- include/command.h +++ include/command.h @@ -80,13 +80,14 @@ * void function (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); */ #if defined(CONFIG_CMD_MEMORY) || \ defined(CONFIG_CMD_I2C) || \ defined(CONFIG_CMD_ITEST) || \ - defined(CONFIG_CMD_PCI) + defined(CONFIG_CMD_PCI) || \ + defined(CONFIG_CMD_SETEXPR) #define CMD_DATA_SIZE extern int cmd_get_data_size(char* arg, int default_size); #endif #ifdef CONFIG_CMD_BOOTD extern int do_bootd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] Enable test case with A20-OLinuXino-Lime2
On 02/07/2018 08:39 AM, Jagan Teki wrote: On Wed, Feb 7, 2018 at 12:00 PM, Stefan Mavrodiev wrote: On 02/06/2018 06:48 PM, Jagan Teki wrote: On Tue, Feb 6, 2018 at 6:44 PM, Stefan Mavrodiev wrote: Driver testing is done with A20-OLinuXino-Lime2. Testing requirements are: - Exposing spi0 alternative pins in the dts file - Add alias node, enabling driver probing - Add flash sub-node of spi - Enable spi flash related options in the defconfig file The testing log is: U-Boot SPL 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - 14:40:07 +0200) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from FEL Why FEL? can't it boot from SPI-FLASH? Because I previously erased the flash during testing. Here is same, booting from SPI: U-Boot SPL 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 +0200) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from sunxi SPI U-Boot 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Olimex A20-OLinuXino-LIME2 I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from SPI Flash... SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial Out: serial Err: serial Allwinner mUSB OTG (Peripheral) SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: No ethernet found. starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: U-Boot 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - 14:40:07 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Olimex A20-OLinuXino-LIME2 I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from SPI Flash... SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial Out: serial Err: serial Allwinner mUSB OTG (Peripheral) SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: No ethernet found. starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 # Probe device => sf probe SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB How did this resolved w/o sspi? I enabled both CONFIG_SPI_FLASH and CONFIG_DM_SPI_FLASH. The driver-model search for "spi-flash" compatible string, probe it and bind it to the spi driver. # Erase => sf erase 0x1000 0x100 SF: 256 bytes @ 0x1000 Erased: ERROR => sf erase 0x1000 0x1000 SF: 4096 bytes @ 0x1000 Erased: OK # Test => sf test 0 10 SPI flash test: 0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps 1 check: 8881 ticks, 115 KiB/s 0.920 Mbps 2 write: 10824 ticks, 94 KiB/s 0.752 Mbps 3 read: 8872 ticks, 115 KiB/s 0.920 Mbps Test passed 0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps 1 check: 8881 ticks, 115 KiB/s 0.920 Mbps 2 write: 10824 ticks, 94 KiB/s 0.752 Mbps 3 read: 8872 ticks, 115 KiB/s 0.920 Mbps # Try write/read => sf erase 0x1000 0x1000 SF: 4096 bytes @ 0x1000 Erased: OK => md.b 0x5000 0x100 5000: a9 4d b7 68 d2 48 69 c3 09 78 fa d3 33 66 e9 53 .M.h.Hi..x..3f.S 5010: b0 53 af 79 ad 33 79 b1 f1 e3 1d 09 2e ba dd dc .S.y.3y. 5020: 8c eb eb 53 f4 ef 66 89 b5 e9 f6 fb af 73 7f cb ...S..f..s.. 5030: b6 4b bf de c3 fd de bb 9a 53 ad 7d ef 38 6f bf .K...S.}.8o. 5040: fd fb e7 5e e9 db fc 0c fc f7 be 76 ad b9 fd eb ...^...v 5050: f3 ed 5f b5 bb bd ba 8f ff df 1f bf f3 ff fb d7 .._. 5060: b7 6e 9e 5f af 7a 62 ed 7f 66 1b 6d fd fb 47 f7 .n._.zb..f.m..G. 5070: b7 fa f4 db d5 b6 d5 ff 81 e6 f5 d9 8f ef ff db 5080: b7 dd bd fb f3 1d 9d 2f f6 db c8 7f fb cf b9 f3 .../ 5090: 3c ee da 2f b7 5e 6f bc f1 2f 2b cf 3f f2 fb ee <../.^o../+.?... 50a0: 6f 5e 99 c3 3b 51 bd d4 be 40 4e db ab ed f9 77 o^..;Q...@Nw 50b0: 9f f6 7d ed 54 4a 68 f8 7d ee 53 9b ff ae ef e4 ..}.TJh.}.S. 50c0: 73 ff 3c c7 f7 df f6 be bf 0f 97 96 3d 9b 9e 9f s.<.=... 50d0: e4 49 ca ff be fa ff df f7 7a cf ab 7f 7a 7b cf .I
Re: [U-Boot] [PATCH v4 2/2] Enable test case with A20-OLinuXino-Lime2
On 02/06/2018 06:48 PM, Jagan Teki wrote:
On Tue, Feb 6, 2018 at 6:44 PM, Stefan Mavrodiev wrote:
Driver testing is done with A20-OLinuXino-Lime2. Testing
requirements are:
- Exposing spi0 alternative pins in the dts file
- Add alias node, enabling driver probing
- Add flash sub-node of spi
- Enable spi flash related options in the defconfig file
The testing log is:
U-Boot SPL 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - 14:40:07 +0200)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from FEL
Why FEL? can't it boot from SPI-FLASH?
Because I previously erased the flash during testing. Here is same,
booting from SPI:
U-Boot SPL 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 +0200)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from sunxi SPI
U-Boot 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 +0200)
Allwinner Technology
CPU: Allwinner A20 (SUN7I)
Model: Olimex A20-OLinuXino-LIME2
I2C: ready
DRAM: 1 GiB
MMC: SUNXI SD/MMC: 0
Loading Environment from SPI Flash... SF: Detected w25q128bv with
page size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
In: serial
Out: serial
Err: serial
Allwinner mUSB OTG (Peripheral)
SCSI: SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net: No ethernet found.
starting USB...
USB0: USB EHCI 1.00
USB1: USB OHCI 1.0
USB2: USB EHCI 1.00
USB3: USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:
U-Boot 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - 14:40:07 +0200)
Allwinner Technology
CPU: Allwinner A20 (SUN7I)
Model: Olimex A20-OLinuXino-LIME2
I2C: ready
DRAM: 1 GiB
MMC: SUNXI SD/MMC: 0
Loading Environment from SPI Flash... SF: Detected w25q128bv with page size
256 Bytes, erase size 4 KiB, total 16 MiB
OK
In:serial
Out: serial
Err: serial
Allwinner mUSB OTG (Peripheral)
SCSI: SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net: No ethernet found.
starting USB...
USB0: USB EHCI 1.00
USB1: USB OHCI 1.0
USB2: USB EHCI 1.00
USB3: USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
# Probe device
=> sf probe
SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16
MiB
How did this resolved w/o sspi?
I enabled both CONFIG_SPI_FLASH and CONFIG_DM_SPI_FLASH. The
driver-model search for
"spi-flash" compatible string, probe it and bind it to the spi driver.
# Erase
=> sf erase 0x1000 0x100
SF: 256 bytes @ 0x1000 Erased: ERROR
=> sf erase 0x1000 0x1000
SF: 4096 bytes @ 0x1000 Erased: OK
# Test
=> sf test 0 10
SPI flash test:
0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps
1 check: 8881 ticks, 115 KiB/s 0.920 Mbps
2 write: 10824 ticks, 94 KiB/s 0.752 Mbps
3 read: 8872 ticks, 115 KiB/s 0.920 Mbps
Test passed
0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps
1 check: 8881 ticks, 115 KiB/s 0.920 Mbps
2 write: 10824 ticks, 94 KiB/s 0.752 Mbps
3 read: 8872 ticks, 115 KiB/s 0.920 Mbps
# Try write/read
=> sf erase 0x1000 0x1000
SF: 4096 bytes @ 0x1000 Erased: OK
=> md.b 0x5000 0x100
5000: a9 4d b7 68 d2 48 69 c3 09 78 fa d3 33 66 e9 53.M.h.Hi..x..3f.S
5010: b0 53 af 79 ad 33 79 b1 f1 e3 1d 09 2e ba dd dc.S.y.3y.
5020: 8c eb eb 53 f4 ef 66 89 b5 e9 f6 fb af 73 7f cb...S..f..s..
5030: b6 4b bf de c3 fd de bb 9a 53 ad 7d ef 38 6f bf.K...S.}.8o.
5040: fd fb e7 5e e9 db fc 0c fc f7 be 76 ad b9 fd eb...^...v
5050: f3 ed 5f b5 bb bd ba 8f ff df 1f bf f3 ff fb d7.._.
5060: b7 6e 9e 5f af 7a 62 ed 7f 66 1b 6d fd fb 47 f7.n._.zb..f.m..G.
5070: b7 fa f4 db d5 b6 d5 ff 81 e6 f5 d9 8f ef ff db
5080: b7 dd bd fb f3 1d 9d 2f f6 db c8 7f fb cf b9 f3.../
5090: 3c ee da 2f b7 5e 6f bc f1 2f 2b cf 3f f2 fb ee<../.^o../+.?...
50a0: 6f 5e 99 c3 3b 51 bd d4 be 40 4e db ab ed f9 77o^..;Q...@Nw
50b0: 9f f6 7d ed 54 4a 68 f8 7d ee 53 9b ff ae ef e4..}.TJh.}.S.
50c0: 73 ff 3c c7 f7 df f6 be bf 0f 97 96 3d 9b 9e 9fs.<.=...
50d0: e4 49 ca ff be fa ff df f7 7a cf ab 7f 7a 7b cf.I...z...z{.
50e0: bb c7 9f 3f c1 99 f2 f2 bf ee cf fb d5 b9 e2 e8...?
50f0: ec e8 b2 bd 21 1f 5a ef 7a 7d 9d ad 31 89 3f 6f
Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver
Hi Jagan, > -Original Message- > From: Jagan Teki [mailto:ja...@amarulasolutions.com] > Sent: Tuesday, January 23, 2018 10:41 PM > To: Siva Durga Prasad Paladugu > Cc: U-Boot-Denx ; Siva Durga Prasad Paladugu > > Subject: Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for > ZynqMP qspi driver > > On Thu, Jan 4, 2018 at 1:07 PM, Siva Durga Prasad Paladugu > wrote: > > This patch adds qspi driver support for ZynqMP SoC. This driver is > > responsible for communicating with qspi flash devices. > > > > Signed-off-by: Siva Durga Prasad Paladugu > > --- > > Changes from v1: > > - Rebased on top of latest master > > - Moved macro definitions to .h file as per comment > > - Fixed magic values with macros as per comment > > --- > > arch/arm/cpu/armv8/zynqmp/Kconfig | 7 + > > arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h | 154 ++ > > drivers/spi/Makefile | 1 + > > drivers/spi/zynqmp_qspi.c | 678 > + > > Was this gqspi like linux spi-zynqmp-gqspi.c or different? Yes. > > > 4 files changed, 840 insertions(+) > > create mode 100644 arch/arm/include/asm/arch- > zynqmp/zynqmp_qspi.h > > create mode 100644 drivers/spi/zynqmp_qspi.c > > > > diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig > > b/arch/arm/cpu/armv8/zynqmp/Kconfig > > index 3f922b4..2fe4f71 100644 > > --- a/arch/arm/cpu/armv8/zynqmp/Kconfig > > +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig > > @@ -65,6 +65,13 @@ config PMUFW_INIT_FILE > > Include external PMUFW (Platform Management Unit FirmWare) to > > a Xilinx bootable image (boot.bin). > > > > +config ZYNQMP_QSPI > > + bool "Configure ZynqMP QSPI" > > + select DM_SPI > > + help > > + This option is used to enable ZynqMP QSPI controller driver which > > + is used to communicate with qspi flash devices. > > I've commented this before, what is the reason for adding spi kconfig entry > in arch area instead of drivers/spi? I might have missed it, Will move to drivers/spi > > > + > > config ZYNQMP_USB > > bool "Configure ZynqMP USB" > > > > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h > > b/arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h > > new file mode 100644 > > index 000..5e2926e > > --- /dev/null > > +++ b/arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h > > @@ -0,0 +1,154 @@ > > +/* > > + * (C) Copyright 2014 - 2015 Xilinx > > + * > > + * Xilinx ZynqMP Quad-SPI(QSPI) controller driver (master mode only) > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > + > > +#ifndef _ASM_ARCH_ZYNQMP_QSPI_H_ > > +#define _ASM_ARCH_ZYNQMP_QSPI_H_ > > + > > +#define ZYNQMP_QSPI_GFIFO_STRT_MODE_MASK BIT(29) > > +#define ZYNQMP_QSPI_CONFIG_MODE_EN_MASK(3 << 30) > > +#define ZYNQMP_QSPI_CONFIG_DMA_MODE(2 << 30) > > +#define ZYNQMP_QSPI_CONFIG_CPHA_MASK BIT(2) > > +#define ZYNQMP_QSPI_CONFIG_CPOL_MASK BIT(1) > > + > > +/* QSPI MIO's count for different connection topologies */ > > +#define ZYNQMP_QSPI_MIO_NUM_QSPI0 6 > > +#define ZYNQMP_QSPI_MIO_NUM_QSPI1 5 > > +#define ZYNQMP_QSPI_MIO_NUM_QSPI1_CS 1 > > + > > +/* > > + * QSPI Interrupt Registers bit Masks > > + * > > + * All the four interrupt registers (Status/Mask/Enable/Disable) have > > +the same > > + * bit definitions. > > + */ > > +#define ZYNQMP_QSPI_IXR_TXNFULL_MASK 0x0004 /* QSPI TX > FIFO Overflow */ > > +#define ZYNQMP_QSPI_IXR_TXFULL_MASK0x0008 /* QSPI TX > FIFO is full */ > > +#define ZYNQMP_QSPI_IXR_RXNEMTY_MASK 0x0010 /* QSPI RX > FIFO Not Empty */ > > +#define ZYNQMP_QSPI_IXR_GFEMTY_MASK0x0080 /* QSPI > Generic FIFO Empty */ > > +#define ZYNQMP_QSPI_IXR_ALL_MASK > (ZYNQMP_QSPI_IXR_TXNFULL_MASK | \ > > + ZYNQMP_QSPI_IXR_RXNEMTY_MASK) > > + > > +/* > > + * QSPI Enable Register bit Masks > > + * > > + * This register is used to enable or disable the QSPI controller */ > > +#define ZYNQMP_QSPI_ENABLE_ENABLE_MASK 0x0001 /* QSPI > Enable Bit > > +Mask */ > > + > > +#define ZYNQMP_QSPI_GFIFO_LOW_BUS BIT(14) > > +#define ZYNQMP_QSPI_GFIFO_CS_LOWER BIT(12) > > +#define ZYNQMP_QSPI_GFIFO_UP_BUS BIT(15) > > +#define ZYNQMP_QSPI_GFIFO_CS_UPPER BIT(13) > > +#define ZYNQMP_QSPI_SPI_MODE_QSPI (3 << 10) > > +#define ZYNQMP_QSPI_SPI_MODE_SPI BIT(10) > > +#define ZYNQMP_QSPI_SPI_MODE_DUAL_SPI (2 << 10) > > +#define ZYNQMP_QSPI_IMD_DATA_CS_ASSERT 5 > > +#define ZYNQMP_QSPI_IMD_DATA_CS_DEASSERT 5 > > +#define ZYNQMP_QSPI_GFIFO_TX BIT(16) > > +#define ZYNQMP_QSPI_GFIFO_RX BIT(17) > > +#define ZYNQMP_QSPI_GFIFO_STRIPE_MASK BIT(18) > > +#define ZYNQMP_QSPI_GFIFO_IMD_MASK 0xFF > > +#define ZYNQMP_QSPI_GFIFO_EXP_MASK BIT(9) > > +#define ZYNQMP_QSPI_GFIFO_DATA_XFR_MASKBIT(8) > > +#define ZYNQMP_QSPI_STRT_GEN_FIFO BIT(28) > > +#
Re: [U-Boot] [PATCH v4 2/2] Enable test case with A20-OLinuXino-Lime2
On Wed, Feb 7, 2018 at 2:54 PM, Stefan Mavrodiev wrote: > On 02/07/2018 09:25 AM, Jagan Teki wrote: >> >> On Wed, Feb 7, 2018 at 12:35 PM, Stefan Mavrodiev >> wrote: >>> >>> On 02/07/2018 08:39 AM, Jagan Teki wrote: On Wed, Feb 7, 2018 at 12:00 PM, Stefan Mavrodiev wrote: > > On 02/06/2018 06:48 PM, Jagan Teki wrote: >> >> On Tue, Feb 6, 2018 at 6:44 PM, Stefan Mavrodiev >> wrote: >>> >>> Driver testing is done with A20-OLinuXino-Lime2. Testing >>> requirements are: >>> - Exposing spi0 alternative pins in the dts file >>> - Add alias node, enabling driver probing >>> - Add flash sub-node of spi >>> - Enable spi flash related options in the defconfig file >>> >>> The testing log is: >>> >>> U-Boot SPL 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - >>> 14:40:07 >>> +0200) >>> DRAM: 1024 MiB >>> CPU: 91200Hz, AXI/AHB/APB: 3/2/2 >>> Trying to boot from FEL >> >> Why FEL? can't it boot from SPI-FLASH? > > Because I previously erased the flash during testing. Here is same, > booting > from SPI: > > U-Boot SPL 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 > +0200) > DRAM: 1024 MiB > CPU: 91200Hz, AXI/AHB/APB: 3/2/2 > Trying to boot from sunxi SPI > > > U-Boot 2018.03-rc1-00075-g61ce225 (Feb 07 2018 - 08:21:07 +0200) > Allwinner > Technology > > > CPU: Allwinner A20 (SUN7I) > Model: Olimex A20-OLinuXino-LIME2 > I2C: ready > DRAM: 1 GiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from SPI Flash... SF: Detected w25q128bv with > page > size 256 Bytes, erase size 4 KiB, total 16 MiB > OK > In:serial > Out: serial > Err: serial > Allwinner mUSB OTG (Peripheral) > SCSI: SATA link 0 timeout. > AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode > flags: ncq stag pm led clo only pmp pio slum part ccc apst > Net: No ethernet found. > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > USB2: USB EHCI 1.00 > USB3: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 2 for devices... 1 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) > found > Hit any key to stop autoboot: >> >> >>> U-Boot 2018.03-rc1-00075-g35a689a-dirty (Feb 06 2018 - 14:40:07 >>> +0200) >>> Allwinner Technology >>> >>> CPU: Allwinner A20 (SUN7I) >>> Model: Olimex A20-OLinuXino-LIME2 >>> I2C: ready >>> DRAM: 1 GiB >>> MMC: SUNXI SD/MMC: 0 >>> Loading Environment from SPI Flash... SF: Detected w25q128bv >>> with >>> page >>> size 256 Bytes, erase size 4 KiB, total 16 MiB >>> OK >>> In:serial >>> Out: serial >>> Err: serial >>> Allwinner mUSB OTG (Peripheral) >>> SCSI: SATA link 0 timeout. >>> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode >>> flags: ncq stag pm led clo only pmp pio slum part ccc apst >>> Net: No ethernet found. >>> starting USB... >>> USB0: USB EHCI 1.00 >>> USB1: USB OHCI 1.0 >>> USB2: USB EHCI 1.00 >>> USB3: USB OHCI 1.0 >>> scanning bus 0 for devices... 1 USB Device(s) found >>> scanning bus 2 for devices... 1 USB Device(s) found >>> scanning usb for storage devices... 0 Storage Device(s) >>> found >>> Hit any key to stop autoboot: 0 >>> >>> # Probe device >>> => sf probe >>> SF: Detected w25q128bv with page size 256 Bytes, erase size 4 >>> KiB, >>> total 16 MiB >> >> How did this resolved w/o sspi? > > I enabled both CONFIG_SPI_FLASH and CONFIG_DM_SPI_FLASH. The > driver-model > search for > "spi-flash" compatible string, probe it and bind it to the spi driver. >> >> >>> # Erase >>> => sf erase 0x1000 0x100 >>> SF: 256 bytes @ 0x1000 Erased: ERROR >>> => sf erase 0x1000 0x1000 >>> SF: 4096 bytes @ 0x1000 Erased: OK >>> >>> # Test >>> => sf test 0 10 >>> SPI flash test: >>> 0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps >>> 1 check: 8881 ticks, 115 KiB/s 0.920 Mbps >>> 2 write: 10824 ticks, 94 KiB/s 0.752 Mbps >>> 3 read: 8872 ticks, 115 KiB/s 0.920 Mbps >>> Test passed >>> 0 erase: 12104 ticks, 84 KiB/s 0.672 Mbps >>> 1 check: 8881 ticks, 115 KiB/s 0.920 Mbps >>> 2 write: 10824 ticks, 94 KiB/s 0.752 Mbps >>> 3 read: 8872 ticks, 115 KiB/s 0.920 Mbps >>> >
[U-Boot] [PATCH 4/6] clk: clk_stm32h7: Fix prescaler for Domain 3
From: Patrice Chotard
d1cfgr register was used to calculate the domain 3
prescaler value instead of d3cfgr.
Signed-off-by: Patrice Chotard
---
drivers/clk/clk_stm32h7.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c
index 92db71431e45..9ee2e2e999a2 100644
--- a/drivers/clk/clk_stm32h7.c
+++ b/drivers/clk/clk_stm32h7.c
@@ -635,7 +635,7 @@ static ulong stm32_clk_get_rate(struct clk *clk)
struct stm32_rcc_regs *regs = priv->rcc_base;
ulong sysclk = 0;
u32 gate_offset;
- u32 d1cfgr;
+ u32 d1cfgr, d3cfgr;
/* prescaler table lookups for clock computation */
u16 prescaler_table[8] = {2, 4, 8, 16, 64, 128, 256, 512};
u8 source, idx;
@@ -712,9 +712,10 @@ static ulong stm32_clk_get_rate(struct clk *clk)
break;
case RCC_APB4ENR:
- if (d1cfgr & RCC_D3CFGR_D3PPRE_DIVIDED) {
+ d3cfgr = readl(®s->d3cfgr);
+ if (d3cfgr & RCC_D3CFGR_D3PPRE_DIVIDED) {
/* get D3 domain APB4 prescaler */
- idx = (d1cfgr & RCC_D3CFGR_D3PPRE_DIVIDER) >>
+ idx = (d3cfgr & RCC_D3CFGR_D3PPRE_DIVIDER) >>
RCC_D3CFGR_D3PPRE_SHIFT;
sysclk = sysclk / prescaler_table[idx];
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] board: stm32: switch to DM STM32 timer
From: Patrice Chotard
Use available DM stm32_timer driver instead of dedicated
mach-stm32/stm32fx/timer.c.
Remove all defines or files previously used for timer usage in
arch/arm/include/asm/arch-stm32fx and in arch/arm/mach-stm32/stm32fx
Enable DM STM32_TIMER for STM32F4/F7 and H7.
Signed-off-by: Patrice Chotard
---
arch/arm/include/asm/arch-stm32f4/stm32.h| 3 -
arch/arm/include/asm/arch-stm32f4/stm32_defs.h | 15 ---
arch/arm/include/asm/arch-stm32f7/gpt.h | 53 ---
arch/arm/include/asm/arch-stm32f7/stm32.h| 5 -
arch/arm/include/asm/arch-stm32f7/stm32_defs.h | 15 ---
arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 4 -
arch/arm/mach-stm32/Kconfig | 7 ++
arch/arm/mach-stm32/Makefile | 2 -
arch/arm/mach-stm32/stm32f4/Makefile | 11 ---
arch/arm/mach-stm32/stm32f4/timer.c | 115 ---
arch/arm/mach-stm32/stm32f7/Makefile | 8 --
arch/arm/mach-stm32/stm32f7/timer.c | 113 --
board/st/stm32f746-disco/stm32f746-disco.c | 1 -
drivers/clk/clk_stm32f.c | 15 ---
drivers/spi/stm32_qspi.c | 1 -
include/configs/stm32h743-disco.h| 3 +-
include/configs/stm32h743-eval.h | 3 +-
17 files changed, 9 insertions(+), 365 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_defs.h
delete mode 100644 arch/arm/include/asm/arch-stm32f7/gpt.h
delete mode 100644 arch/arm/include/asm/arch-stm32f7/stm32_defs.h
delete mode 100644 arch/arm/mach-stm32/stm32f4/Makefile
delete mode 100644 arch/arm/mach-stm32/stm32f4/timer.c
delete mode 100644 arch/arm/mach-stm32/stm32f7/Makefile
delete mode 100644 arch/arm/mach-stm32/stm32f7/timer.c
diff --git a/arch/arm/include/asm/arch-stm32f4/stm32.h
b/arch/arm/include/asm/arch-stm32f4/stm32.h
index 0449fcecede0..763b18cb5412 100644
--- a/arch/arm/include/asm/arch-stm32f4/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f4/stm32.h
@@ -38,9 +38,6 @@ struct stm32_u_id_regs {
#define STM32_U_ID_BASE(STM32_SYSMEM_BASE + 0x7A10)
#define STM32_U_ID ((struct stm32_u_id_regs *)STM32_U_ID_BASE)
-#define STM32_RCC_BASE (STM32_AHB1PERIPH_BASE + 0x3800)
-#define STM32_RCC ((struct stm32_rcc_regs *)STM32_RCC_BASE)
-
#define FLASH_CNTL_BASE(STM32_AHB1PERIPH_BASE + 0x3C00)
static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
diff --git a/arch/arm/include/asm/arch-stm32f4/stm32_defs.h
b/arch/arm/include/asm/arch-stm32f4/stm32_defs.h
deleted file mode 100644
index 9a967ac38a1f..
--- a/arch/arm/include/asm/arch-stm32f4/stm32_defs.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/*
- * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
- * Author(s): Vikas Manocha, for STMicroelectronics.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __STM32_DEFS_H__
-#define __STM32_DEFS_H__
-#include
-
-int clock_setup(enum periph_clock);
-
-#endif
-
diff --git a/arch/arm/include/asm/arch-stm32f7/gpt.h
b/arch/arm/include/asm/arch-stm32f7/gpt.h
deleted file mode 100644
index b43dc612c847..
--- a/arch/arm/include/asm/arch-stm32f7/gpt.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
- * Author(s): Vikas Manocha, for STMicroelectronics.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef _STM32_GPT_H
-#define _STM32_GPT_H
-
-#include
-
-struct gpt_regs {
- u32 cr1;
- u32 cr2;
- u32 smcr;
- u32 dier;
- u32 sr;
- u32 egr;
- u32 ccmr1;
- u32 ccmr2;
- u32 ccer;
- u32 cnt;
- u32 psc;
- u32 arr;
- u32 reserved;
- u32 ccr1;
- u32 ccr2;
- u32 ccr3;
- u32 ccr4;
- u32 reserved1;
- u32 dcr;
- u32 dmar;
- u32 tim2_5_or;
-};
-
-struct gpt_regs *const gpt1_regs_ptr =
- (struct gpt_regs *)TIM2_BASE;
-
-/* Timer control1 register */
-#define GPT_CR1_CENBIT(0)
-#define GPT_MODE_AUTO_RELOAD BIT(7)
-
-/* Auto reload register for free running config */
-#define GPT_FREE_RUNNING 0x
-
-/* Timer, HZ specific defines */
-#define CONFIG_STM32_HZ1000
-
-/* Timer Event Generation registers */
-#define TIM_EGR_UG BIT(0)
-
-#endif
diff --git a/arch/arm/include/asm/arch-stm32f7/stm32.h
b/arch/arm/include/asm/arch-stm32f7/stm32.h
index f54e6f195575..40df89142608 100644
--- a/arch/arm/include/asm/arch-stm32f7/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f7/stm32.h
@@ -25,7 +25,6 @@
#define AHB2_PERIPH_BASE (PERIPH_BASE + 0x1000)
#define AHB3_PERIPH_BASE (PERIPH_BASE + 0x2000)
-#define TIM2_BASE (APB1_PERIPH_BASE + 0x)
#define USART2_BASE(APB1_PERIPH_BASE + 0x4400)
#define USART3_BASE(APB
[U-Boot] [PATCH 5/6] ARM: dts: stm32: Add timer support for STM32F7
From: Patrice Chotard
Add missing timer node to enable timer5 for STM32F7 SoCs family
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32f7-u-boot.dtsi | 8
arch/arm/dts/stm32f746.dtsi | 7 +++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/dts/stm32f7-u-boot.dtsi b/arch/arm/dts/stm32f7-u-boot.dtsi
index 9a9e4e5f3718..4a677192a2dd 100644
--- a/arch/arm/dts/stm32f7-u-boot.dtsi
+++ b/arch/arm/dts/stm32f7-u-boot.dtsi
@@ -1,3 +1,11 @@
+/{
+ soc {
+ timer5: timer@4c00 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
+
&pinctrl {
usart1_pins_a: usart1@0 {
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 46d148eab2c8..8c6fa133e0ab 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -323,6 +323,13 @@
pinctrl-names = "default", "opendrain";
max-frequency = <4800>;
};
+
+ timer5: timer@4c00 {
+ compatible = "st,stm32-timer";
+ reg = <0x4c00 0x400>;
+ interrupts = <50>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
+ };
};
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] clk: clk_stm32h7: Fix stm32_clk_get_rate() for timer
From: Patrice Chotard
For timer clock, an additional prescaler is used which
was not taken into account previously.
Signed-off-by: Patrice Chotard
---
drivers/clk/clk_stm32h7.c | 102 --
1 file changed, 90 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c
index c9594d405a0c..92db71431e45 100644
--- a/drivers/clk/clk_stm32h7.c
+++ b/drivers/clk/clk_stm32h7.c
@@ -35,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define RCC_CFGR_SW_CSI1
#define RCC_CFGR_SW_HSE2
#define RCC_CFGR_SW_PLL1 3
+#define RCC_CFGR_TIMPREBIT(15)
#define RCC_PLLCKSELR_PLLSRC_HSI 0
#define RCC_PLLCKSELR_PLLSRC_CSI 1
@@ -339,6 +340,11 @@ struct pll_psc sys_pll_psc = {
.divr = 2,
};
+enum apb {
+ APB1,
+ APB2,
+};
+
int configure_clocks(struct udevice *dev)
{
struct stm32_clk *priv = dev_get_priv(dev);
@@ -562,6 +568,67 @@ static u32 stm32_get_PLL1_rate(struct stm32_rcc_regs *regs,
return -EINVAL;
}
+static u32 stm32_get_apb_psc(struct stm32_rcc_regs *regs, enum apb apb)
+{
+ u16 prescaler_table[8] = {2, 4, 8, 16, 64, 128, 256, 512};
+ u32 d2cfgr = readl(®s->d2cfgr);
+
+ if (apb == APB1) {
+ if (d2cfgr & RCC_D2CFGR_D2PPRE1_DIVIDED)
+ /* get D2 domain APB1 prescaler */
+ return prescaler_table[
+ ((d2cfgr & RCC_D2CFGR_D2PPRE1_DIVIDER)
+ >> RCC_D2CFGR_D2PPRE1_SHIFT)];
+ } else { /* APB2 */
+ if (d2cfgr & RCC_D2CFGR_D2PPRE2_DIVIDED)
+ /* get D2 domain APB2 prescaler */
+ return prescaler_table[
+ ((d2cfgr & RCC_D2CFGR_D2PPRE2_DIVIDER)
+ >> RCC_D2CFGR_D2PPRE2_SHIFT)];
+ }
+
+ return 1;
+};
+
+static u32 stm32_get_timer_rate(struct stm32_clk *priv, u32 sysclk,
+ enum apb apb)
+{
+ struct stm32_rcc_regs *regs = priv->rcc_base;
+u32 psc = stm32_get_apb_psc(regs, apb);
+
+ if (readl(®s->cfgr) & RCC_CFGR_TIMPRE)
+ /*
+* if APB prescaler is configured to a
+* division factor of 1, 2 or 4
+*/
+ switch (psc) {
+ case 1:
+ case 2:
+ case 4:
+ return sysclk;
+ case 8:
+ return sysclk / 2;
+ case 16:
+ return sysclk / 4;
+ default:
+ pr_err("unexpected prescaler value (%d)\n", psc);
+ return 0;
+ }
+ else
+ switch (psc) {
+ case 1:
+ return sysclk;
+ case 2:
+ case 4:
+ case 8:
+ case 16:
+ return sysclk / psc;
+ default:
+ pr_err("unexpected prescaler value (%d)\n", psc);
+ return 0;
+ }
+};
+
static ulong stm32_clk_get_rate(struct clk *clk)
{
struct stm32_clk *priv = dev_get_priv(clk->dev);
@@ -660,31 +727,42 @@ static ulong stm32_clk_get_rate(struct clk *clk)
case RCC_APB1LENR:
case RCC_APB1HENR:
- if (d1cfgr & RCC_D2CFGR_D2PPRE1_DIVIDED) {
- /* get D2 domain APB1 prescaler */
- idx = (d1cfgr & RCC_D2CFGR_D2PPRE1_DIVIDER) >>
- RCC_D2CFGR_D2PPRE1_SHIFT;
- sysclk = sysclk / prescaler_table[idx];
+ /* special case for GPT timers */
+ switch (clk->id) {
+ case TIM14_CK:
+ case TIM13_CK:
+ case TIM12_CK:
+ case TIM7_CK:
+ case TIM6_CK:
+ case TIM5_CK:
+ case TIM4_CK:
+ case TIM3_CK:
+ case TIM2_CK:
+ return stm32_get_timer_rate(priv, sysclk, APB1);
}
debug("%s system clock: freq after APB1 prescaler = %ld\n",
__func__, sysclk);
- return sysclk;
+ return (sysclk / stm32_get_apb_psc(regs, APB1));
break;
case RCC_APB2ENR:
- if (d1cfgr & RCC_D2CFGR_D2PPRE2_DIVIDED) {
- /* get D2 domain APB1 prescaler */
- idx = (d1cfgr & RCC_D2CFGR_D2PPRE2_DIVIDER) >>
- RCC_D2CFGR_D2PPRE2_SHIFT;
- sysclk = sysclk / prescaler_table[idx];
+ /* special case for timers */
+ switch (clk->id) {
+ case TIM17_CK:
+ case TIM16_CK:
+ case TIM15_CK:
+ case TIM8_
[U-Boot] [PATCH 2/6] clk: clk_stm32f: Fix stm32_clk_get_rate() for timer
From: Patrice Chotard
For timer clock, an additionnal prescaler is used which was
not taken into account previously.
Signed-off-by: Patrice Chotard
---
drivers/clk/clk_stm32f.c | 116 ---
include/stm32_rcc.h | 5 ++
2 files changed, 104 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/clk_stm32f.c b/drivers/clk/clk_stm32f.c
index 926b249ff3b7..bde31607cfe9 100644
--- a/drivers/clk/clk_stm32f.c
+++ b/drivers/clk/clk_stm32f.c
@@ -63,6 +63,7 @@
#define RCC_PLLSAICFGR_PLLSAIQ_4 BIT(26)
#define RCC_PLLSAICFGR_PLLSAIR_2 BIT(29)
+#define RCC_DCKCFGRX_TIMPREBIT(24)
#define RCC_DCKCFGRX_CK48MSEL BIT(27)
#define RCC_DCKCFGRX_SDMMC1SEL BIT(28)
#define RCC_DCKCFGR2_SDMMC2SEL BIT(29)
@@ -260,21 +261,88 @@ static unsigned long stm32_clk_pll48clk_rate(struct
stm32_clk *priv,
return sysclk / pllq;
}
-static unsigned long stm32_clk_get_rate(struct clk *clk)
+static bool stm32_get_timpre(struct stm32_clk *priv)
{
- struct stm32_clk *priv = dev_get_priv(clk->dev);
struct stm32_rcc_regs *regs = priv->base;
- u32 sysclk = 0;
- u32 shift = 0;
- u16 pllm, plln, pllp;
+ u32 val;
+
+ if (priv->info.v2) /*stm32f7 case */
+ val = readl(®s->dckcfgr2);
+ else
+ val = readl(®s->dckcfgr);
+ /* get timer prescaler */
+ return !!(val & RCC_DCKCFGRX_TIMPRE);
+}
+
+static u32 stm32_get_hclk_rate(struct stm32_rcc_regs *regs, u32 sysclk)
+{
+ u8 shift;
/* Prescaler table lookups for clock computation */
u8 ahb_psc_table[16] = {
0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 6, 7, 8, 9
};
+
+ shift = ahb_psc_table[(
+ (readl(®s->cfgr) & RCC_CFGR_AHB_PSC_MASK)
+ >> RCC_CFGR_HPRE_SHIFT)];
+
+ return sysclk >> shift;
+};
+
+static u8 stm32_get_apb_shift(struct stm32_rcc_regs *regs, enum apb apb)
+{
+ /* Prescaler table lookups for clock computation */
u8 apb_psc_table[8] = {
0, 0, 0, 0, 1, 2, 3, 4
};
+ if (apb == APB1)
+ return apb_psc_table[(
+ (readl(®s->cfgr) & RCC_CFGR_APB1_PSC_MASK)
+ >> RCC_CFGR_PPRE1_SHIFT)];
+ else /* APB2 */
+ return apb_psc_table[(
+ (readl(®s->cfgr) & RCC_CFGR_APB2_PSC_MASK)
+ >> RCC_CFGR_PPRE2_SHIFT)];
+};
+
+static u32 stm32_get_timer_rate(struct stm32_clk *priv, u32 sysclk,
+ enum apb apb)
+{
+ struct stm32_rcc_regs *regs = priv->base;
+ u8 shift = stm32_get_apb_shift(regs, apb);
+
+ if (stm32_get_timpre(priv))
+ /*
+* if APB prescaler is configured to a
+* division factor of 1, 2 or 4
+*/
+ switch (shift) {
+ case 0:
+ case 1:
+ case 2:
+ return stm32_get_hclk_rate(regs, sysclk);
+ default:
+ return (sysclk >> shift) * 4;
+ }
+ else
+ /*
+* if APB prescaler is configured to a
+* division factor of 1
+*/
+ if (shift == 0)
+ return sysclk;
+ else
+ return (sysclk >> shift) * 2;
+};
+
+static ulong stm32_clk_get_rate(struct clk *clk)
+{
+ struct stm32_clk *priv = dev_get_priv(clk->dev);
+ struct stm32_rcc_regs *regs = priv->base;
+ u32 sysclk = 0;
+ u16 pllm, plln, pllp;
+
if ((readl(®s->cfgr) & RCC_CFGR_SWS_MASK) ==
RCC_CFGR_SWS_PLL) {
pllm = (readl(®s->pllcfgr) & RCC_PLLCFGR_PLLM_MASK);
@@ -293,16 +361,24 @@ static unsigned long stm32_clk_get_rate(struct clk *clk)
* AHB1, AHB2 and AHB3
*/
case STM32F7_AHB1_CLOCK(GPIOA) ... STM32F7_AHB3_CLOCK(QSPI):
- shift = ahb_psc_table[(
- (readl(®s->cfgr) & RCC_CFGR_AHB_PSC_MASK)
- >> RCC_CFGR_HPRE_SHIFT)];
- return sysclk >>= shift;
+ return stm32_get_hclk_rate(regs, sysclk);
/* APB1 CLOCK */
case STM32F7_APB1_CLOCK(TIM2) ... STM32F7_APB1_CLOCK(UART8):
- shift = apb_psc_table[(
- (readl(®s->cfgr) & RCC_CFGR_APB1_PSC_MASK)
- >> RCC_CFGR_PPRE1_SHIFT)];
- return sysclk >>= shift;
+ /* For timer clock, an additionnal prescaler is used*/
+ switch (clk->id) {
+ case STM32F7_APB1_CLOCK(TIM2):
+ case STM32F7_APB1_CLOCK(TIM3):
+ case STM32F7_APB1_CLOCK(TIM4):
+ case STM32F7_APB1_CLOCK(TIM5):
+ case STM32F7_APB1_CLOCK(TIM6):
+ case STM32F7_APB1_CLOCK(TIM7):
+ case STM32F7_A
[U-Boot] [PATCH 0/6] Add DM timer support for STM32 SoCs family
From: Patrice Chotard Add DM timer support for all STM32F7/F4/H7 SoCs family. Clock driver for STM32F4/F7 and H7 need to updated to get timer clock rate. Remove all defines or files previously used for timer usage in arch/arm/include/asm/arch-stm32fx and in arch/arm/mach-stm32/stm32fx. Patrice Chotard (6): timer: stm32: Add timer support for STM32 SoCs family clk: clk_stm32f: Fix stm32_clk_get_rate() for timer clk: clk_stm32h7: Fix stm32_clk_get_rate() for timer clk: clk_stm32h7: Fix prescaler for Domain 3 ARM: dts: stm32: Add timer support for STM32F7 board: stm32: switch to DM STM32 timer arch/arm/dts/stm32f7-u-boot.dtsi | 8 ++ arch/arm/dts/stm32f746.dtsi | 7 ++ arch/arm/include/asm/arch-stm32f4/stm32.h| 3 - arch/arm/include/asm/arch-stm32f4/stm32_defs.h | 15 --- arch/arm/include/asm/arch-stm32f7/gpt.h | 53 - arch/arm/include/asm/arch-stm32f7/stm32.h| 5 - arch/arm/include/asm/arch-stm32f7/stm32_defs.h | 15 --- arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 4 - arch/arm/mach-stm32/Kconfig | 7 ++ arch/arm/mach-stm32/Makefile | 2 - arch/arm/mach-stm32/stm32f4/Makefile | 11 -- arch/arm/mach-stm32/stm32f4/timer.c | 115 --- arch/arm/mach-stm32/stm32f7/Makefile | 8 -- arch/arm/mach-stm32/stm32f7/timer.c | 113 --- board/st/stm32f746-disco/stm32f746-disco.c | 1 - drivers/clk/clk_stm32f.c | 131 +++-- drivers/clk/clk_stm32h7.c| 109 +++--- drivers/spi/stm32_qspi.c | 1 - drivers/timer/Kconfig| 7 ++ drivers/timer/Makefile | 1 + drivers/timer/stm32_timer.c | 138 +++ include/configs/stm32h743-disco.h| 3 +- include/configs/stm32h743-eval.h | 3 +- include/stm32_rcc.h | 5 + 24 files changed, 368 insertions(+), 397 deletions(-) delete mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_defs.h delete mode 100644 arch/arm/include/asm/arch-stm32f7/gpt.h delete mode 100644 arch/arm/include/asm/arch-stm32f7/stm32_defs.h delete mode 100644 arch/arm/mach-stm32/stm32f4/Makefile delete mode 100644 arch/arm/mach-stm32/stm32f4/timer.c delete mode 100644 arch/arm/mach-stm32/stm32f7/Makefile delete mode 100644 arch/arm/mach-stm32/stm32f7/timer.c create mode 100644 drivers/timer/stm32_timer.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] timer: stm32: Add timer support for STM32 SoCs family
From: Patrice Chotard
This timer driver is using GPT Timer (General Purpose Timer)
available on all STM32 SOCs family.
This driver can be used on STM32F4/F7 and H7 SoCs family
Signed-off-by: Patrice Chotard
---
drivers/timer/Kconfig | 7 +++
drivers/timer/Makefile | 1 +
drivers/timer/stm32_timer.c | 138
3 files changed, 146 insertions(+)
create mode 100644 drivers/timer/stm32_timer.c
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 3a1f8311c12e..2c9689672627 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -119,4 +119,11 @@ config ROCKCHIP_TIMER
Select this to enable support for the timer found on
Rockchip devices.
+config STM32_TIMER
+bool "STM32 timer support"
+ depends on TIMER
+ help
+ Select this to enable support for the timer found on
+ STM32 devices.
+
endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index 15e515407e30..a6e7832154a1 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_AG101P_TIMER) += ag101p_timer.o
obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o
+obj-$(CONFIG_STM32_TIMER) += stm32_timer.o
diff --git a/drivers/timer/stm32_timer.c b/drivers/timer/stm32_timer.c
new file mode 100644
index ..344e6fba1e95
--- /dev/null
+++ b/drivers/timer/stm32_timer.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Patrice Chotard, for STMicroelectronics.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Timer control1 register */
+#define CR1_CENBIT(0)
+#define CR1_ARPE BIT(7)
+
+/* Event Generation Register register */
+#define EGR_UG BIT(0)
+
+/* Auto reload register for free running config */
+#define GPT_FREE_RUNNING 0x
+
+struct stm32_timer_regs {
+ u32 cr1;
+ u32 cr2;
+ u32 smcr;
+ u32 dier;
+ u32 sr;
+ u32 egr;
+ u32 ccmr1;
+ u32 ccmr2;
+ u32 ccer;
+ u32 cnt;
+ u32 psc;
+ u32 arr;
+ u32 reserved;
+ u32 ccr1;
+ u32 ccr2;
+ u32 ccr3;
+ u32 ccr4;
+ u32 reserved1;
+ u32 dcr;
+ u32 dmar;
+ u32 tim2_5_or;
+};
+
+struct stm32_timer_priv {
+ struct stm32_timer_regs *base;
+};
+
+static int stm32_timer_get_count(struct udevice *dev, u64 *count)
+{
+ struct stm32_timer_priv *priv = dev_get_priv(dev);
+ struct stm32_timer_regs *regs = priv->base;
+
+ *count = readl(®s->cnt);
+
+ return 0;
+}
+
+static int stm32_timer_probe(struct udevice *dev)
+{
+ struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct stm32_timer_priv *priv = dev_get_priv(dev);
+ struct stm32_timer_regs *regs;
+ struct clk clk;
+ fdt_addr_t addr;
+ int ret;
+ u32 rate, psc;
+
+ addr = dev_read_addr(dev);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ priv->base = (struct stm32_timer_regs *)addr;
+
+ ret = clk_get_by_index(dev, 0, &clk);
+ if (ret < 0)
+ return ret;
+
+ ret = clk_enable(&clk);
+ if (ret) {
+ dev_err(dev, "failed to enable clock\n");
+ return ret;
+ }
+
+ regs = priv->base;
+
+ /* Stop the timer */
+ clrbits_le32(®s->cr1, CR1_CEN);
+
+ /* get timer clock */
+ rate = clk_get_rate(&clk);
+
+ /* we set timer prescaler to obtain a 1MHz timer counter frequency */
+ psc = (rate / CONFIG_SYS_HZ_CLOCK) - 1;
+ writel(psc, ®s->psc);
+
+ /* Set timer frequency to 1MHz */
+ uc_priv->clock_rate = CONFIG_SYS_HZ_CLOCK;
+
+ /* Configure timer for auto-reload */
+ setbits_le32(®s->cr1, CR1_ARPE);
+
+ /* load value for auto reload */
+ writel(GPT_FREE_RUNNING, ®s->arr);
+
+ /* start timer */
+ setbits_le32(®s->cr1, CR1_CEN);
+
+ /* Update generation */
+ setbits_le32(®s->egr, EGR_UG);
+
+ return 0;
+}
+
+static const struct timer_ops stm32_timer_ops = {
+ .get_count = stm32_timer_get_count,
+};
+
+static const struct udevice_id stm32_timer_ids[] = {
+ { .compatible = "st,stm32-timer" },
+ {}
+};
+
+U_BOOT_DRIVER(stm32_timer) = {
+ .name = "stm32_timer",
+ .id = UCLASS_TIMER,
+ .of_match = stm32_timer_ids,
+ .priv_auto_alloc_size = sizeof(struct stm32_timer_priv),
+ .probe = stm32_timer_probe,
+ .ops = &stm32_timer_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
+
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ls1088a: qspi: Enable XIP mode above 16 MB addresses
> -Original Message- > From: York Sun > Sent: Tuesday, February 06, 2018 10:38 PM > To: Rajat Srivastava ; u-boot@lists.denx.de > Subject: Re: [PATCH] ls1088a: qspi: Enable XIP mode above 16 MB addresses > > On 02/06/2018 02:59 AM, Rajat Srivastava wrote: > > > > > > > >> How do you put the image into it to begin with? Don't tell me you > >> were using an external tool or a hacked version of older U-Boot. > >> > > This patch enables data read above 16MB using AHB (on Uboot prompt) > > and does not involve our QSPI driver. It is equivalent to reading from DDR > > via > cp or md commands. > > Whereas writing to flash is possible via IPS mode which involves our > > driver (using sf commands). > > > OK. So we are still far away to have the full flash supported. > AHB Write is not supported by QSPI hardware. Rajat ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it
Dear Faiz Abbas, In message <1517564875-10237-1-git-send-email-faiz_ab...@ti.com> you wrote: > When booting from a non-MMC device, the MMC sub-system may not be > initialized when the environment is first accessed. > We need to make sure that the MMC sub-system is ready in even a non-MMC > boot case. > > Therefore, initialize mmc during .init() of environment. Do I understand correctly that you will always initialize the MMC sub-system if it is a candidate for reading the environment, even when the environment is read from elsewhere? In this case I hereby NAK this patch. U-Boot shall always use lazy initialization and never ever initialize hardware which it does not really use - see especially item 2 at [1]. [1] http://www.denx.de/wiki/U-Boot/DesignPrinciples Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The management question ... is not _whether_ to build a pilot system and throw it away. You _will_ do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. - Fred Brooks, "The Mythical Man Month" ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 06.02.2018 09:20, Joakim Tjernlund wrote:
> > On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> >
> > .
> > > > Reviewed-by: Andre Przywara
> > > > Reviewed-by: Simon Glass
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > >env/env.c | 80
> > > > +++-
> > > >1 file changed, 50 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/env/env.c b/env/env.c
> > > > index 906f28ee50a1..1182fdb545db 100644
> > > > --- a/env/env.c
> > > > +++ b/env/env.c
> > > > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum
> > > > env_location loc)
> > > >return NULL;
> > > >}
> > > >
> > > > +static enum env_location env_locations[] = {
> >
> > Don't use static/global variables. They cause a lot of relocation work/size
> > and is less flexible.
>
> In this specific case, I think this array should be const anyway, would
> that prevent the relocation problems you see?
>
> > There is no way to #define ENVL_EEPROM to a function
> > when a variable.
>
> ENVL_EEPROM is an enum value, why would you define it to a function?
I got boards that very similar but differ in where/how env. is stored, like
different
flash so I need to be able to select at runtime how get my env., I haven't
looked if this particular area is affected but ideally I would like if all
env. related "constants" could be impl. with a function instead.
Also, using static/global vars takes more space than simple assignments in
code, ideally
everything needed early (before reloc/ in SPL) should avoid relocations to save
space.
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
Hi, On Tue, Jan 30, 2018 at 11:02:49PM +, York Sun wrote: > On 01/30/2018 12:16 PM, York Sun wrote: > > On 01/30/2018 11:40 AM, York Sun wrote: > >> On 01/30/2018 12:19 AM, Simon Goldschmidt wrote: > >>> On 23.01.2018 21:16, Maxime Ripard wrote: > Now that we have everything in place to support multiple environment, > let's > make sure the current code can use it. > > The priority used between the various environment is the same one that > was > used in the code previously. > > At read / init times, the highest priority environment is going to be > detected, > >>> > >>> Does priority handling really work here? Most env drivers seem to ignore > >>> the return value of env_import and may thus return success although > >>> importing the environment failed (only reading the data from the device > >>> succeeded). > >>> > >>> This is from reading the code, I haven't had a chance to test this, yet. > >> > >> It is broken on my LS1043ARDB with simply NOR flash. I am trying to > >> determine what went wrong. > >> > > > > I found the problem. The variable "env_load_location" is static. It is > > probably not write-able during booting from flash. It is expected to be > > set during ENVOP_INIT. But if I print this variable, it has > > ENVL_UNKNOWN. I can make it work by moving env_load_location to global > > data structure. That would work for me. > > That being said, this addition of multiple environments really slows > > down the booting process for me. I see every time env_get_char() is > > called, env_driver_lookup() runs. A simple call of env_get_f() gets > > slowed down dramatically. I didn't find out where the most time is spent > > yet. > > > > Does anyone else experience this unbearable slowness? > > > > I found the problem. In patch #3 in this series, the default get_char() > was dropped so there is no driver for a plain NOR flash. A quick (and > maybe dirty) fix is this > > > diff --git a/env/env.c b/env/env.c > index edfb575..210bae2 100644 > --- a/env/env.c > +++ b/env/env.c > @@ -159,7 +159,7 @@ int env_get_char(int index) > int ret; > > if (!drv->get_char) > - continue; > + return *(uchar *)(gd->env_addr + index); > > if (!env_has_inited(drv->location)) > continue; And this too. > With this temporary fix, my flash chip works again and I can boot all > the way up in a timely manner. I still don't like to call > env_driver_lookup() thousands of times to get a simple env variable. > > Can Maxime post a quick post soon? Given that you already made all the debugging, and the patches, and I have no way to test, I guess it would make more sense if you did it :) Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On Thu, 1970-01-01 at 00:00 +, Maxime Ripard wrote:
> Hi,
>
> On Tue, Feb 06, 2018 at 08:20:49AM +, Joakim Tjernlund wrote:
> > On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> >
> > .
> > > > Reviewed-by: Andre Przywara
> > > > Reviewed-by: Simon Glass
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > > env/env.c | 80
> > > > +++-
> > > > 1 file changed, 50 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/env/env.c b/env/env.c
> > > > index 906f28ee50a1..1182fdb545db 100644
> > > > --- a/env/env.c
> > > > +++ b/env/env.c
> > > > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum
> > > > env_location loc)
> > > > return NULL;
> > > > }
> > > >
> > > > +static enum env_location env_locations[] = {
> >
> > Don't use static/global variables. They cause a lot of relocation work/size
> > and is less flexible. There is no way to #define ENVL_EEPROM to a function
> > when a variable.
>
> Is that last sentence truncated?
>
> Can you elaborate a bit more on what is the source of the relocation
> issues you're mentionning? Is that because of the section it ends up
> in?
Mainly that its adds relocation entries that take up space, more space than
doing
a simple assignment directly in code.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On 06.02.2018 09:20, Joakim Tjernlund wrote:
On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
.
Reviewed-by: Andre Przywara
Reviewed-by: Simon Glass
Signed-off-by: Maxime Ripard
---
env/env.c | 80 +++-
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/env/env.c b/env/env.c
index 906f28ee50a1..1182fdb545db 100644
--- a/env/env.c
+++ b/env/env.c
@@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum
env_location loc)
return NULL;
}
+static enum env_location env_locations[] = {
Don't use static/global variables. They cause a lot of relocation work/size
and is less flexible.
In this specific case, I think this array should be const anyway, would
that prevent the relocation problems you see?
There is no way to #define ENVL_EEPROM to a function
when a variable.
ENVL_EEPROM is an enum value, why would you define it to a function?
Simon
Jocke
+#ifdef CONFIG_ENV_IS_IN_EEPROM
+ ENVL_EEPROM,
+#endif
+#ifdef CONFIG_ENV_IS_IN_FAT
+ ENVL_FAT,
+#endif
+#ifdef CONFIG_ENV_IS_IN_FLASH
+ ENVL_FLASH,
+#endif
+#ifdef CONFIG_ENV_IS_IN_MMC
+ ENVL_MMC,
+#endif
+#ifdef CONFIG_ENV_IS_IN_NAND
+ ENVL_NAND,
+#endif
+#ifdef CONFIG_ENV_IS_IN_NVRAM
+ ENVL_NVRAM,
+#endif
+#ifdef CONFIG_ENV_IS_IN_REMOTE
+ ENVL_REMOTE,
+#endif
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+ ENVL_SPI_FLASH,
+#endif
+#ifdef CONFIG_ENV_IS_IN_UBI
+ ENVL_UBI,
+#endif
+#ifdef CONFIG_ENV_IS_NOWHERE
+ ENVL_NOWHERE,
+#endif
+};
+
+static enum env_location env_load_location = ENVL_UNKNOWN;
+
/**
* env_get_location() - Returns the best env location for a board
* @op: operations performed on the environment
@@ -45,36 +80,21 @@ static struct env_driver *_env_driver_lookup(enum
env_location loc)
*/
static enum env_location env_get_location(enum env_operation op, int prio)
{
- /*
- * We support a single environment, so any environment asked
- * with a priority that is not zero is out of our supported
- * bounds.
- */
- if (prio >= 1)
- return ENVL_UNKNOWN;
-
- if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
- return ENVL_EEPROM;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
- return ENVL_FAT;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_FLASH)
- return ENVL_FLASH;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
- return ENVL_MMC;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_NAND)
- return ENVL_NAND;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_NVRAM)
- return ENVL_NVRAM;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_REMOTE)
- return ENVL_REMOTE;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)
- return ENVL_SPI_FLASH;
- else if IS_ENABLED(CONFIG_ENV_IS_IN_UBI)
- return ENVL_UBI;
- else if IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
- return ENVL_NOWHERE;
- else
- return ENVL_UNKNOWN;
+ switch (op) {
+ case ENVOP_GET_CHAR:
+ case ENVOP_INIT:
+ case ENVOP_LOAD:
+ if (prio >= ARRAY_SIZE(env_locations))
+ return ENVL_UNKNOWN;
+
+ env_load_location = env_locations[prio];
+ return env_load_location;
+
+ case ENVOP_SAVE:
+ return env_load_location;
+ }
+
+ return ENVL_UNKNOWN;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: nvedit: env_get_f must check for env_get_char error codes
On Mon, Feb 05, 2018 at 04:30:50PM +, York Sun wrote: > On 02/05/2018 05:44 AM, Maxime Ripard wrote: > > Hi York, > > > > On Fri, Feb 02, 2018 at 08:04:12PM +, York Sun wrote: > >> On 02/02/2018 10:51 AM, Maxime Ripard wrote: > > This patch looks correct. But it doesn't fix NOR flash. Do you have plan > > to add .get_char function to other drivers? Without that function, we > > cannot get env variables before relocation. > > Ehrm, sorry I don't plan to do that, no: my target seems to run fine > without this. > > Given that only the eeprom and nvram env drivers support the get_char > method, I don't know if this is widely used at all. Maybe a better > fallback > would be to just remove that get_char code path totally and always load > from > the internal (default) environment until the full environment is > available > (after relocation). > > After all, the environment variables loaded via get_char are not CRC > checked > at all. To me, this is another indication that this code is not really > useful and should probably be removed. > >>> > >>> To be honest, I'm not really sure what get_char was here for in the > >>> first place, so getting rid of it sounds like a good idea :) > >> > >> On almost all my boards, a variable hwconfig is read before relocation > >> to determine DDR configuration. This has been broken. I don't mind you > >> remove some dead code. But this is breaking almost all my boards booting > >> from NOR flash. > > > > Sorry if it fell through the cracks, I don't have a board with NOR > > myself. Do you know what breaks exactly? > > > > Or can you bisect at least? > Yes, I did. It was the #3 patch in the series of "env: Multiple env > support and env transition for sunxi". I reported in the email thread > "Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments", > along with another problem found regarding variable "env_load_location". > The latter problem breaks saveenv on NOR flash. Ah, right, I overlooked it, sorry. I'll reply there. Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On 07.02.2018 09:19, Maxime Ripard wrote: On Tue, Feb 06, 2018 at 09:09:07AM +0100, Simon Goldschmidt wrote: On 23.01.2018 21:16, Maxime Ripard wrote: Now that we have everything in place to support multiple environment, let's make sure the current code can use it. I get more build errors testing this feature: there's a global variable 'env_ptr' declared in flash, nand, nvram and remote env drivers (declared as extern in envrionment.h). From reading the code, it seems like these could just be changed to static, since 'env_ptr' is not used outside these drivers? Given Joakim's comment, I guess we should keep them !static, rename them to $env_env_ptr, and remove the definition in the include/environment that doesn't seem used anywhere. That's OK for me, I just wanted to point out the build error. However, I do think that having unnecessary non-static global variables is not really good coding style as you risk name clashes. I'd really be interested in a reason for this. Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
On Tue, Feb 06, 2018 at 09:09:07AM +0100, Simon Goldschmidt wrote: > On 23.01.2018 21:16, Maxime Ripard wrote: > > Now that we have everything in place to support multiple environment, let's > > make sure the current code can use it. > > I get more build errors testing this feature: there's a global variable > 'env_ptr' declared in flash, nand, nvram and remote env drivers (declared as > extern in envrionment.h). From reading the code, it seems like these could > just be changed to static, since 'env_ptr' is not used outside these > drivers? Given Joakim's comment, I guess we should keep them !static, rename them to $env_env_ptr, and remove the definition in the include/environment that doesn't seem used anywhere. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments
Hi,
On Tue, Feb 06, 2018 at 08:20:49AM +, Joakim Tjernlund wrote:
> On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
>
> .
> > > Reviewed-by: Andre Przywara
> > > Reviewed-by: Simon Glass
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > env/env.c | 80 +++-
> > > 1 file changed, 50 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/env/env.c b/env/env.c
> > > index 906f28ee50a1..1182fdb545db 100644
> > > --- a/env/env.c
> > > +++ b/env/env.c
> > > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum
> > > env_location loc)
> > > return NULL;
> > > }
> > >
> > > +static enum env_location env_locations[] = {
>
> Don't use static/global variables. They cause a lot of relocation work/size
> and is less flexible. There is no way to #define ENVL_EEPROM to a function
> when a variable.
Is that last sentence truncated?
Can you elaborate a bit more on what is the source of the relocation
issues you're mentionning? Is that because of the section it ends up
in?
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
