Re: [U-Boot] [PATCH 1/1] x86: qemu-x86 requires CONFIG_SYS_HZ=2000
On Thu, Sep 6, 2018 at 2:49 PM Bin Meng wrote: > > Hi Heinrich, > > On Thu, Sep 6, 2018 at 2:06 PM Heinrich Schuchardt wrote: > > > > The sleep command only provides correct timings for > > CONFIG_SYS_HZ=2000 on qemu-x86_defconfig. > > > > This can be tested with > > > > date && sleep 4 && date > > With current u-boot/master, with the same test command you provided, I got: > > => date && sleep 4 && date > Date: 2018-09-06 (Thursday)Time: 6:47:28 > Date: 2018-09-06 (Thursday)Time: 6:47:32 > => date && sleep 4 && date > Date: 2018-09-06 (Thursday)Time: 6:47:41 > Date: 2018-09-06 (Thursday)Time: 6:47:45 > => date && sleep 4 && date > Date: 2018-09-06 (Thursday)Time: 6:47:47 > Date: 2018-09-06 (Thursday)Time: 6:47:51 > > It seems there is no issue. > > QEMU was invoked like this: qemu-system-i386 -nographic -bios u-boot.rom with '-smp 4', the issue still cannot be reproduced. I am using QEMU 2.5.0, shipped by Ubuntu 16.04. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: qemu-x86 requires CONFIG_SYS_HZ=2000
Hi Heinrich, On Thu, Sep 6, 2018 at 2:06 PM Heinrich Schuchardt wrote: > > The sleep command only provides correct timings for > CONFIG_SYS_HZ=2000 on qemu-x86_defconfig. > > This can be tested with > > date && sleep 4 && date With current u-boot/master, with the same test command you provided, I got: => date && sleep 4 && date Date: 2018-09-06 (Thursday)Time: 6:47:28 Date: 2018-09-06 (Thursday)Time: 6:47:32 => date && sleep 4 && date Date: 2018-09-06 (Thursday)Time: 6:47:41 Date: 2018-09-06 (Thursday)Time: 6:47:45 => date && sleep 4 && date Date: 2018-09-06 (Thursday)Time: 6:47:47 Date: 2018-09-06 (Thursday)Time: 6:47:51 It seems there is no issue. QEMU was invoked like this: qemu-system-i386 -nographic -bios u-boot.rom > > Make CONFIG_SYS_HZ editable. > Set it in qemu-x86_defconfig to 2000. > > Signed-off-by: Heinrich Schuchardt > --- > configs/qemu-x86_defconfig | 1 + > lib/Kconfig| 4 +--- > 2 files changed, 2 insertions(+), 3 deletions(-) > [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] gpio: dwapb_gpio: Change to use devm_kcalloc()
Change to use managed resource function devm_kcalloc(), so it will auto free memory when driver is removed. Signed-off-by: Ley Foon Tan --- drivers/gpio/dwapb_gpio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c index 0f6574d..1594434 100644 --- a/drivers/gpio/dwapb_gpio.c +++ b/drivers/gpio/dwapb_gpio.c @@ -171,8 +171,7 @@ static int gpio_dwapb_bind(struct udevice *dev) if (!fdtdec_get_bool(blob, node, "gpio-controller")) continue; - plat = NULL; - plat = calloc(1, sizeof(*plat)); + plat = devm_kcalloc(dev, 1, sizeof(*plat), GFP_KERNEL); if (!plat) return -ENOMEM; -- 2.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/8] rockchip: add STIMER_BASE for Rockchip SoCs
Hi Philipp, ping... Could you reply this first before I send next patch set? Thanks, - Kever On 09/03/2018 11:21 AM, Kever Yang wrote: > Hi Philipp, > > > On 08/30/2018 05:11 PM, Philipp Tomsich wrote: >> >> On Wed, 18 Apr 2018, Kever Yang wrote: >> >>> Most of Rockchip SoCs have ARM arch/generic timer whose clock source >>> is from one of secure timer(if the soc supports Trust environment). >>> >>> STIMER can only access in secure mode, so it should be init before >>> the proper U-Boot(usually in non-secure mode). >>> Add a MACRO for timer base addr so that we can init with a common >>> function in SPL/TPL. >>> >>> Signed-off-by: Kever Yang >> See below for required changes. >> >>> --- >>> >>> arch/arm/mach-rockchip/Kconfig | 16 >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/arch/arm/mach-rockchip/Kconfig >>> b/arch/arm/mach-rockchip/Kconfig >>> index 0adaed4..55d3d5c 100644 >>> --- a/arch/arm/mach-rockchip/Kconfig >>> +++ b/arch/arm/mach-rockchip/Kconfig >>> @@ -191,6 +191,22 @@ config ROCKCHIP_BOOT_MODE_REG >>> The Soc will enter to different boot mode(defined in >>> asm/arch/boot_mode.h) >>> according to the value from this register. >>> >>> +config ROCKCHIP_STIMER_BASE >>> + hex "Rockchip Secure timer base address" >>> + default 0x200440a0 if ROCKCHIP_RK3036 >>> + default 0x20018020 if ROCKCHIP_RK3126 >>> + default 0x200440a0 if ROCKCHIP_RK3128 >>> + default 0x110d0020 if ROCKCHIP_RK322X >>> + default 0xff810020 if ROCKCHIP_RK3288 >>> + default 0xff1d0020 if ROCKCHIP_RK3328 >>> + default 0xff830020 if ROCKCHIP_RK3368 >>> + default 0xff8680a0 if ROCKCHIP_RK3399 >>> + default 0x10350020 if ROCKCHIP_RV1108 >>> + default 0 >>> + help >>> + The secure timer inited in SPL/TPL in secure word, ARM generic >>> timer >>> + works after this timer work. >> NAK. >> This is not a user-configurable/selectable option, but rather a >> function of the chip used. >> This belongs into a header file in arch/arm/include/asm/arch-rockchip. > Yes, you are correct in one way, but I think if this goes to header > file, it will separate in different > header file for different SoCs, or with a lot if MACRO like "#if > defined(CONFIG_ROCKCHIP_RK3288) #elif" > in one header file. > > Make ROCKCHIP_STIMER_BASE in Kconfig and use like ROCKCHIP_BOOT_MODE_REG > seems like a better idea to make things simple. > > Actually there are many other configs like this: > - DEBUG_UART_BASE > - IRAM_START > - DRAM_START > > One more consideration is, I don't think make SoC configs into too much > place is a good idea, > now we have 3 places for configs: > - Kconfig default value > - configs/soc_defconfig > - include/configs/soc_header.h (this is moving to Kconfig one by one now) > > so I would not like to move it into arch/arm/include/asm/arch-rockchip, > if you insist this should go to header file instead of Kconfig, I would > prefer > to use header file in 'include/configs/' folder, how do you think? > > Thanks, > - Kever >>> + >>> config ROCKCHIP_SPL_RESERVE_IRAM >>> hex "Size of IRAM reserved in SPL" >>> default 0 >>> > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spi: designware_spi: Add reset ctrl to driver
Add code to reset all reset signals as in SPI DT node. A reset property
is an optional feature, so only print out a warning and do not fail if a
reset property is not present.
If a reset property is discovered, then use it to deassert, thus
bringing the IP out of reset.
Release reset when _remove().
Signed-off-by: Ley Foon Tan
---
drivers/spi/designware_spi.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index d8b73ea..b73ec38 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -111,6 +112,8 @@ struct dw_spi_priv {
void *tx_end;
void *rx;
void *rx_end;
+
+ struct reset_ctl_bulk resets;
};
static inline u32 dw_read(struct dw_spi_priv *priv, u32 offset)
@@ -231,6 +234,33 @@ err_rate:
return -EINVAL;
}
+static int dw_spi_reset(struct udevice *bus)
+{
+ int ret;
+ struct dw_spi_priv *priv = dev_get_priv(bus);
+
+ ret = reset_get_bulk(bus, &priv->resets);
+ if (ret) {
+ /* Return 0 if error due to !CONFIG_DM_RESET and reset
+* DT property is not present.
+*/
+ if (ret == -ENOENT || ret == -ENOTSUPP)
+ return 0;
+
+ dev_warn(bus, "Can't get reset: %d\n", ret);
+ return ret;
+ }
+
+ ret = reset_deassert_bulk(&priv->resets);
+ if (ret) {
+ reset_release_bulk(&priv->resets);
+ dev_err(bus, "Failed to reset: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
static int dw_spi_probe(struct udevice *bus)
{
struct dw_spi_platdata *plat = dev_get_platdata(bus);
@@ -244,6 +274,10 @@ static int dw_spi_probe(struct udevice *bus)
if (ret)
return ret;
+ ret = dw_spi_reset(bus);
+ if (ret)
+ return ret;
+
/* Currently only bits_per_word == 8 supported */
priv->bits_per_word = 8;
@@ -478,6 +512,13 @@ static int dw_spi_set_mode(struct udevice *bus, uint mode)
return 0;
}
+static int dw_spi_remove(struct udevice *bus)
+{
+ struct dw_spi_priv *priv = dev_get_priv(bus);
+
+ return reset_release_bulk(&priv->resets);
+}
+
static const struct dm_spi_ops dw_spi_ops = {
.xfer = dw_spi_xfer,
.set_speed = dw_spi_set_speed,
@@ -502,4 +543,5 @@ U_BOOT_DRIVER(dw_spi) = {
.platdata_auto_alloc_size = sizeof(struct dw_spi_platdata),
.priv_auto_alloc_size = sizeof(struct dw_spi_priv),
.probe = dw_spi_probe,
+ .remove = dw_spi_remove,
};
--
2.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/23] efi_loader: implement a pseudo "file delete"
> Am 06.09.2018 um 04:43 schrieb AKASHI Takahiro : > >> On Wed, Sep 05, 2018 at 10:22:07AM +0200, Alexander Graf wrote: >> >> >>> On 05.09.18 04:51, AKASHI Takahiro wrote: On Tue, Sep 04, 2018 at 11:16:38AM +0200, Alexander Graf wrote: > On 04.09.18 09:49, AKASHI Takahiro wrote: > This patch is necessary to run SCT.efi (UEFI Self-Certification Test). > Returning EFI_SUCCESS can cheat SCT execution. > > Signed-off-by: AKASHI Takahiro How hard would it be to implement a real delete instead? >>> >>> Good question. >>> The hardest part of implementation, I believe, is about handling >>> nasty long file names in a directory, in particular, when >>> directory entries which comprise a single LFN extend across two clusters. >>> In this case, all the entries must be deleted first, and then go back >>> to the first one and modify it. Due to a current simple buffering of >>> cluster (only one cluster buffer a time), some tweak is necessary. >>> In addition, if there is an already-deleted entry ahead of the given file, >>> we need further rewind directory entries and update the "new" last valid >>> one to mark it as so. >>> Those kind of things would make the implementation a bit complicated >>> rather than simple as expected. >>> >>> So unless 'real' delete is a must for anything, I'm lukewarm to >>> work on it. >>> >>> # I admit that we don't have to have this patch just if *delete* returns >>> successfully without doing anything. >> >> I think both truncate-to-zero (this patch) and >> report-success-when-failure (suggested patch) are hacks that shouldn't >> really go upstream that way unfortunately. >> >> The way I read the long file name definitions, I think it should be >> perfectly ok to only remove the short file name directory entry. > > Do you accept such an ugly implementation although it yet complies > with fat specification? It's valid for all intents and purposes, so why not :). > >> Sure, >> we're leaking a few directory entries for the LFN, but I don't think >> that's too bad. Any fsck should be able to find those later on... > > As I said in my cover-letter, fsck would complain any way. > >> As for how to delete the entry without rewinding directory entries, you >> can just set name[0]=DELETED_FLAG; to indicate that the SFN is deleted, no? > > Yes if DELETED_FLAG=0x5e and if we ignore the specific case where > name[0] be 0x00, which means the entry is the *first* invalid one. > (again, the latter would not be mandatory in term of compatibility.) > > Since I have already had the code, "real" delete will be put in my next > version if nobody has concerns on this simple implementation. Thanks, that would be great! :) Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] x86: qemu-x86 requires CONFIG_SYS_HZ=2000
The sleep command only provides correct timings for CONFIG_SYS_HZ=2000 on qemu-x86_defconfig. This can be tested with date && sleep 4 && date Make CONFIG_SYS_HZ editable. Set it in qemu-x86_defconfig to 2000. Signed-off-by: Heinrich Schuchardt --- configs/qemu-x86_defconfig | 1 + lib/Kconfig| 4 +--- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig index 12ea72f562..8fc725dcc4 100644 --- a/configs/qemu-x86_defconfig +++ b/configs/qemu-x86_defconfig @@ -51,3 +51,4 @@ CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_FRAMEBUFFER_VESA_MODE_USER=y CONFIG_FRAMEBUFFER_VESA_MODE=0x144 CONFIG_CONSOLE_SCROLL_LINES=5 +CONFIG_SYS_HZ=2000 diff --git a/lib/Kconfig b/lib/Kconfig index 622f3c26c3..f37db20593 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -82,12 +82,10 @@ config USE_PRIVATE_LIBGCC If unsure, say N. config SYS_HZ - int + int "Frequency of the timer" default 1000 help The frequency of the timer returned by get_timer(). - get_timer() must operate in milliseconds and this option must be - set to 1000. config USE_TINY_PRINTF bool "Enable tiny printf() version" -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Thu, Sep 6, 2018 at 5:04 AM Dalon Westergreen wrote: > > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. Although not running a Stratix10, I also need a hex image for spl to boot unconfigured CycloneV devices. However, for this, it is enough to objcopy u-boot.spl.sfp to hex and add the resulting file to the FPGA configuration image. Quartus does complain about the format a bit, but it does work. Is this different for Stratix10? Simon > > v2: > -> add CONFIG_OF_EMBED to include dtb in elf > -> generate hex from elf source > > Signed-off-by: Dalon Westergreen > --- > configs/socfpga_stratix10_defconfig | 1 + > scripts/Makefile.spl| 6 ++ > 2 files changed, 7 insertions(+) > > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfig > index dceadff439..17cc732cbe 100644 > --- a/configs/socfpga_stratix10_defconfig > +++ b/configs/socfpga_stratix10_defconfig > @@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y > CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y > +CONFIG_OF_EMBED=y > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..b09bd40b2a 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,11 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex > + > +$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN) FORCE > + $(call if_changed,objcopy) > + > LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL) > > # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. > -- > 2.17.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: Specify aligned address for secure section instead of using attributes
In commit a1274cc94a20 ("ARM: Page align secure section only when it is
executed in situ"), we used output section attributes (the "ALIGN"
keyword after the colon) to specify the alignment requirements. Using
the constant "COMMONPAGE" there was recently broken in binutils 2.31 [1].
Binutils maintainer Alan Modra suggested the former method would still
work. Since both methods achieve the same result, this patch does just
that. This fixes the "reboot after bootm" issue we've been seeing on
sunxi when booting non-secure.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23571
Suggested-by: Alan Modra
Signed-off-by: Chen-Yu Tsai
---
arch/arm/cpu/u-boot.lds | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 834dc99554c9..0eb164d2e694 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -68,11 +68,11 @@ SECTIONS
#ifdef CONFIG_ARMV7_NONSEC
/* Align the secure section only if we're going to use it in situ */
- .__secure_start :
+ .__secure_start
#ifndef CONFIG_ARMV7_SECURE_BASE
ALIGN(CONSTANT(COMMONPAGESIZE))
#endif
- {
+ : {
KEEP(*(.__secure_start))
}
--
2.19.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [EDK2] Implementing EFI_SIMPLE_TEXT_INPUT_PROTOCOL
Hello Ruiyu, currently I am struggling a bit with interpreting the UEFI spec concerning the EFI_SIMPLE_TEXT_INPUT_PROTOCOL. In UEFI spec 2.7. chapter 12.1.2 ConsoleIn Definition there is this sentence: "Only the control characters defined in Table 100 have meaning in the Unicode input or output streams." Table 100: U+ Null character ignored when received. U+0008 Backspace. Moves cursor left one column. U+0009 Tab. U+000A Linefeed. Moves cursor to the next line. U+000D Carriage Return. Moves cursor to left margin of the current line. Rob interpreted this in a patch for U-Boot such that he simply suppressed all other Unicode characters in the 0x00-01F range except for special treatment of 0x001b as ESC. When I look at EDK2 function USBKeyboardReadKeyStroke() (MdeModulePkg/Bus/Usb/UsbKbDxe/EfiKey.c:700) it seems that EDK2 would pass CTRL+C as Unicode character U+0003 (cf. your patch 608817ad7114 "Change the SimpleTextInEx implementation to return CTRL+C"). The same seems to be the case in function KeyboardReadKeyStroke() (MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KbdTextIn.c:265). So do I get it right that for CTRL+A to CTRL+Z we should return a value U+0001 - U+001a in Key->UnicodeChar and table 100 is about meaning of control characters only and does *not* prescribe a filter? But what about CTRL+[ - CTRL+_ ? Why are they suppressed in the EDK2 keyboard drivers? How do we enter U+001c - U+001f? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
Hi Lukas, On Wed, Sep 5, 2018 at 5:37 PM Auer, Lukas wrote: > > On Wed, 2018-09-05 at 10:34 +0800, Bin Meng wrote: > > Hi Rick, > > > > On Wed, Sep 5, 2018 at 9:27 AM Rick Chen > > wrote: > > > > > > > > From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de] > > > > > Sent: Wednesday, September 05, 2018 5:53 AM > > > > > To: bmeng...@gmail.com > > > > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot@lists.denx.de > > > > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board > > > support > > > > > > > > > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote: > > > > > > Hi Lukas, > > > > > > > > > > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas > > > > > > wrote: > > > > > > > > > > > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote: > > > > > > > > This adds QEMU RISC-V 'virt' board target support, with > > > the hope > > > > > > > > of helping people easily test U-Boot on RISC-V. > > > > > > > > > > > > > > > > The QEMU virt machine models a generic RISC-V virtual > > > machine > > > > > > > > with support for the VirtIO standard networking and > > > block > > > > > > > > storage devices. > > > > > > > > It has CLINT, PLIC, 16550A UART devices in addition to > > > VirtIO > > > > > > > > and it also uses device-tree to pass configuration > > > information > > > > > > > > to guest software. It implements RISC-V privileged > > > architecture > > > > > > > > spec v1.10. > > > > > > > > > > > > > > > > Both 32-bit and 64-bit builds are supported. Support is > > > pretty > > > > > > > > much preliminary, only booting to U-Boot shell with the > > > UART > > > > > > > > driver on a single core. Booting Linux is not supported > > > yet. > > > > > > > > > > > > > > > > > > > > > > For your information and to avoid duplicate work, I am > > > working on > > > > > > > a patch set that improves RISC-V support in u-boot. I am > > > currently > > > > > > > able to boot Linux on a multi-core setup in QEMU, but they > > > are not > > > > > > > quite ready to submit yet. > > > > > > > > > > > > > > > > > > > This is great! My next step is to work on virtio driver > > > support in > > > > > > U-Boot as qemu-riscv virt machine has these devices but we > > > don't > > > > > > have corresponding drivers in U-Boot. Then I will try to > > > boot Linux > > > > > > after that. Good to hear you already boot Linux with qemu- > > > riscv! > > > > > > Have you already supported virtio drivers in your port? If > > > yes, I > > > > > > will just hold on and wait for your patch series :-) > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > Support for the virtio devices would be great! I don't support > > > them in > > > > > my port, I can only boot a kernel image from RAM. > > > > > I only have a driver for the clint0 (core local interrupt > > > controller), > > > > > which I need for software interrupts to other cores and as a > > > timer. > > > > > Software interrupts also work over the supervisor binary > > > interface > > > > > (SBI), which allows u-boot to run in supervisor mode with bbl > > > running > > > > > in machine mode to handle the SBI calls. > > > > > > > > > > > Hi Bin and Auer > > > > > > I have already boot bbl run in S-mode and riscv-linux in M-mode via > > > u-boot from SD card or FLASH. > > > It mean after booting riscv-linux, u-boot will be dead. And no > > > matter > > > about kernel. > > > Please refer to doc/README.ae350 > > > > > > > Thanks for pointing out the doc for ae350. I just read it, and have > > one question. There is a chapter in that doc "Boot bbl and riscv- > > linux > > via U-Boot on QEMU", yet I don't see what QEMU command is invoked. > > Can > > you please clarify? AFAIK mainline QEMU does not have support to > > ae350 > > board. Also there is no instructions on how bbl was built. Is that > > the > > mainline bbl that can work on every riscv board? I doubt that. > > > > > May I figure out more clearly what are you going to do ? > > > What are you going to do is let u-boot run in S-mode and boot bbl > > > and > > > riscv-linux in M-mode, right ? > > > > I want to use U-Boot to directly boot Linux, but seems Lukas is using > > bbl for SBI implementation. > > > > Hi Bin, > > I don't really need bbl to run u-boot. I use it for Linux, which > expects the SBI to be present. > > > > It mean after booting bbl and riscv-linux, u-boot will still alive > > > and > > > handle SBI calls and somethings in S-mode. > > > > > > Or u-boot is going to replace the role of bbl ? > > > > > > > That's my plan. I don't see a need to use bbl which is quite feature > > limited. > > > > That's a good idea! At the very least, all the device initialization in > bbl should be moved into u-boot. > I do think a bootloader-independent SBI implementation makes sense > though. That way all bootloaders can use the same implementation, which > should make adding new SBI calls easier. But I doubt we can have a generic SBI implementation. At least the console
Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
Hi Lukas, On Wed, Sep 5, 2018 at 5:35 PM Auer, Lukas wrote: > > On Wed, 2018-09-05 at 09:28 +0800, Rick Chen wrote: > > > > From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de] > > > > Sent: Wednesday, September 05, 2018 5:53 AM > > > > To: bmeng...@gmail.com > > > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot@lists.denx.de > > > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board > > support > > > > > > > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote: > > > > > Hi Lukas, > > > > > > > > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas > > > > > wrote: > > > > > > > > > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote: > > > > > > > This adds QEMU RISC-V 'virt' board target support, with > > the hope > > > > > > > of helping people easily test U-Boot on RISC-V. > > > > > > > > > > > > > > The QEMU virt machine models a generic RISC-V virtual > > machine > > > > > > > with support for the VirtIO standard networking and block > > > > > > > storage devices. > > > > > > > It has CLINT, PLIC, 16550A UART devices in addition to > > VirtIO > > > > > > > and it also uses device-tree to pass configuration > > information > > > > > > > to guest software. It implements RISC-V privileged > > architecture > > > > > > > spec v1.10. > > > > > > > > > > > > > > Both 32-bit and 64-bit builds are supported. Support is > > pretty > > > > > > > much preliminary, only booting to U-Boot shell with the > > UART > > > > > > > driver on a single core. Booting Linux is not supported > > yet. > > > > > > > > > > > > > > > > > > > For your information and to avoid duplicate work, I am > > working on > > > > > > a patch set that improves RISC-V support in u-boot. I am > > currently > > > > > > able to boot Linux on a multi-core setup in QEMU, but they > > are not > > > > > > quite ready to submit yet. > > > > > > > > > > > > > > > > This is great! My next step is to work on virtio driver > > support in > > > > > U-Boot as qemu-riscv virt machine has these devices but we > > don't > > > > > have corresponding drivers in U-Boot. Then I will try to boot > > Linux > > > > > after that. Good to hear you already boot Linux with qemu- > > riscv! > > > > > Have you already supported virtio drivers in your port? If > > yes, I > > > > > will just hold on and wait for your patch series :-) > > > > > > > > > > > > > Hi Bin, > > > > > > > > Support for the virtio devices would be great! I don't support > > them in > > > > my port, I can only boot a kernel image from RAM. > > > > I only have a driver for the clint0 (core local interrupt > > controller), > > > > which I need for software interrupts to other cores and as a > > timer. > > > > Software interrupts also work over the supervisor binary > > interface > > > > (SBI), which allows u-boot to run in supervisor mode with bbl > > running > > > > in machine mode to handle the SBI calls. > > > > > > > > Hi Bin and Auer > > > > I have already boot bbl run in S-mode and riscv-linux in M-mode via > > u-boot from SD card or FLASH. > > It mean after booting riscv-linux, u-boot will be dead. And no matter > > about kernel. > > Please refer to doc/README.ae350 > > > > May I figure out more clearly what are you going to do ? > > What are you going to do is let u-boot run in S-mode and boot bbl and > > riscv-linux in M-mode, right ? > > It mean after booting bbl and riscv-linux, u-boot will still alive > > and > > handle SBI calls and somethings in S-mode. > > > > Or u-boot is going to replace the role of bbl ? > > > > Rick > > > > Hi Rick, > > Not exactly, my current boot flow is as follows. > > 1. u-boot SPL starts in machine mode and jumps to bbl > 2. bbl starts u-boot proper in supervisor mode > 3. u-boot boots the kernel > If this is QEMU virt target, there is no need to boot from SPL then U-Boot proper. > bbl is still active once Linux has booted and is used there for its SBI > implementation. Hope this helps. Yes, I am not quite convinced why Linux kernel was designed this way. This is something like x86's SMM or EFI runtime services... Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] riscv: Add a helper routine to print CPU information
Hi Lukas,
On Tue, Sep 4, 2018 at 5:42 AM Auer, Lukas
wrote:
>
> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > This adds a helper routine to print CPU information. Currently
> > it prints all the instruction set extensions that the processor
> > core supports.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > arch/riscv/Makefile | 1 +
> > arch/riscv/cpu/Makefile | 5 ++
> > arch/riscv/cpu/cpu.c | 49 +
> > arch/riscv/include/asm/csr.h | 124
> > +++
> > 4 files changed, 179 insertions(+)
> > create mode 100644 arch/riscv/cpu/Makefile
> > create mode 100644 arch/riscv/cpu/cpu.c
> > create mode 100644 arch/riscv/include/asm/csr.h
> >
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index 084888a..af432e1 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -5,5 +5,6 @@
> >
> > head-y := arch/riscv/cpu/$(CPU)/start.o
> >
> > +libs-y += arch/riscv/cpu/
> > libs-y += arch/riscv/cpu/$(CPU)/
> > libs-y += arch/riscv/lib/
> > diff --git a/arch/riscv/cpu/Makefile b/arch/riscv/cpu/Makefile
> > new file mode 100644
> > index 000..63de163
> > --- /dev/null
> > +++ b/arch/riscv/cpu/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2018, Bin Meng
> > +
> > +obj-y += cpu.o
> > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > new file mode 100644
> > index 000..ae57fb8
> > --- /dev/null
> > +++ b/arch/riscv/cpu/cpu.c
> > @@ -0,0 +1,49 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018, Bin Meng
> > + */
> > +
> > +#include
> > +#include
> > +
> > +enum {
> > + ISA_INVALID = 0,
> > + ISA_32BIT,
> > + ISA_64BIT,
> > + ISA_128BIT
> > +};
> > +
> > +static const char * const isa_bits[] = {
> > + [ISA_INVALID] = NULL,
> > + [ISA_32BIT] = "32",
> > + [ISA_64BIT] = "64",
> > + [ISA_128BIT] = "128"
> > +};
> > +
> > +static inline bool supports_extension(char ext)
> > +{
> > + return csr_read(misa) & (1 << (ext - 'a'));
> > +}
> > +
> > +int print_cpuinfo(void)
> > +{
> > + char name[32];
> > + char *s = name;
> > + int bit;
> > +
> > + s += sprintf(name, "rv");
> > + bit = csr_read(misa) >> (sizeof(long) * 8 - 2);
> > + s += sprintf(s, isa_bits[bit]);
> > +
> > + supports_extension('i') ? *s++ = 'i' : 'r';
> > + supports_extension('m') ? *s++ = 'm' : 'i';
> > + supports_extension('a') ? *s++ = 'a' : 's';
> > + supports_extension('f') ? *s++ = 'f' : 'c';
> > + supports_extension('d') ? *s++ = 'd' : '-';
> > + supports_extension('c') ? *s++ = 'c' : 'v';
> > + *s++ = '\0';
> > +
> > + printf("CPU: %s\n", name);
> > +
> > + return 0;
> > +}
> > diff --git a/arch/riscv/include/asm/csr.h
> > b/arch/riscv/include/asm/csr.h
> > new file mode 100644
> > index 000..50fccea
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/csr.h
> > @@ -0,0 +1,124 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2015 Regents of the University of California
> > + *
> > + * Taken from Linux arch/riscv/include/asm/csr.h
> > + */
> > +
> > +#ifndef _ASM_RISCV_CSR_H
> > +#define _ASM_RISCV_CSR_H
> > +
> > +/* Status register flags */
> > +#define SR_SIE _AC(0x0002, UL) /* Supervisor
> > Interrupt Enable */
> > +#define SR_SPIE _AC(0x0020, UL) /* Previous
> > Supervisor IE */
> > +#define SR_SPP _AC(0x0100, UL) /* Previously
> > Supervisor */
> > +#define SR_SUM _AC(0x0004, UL) /* Supervisor
> > access User Memory */
> > +
> > +#define SR_FS_AC(0x6000, UL) /* Floating-point
> > Status */
> > +#define SR_FS_OFF_AC(0x, UL)
> > +#define SR_FS_INITIAL_AC(0x2000, UL)
> > +#define SR_FS_CLEAN _AC(0x4000, UL)
> > +#define SR_FS_DIRTY _AC(0x6000, UL)
> > +
> > +#define SR_XS_AC(0x00018000, UL) /* Extension Status
> > */
> > +#define SR_XS_OFF_AC(0x, UL)
> > +#define SR_XS_INITIAL_AC(0x8000, UL)
> > +#define SR_XS_CLEAN _AC(0x0001, UL)
> > +#define SR_XS_DIRTY _AC(0x00018000, UL)
> > +
> > +#ifndef CONFIG_64BIT
> > +#define SR_SD_AC(0x8000, UL) /* FS/XS dirty */
> > +#else
> > +#define SR_SD_AC(0x8000, UL) /* FS/XS
> > dirty */
> > +#endif
> > +
> > +/* SATP flags */
> > +#if __riscv_xlen == 32
> > +#define SATP_PPN _AC(0x003F, UL)
> > +#define SATP_MODE_32 _AC(0x8000, UL)
> > +#define SATP_MODESATP_MODE_32
> > +#else
> > +#define SATP_PPN _AC(0x0FFF, UL)
> > +#define SATP_MODE_39 _AC(0x8000, UL)
> > +#define SATP_MODESATP_MODE_39
> > +#endif
> > +
> > +/* Interrupt Enable and Interrupt Pending flags */
> > +#define SIE_SSIE _AC(0x0002, UL) /* Software Interrupt
> > Enable */
> > +#define SIE_STIE _AC(0x0020, UL) /* Timer Interr
[U-Boot] [PATCH v2 1/2] spl: socfpga: only gen5 devices and arria10 require sfp image
Only the Cyclone5/Arria5 and Arria10 devices require the sfp formated image for booting. This path ensures that the file is only generated for those devices. Signed-off-by: Dalon Westergreen --- scripts/Makefile.spl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 252f13826d..76d08fd92b 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -188,7 +188,8 @@ ALL-y += $(obj)/$(BOARD)-spl.bin endif ifdef CONFIG_ARCH_SOCFPGA -ALL-y += $(obj)/$(SPL_BIN).sfp +ALL-$(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp +ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp endif ifdef CONFIG_ARCH_SUNXI -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
Stratix10 requires a hex image of the spl for boot. The hex image is added to the FPGA configuration image and loaded to the processor memory by the configuration engine. v2: -> add CONFIG_OF_EMBED to include dtb in elf -> generate hex from elf source Signed-off-by: Dalon Westergreen --- configs/socfpga_stratix10_defconfig | 1 + scripts/Makefile.spl| 6 ++ 2 files changed, 7 insertions(+) diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig index dceadff439..17cc732cbe 100644 --- a/configs/socfpga_stratix10_defconfig +++ b/configs/socfpga_stratix10_defconfig @@ -56,3 +56,4 @@ CONFIG_DM_USB=y CONFIG_USB_DWC2=y CONFIG_USB_STORAGE=y CONFIG_USE_TINY_PRINTF=y +CONFIG_OF_EMBED=y diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 76d08fd92b..b09bd40b2a 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -190,6 +190,7 @@ endif ifdef CONFIG_ARCH_SOCFPGA ALL-$(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex endif ifdef CONFIG_ARCH_SUNXI @@ -299,6 +300,11 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j .start16 -j .resetvec $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE $(call if_changed,objcopy) +OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex + +$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN) FORCE + $(call if_changed,objcopy) + LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL) # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] riscv: bootm: Correct the 1st kernel argument to hart id
Hi Lukas,
On Tue, Sep 4, 2018 at 5:41 AM Auer, Lukas
wrote:
>
> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > The first argument of Linux kernel is the risc-v core hart id,
> > from which the kernel is booted from. It is not the mach_id,
> > which seems to be copied from arm.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > arch/riscv/lib/bootm.c | 18 +-
> > 1 file changed, 5 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > index 6662aff..754bbff 100644
> > --- a/arch/riscv/lib/bootm.c
> > +++ b/arch/riscv/lib/bootm.c
> > @@ -25,10 +25,7 @@ int arch_fixup_fdt(void *blob)
> >
> > int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t
> > *images)
> > {
> > - bd_t*bd = gd->bd;
> > - char*s;
> > - int machid = bd->bi_arch_number;
> > - void(*theKernel)(int arch, uint params);
> > + void(*kernel)(int hart, uint dtb);
>
> This probably does not cause any issues in u-boot, but the second
> parameter should be 32 bit or 64 bit depending on the architecture.
> Since you are already changing the kernel arguments it would make sense
> to also change dtb from uint to ulong or void *.
>
Yes. Will address this in v2.
> >
> > /*
> >* allow the PREP bootm subcommand, it is required for bootm to
> > work
> > @@ -39,18 +36,12 @@ int do_bootm_linux(int flag, int argc, char
> > *argv[], bootm_headers_t *images)
> > if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
> > return 1;
> >
> > - theKernel = (void (*)(int, uint))images->ep;
> > -
> > - s = env_get("machid");
> > - if (s) {
> > - machid = simple_strtoul(s, NULL, 16);
> > - printf("Using machid 0x%x from environment\n", machid);
> > - }
> > + kernel = (void (*)(int, uint))images->ep;
> >
> > bootstage_mark(BOOTSTAGE_ID_RUN_OS);
> >
> > debug("## Transferring control to Linux (at address %08lx)
> > ...\n",
> > -(ulong)theKernel);
> > +(ulong)kernel);
> >
> > if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
> > #ifdef CONFIG_OF_LIBFDT
> > @@ -66,8 +57,9 @@ int do_bootm_linux(int flag, int argc, char
> > *argv[], bootm_headers_t *images)
> > printf("\nStarting kernel ...\n\n");
> >
> > cleanup_before_linux();
> > + /* TODO: hardcode the hart id to zero for now */
> > if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
> > - theKernel(machid, (unsigned long)images->ft_addr);
> > + kernel(0, (unsigned long)images->ft_addr);
> >
>
> You can use the mhartid CSR to get the hart id. This will limit u-boot
> to running in machine mode however. Alternatively you can also use the
> hart id, which is passed in a0 by the bootloader.
>
If the goal is to use U-Boot to directly boot Linux, I think we need
more changes. I believe we should allow only one hart to execute this
function. For other harts, they should be waked up and jump to kernel
directly.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/23] efi_loader: implement a pseudo "file delete"
On Wed, Sep 05, 2018 at 10:22:07AM +0200, Alexander Graf wrote: > > > On 05.09.18 04:51, AKASHI Takahiro wrote: > > On Tue, Sep 04, 2018 at 11:16:38AM +0200, Alexander Graf wrote: > >> > >> > >> On 04.09.18 09:49, AKASHI Takahiro wrote: > >>> This patch is necessary to run SCT.efi (UEFI Self-Certification Test). > >>> Returning EFI_SUCCESS can cheat SCT execution. > >>> > >>> Signed-off-by: AKASHI Takahiro > >> > >> How hard would it be to implement a real delete instead? > > > > Good question. > > The hardest part of implementation, I believe, is about handling > > nasty long file names in a directory, in particular, when > > directory entries which comprise a single LFN extend across two clusters. > > In this case, all the entries must be deleted first, and then go back > > to the first one and modify it. Due to a current simple buffering of > > cluster (only one cluster buffer a time), some tweak is necessary. > > In addition, if there is an already-deleted entry ahead of the given file, > > we need further rewind directory entries and update the "new" last valid > > one to mark it as so. > > Those kind of things would make the implementation a bit complicated > > rather than simple as expected. > > > > So unless 'real' delete is a must for anything, I'm lukewarm to > > work on it. > > > > # I admit that we don't have to have this patch just if *delete* returns > > successfully without doing anything. > > I think both truncate-to-zero (this patch) and > report-success-when-failure (suggested patch) are hacks that shouldn't > really go upstream that way unfortunately. > > The way I read the long file name definitions, I think it should be > perfectly ok to only remove the short file name directory entry. Do you accept such an ugly implementation although it yet complies with fat specification? > Sure, > we're leaking a few directory entries for the LFN, but I don't think > that's too bad. Any fsck should be able to find those later on... As I said in my cover-letter, fsck would complain any way. > As for how to delete the entry without rewinding directory entries, you > can just set name[0]=DELETED_FLAG; to indicate that the SFN is deleted, no? Yes if DELETED_FLAG=0x5e and if we ignore the specific case where name[0] be 0x00, which means the entry is the *first* invalid one. (again, the latter would not be mandatory in term of compatibility.) Since I have already had the code, "real" delete will be put in my next version if nobody has concerns on this simple implementation. Thanks, -Takahiro AKASHI > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/23] fs: fat: make directory iterator global for write use
On Wed, Sep 05, 2018 at 10:16:32AM +0200, Alexander Graf wrote: > > > On 05.09.18 04:14, AKASHI Takahiro wrote: > > On Tue, Sep 04, 2018 at 12:57:54PM +0200, Alexander Graf wrote: > >> > >> > >>> Am 04.09.2018 um 12:50 schrieb Heinrich Schuchardt : > >>> > >>> > >>> > On 09/04/2018 11:01 AM, Alexander Graf wrote: > > > > On 04.09.18 09:49, AKASHI Takahiro wrote: > > Directory iterator was introduced in major re-work of read operation by > > Rob. We want to use it for write operation extensively as well. > > Please indicate in the commit message that write operations are > implemented in a different .c file and so we have to export the > respective functions. > >>> > >>> Why? Look at this ugly code: > >>> > >>> fs/fat/fat_write.c:17:#include "fat.c" > >> > >> In that case we don't need this patch at all, no? > > > > Oops, I didn't notice this before. > > If, however, "include fat.c" makes any sense, theoretically we don't need > > "depends on FS_FAT" for FS_FAT_WRITE. > > There seems to be a contradiction between the code and config. > > I'm not sure it's contradictory. Someone just implemented a poor man's > LTO by including the 2 files with each other. Well, LTO has long existed since gcc4.8 ... (and improvement would be quite small, I guess.) > > I prefer just to remove the line, '#include "fat.c"' from fat_write.c > > and add more "extern" definitions in fat.h if necessary. > > We can worry about refactoring things later down the road. By making > functions go external, we lose the compiler's ability to inline > functions which may again bloat code which may trip random boards above > size limits. > > For now, I'd suggest you leave the ugly #include "fat.c" in and not move > anything into fat.h. That way the file is self-contained and you don't > have to worry about exporting just yet. Although I won't tolerate such an ugly code, I will follow your suggestion mainly because lots of existing defconfigs enable FAT_WRITE without FS_FAT. Thanks, -Takahiro AKASHI > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] travis: Use kernel.org pre-built toolchain for riscv
Bin Meng 於 2018年9月6日 週四 上午9:43寫道： > > Hi Rick, > > On Tue, Sep 4, 2018 at 4:56 PM Bin Meng wrote: > > > > Hi Rick, > > > > On Tue, Sep 4, 2018 at 1:36 PM Rick Chen wrote: > > > > > > > From: Tom Rini [mailto:tr...@konsulko.com] > > > > Sent: Tuesday, September 04, 2018 3:24 AM > > > > To: Bin Meng > > > > Cc: U-Boot Mailing List; Rick Jian-Zhi Chen(陳建志) > > > > Subject: Re: [PATCH] travis: Use kernel.org pre-built toolchain for > > > riscv > > > > > > > > On Mon, Sep 03, 2018 at 05:50:39PM +0800, Bin Meng wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, Aug 30, 2018 at 9:12 PM Bin Meng wrote: > > > > > > > > > > > > This updates travis configuration to use kernel.org pre-built > > > > > > toolchain for riscv. > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > --- > > > > > > > > > > > > .travis.yml | 5 ++--- > > > > > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > > > Since this is travis-ci changes, can we take this for v2018.09? I've > > > > > verified that it works well for current riscv build on travis-ci.org. > > > > > > > > Seeing as things are still working before this change I would like > > > to see an ack > > > > from the custodian, thanks! > > > > > > > > -- > > > > Tom > > > > > > Hi Bin > > > > > > I think lt is a positive way to use kernel.org pre-built toolchain for > > > code coverage. > > > And very agree with that. > > > > > > But there is a problem, it maybe encounter in the future. > > > If I or someone try to add a private csr which the public toolchain > > > may not recognize it. > > > > I assume what you said "private" csr means "vendor-specific" csr that > > is not defined by the risc-v ISA? > > > > > How shall it be overcomed ? Do you have any ideas ? > > > > I believe this shall be implemented properly by the toolchain itself. > > Or we hardcode the instruction for such "private" csr if there is no > > good solution from the toolchain side. Having a custom toolchain seems > > not a good idea. Hi Bin Agree with you, maybe I shall consider to isolate the vendor-specific code with CONFIG_XXX. > > I did not see a confirmative response on whether this patch is OK. Can > you please comment, and if no issue I hope this can catch up the train > of upcoming release :) > Hi Tom I think it is OK to pull this change into the master. Hope everything goes fine :) Rick > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: denali_dt: Add reset support
2018-09-05 17:31 GMT+09:00 Marek Vasut :
> On 08/24/2018 03:10 PM, Marek Vasut wrote:
>> On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> 2018-08-21 22:57 GMT+09:00 Marek Vasut :
Add optional reset support into the Denali NAND driver. In case there is
a valid reset entry in the DT, the reset gets deasserted before the NAND
controller gets used.
Signed-off-by: Marek Vasut
Cc: Masahiro Yamada
---
drivers/mtd/nand/denali_dt.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index 65a7797f0f..6fcd7d3843 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev)
const struct denali_dt_data *data;
struct clk clk;
struct resource res;
+ struct reset_ctl reset_ctl;
int ret;
data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
+ ret = reset_get_by_index(dev, 0, &reset_ctl);
+ if (!ret) {
+ reset_assert(&reset_ctl);
+ udelay(2);
+ reset_deassert(&reset_ctl);
+ }
+
return denali_init(denali);
}
>>>
>>>
>>> I was testing this patch today
>>> because my SoC also has a reset line for NAND.
>>>
>>>
>>> This patch looks trivial enough,
>>> but if the NAND is reset here,
>>> my board fails to boot with
>>> "nand_base: timeout while waiting for chip to become ready"
>>>
>>>
>>> I do not know why.
>>> Please give me more time to figure out what is going on in my SoC.
>>
>> Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?
I do not think so.
The reset sequence of Denali is not so simple as you may think
because the HW sequencer runs after the reset de-assertion.
It includes some SoC-dependent parts.
>
> Did you figure something out ?
>
Just testing one of my boards.
It booted by adding mdelay() after reset_deassert().
reset_assert(&reset_ctl);
udelay(2);
reset_deassert(&reset_ctl);
mdelay(1); /* Why is this long delay required? */
I will read HW docs more,
and talk to HW engineers
to figure out the right solution.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] travis: Use kernel.org pre-built toolchain for riscv
Hi Rick, On Tue, Sep 4, 2018 at 4:56 PM Bin Meng wrote: > > Hi Rick, > > On Tue, Sep 4, 2018 at 1:36 PM Rick Chen wrote: > > > > > From: Tom Rini [mailto:tr...@konsulko.com] > > > Sent: Tuesday, September 04, 2018 3:24 AM > > > To: Bin Meng > > > Cc: U-Boot Mailing List; Rick Jian-Zhi Chen(陳建志) > > > Subject: Re: [PATCH] travis: Use kernel.org pre-built toolchain for riscv > > > > > > On Mon, Sep 03, 2018 at 05:50:39PM +0800, Bin Meng wrote: > > > > Hi Tom, > > > > > > > > On Thu, Aug 30, 2018 at 9:12 PM Bin Meng wrote: > > > > > > > > > > This updates travis configuration to use kernel.org pre-built > > > > > toolchain for riscv. > > > > > > > > > > Signed-off-by: Bin Meng > > > > > --- > > > > > > > > > > .travis.yml | 5 ++--- > > > > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > > > > > > > > > > Since this is travis-ci changes, can we take this for v2018.09? I've > > > > verified that it works well for current riscv build on travis-ci.org. > > > > > > Seeing as things are still working before this change I would like > > to see an ack > > > from the custodian, thanks! > > > > > > -- > > > Tom > > > > Hi Bin > > > > I think lt is a positive way to use kernel.org pre-built toolchain for > > code coverage. > > And very agree with that. > > > > But there is a problem, it maybe encounter in the future. > > If I or someone try to add a private csr which the public toolchain > > may not recognize it. > > I assume what you said "private" csr means "vendor-specific" csr that > is not defined by the risc-v ISA? > > > How shall it be overcomed ? Do you have any ideas ? > > I believe this shall be implemented properly by the toolchain itself. > Or we hardcode the instruction for such "private" csr if there is no > good solution from the toolchain side. Having a custom toolchain seems > not a good idea. I did not see a confirmative response on whether this patch is OK. Can you please comment, and if no issue I hope this can catch up the train of upcoming release :) Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] efi_loader: SIMPLE_TEXT_INPUT_EX plus wire up objects properly
On 05.09.18 22:21, Heinrich Schuchardt wrote: > Hello Alex, > > in your efi-next tree you have merged > efi_loader: SIMPLE_TEXT_INPUT_EX plus wire up objects properly > https://github.com/agraf/u-boot/commit/3486573794a0809d987fd690b1bf6c9093124ce9 Sure, removed again. > The EFI_SIMPLE_TEXT_INPUT_PROTOCOL can be tested with: > > setenv efi_selftest text input > bootefi selftest > > Before the patch entering CTRL+C resulted in: > > Executing 'text input' > Waiting for your input > To terminate type 'x' > > > Unicode char 3 (unknown), scan code 0 (Null) > > With this patch CTRC+C is not interpreted as 0x03 anymore. > > So, please, remove the patch from the repository, rework it and subject > it to review. No promises on the rework anytime soon :) > > I will try to write a Python test for EFI_SIMPLE_TEXT_INPUT_PROTOCOL so > that we do not miss the problem again. Thanks! Alex > > We need testing for the EFISIMPLE_TEXT_INPUT_EX_PROTOCOL too. > > Best regards > > Heinrich > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [BUG] efi_loader: SIMPLE_TEXT_INPUT_EX plus wire up objects properly
Hello Alex, in your efi-next tree you have merged efi_loader: SIMPLE_TEXT_INPUT_EX plus wire up objects properly https://github.com/agraf/u-boot/commit/3486573794a0809d987fd690b1bf6c9093124ce9 The EFI_SIMPLE_TEXT_INPUT_PROTOCOL can be tested with: setenv efi_selftest text input bootefi selftest Before the patch entering CTRL+C resulted in: Executing 'text input' Waiting for your input To terminate type 'x' Unicode char 3 (unknown), scan code 0 (Null) With this patch CTRC+C is not interpreted as 0x03 anymore. So, please, remove the patch from the repository, rework it and subject it to review. I will try to write a Python test for EFI_SIMPLE_TEXT_INPUT_PROTOCOL so that we do not miss the problem again. We need testing for the EFISIMPLE_TEXT_INPUT_EX_PROTOCOL too. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed
In the case where one deletes an already-non-existing variable, or sets
a variable to the value it already has, there is no point in writing the
environment back, thus reducing wear on the underlying storage
device.
Signed-off-by: Rasmus Villemoes
---
tools/env/fw_env.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index a5d75958e1..87aaa15198 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -110,6 +110,7 @@ struct environment {
unsigned char *flags;
char *data;
enum flag_scheme flag_scheme;
+ int dirty;
};
static struct environment environment = {
@@ -508,6 +509,9 @@ int fw_env_flush(struct env_opts *opts)
if (!opts)
opts = &default_opts;
+ if (!environment.dirty)
+ return 0;
+
/*
* Update CRC
*/
@@ -553,7 +557,8 @@ int fw_env_write(char *name, char *value)
deleting = (oldval && !(value && strlen(value)));
creating = (!oldval && (value && strlen(value)));
- overwriting = (oldval && (value && strlen(value)));
+ overwriting = (oldval && (value && strlen(value) &&
+ strcmp(oldval, value)));
/* check for permission */
if (deleting) {
@@ -593,6 +598,7 @@ int fw_env_write(char *name, char *value)
/* Nothing to do */
return 0;
+ environment.dirty = 1;
if (deleting || overwriting) {
if (*++nxt == '\0') {
*env = '\0';
@@ -1441,6 +1447,7 @@ int fw_env_open(struct env_opts *opts)
"Warning: Bad CRC, using default
environment\n");
memcpy(environment.data, default_environment,
sizeof(default_environment));
+ environment.dirty = 1;
}
} else {
flag0 = *environment.flags;
@@ -1503,6 +1510,7 @@ int fw_env_open(struct env_opts *opts)
"Warning: Bad CRC, using default
environment\n");
memcpy(environment.data, default_environment,
sizeof(default_environment));
+ environment.dirty = 1;
dev_current = 0;
} else {
switch (environment.flag_scheme) {
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/13] pico-imx7d: Update the README file
Hello Tom and Stefano, This should be applied for release as it puts the README aligned with current use. Please consider it. On Tue, Sep 4, 2018 at 4:13 PM Otavio Salvador wrote: > On Tue, Sep 4, 2018 at 11:06 AM Michael Nazzareno Trimarchi > wrote: > ... > > Those change are about imx6ul and you update the readme of imx7d > > Those put them on sync and it is part of our work. I see no reason for > another PR just for a single commit. > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 > -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fwd: Parallel build is broken
On Wed, Sep 5, 2018 at 2:58 PM Adam Ford wrote: > > On Wed, Sep 5, 2018 at 3:46 AM Alex Kiernan wrote: > > > > On Tue, Sep 4, 2018 at 3:54 PM Andy Shevchenko > > wrote: > > > > > > On Tue, Sep 4, 2018 at 5:50 PM Andy Shevchenko > > > wrote: > > > > > > > > On Tue, Sep 4, 2018 at 5:00 PM Tom Rini wrote: > > > > > > > > > > On Tue, Sep 04, 2018 at 03:42:05PM +0300, Andy Shevchenko wrote: > > > > > > > > > > > -- Forwarded message - > > > > > > From: Andy Shevchenko > > > > > > Date: Tue, Sep 4, 2018 at 3:40 PM > > > > > > Subject: Parallel build is broken > > > > > > To: Tom Rini > > > > > > Cc: Bin Meng , Simon Glass > > > > > > > > > > > > > > > > > > U-Boot can't be build with make -j16. > > > > > > > > > > > > Second pass passes fine. > > > > > > > > > > > > Didn't investigate myself and probably will not have time (near to > > > > > > vacation time for me). > > > > > > So, please, fix it before release. > > > > > > > > > > > > sh: echo: I/O error > > > > > > make[1]: *** [scripts/Makefile.build:278: common/malloc_simple.o] > > > > > > Error 1 > > I am no expert, but I/O error to me indicates a hardware problem on > the build machine and not necessarily a software issue. Not exactly. AFAIR it's a message mapped to EIO errno. The scenario can be like that (hypothetically), make runs compiler, but instead of compiler ccache is being called and, in case it's somehow broken, it might try to access to wrong block on the block device which returns EIO on some (read()?) system call. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull last minute ARC fixes
On Wed, Sep 05, 2018 at 03:19:13PM +, Alexey Brodkin wrote: > Hi Tom, > > The following changes since commit 3005162a43adcfd9cbb524960ad9ff44e809980c: > > Prepare v2018.09-rc3 (2018-09-03 15:36:33 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-arc.git tags/arc-updates-for-2018.09 > > for you to fetch changes up to 13e57722fe7a96f23b09d3407f871f43aa3b096e: > > ARC: HSDK: Fix timer frequency value (2018-09-05 18:11:45 +0300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] Please pull u-boot-imx
On Tue, Sep 04, 2018 at 09:11:50AM +0200, Stefano Babic wrote: > Hi Tom, > > a new PR. I dropped the patches causing breakages on PowerPC boards, as > well as the issue on GE boards. It ran on travis successfully. > > > The following changes since commit 11ed312896c5f5814064c5d45dcb2f53dc121437: > > configs: am57xx: change default board name to beagle_x15 (2018-08-26 > 12:26:16 -0400) > > are available in the Git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to c1d1543ebc6e1fb026d0d7ac96d865faa7567555: > > mx7dsabresd: Add the qspi target to the list of supported defconfigs > (2018-09-04 08:47:23 +0200) Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] x86: tangier: pinmux: add API to configure protected pins
On Wed, Sep 05, 2018 at 09:24:40AM -0600, Simon Glass wrote: > Hi Georgi, > > On 4 September 2018 at 07:34, Georgii Staroselskii > wrote: > > This API is going to be used to configure some pins that are protected > > for simple modification. > > > > It's not a comprehensive pinctrl driver but can be turned into one > > when we need this in the future. Now it is planned to be used only > > in one place. So that's why I decided not to pollute the codebase with a > > full-blown pinctrl-merrifield nobody will use. > > > > This driver reads corresponding fields in DT and configures pins > > accordingly. > > > > The "protected" flag is used to distinguish configuration of SCU-owned > > pins from the ordinary ones. > > > > The code has been adapted from Linux work done by Andy Shevchenko > > in pinctrl-merrfifield.c > > > > Signed-off-by: Georgii Staroselskii > > --- > > arch/x86/cpu/tangier/Makefile | 2 +- > > arch/x86/cpu/tangier/pinmux.c | 196 > > ++ > > 2 files changed, 197 insertions(+), 1 deletion(-) > > create mode 100644 arch/x86/cpu/tangier/pinmux.c > > > > Please can you use the livetree API (dev_read_...)? > > Regards, > Simon Sure. Will do. It will need CONFIG_OF_LIVE=y for edison_defconfig to be set. Is there any other modifications or possible regressions that I need to take into account? Or if I just stick to doc/driver-model/livetree.txt things should go smoothly? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: Update README.txt to clarify device tree usage
On Wed, Sep 05, 2018 at 09:24:44AM -0600, Simon Glass wrote: > Hi Tom, > > On 31 August 2018 at 09:59, Tom Rini wrote: > > In the section about Device Trees add a paragraph at the end that > > clarifies how we decide of a tree is valid or not. We say that all > > bindings must either be in the specification (link provided) or in our > > device-tree-bindings directory. We say that most of these come from the > > Linux Kernel and as such some design decisions are made for us already, > > but that in most cases we wish to retain compatibility. > > > > Cc: Simon Glass > > Cc: Bin Meng > > Signed-off-by: Tom Rini > > --- > > doc/driver-model/README.txt | 9 + > > 1 file changed, 9 insertions(+) > > > > Reviewed-by: Simon Glass > > nits below > > > diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt > > index d6fa5c485793..e949ff63bae4 100644 > > --- a/doc/driver-model/README.txt > > +++ b/doc/driver-model/README.txt > > @@ -449,6 +449,15 @@ The driver model tree is intended to mirror that of > > the device tree. The > > root driver is at device tree offset 0 (the root node, '/'), and its > > children are the children of the root node. > > > > +In order for a device tree to be valid, the content must be correct with > > +respect to either device tree specification > > +(https://www.devicetree.org/specifications/) or the device tree bindings > > that > > +are found in the doc/device-tree-bindings directory. When not U-Boot > > specific > > When not U-Boot-specific, > > > +the bindings in this directory tend to come from the Linux Kernel. As such > > +certain design decisions may have been made already for us in terms of how > > +specific devices are described and bound. In most circumstances we wish to > > +retain compatibility without additional changes being made to the device > > tree > > +source files. > > > > Declaring Uclasses > > -- Thanks, I'll add the comma when I commit, barring further comments from people. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: Update README.txt to clarify device tree usage
Hi Tom, On 31 August 2018 at 09:59, Tom Rini wrote: > In the section about Device Trees add a paragraph at the end that > clarifies how we decide of a tree is valid or not. We say that all > bindings must either be in the specification (link provided) or in our > device-tree-bindings directory. We say that most of these come from the > Linux Kernel and as such some design decisions are made for us already, > but that in most cases we wish to retain compatibility. > > Cc: Simon Glass > Cc: Bin Meng > Signed-off-by: Tom Rini > --- > doc/driver-model/README.txt | 9 + > 1 file changed, 9 insertions(+) > Reviewed-by: Simon Glass nits below > diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt > index d6fa5c485793..e949ff63bae4 100644 > --- a/doc/driver-model/README.txt > +++ b/doc/driver-model/README.txt > @@ -449,6 +449,15 @@ The driver model tree is intended to mirror that of the > device tree. The > root driver is at device tree offset 0 (the root node, '/'), and its > children are the children of the root node. > > +In order for a device tree to be valid, the content must be correct with > +respect to either device tree specification > +(https://www.devicetree.org/specifications/) or the device tree bindings that > +are found in the doc/device-tree-bindings directory. When not U-Boot > specific When not U-Boot-specific, > +the bindings in this directory tend to come from the Linux Kernel. As such > +certain design decisions may have been made already for us in terms of how > +specific devices are described and bound. In most circumstances we wish to > +retain compatibility without additional changes being made to the device tree > +source files. > > Declaring Uclasses > -- > -- > 2.7.4 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] x86: tangier: pinmux: add API to configure protected pins
Hi Georgi, On 4 September 2018 at 07:34, Georgii Staroselskii wrote: > This API is going to be used to configure some pins that are protected > for simple modification. > > It's not a comprehensive pinctrl driver but can be turned into one > when we need this in the future. Now it is planned to be used only > in one place. So that's why I decided not to pollute the codebase with a > full-blown pinctrl-merrifield nobody will use. > > This driver reads corresponding fields in DT and configures pins > accordingly. > > The "protected" flag is used to distinguish configuration of SCU-owned > pins from the ordinary ones. > > The code has been adapted from Linux work done by Andy Shevchenko > in pinctrl-merrfifield.c > > Signed-off-by: Georgii Staroselskii > --- > arch/x86/cpu/tangier/Makefile | 2 +- > arch/x86/cpu/tangier/pinmux.c | 196 > ++ > 2 files changed, 197 insertions(+), 1 deletion(-) > create mode 100644 arch/x86/cpu/tangier/pinmux.c > Please can you use the livetree API (dev_read_...)? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull last minute ARC fixes
Hi Tom, The following changes since commit 3005162a43adcfd9cbb524960ad9ff44e809980c: Prepare v2018.09-rc3 (2018-09-03 15:36:33 -0400) are available in the Git repository at: git://git.denx.de/u-boot-arc.git tags/arc-updates-for-2018.09 for you to fetch changes up to 13e57722fe7a96f23b09d3407f871f43aa3b096e: ARC: HSDK: Fix timer frequency value (2018-09-05 18:11:45 +0300) Minor changes for ARC 1. Fix CPU clock value in HSDK's .dts so time is counted properly. 2. Enable bootelf command on EMDK Alexey Brodkin (1): EMDK: Enable bootelf Eugeniy Paltsev (1): ARC: HSDK: Fix timer frequency value arch/arc/dts/hsdk.dts | 2 +- configs/emdk_defconfig | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: extend baudrate table with 57600
On Wed, Sep 05, 2018 at 12:57:39PM +0800, Bin Meng wrote:
> Hi Christian,
>
> On Tue, Sep 4, 2018 at 6:07 PM Christian Gmeiner
> wrote:
> >
> > Hi all,
> >
> > I totally forgot to answer that mail - but as I need this change my
> > motivation is back.
> >
> > Am Do., 22. Juni 2017 um 08:50 Uhr schrieb Bin Meng :
> > >
> > > Hi Christian,
> > >
> > > On Fri, Jun 9, 2017 at 8:58 AM, Tom Rini wrote:
> > > > On Thu, Jun 08, 2017 at 09:38:49AM +0200, Christian Gmeiner wrote:
> > > >> Hi Tom
> > > >>
> > > >> 2017-06-06 22:04 GMT+02:00 Tom Rini :
> > > >> > On Tue, Jun 06, 2017 at 01:51:38PM +0200, Christian Gmeiner wrote:
> > > >> >
> > > >> >> Signed-off-by: Christian Gmeiner
> > > >> >> ---
> > > >> >> include/configs/x86-common.h | 2 +-
> > > >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >> >>
> > > >> >> diff --git a/include/configs/x86-common.h
> > > >> >> b/include/configs/x86-common.h
> > > >> >> index b5ef8b5..9a97714 100644
> > > >> >> --- a/include/configs/x86-common.h
> > > >> >> +++ b/include/configs/x86-common.h
> > > >> >> @@ -56,7 +56,7 @@
> > > >> >> * Serial Configuration
> > > >> >> */
> > > >> >> #define CONFIG_SYS_BAUDRATE_TABLE{300, 600, 1200, 2400, 4800, \
> > > >> >> - 9600, 19200, 38400, 115200}
> > > >> >> + 9600, 19200, 38400, 57600,
> > > >> >> 115200}
> > > >> >> #define CONFIG_SYS_NS16550_PORT_MAPPED
> > > >> >>
> > > >> >> #define CONFIG_CMDLINE_EDITING
> > > >> >
> > > >> > Can we just use the fall back table instead? Thanks!
> > > >>
> > > >> Can you point me to the "fall back table"?
> > > >
> > > > If one isn't defined the one in is used.
> > >
> >
> > The fallback table looks okay and has 57600 as baud rate in it. The
> > problematic
> > part is the xf86-common.h which defines CONFIG_SYS_BAUDRATE_TABLE and
> > as a result the fallback table plays no role here.
> >
> > > Can you respin the patch per Tom's suggestion? Thanks!
> >
> > I think that the current patch is okay as Tom's suggestion does not fly.
> >
>
> I believe what Tom asked was to update config_fallbacks.h directly,
> and then no need to keep x86-specific one.
To be extra clear, drop the table from the x86 file and then the default
will be used.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] imx: mx7: avoid some initialization if low level is skipped
> -Original Message-
> From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> Sent: 2018年9月5日 18:56
> To: u-boot@lists.denx.de; Fabio Estevam
> Cc: ryan.har...@linaro.org; Rui Miguel Silva ; Bryan
> O'Donoghue ; Stefano Babic ;
> Albert Aribaud ; Peng Fan
> Subject: [PATCH 1/4] imx: mx7: avoid some initialization if low level is
> skipped
>
> From: Rui Miguel Silva
>
> We can have the case where u-boot is launched after some other low level
> enabler, like for example when u-boot runs after arm-trusted-firmware and/or
> optee. So, because of that we may need to jump the initialization of some IP
> blocks even because we may no longer have the permission for that.
>
> So, if the config option to skip low level init is set disable also timer,
> board and
> csu initialization.
>
> Signed-off-by: Rui Miguel Silva
> Signed-off-by: Bryan O'Donoghue
> Cc: Stefano Babic
> Cc: Fabio Estevam
> Cc: Albert Aribaud
> Cc: Peng Fan
> Cc: u-boot@lists.denx.de
> ---
> arch/arm/mach-imx/mx7/soc.c| 2 ++
> arch/arm/mach-imx/syscounter.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
> index 7334ca9eb8..c38bd1ce46 100644
> --- a/arch/arm/mach-imx/mx7/soc.c
> +++ b/arch/arm/mach-imx/mx7/soc.c
> @@ -133,6 +133,7 @@ u32 __weak get_board_rev(void) } #endif
>
> +#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> /* enable all periherial can be accessed in nosec mode */ static void
> init_csu(void) { @@ -182,6 +183,7 @@ int arch_cpu_init(void)
>
> return 0;
> }
> +#endif
>
> #ifdef CONFIG_ARCH_MISC_INIT
> int arch_misc_init(void)
> diff --git a/arch/arm/mach-imx/syscounter.c b/arch/arm/mach-imx/syscounter.c
> index 676bb3caa9..2c319681fc 100644
> --- a/arch/arm/mach-imx/syscounter.c
> +++ b/arch/arm/mach-imx/syscounter.c
> @@ -55,6 +55,7 @@ static inline unsigned long long us_to_tick(unsigned long
> long usec)
> return usec;
> }
>
> +#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> int timer_init(void)
> {
> struct sctr_regs *sctr = (struct sctr_regs *)SCTR_BASE_ADDR; @@ -76,6
> +77,7 @@ int timer_init(void)
>
> return 0;
> }
> +#endif
>
> unsigned long long get_ticks(void)
> {
Reviewed-by: Peng Fan
> --
> 2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6 v4] mips: Add basic MediaTek MT7620/88 support
This patch adds basic support for the MediaTek MT7620/88 SoCs. Parts of
the code is copied from the MediaTek GitHub repository:
https://github.com/MediaTek-Labs/linkit-smart-uboot.git
The mt7628a.dtsi file is imported from Linux v4.17.
Support for the LinkIt Smart 7688 module and the Gardena Smart Gateway
both based on the MT7688 will be added in further patches.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
---
v4:
- Remove dead code from debug version in lowlevel_init
- Use sX registers now for real
- Increase cache line size in ddr_calibrate() to 128 as done in the
original code
v3:
- Added dtsi file with this platforms support as suggested by Daniel
- Rebased on top of Daniels I-cache startup patches -> removed magic
with KSEG0 call of ddr_calibrate. Its now called directly and the
bootup is much faster
- Some improvements to print_cpuinfo(), use ioremap_nocache etc
- Added .set noreorder to lowlevel_init.S
- Multiple improvements to lowlevel_init.S as suggested by Daniel
v2:
- Sort Kconfig symbols alphabetically
- Use MIPS_TUNE_24KC
- Use imply for SPI support
- Dont' add LinkIt module support yet (is added with the board support)
- Move SKIP_LOWLEVEL_INIT from Kconfig to config header
- Use DT to get the base address of the system controller (for
display_cpuinfo)
- Remove _machine_restart - a separate driver is provided in a new patch
- Remove cachop_op() and cal_invalidate_dcache_range and use the
generic invalidate_dcache_range function instead
arch/mips/Kconfig | 16 ++
arch/mips/Makefile| 1 +
arch/mips/dts/mt7628a.dtsi| 135 +++
arch/mips/mach-mt7620/Kconfig | 113 +
arch/mips/mach-mt7620/Makefile| 8 +
arch/mips/mach-mt7620/cpu.c | 69 ++
arch/mips/mach-mt7620/ddr_calibrate.c | 308
arch/mips/mach-mt7620/lowlevel_init.S | 322 ++
arch/mips/mach-mt7620/mt76xx.h| 32 +++
9 files changed, 1004 insertions(+)
create mode 100644 arch/mips/dts/mt7628a.dtsi
create mode 100644 arch/mips/mach-mt7620/Kconfig
create mode 100644 arch/mips/mach-mt7620/Makefile
create mode 100644 arch/mips/mach-mt7620/cpu.c
create mode 100644 arch/mips/mach-mt7620/ddr_calibrate.c
create mode 100644 arch/mips/mach-mt7620/lowlevel_init.S
create mode 100644 arch/mips/mach-mt7620/mt76xx.h
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 6e5e0ffe65..b3981ef2e6 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -68,6 +68,21 @@ config ARCH_BMIPS
select SYSRESET
imply CMD_DM
+config ARCH_MT7620
+ bool "Support MT7620/7688 SoCs"
+ imply CMD_DM
+ select DISPLAY_CPUINFO
+ select DM
+ select DM_SERIAL
+ imply DM_SPI
+ imply DM_SPI_FLASH
+ select MIPS_TUNE_24KC
+ select OF_CONTROL
+ select ROM_EXCEPTION_VECTORS
+ select SUPPORTS_CPU_MIPS32_R1
+ select SUPPORTS_CPU_MIPS32_R2
+ select SUPPORTS_LITTLE_ENDIAN
+
config MACH_PIC32
bool "Support Microchip PIC32"
select DM
@@ -120,6 +135,7 @@ source "board/qemu-mips/Kconfig"
source "arch/mips/mach-ath79/Kconfig"
source "arch/mips/mach-bmips/Kconfig"
source "arch/mips/mach-pic32/Kconfig"
+source "arch/mips/mach-mt7620/Kconfig"
if MIPS
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index a36f5f1fb6..802244a06e 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -14,6 +14,7 @@ libs-y += arch/mips/lib/
machine-$(CONFIG_ARCH_ATH79) += ath79
machine-$(CONFIG_ARCH_BMIPS) += bmips
machine-$(CONFIG_MACH_PIC32) += pic32
+machine-$(CONFIG_ARCH_MT7620) += mt7620
machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y))
libs-y += $(machdirs)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
new file mode 100644
index 00..d00f528e1f
--- /dev/null
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "ralink,mt7628a-soc";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "mti,mips24KEc";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ resetc: reset-controller {
+ compatible = "ralink,rt2880-reset";
+ #reset-cells = <1>;
+ };
+
+ cpuintc: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ palmbus@1000 {
+ compatible = "palmbus", "simple-bus";
+ reg = <0x1000 0x20>;
+ ranges = <0x0 0x1000 0x1F>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+
Re: [U-Boot] [PATCH] ARM: dts: logicpd-torpedo-37xx-devkit-u-boot: Fix MMC Card Detect
Hi Adam,
On 09/03/2018 05:08 PM, Adam Ford wrote:
When re-syncing the DTS files from the kernel, something caused
the MMC driver to no longer detect the MMC card. Undoing the
CD-invert appears to fix the issue.
Fixes: e6ea2390cde3 ("ARM: DTS: Resync LogicPD-Torpedo-37xx-devkit
with Linux 4.18-RC4")
Looking at that commit, we see:
- cd-gpios = <&gpio4 31 IRQ_TYPE_LEVEL_LOW>; /* gpio127 */
+ cd-gpios = <&gpio4 31 GPIO_ACTIVE_LOW>; /* gpio127 */
IRQ_TYPE_LEVEL_LOW is defined as 8, which in this context should get
interpreted as GPIO_TRANSITORY which is ignored by U-Boot. Thus the
card-detect polarity got toggled by that commit.
If ACTIVE_LOW is indeed the correct polarity (and I'm guessing it
is because otherwise MMC wouldn't work in Linux), this patch sounds
correct.
- Tuomas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6 v3] mips: Add basic MediaTek MT7620/88 support
Hi Daniel,
On 05.09.2018 13:45, Daniel Schwierzeck wrote:
On 16.08.2018 15:27, Stefan Roese wrote:
This patch adds basic support for the MediaTek MT7620/88 SoCs. Parts of
the code is copied from the MediaTek GitHub repository:
https://github.com/MediaTek-Labs/linkit-smart-uboot.git
The mt7628a.dtsi file is imported from Linux v4.17.
Support for the LinkIt Smart 7688 module and the Gardena Smart Gateway
both based on the MT7688 will be added in further patches.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
---
v3:
- Added dtsi file with this platforms support as suggested by Daniel
- Rebased on top of Daniels I-cache startup patches -> removed magic
with KSEG0 call of ddr_calibrate. Its now called directly and the
bootup is much faster
- Some improvements to print_cpuinfo(), use ioremap_nocache etc
- Added .set noreorder to lowlevel_init.S
- Multiple improvements to lowlevel_init.S as suggested by Daniel
v2:
- Sort Kconfig symbols alphabetically
- Use MIPS_TUNE_24KC
- Use imply for SPI support
- Dont' add LinkIt module support yet (is added with the board support)
- Move SKIP_LOWLEVEL_INIT from Kconfig to config header
- Use DT to get the base address of the system controller (for
display_cpuinfo)
- Remove _machine_restart - a separate driver is provided in a new patch
- Remove cachop_op() and cal_invalidate_dcache_range and use the
generic invalidate_dcache_range function instead
arch/mips/Kconfig | 16 +
arch/mips/Makefile| 1 +
arch/mips/dts/mt7628a.dtsi| 135 +
arch/mips/mach-mt7620/Kconfig | 113 +++
arch/mips/mach-mt7620/Makefile| 8 +
arch/mips/mach-mt7620/cpu.c | 69 +
arch/mips/mach-mt7620/ddr_calibrate.c | 308 +++
arch/mips/mach-mt7620/lowlevel_init.S | 406 ++
arch/mips/mach-mt7620/mt76xx.h| 32 ++
9 files changed, 1088 insertions(+)
create mode 100644 arch/mips/dts/mt7628a.dtsi
create mode 100644 arch/mips/mach-mt7620/Kconfig
create mode 100644 arch/mips/mach-mt7620/Makefile
create mode 100644 arch/mips/mach-mt7620/cpu.c
create mode 100644 arch/mips/mach-mt7620/ddr_calibrate.c
create mode 100644 arch/mips/mach-mt7620/lowlevel_init.S
create mode 100644 arch/mips/mach-mt7620/mt76xx.h
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 6e5e0ffe65..b3981ef2e6 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -68,6 +68,21 @@ config ARCH_BMIPS
select SYSRESET
imply CMD_DM
+config ARCH_MT7620
+ bool "Support MT7620/7688 SoCs"
+ imply CMD_DM
+ select DISPLAY_CPUINFO
+ select DM
+ select DM_SERIAL
+ imply DM_SPI
+ imply DM_SPI_FLASH
+ select MIPS_TUNE_24KC
+ select OF_CONTROL
+ select ROM_EXCEPTION_VECTORS
+ select SUPPORTS_CPU_MIPS32_R1
+ select SUPPORTS_CPU_MIPS32_R2
+ select SUPPORTS_LITTLE_ENDIAN
+
config MACH_PIC32
bool "Support Microchip PIC32"
select DM
@@ -120,6 +135,7 @@ source "board/qemu-mips/Kconfig"
source "arch/mips/mach-ath79/Kconfig"
source "arch/mips/mach-bmips/Kconfig"
source "arch/mips/mach-pic32/Kconfig"
+source "arch/mips/mach-mt7620/Kconfig"
if MIPS
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index a36f5f1fb6..802244a06e 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -14,6 +14,7 @@ libs-y += arch/mips/lib/
machine-$(CONFIG_ARCH_ATH79) += ath79
machine-$(CONFIG_ARCH_BMIPS) += bmips
machine-$(CONFIG_MACH_PIC32) += pic32
+machine-$(CONFIG_ARCH_MT7620) += mt7620
machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y))
libs-y += $(machdirs)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
new file mode 100644
index 00..d00f528e1f
--- /dev/null
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "ralink,mt7628a-soc";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "mti,mips24KEc";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ resetc: reset-controller {
+ compatible = "ralink,rt2880-reset";
+ #reset-cells = <1>;
+ };
+
+ cpuintc: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ palmbus@1000 {
+ compatible = "palmbus", "simple-bus";
+ reg = <0x1000 0x20>;
+ ranges = <0x0 0x1000 0x1F>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sysc: system-controller@0 {
+
Re: [U-Boot] [PATCH 1/3] gpio: omap_gpio: Add xlate function to support GPIO_ACTIVE_LOW
On Wed, Sep 5, 2018 at 7:29 AM Jean-Jacques Hiblot wrote:
>
> Adam,
>
>
> On 05/09/2018 11:35, Adam Ford wrote:
> > The gpio driver doesn't current support knowing whether or not
> > GPIO is active low or high. It simply returns the value. The
> > side effect of this, is that the MMC routines which check
> > the status card detect or write protect must use a u-boot specific
> > dts modification to enable inverting the pin values when
> > GPIO_ACTIVE_LOW is used. This allows the invert option to be removed
> >
> > Signed-off-by: Adam Ford
> >
> > diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
> > index 555eba2662..0ecd2f374a 100644
> > --- a/drivers/gpio/omap_gpio.c
> > +++ b/drivers/gpio/omap_gpio.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -275,12 +276,25 @@ static int omap_gpio_get_function(struct udevice
> > *dev, unsigned offset)
> > return GPIOF_INPUT;
> > }
> >
> > +static int omap_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
> > +struct ofnode_phandle_args *args)
> > +{
> > + desc->offset = args->args[0];
> > +
> > + if (args->args[1] & GPIO_ACTIVE_LOW)
> > + desc->flags = GPIOD_ACTIVE_LOW;
> > + else
> > + desc->flags = 0;
> > + return 0;
> > +}
> Do we need this ? It looks a lot like the default behaviour (see
> gpio_xlate_offs_flags in gpio-uclass.c).
I don't know. I saw that other gpio drivers had the xlate, so it
seemed like it made sense to have it here. I'll revert it, and keep
the other stuff and see what happens along with removing the entry
from the struct.
I don't have the other (non-Logic PD) boards, so I cannot test them.
adam
>
> JJ
> > Do we need this ? It looks like the default behaviour
> > static const struct dm_gpio_ops gpio_omap_ops = {
> > .direction_input= omap_gpio_direction_input,
> > .direction_output = omap_gpio_direction_output,
> > .get_value = omap_gpio_get_value,
> > .set_value = omap_gpio_set_value,
> > .get_function = omap_gpio_get_function,
> > + .xlate = omap_gpio_xlate,
> > };
> >
> > static int omap_gpio_probe(struct udevice *dev)
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: DTS: various omap3: Remove cd-inverted from u-boot.dtsi
On Wed, Sep 5, 2018 at 7:24 AM Jean-Jacques Hiblot wrote:
>
> Hi Adam,
>
>
> On 05/09/2018 11:35, Adam Ford wrote:
> > With the omap_mmc driver no longer supporting cd-inverted, this
> > patch removes all these references since they are not needed.
> >
> > Signed-off-by: Adam Ford
> >
> > diff --git a/arch/arm/dts/am3517-evm-u-boot.dtsi
> > b/arch/arm/dts/am3517-evm-u-boot.dtsi
> > index c02beaad77..59df819f9d 100644
> > --- a/arch/arm/dts/am3517-evm-u-boot.dtsi
> > +++ b/arch/arm/dts/am3517-evm-u-boot.dtsi
> > @@ -10,10 +10,6 @@
> > };
> > };
> >
> > -&mmc1 {
> > - cd-inverted;
> > -};
> > -
> > &uart1 {
> > reg-shift = <2>;
> > };
> > diff --git a/arch/arm/dts/omap3-beagle-u-boot.dtsi
> > b/arch/arm/dts/omap3-beagle-u-boot.dtsi
> > index 094f9557b7..41beaf0900 100644
> > --- a/arch/arm/dts/omap3-beagle-u-boot.dtsi
> > +++ b/arch/arm/dts/omap3-beagle-u-boot.dtsi
> > @@ -11,10 +11,6 @@
> > };
> > };
> >
> > -&mmc1 {
> > - cd-inverted;
> > -};
> > -
> > &uart1 {
> > reg-shift = <2>;
> > };
> > diff --git a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
> > b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
> > index 094f9557b7..41beaf0900 100644
> > --- a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
> > +++ b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
> > @@ -11,10 +11,6 @@
> > };
> > };
> >
> > -&mmc1 {
> > - cd-inverted;
> > -};
> > -
> > &uart1 {
> > reg-shift = <2>;
> > };
> > diff --git a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
> > b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
> > index 094f9557b7..41beaf0900 100644
> > --- a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
> > +++ b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
> > @@ -11,10 +11,6 @@
> > };
> > };
> >
> > -&mmc1 {
> > - cd-inverted;
> > -};
> > -
> > &uart1 {
> > reg-shift = <2>;
> > };
> > diff --git a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
> > b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
> > index b09ce0efb5..de411316d8 100644
> > --- a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
> > +++ b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
> > @@ -11,10 +11,6 @@
> > };
> > };
> >
> > -&mmc1 {
> > - cd-inverted;
> > -};
> > -
> > &uart1 {
> > reg-shift = <2>;
> > };
> > diff --git a/arch/arm/dts/omap3-evm-u-boot.dtsi
> > b/arch/arm/dts/omap3-evm-u-boot.dtsi
> > index b09ce0efb5..de411316d8 100644
> > --- a/arch/arm/dts/omap3-evm-u-boot.dtsi
> > +++ b/arch/arm/dts/omap3-evm-u-boot.dtsi
> > @@ -11,10 +11,6 @@
> > };
> > };
> >
> > -&mmc1 {
> > - cd-inverted;
> > -};
> > -
> > &uart1 {
> > reg-shift = <2>;
> > };
>
> Shouldn't logicpd-torpedo-37xx-devkit-u-boot.dtsi be updated ?
I did that already at: https://patchwork.ozlabs.org/patch/965450/
adam
>
> JJ
> ___
> 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] mtd: nand: denali_dt: Add reset support
On 08/24/2018 03:10 PM, Marek Vasut wrote:
> On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
>> Hi Marek,
>
> Hi,
>
>> 2018-08-21 22:57 GMT+09:00 Marek Vasut :
>>> Add optional reset support into the Denali NAND driver. In case there is
>>> a valid reset entry in the DT, the reset gets deasserted before the NAND
>>> controller gets used.
>>>
>>> Signed-off-by: Marek Vasut
>>> Cc: Masahiro Yamada
>>> ---
>>> drivers/mtd/nand/denali_dt.c | 9 +
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
>>> index 65a7797f0f..6fcd7d3843 100644
>>> --- a/drivers/mtd/nand/denali_dt.c
>>> +++ b/drivers/mtd/nand/denali_dt.c
>>> @@ -9,6 +9,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "denali.h"
>>>
>>> @@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev)
>>> const struct denali_dt_data *data;
>>> struct clk clk;
>>> struct resource res;
>>> + struct reset_ctl reset_ctl;
>>> int ret;
>>>
>>> data = (void *)dev_get_driver_data(dev);
>>> @@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
>>>
>>> denali->clk_x_rate = clk_get_rate(&clk);
>>>
>>> + ret = reset_get_by_index(dev, 0, &reset_ctl);
>>> + if (!ret) {
>>> + reset_assert(&reset_ctl);
>>> + udelay(2);
>>> + reset_deassert(&reset_ctl);
>>> + }
>>> +
>>> return denali_init(denali);
>>> }
>>>
>>
>>
>> I was testing this patch today
>> because my SoC also has a reset line for NAND.
>>
>>
>> This patch looks trivial enough,
>> but if the NAND is reset here,
>> my board fails to boot with
>> "nand_base: timeout while waiting for chip to become ready"
>>
>>
>> I do not know why.
>> Please give me more time to figure out what is going on in my SoC.
>
> Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?
Did you figure something out ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mmc: omap_mmc: Remove invert references with gpio xlate available
Adam,
On 05/09/2018 11:35, Adam Ford wrote:
With omap_gpio now translating GPIO_ACTIVE_LOW, any boards
using the 'invert' option will no longer need to do this. This
patch removes the support for 'invert' from the MMC driver.
Signed-off-by: Adam Ford
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 8ab56d247d..e9786ec5bb 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -83,7 +83,6 @@ struct omap_hsmmc_data {
#if CONFIG_IS_ENABLED(DM_MMC)
struct gpio_desc cd_gpio; /* Change Detect GPIO */
struct gpio_desc wp_gpio; /* Write Protect GPIO */
- bool cd_inverted;
#else
int cd_gpio;
int wp_gpio;
@@ -1377,8 +1376,6 @@ static int omap_hsmmc_getcd(struct udevice *dev)
if (value < 0)
return 1;
- if (priv->cd_inverted)
- return !value;
return value;
}
@@ -1860,10 +1857,6 @@ static int omap_hsmmc_ofdata_to_platdata(struct udevice *dev)
}
#endif
-#ifdef OMAP_HSMMC_USE_GPIO
- plat->cd_inverted = fdtdec_get_bool(fdt, node, "cd-inverted");
-#endif
-
return 0;
}
#endif
@@ -1892,9 +1885,6 @@ static int omap_hsmmc_probe(struct udevice *dev)
priv->base_addr = plat->base_addr;
priv->controller_flags = plat->controller_flags;
priv->hw_rev = plat->hw_rev;
-#ifdef OMAP_HSMMC_USE_GPIO
- priv->cd_inverted = plat->cd_inverted;
Could you remove it also from struct omap_hsmmc_plat since it is not
used anymore ?
JJ
-#endif
#ifdef CONFIG_BLK
mmc = plat->mmc;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] gpio: omap_gpio: Add xlate function to support GPIO_ACTIVE_LOW
Adam,
On 05/09/2018 11:35, Adam Ford wrote:
The gpio driver doesn't current support knowing whether or not
GPIO is active low or high. It simply returns the value. The
side effect of this, is that the MMC routines which check
the status card detect or write protect must use a u-boot specific
dts modification to enable inverting the pin values when
GPIO_ACTIVE_LOW is used. This allows the invert option to be removed
Signed-off-by: Adam Ford
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index 555eba2662..0ecd2f374a 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -275,12 +276,25 @@ static int omap_gpio_get_function(struct udevice *dev, unsigned offset)
return GPIOF_INPUT;
}
+static int omap_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
+ struct ofnode_phandle_args *args)
+{
+ desc->offset = args->args[0];
+
+ if (args->args[1] & GPIO_ACTIVE_LOW)
+ desc->flags = GPIOD_ACTIVE_LOW;
+ else
+ desc->flags = 0;
+ return 0;
+}
Do we need this ? It looks a lot like the default behaviour (see
gpio_xlate_offs_flags in gpio-uclass.c).
JJ
Do we need this ? It looks like the default behaviour
static const struct dm_gpio_ops gpio_omap_ops = {
.direction_input= omap_gpio_direction_input,
.direction_output = omap_gpio_direction_output,
.get_value = omap_gpio_get_value,
.set_value = omap_gpio_set_value,
.get_function = omap_gpio_get_function,
+ .xlate = omap_gpio_xlate,
};
static int omap_gpio_probe(struct udevice *dev)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: DTS: various omap3: Remove cd-inverted from u-boot.dtsi
Hi Adam,
On 05/09/2018 11:35, Adam Ford wrote:
With the omap_mmc driver no longer supporting cd-inverted, this
patch removes all these references since they are not needed.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/am3517-evm-u-boot.dtsi
b/arch/arm/dts/am3517-evm-u-boot.dtsi
index c02beaad77..59df819f9d 100644
--- a/arch/arm/dts/am3517-evm-u-boot.dtsi
+++ b/arch/arm/dts/am3517-evm-u-boot.dtsi
@@ -10,10 +10,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-beagle-u-boot.dtsi
b/arch/arm/dts/omap3-beagle-u-boot.dtsi
index 094f9557b7..41beaf0900 100644
--- a/arch/arm/dts/omap3-beagle-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
index 094f9557b7..41beaf0900 100644
--- a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
index 094f9557b7..41beaf0900 100644
--- a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
index b09ce0efb5..de411316d8 100644
--- a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
+++ b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-evm-u-boot.dtsi
b/arch/arm/dts/omap3-evm-u-boot.dtsi
index b09ce0efb5..de411316d8 100644
--- a/arch/arm/dts/omap3-evm-u-boot.dtsi
+++ b/arch/arm/dts/omap3-evm-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
Shouldn't logicpd-torpedo-37xx-devkit-u-boot.dtsi be updated ?
JJ
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fwd: Parallel build is broken
On Wed, Sep 5, 2018 at 3:46 AM Alex Kiernan wrote: > > On Tue, Sep 4, 2018 at 3:54 PM Andy Shevchenko > wrote: > > > > On Tue, Sep 4, 2018 at 5:50 PM Andy Shevchenko > > wrote: > > > > > > On Tue, Sep 4, 2018 at 5:00 PM Tom Rini wrote: > > > > > > > > On Tue, Sep 04, 2018 at 03:42:05PM +0300, Andy Shevchenko wrote: > > > > > > > > > -- Forwarded message - > > > > > From: Andy Shevchenko > > > > > Date: Tue, Sep 4, 2018 at 3:40 PM > > > > > Subject: Parallel build is broken > > > > > To: Tom Rini > > > > > Cc: Bin Meng , Simon Glass > > > > > > > > > > > > > > > U-Boot can't be build with make -j16. > > > > > > > > > > Second pass passes fine. > > > > > > > > > > Didn't investigate myself and probably will not have time (near to > > > > > vacation time for me). > > > > > So, please, fix it before release. > > > > > > > > > > sh: echo: I/O error > > > > > make[1]: *** [scripts/Makefile.build:278: common/malloc_simple.o] > > > > > Error 1 I am no expert, but I/O error to me indicates a hardware problem on the build machine and not necessarily a software issue. adam > > > > > make[1]: *** Waiting for unfinished jobs > > > > > CC drivers/serial/ns16550.o > > > > > CC drivers/spi/spi.o > > > > > CC cmd/mmc.o > > > > > CC drivers/watchdog/tangier_wdt.o > > > > > CC drivers/serial/serial_intel_mid.o > > > > > CC cmd/net.o > > > > > CC drivers/usb/common/common.o > > > > > CC arch/x86/lib/acpi.o > > > > > LD drivers/timer/built-in.o > > > > > CC arch/x86/lib/acpi_table.o > > > > > CC drivers/video/console_normal.o > > > > > make: *** [Makefile:1377: common] Error 2 > > > > > make: *** Waiting for unfinished jobs > > > > > > > > What build target (and O= or not?) is this with? Thanks! > > > > > > make clean && make edison_defconfig && make -j16 > > > > > > gcc (Debian 8.2.0-4) 8.2.0 > > > Copyright (C) 2018 Free Software Foundation, Inc. > > > This is free software; see the source for copying conditions. There is NO > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > > PURPOSE. > > > > So, first time it's being built, consequent runs usually failed. > > > > I've seen this problem - building inside a VMware VM. I've always > found that logging out and back in appears to fix it, so possibly > something related to the session... I've similarly failed to figure > out what the problem is as it comes and goes. > > -- > Alex Kiernan > ___ > 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 1/6 v3] mips: Add basic MediaTek MT7620/88 support
On 16.08.2018 15:27, Stefan Roese wrote:
> This patch adds basic support for the MediaTek MT7620/88 SoCs. Parts of
> the code is copied from the MediaTek GitHub repository:
>
> https://github.com/MediaTek-Labs/linkit-smart-uboot.git
>
> The mt7628a.dtsi file is imported from Linux v4.17.
>
> Support for the LinkIt Smart 7688 module and the Gardena Smart Gateway
> both based on the MT7688 will be added in further patches.
>
> Signed-off-by: Stefan Roese
> Cc: Daniel Schwierzeck
> ---
> v3:
> - Added dtsi file with this platforms support as suggested by Daniel
> - Rebased on top of Daniels I-cache startup patches -> removed magic
> with KSEG0 call of ddr_calibrate. Its now called directly and the
> bootup is much faster
> - Some improvements to print_cpuinfo(), use ioremap_nocache etc
> - Added .set noreorder to lowlevel_init.S
> - Multiple improvements to lowlevel_init.S as suggested by Daniel
>
> v2:
> - Sort Kconfig symbols alphabetically
> - Use MIPS_TUNE_24KC
> - Use imply for SPI support
> - Dont' add LinkIt module support yet (is added with the board support)
> - Move SKIP_LOWLEVEL_INIT from Kconfig to config header
> - Use DT to get the base address of the system controller (for
> display_cpuinfo)
> - Remove _machine_restart - a separate driver is provided in a new patch
> - Remove cachop_op() and cal_invalidate_dcache_range and use the
> generic invalidate_dcache_range function instead
>
> arch/mips/Kconfig | 16 +
> arch/mips/Makefile| 1 +
> arch/mips/dts/mt7628a.dtsi| 135 +
> arch/mips/mach-mt7620/Kconfig | 113 +++
> arch/mips/mach-mt7620/Makefile| 8 +
> arch/mips/mach-mt7620/cpu.c | 69 +
> arch/mips/mach-mt7620/ddr_calibrate.c | 308 +++
> arch/mips/mach-mt7620/lowlevel_init.S | 406 ++
> arch/mips/mach-mt7620/mt76xx.h| 32 ++
> 9 files changed, 1088 insertions(+)
> create mode 100644 arch/mips/dts/mt7628a.dtsi
> create mode 100644 arch/mips/mach-mt7620/Kconfig
> create mode 100644 arch/mips/mach-mt7620/Makefile
> create mode 100644 arch/mips/mach-mt7620/cpu.c
> create mode 100644 arch/mips/mach-mt7620/ddr_calibrate.c
> create mode 100644 arch/mips/mach-mt7620/lowlevel_init.S
> create mode 100644 arch/mips/mach-mt7620/mt76xx.h
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 6e5e0ffe65..b3981ef2e6 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -68,6 +68,21 @@ config ARCH_BMIPS
> select SYSRESET
> imply CMD_DM
>
> +config ARCH_MT7620
> + bool "Support MT7620/7688 SoCs"
> + imply CMD_DM
> + select DISPLAY_CPUINFO
> + select DM
> + select DM_SERIAL
> + imply DM_SPI
> + imply DM_SPI_FLASH
> + select MIPS_TUNE_24KC
> + select OF_CONTROL
> + select ROM_EXCEPTION_VECTORS
> + select SUPPORTS_CPU_MIPS32_R1
> + select SUPPORTS_CPU_MIPS32_R2
> + select SUPPORTS_LITTLE_ENDIAN
> +
> config MACH_PIC32
> bool "Support Microchip PIC32"
> select DM
> @@ -120,6 +135,7 @@ source "board/qemu-mips/Kconfig"
> source "arch/mips/mach-ath79/Kconfig"
> source "arch/mips/mach-bmips/Kconfig"
> source "arch/mips/mach-pic32/Kconfig"
> +source "arch/mips/mach-mt7620/Kconfig"
>
> if MIPS
>
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index a36f5f1fb6..802244a06e 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -14,6 +14,7 @@ libs-y += arch/mips/lib/
> machine-$(CONFIG_ARCH_ATH79) += ath79
> machine-$(CONFIG_ARCH_BMIPS) += bmips
> machine-$(CONFIG_MACH_PIC32) += pic32
> +machine-$(CONFIG_ARCH_MT7620) += mt7620
>
> machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y))
> libs-y += $(machdirs)
> diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
> new file mode 100644
> index 00..d00f528e1f
> --- /dev/null
> +++ b/arch/mips/dts/mt7628a.dtsi
> @@ -0,0 +1,135 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ralink,mt7628a-soc";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + compatible = "mti,mips24KEc";
> + device_type = "cpu";
> + reg = <0>;
> + };
> + };
> +
> + resetc: reset-controller {
> + compatible = "ralink,rt2880-reset";
> + #reset-cells = <1>;
> + };
> +
> + cpuintc: interrupt-controller {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "mti,cpu-interrupt-controller";
> + };
> +
> + palmbus@1000 {
> + compatible = "palmbus", "simple-bus";
> + reg = <0x1000 0x20>;
> + ranges = <0x0 0x1000 0x1F>;
> +
> + #address-cells = <1>;
> +
[U-Boot] [PATCH] ARC: HSDK: Fix timer frequency value
CPU (and hence cpu timers) on HSDK board runs at 500MHz after
preloader so fix wrong CPU frequency value in hsdk.dts
Signed-off-by: Eugeniy Paltsev
---
arch/arc/dts/hsdk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/dts/hsdk.dts b/arch/arc/dts/hsdk.dts
index e41e4ce84b..673bc5b26a 100644
--- a/arch/arc/dts/hsdk.dts
+++ b/arch/arc/dts/hsdk.dts
@@ -20,7 +20,7 @@
core_clk: core_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
- clock-frequency = <10>;
+ clock-frequency = <5>;
u-boot,dm-pre-reloc;
};
};
--
2.14.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Add a pinctrl driver for Merrifield to pinmux I2C#6
On Wed, Sep 5, 2018 at 7:41 AM Bin Meng wrote: > Somehow I did not receive all 5 patches in the v2. Only 2/3/5 is in my > inbox. It looks good and I will wait some comments from others (if > any) for another day or two before applying this. Hmm... At least now I can see your email address in the list of mails I got received. But taking into consideration previous experience with the mails from Georgii I might point to his end for problems. Nevertheless, all of them are available through patchwork: https://patchwork.ozlabs.org/patch/965948/ > > Georgii Staroselskii (5): > > x86: cpu: introduce scu_ipc_raw_command() > > x86: tangier: pinmux: add API to configure protected pins > > x86: dts: edison: configure I2C#6 pins > > x86: tangier: acpi: add I2C6 node > > x86: cpu: add docstring to scu_ipc_command() -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] warp7: configs: add bl33 defconfig
From: Rui Miguel Silva Add default configuration to run u-boot as BL33 in the ARM Trusted Firmware boot flow for AArch32 case. Signed-off-by: Rui Miguel Silva Signed-off-by: Bryan O'Donoghue Cc: Fabio Estevam Cc: Simon Glass Cc: Maxime Ripard Cc: Lukasz Majewski Cc: Tuomas Tynkkynen Cc: u-boot@lists.denx.de --- configs/warp7_bl33_defconfig | 42 1 file changed, 42 insertions(+) create mode 100644 configs/warp7_bl33_defconfig diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig new file mode 100644 index 00..bed970b014 --- /dev/null +++ b/configs/warp7_bl33_defconfig @@ -0,0 +1,42 @@ +CONFIG_ARM=y +CONFIG_ARCH_MX7=y +CONFIG_SECURE_BOOT=y +CONFIG_SYS_TEXT_BASE=0x8780 +CONFIG_TARGET_WARP7=y +CONFIG_ARMV7_BOOT_SEC_DEFAULT=y +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/warp7/imximage.cfg" +CONFIG_HUSH_PARSER=y +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_MMC=y +CONFIG_CMD_PART=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_SETEXPR=y +CONFIG_CMD_DHCP=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_DFU_MMC=y +CONFIG_FSL_ESDHC=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_MXC_USB_OTG_HACTIVE=y +CONFIG_USB_STORAGE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_CI_UDC=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_USB_ETHER=y +CONFIG_USB_ETH_CDC=y +CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" +CONFIG_OF_LIBFDT=y +CONFIG_OPTEE_TZDRAM_SIZE=0x200 -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] warp7: include: configs: set skip low level init
From: Rui Miguel Silva If we have defined the OPTEE ram size and not OPTEE means that we are in the case where OPTEE is loaded already (maybe by ARM Trusted Firmware) and that most of the low level initialization is already done and that we may/should skip it doing them here. Signed-off-by: Rui Miguel Silva Signed-off-by: Bryan O'Donoghue Cc: Fabio Estevam Cc: u-boot@lists.denx.de --- include/configs/warp7.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 1b656a5aaf..a391dfb5c1 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -13,6 +13,17 @@ #define PHYS_SDRAM_SIZESZ_512M +/* + * If we have defined the OPTEE ram size and not OPTEE it means that we were + * launched by OPTEE, because of that we shall skip all the low level + * initialization since it was already done by ATF or OPTEE + */ +#ifdef CONFIG_OPTEE_TZDRAM_SIZE +#ifndef CONFIG_OPTEE +#define CONFIG_SKIP_LOWLEVEL_INIT +#endif +#endif + #define CONFIG_MXC_UART_BASE UART1_IPS_BASE_ADDR /* Size of malloc() pool */ -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] imx: mx7: avoid some initialization if low level is skipped
From: Rui Miguel Silva
We can have the case where u-boot is launched after some other low level
enabler, like for example when u-boot runs after arm-trusted-firmware
and/or optee. So, because of that we may need to jump the initialization of
some IP blocks even because we may no longer have the permission for that.
So, if the config option to skip low level init is set disable also timer,
board and csu initialization.
Signed-off-by: Rui Miguel Silva
Signed-off-by: Bryan O'Donoghue
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Albert Aribaud
Cc: Peng Fan
Cc: u-boot@lists.denx.de
---
arch/arm/mach-imx/mx7/soc.c| 2 ++
arch/arm/mach-imx/syscounter.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 7334ca9eb8..c38bd1ce46 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -133,6 +133,7 @@ u32 __weak get_board_rev(void)
}
#endif
+#ifndef CONFIG_SKIP_LOWLEVEL_INIT
/* enable all periherial can be accessed in nosec mode */
static void init_csu(void)
{
@@ -182,6 +183,7 @@ int arch_cpu_init(void)
return 0;
}
+#endif
#ifdef CONFIG_ARCH_MISC_INIT
int arch_misc_init(void)
diff --git a/arch/arm/mach-imx/syscounter.c b/arch/arm/mach-imx/syscounter.c
index 676bb3caa9..2c319681fc 100644
--- a/arch/arm/mach-imx/syscounter.c
+++ b/arch/arm/mach-imx/syscounter.c
@@ -55,6 +55,7 @@ static inline unsigned long long us_to_tick(unsigned long
long usec)
return usec;
}
+#ifndef CONFIG_SKIP_LOWLEVEL_INIT
int timer_init(void)
{
struct sctr_regs *sctr = (struct sctr_regs *)SCTR_BASE_ADDR;
@@ -76,6 +77,7 @@ int timer_init(void)
return 0;
}
+#endif
unsigned long long get_ticks(void)
{
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] optee: adjust dependencies and default values for dram
From: Rui Miguel Silva We may have, the not yet considered, scenario where OPTEE is loaded before u-boot and *not* by u-boot, e.g, the boot flow using the ARM Trusted Firmware (ATF), where in the 32bit flow is: BootRom->ATF(BL2)->Optee(BL32)->u-boot(BL33) In this case we need still to reserve the memory used by optee, to avoid for example to realocate ourself to the same address at the end of DRAM. So, we change here the dependencies on the OPTEE lib and we set the default size and base of TZRAM to zero. Signed-off-by: Rui Miguel Silva Signed-off-by: Bryan O'Donoghue Cc: Fabio Estevam Cc: Ryan Harkin Cc: u-boot@lists.denx.de --- configs/warp7_defconfig | 2 ++ lib/optee/Kconfig | 8 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 15a66739f8..a1c0b69ea8 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -46,5 +46,7 @@ CONFIG_USB_ETH_CDC=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" CONFIG_OF_LIBFDT=y CONFIG_OPTEE=y +CONFIG_OPTEE_TZDRAM_SIZE=0x300 +CONFIG_OPTEE_TZDRAM_BASE=0x9d00 CONFIG_OPTEE_LOAD_ADDR=0x8400 CONFIG_BOOTM_OPTEE=y diff --git a/lib/optee/Kconfig b/lib/optee/Kconfig index 1e5ab45c3d..3773d89c31 100644 --- a/lib/optee/Kconfig +++ b/lib/optee/Kconfig @@ -10,21 +10,20 @@ config OPTEE config OPTEE_LOAD_ADDR hex "OPTEE load address" default 0x + depends on OPTEE help The load address of the bootable OPTEE binary. config OPTEE_TZDRAM_SIZE hex "Amount of Trust-Zone RAM for the OPTEE image" - depends on OPTEE - default 0x300 + default 0x000 help The size of pre-allocated Trust Zone DRAM to allocate for the OPTEE runtime. config OPTEE_TZDRAM_BASE hex "Base address of Trust-Zone RAM for the OPTEE image" - depends on OPTEE - default 0x9d00 + default 0x help The base address of pre-allocated Trust Zone DRAM for the OPTEE runtime. @@ -32,6 +31,7 @@ config OPTEE_TZDRAM_BASE config BOOTM_OPTEE bool "Support OPTEE bootm command" select BOOTM_LINUX + depends on OPTEE default n help Select this command to enable chain-loading of a Linux kernel -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add WaRP7 ATF chainloaded setup
This set of patches makes a version of u-boot that is bootable as BL33 in a chainloded set of images in the following sequence. BootROM -> ATF (loads a FIP) -> OPTEE -> u-boot -> Linux. Since the OPTEE image enables TrustZone u-boot no longer has access to certain low-level functions. In order to differentiate between the full-fat WaRP7 u-boot which is usually run by the BootROM directly a second defconfig is introduced along with some minimal skipping of low-level bit twiddling. For those motivated to try a description of how to set up the WaRP7 in ATF mode is here: https://github.com/bryanodonoghue/arm-trusted-firmware/blob/atf-master%2Blinaro-warp7-squash-v4/docs/plat/warp7.rst Rui Miguel Silva (4): imx: mx7: avoid some initialization if low level is skipped optee: adjust dependencies and default values for dram warp7: include: configs: set skip low level init warp7: configs: add bl33 defconfig arch/arm/mach-imx/mx7/soc.c| 2 ++ arch/arm/mach-imx/syscounter.c | 2 ++ configs/warp7_bl33_defconfig | 42 ++ configs/warp7_defconfig| 2 ++ include/configs/warp7.h| 11 + lib/optee/Kconfig | 8 +++ 6 files changed, 63 insertions(+), 4 deletions(-) create mode 100644 configs/warp7_bl33_defconfig -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
On Wed, 2018-09-05 at 10:34 +0800, Bin Meng wrote: > Hi Rick, > > On Wed, Sep 5, 2018 at 9:27 AM Rick Chen > wrote: > > > > > > From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de] > > > > Sent: Wednesday, September 05, 2018 5:53 AM > > > > To: bmeng...@gmail.com > > > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot@lists.denx.de > > > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board > > support > > > > > > > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote: > > > > > Hi Lukas, > > > > > > > > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas > > > > > wrote: > > > > > > > > > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote: > > > > > > > This adds QEMU RISC-V 'virt' board target support, with > > the hope > > > > > > > of helping people easily test U-Boot on RISC-V. > > > > > > > > > > > > > > The QEMU virt machine models a generic RISC-V virtual > > machine > > > > > > > with support for the VirtIO standard networking and > > block > > > > > > > storage devices. > > > > > > > It has CLINT, PLIC, 16550A UART devices in addition to > > VirtIO > > > > > > > and it also uses device-tree to pass configuration > > information > > > > > > > to guest software. It implements RISC-V privileged > > architecture > > > > > > > spec v1.10. > > > > > > > > > > > > > > Both 32-bit and 64-bit builds are supported. Support is > > pretty > > > > > > > much preliminary, only booting to U-Boot shell with the > > UART > > > > > > > driver on a single core. Booting Linux is not supported > > yet. > > > > > > > > > > > > > > > > > > > For your information and to avoid duplicate work, I am > > working on > > > > > > a patch set that improves RISC-V support in u-boot. I am > > currently > > > > > > able to boot Linux on a multi-core setup in QEMU, but they > > are not > > > > > > quite ready to submit yet. > > > > > > > > > > > > > > > > This is great! My next step is to work on virtio driver > > support in > > > > > U-Boot as qemu-riscv virt machine has these devices but we > > don't > > > > > have corresponding drivers in U-Boot. Then I will try to > > boot Linux > > > > > after that. Good to hear you already boot Linux with qemu- > > riscv! > > > > > Have you already supported virtio drivers in your port? If > > yes, I > > > > > will just hold on and wait for your patch series :-) > > > > > > > > > > > > > Hi Bin, > > > > > > > > Support for the virtio devices would be great! I don't support > > them in > > > > my port, I can only boot a kernel image from RAM. > > > > I only have a driver for the clint0 (core local interrupt > > controller), > > > > which I need for software interrupts to other cores and as a > > timer. > > > > Software interrupts also work over the supervisor binary > > interface > > > > (SBI), which allows u-boot to run in supervisor mode with bbl > > running > > > > in machine mode to handle the SBI calls. > > > > > > > > Hi Bin and Auer > > > > I have already boot bbl run in S-mode and riscv-linux in M-mode via > > u-boot from SD card or FLASH. > > It mean after booting riscv-linux, u-boot will be dead. And no > > matter > > about kernel. > > Please refer to doc/README.ae350 > > > > Thanks for pointing out the doc for ae350. I just read it, and have > one question. There is a chapter in that doc "Boot bbl and riscv- > linux > via U-Boot on QEMU", yet I don't see what QEMU command is invoked. > Can > you please clarify? AFAIK mainline QEMU does not have support to > ae350 > board. Also there is no instructions on how bbl was built. Is that > the > mainline bbl that can work on every riscv board? I doubt that. > > > May I figure out more clearly what are you going to do ? > > What are you going to do is let u-boot run in S-mode and boot bbl > > and > > riscv-linux in M-mode, right ? > > I want to use U-Boot to directly boot Linux, but seems Lukas is using > bbl for SBI implementation. > Hi Bin, I don't really need bbl to run u-boot. I use it for Linux, which expects the SBI to be present. > > It mean after booting bbl and riscv-linux, u-boot will still alive > > and > > handle SBI calls and somethings in S-mode. > > > > Or u-boot is going to replace the role of bbl ? > > > > That's my plan. I don't see a need to use bbl which is quite feature > limited. > That's a good idea! At the very least, all the device initialization in bbl should be moved into u-boot. I do think a bootloader-independent SBI implementation makes sense though. That way all bootloaders can use the same implementation, which should make adding new SBI calls easier. Thanks, Lukas > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] mmc: omap_mmc: Remove invert references with gpio xlate available
With omap_gpio now translating GPIO_ACTIVE_LOW, any boards
using the 'invert' option will no longer need to do this. This
patch removes the support for 'invert' from the MMC driver.
Signed-off-by: Adam Ford
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 8ab56d247d..e9786ec5bb 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -83,7 +83,6 @@ struct omap_hsmmc_data {
#if CONFIG_IS_ENABLED(DM_MMC)
struct gpio_desc cd_gpio; /* Change Detect GPIO */
struct gpio_desc wp_gpio; /* Write Protect GPIO */
- bool cd_inverted;
#else
int cd_gpio;
int wp_gpio;
@@ -1377,8 +1376,6 @@ static int omap_hsmmc_getcd(struct udevice *dev)
if (value < 0)
return 1;
- if (priv->cd_inverted)
- return !value;
return value;
}
@@ -1860,10 +1857,6 @@ static int omap_hsmmc_ofdata_to_platdata(struct udevice
*dev)
}
#endif
-#ifdef OMAP_HSMMC_USE_GPIO
- plat->cd_inverted = fdtdec_get_bool(fdt, node, "cd-inverted");
-#endif
-
return 0;
}
#endif
@@ -1892,9 +1885,6 @@ static int omap_hsmmc_probe(struct udevice *dev)
priv->base_addr = plat->base_addr;
priv->controller_flags = plat->controller_flags;
priv->hw_rev = plat->hw_rev;
-#ifdef OMAP_HSMMC_USE_GPIO
- priv->cd_inverted = plat->cd_inverted;
-#endif
#ifdef CONFIG_BLK
mmc = plat->mmc;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] gpio: omap_gpio: Add xlate function to support GPIO_ACTIVE_LOW
The gpio driver doesn't current support knowing whether or not
GPIO is active low or high. It simply returns the value. The
side effect of this, is that the MMC routines which check
the status card detect or write protect must use a u-boot specific
dts modification to enable inverting the pin values when
GPIO_ACTIVE_LOW is used. This allows the invert option to be removed
Signed-off-by: Adam Ford
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index 555eba2662..0ecd2f374a 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -275,12 +276,25 @@ static int omap_gpio_get_function(struct udevice *dev,
unsigned offset)
return GPIOF_INPUT;
}
+static int omap_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
+ struct ofnode_phandle_args *args)
+{
+ desc->offset = args->args[0];
+
+ if (args->args[1] & GPIO_ACTIVE_LOW)
+ desc->flags = GPIOD_ACTIVE_LOW;
+ else
+ desc->flags = 0;
+ return 0;
+}
+
static const struct dm_gpio_ops gpio_omap_ops = {
.direction_input= omap_gpio_direction_input,
.direction_output = omap_gpio_direction_output,
.get_value = omap_gpio_get_value,
.set_value = omap_gpio_set_value,
.get_function = omap_gpio_get_function,
+ .xlate = omap_gpio_xlate,
};
static int omap_gpio_probe(struct udevice *dev)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: DTS: various omap3: Remove cd-inverted from u-boot.dtsi
With the omap_mmc driver no longer supporting cd-inverted, this
patch removes all these references since they are not needed.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/am3517-evm-u-boot.dtsi
b/arch/arm/dts/am3517-evm-u-boot.dtsi
index c02beaad77..59df819f9d 100644
--- a/arch/arm/dts/am3517-evm-u-boot.dtsi
+++ b/arch/arm/dts/am3517-evm-u-boot.dtsi
@@ -10,10 +10,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-beagle-u-boot.dtsi
b/arch/arm/dts/omap3-beagle-u-boot.dtsi
index 094f9557b7..41beaf0900 100644
--- a/arch/arm/dts/omap3-beagle-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
index 094f9557b7..41beaf0900 100644
--- a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
index 094f9557b7..41beaf0900 100644
--- a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
index b09ce0efb5..de411316d8 100644
--- a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
+++ b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
diff --git a/arch/arm/dts/omap3-evm-u-boot.dtsi
b/arch/arm/dts/omap3-evm-u-boot.dtsi
index b09ce0efb5..de411316d8 100644
--- a/arch/arm/dts/omap3-evm-u-boot.dtsi
+++ b/arch/arm/dts/omap3-evm-u-boot.dtsi
@@ -11,10 +11,6 @@
};
};
-&mmc1 {
- cd-inverted;
-};
-
&uart1 {
reg-shift = <2>;
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support
On Wed, 2018-09-05 at 09:28 +0800, Rick Chen wrote: > > > From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de] > > > Sent: Wednesday, September 05, 2018 5:53 AM > > > To: bmeng...@gmail.com > > > Cc: Rick Jian-Zhi Chen(陳建志); u-boot@lists.denx.de > > > Subject: Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board > support > > > > > > On Tue, 2018-09-04 at 17:31 +0800, Bin Meng wrote: > > > > Hi Lukas, > > > > > > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas > > > > wrote: > > > > > > > > > > On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote: > > > > > > This adds QEMU RISC-V 'virt' board target support, with > the hope > > > > > > of helping people easily test U-Boot on RISC-V. > > > > > > > > > > > > The QEMU virt machine models a generic RISC-V virtual > machine > > > > > > with support for the VirtIO standard networking and block > > > > > > storage devices. > > > > > > It has CLINT, PLIC, 16550A UART devices in addition to > VirtIO > > > > > > and it also uses device-tree to pass configuration > information > > > > > > to guest software. It implements RISC-V privileged > architecture > > > > > > spec v1.10. > > > > > > > > > > > > Both 32-bit and 64-bit builds are supported. Support is > pretty > > > > > > much preliminary, only booting to U-Boot shell with the > UART > > > > > > driver on a single core. Booting Linux is not supported > yet. > > > > > > > > > > > > > > > > For your information and to avoid duplicate work, I am > working on > > > > > a patch set that improves RISC-V support in u-boot. I am > currently > > > > > able to boot Linux on a multi-core setup in QEMU, but they > are not > > > > > quite ready to submit yet. > > > > > > > > > > > > > This is great! My next step is to work on virtio driver > support in > > > > U-Boot as qemu-riscv virt machine has these devices but we > don't > > > > have corresponding drivers in U-Boot. Then I will try to boot > Linux > > > > after that. Good to hear you already boot Linux with qemu- > riscv! > > > > Have you already supported virtio drivers in your port? If > yes, I > > > > will just hold on and wait for your patch series :-) > > > > > > > > > > Hi Bin, > > > > > > Support for the virtio devices would be great! I don't support > them in > > > my port, I can only boot a kernel image from RAM. > > > I only have a driver for the clint0 (core local interrupt > controller), > > > which I need for software interrupts to other cores and as a > timer. > > > Software interrupts also work over the supervisor binary > interface > > > (SBI), which allows u-boot to run in supervisor mode with bbl > running > > > in machine mode to handle the SBI calls. > > > > > Hi Bin and Auer > > I have already boot bbl run in S-mode and riscv-linux in M-mode via > u-boot from SD card or FLASH. > It mean after booting riscv-linux, u-boot will be dead. And no matter > about kernel. > Please refer to doc/README.ae350 > > May I figure out more clearly what are you going to do ? > What are you going to do is let u-boot run in S-mode and boot bbl and > riscv-linux in M-mode, right ? > It mean after booting bbl and riscv-linux, u-boot will still alive > and > handle SBI calls and somethings in S-mode. > > Or u-boot is going to replace the role of bbl ? > > Rick > Hi Rick, Not exactly, my current boot flow is as follows. 1. u-boot SPL starts in machine mode and jumps to bbl 2. bbl starts u-boot proper in supervisor mode 3. u-boot boots the kernel bbl is still active once Linux has booted and is used there for its SBI implementation. Hope this helps. Thanks, Lukas > > > > > > > Thank you for your patches, it's great to see better support > for > > > > > RISC-V in u-boot! I will add a few comments based on what I > have > > > > > learned so far from working with u-boot on RISC-V. > > > > > > > > > > > > > It's a good start. RISC-V is pretty new and needs more > developers > > > > :-) > > > > > > > > > > Exactly :) > > > > > > Thanks, > > > Lukas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: omap_hsmmc: Fix pbias for omap3_logic to enable CD pin
The MMC card detect pin is connected to gpio127 on omap3_logic.
When setting up the pbias register for MMC, let's also enable
gpio_127 for the card detect. As part of the package deal,
gpio_126 and gpio_129 are also enabled.
Signed-off-by: Adam Ford
diff --git a/arch/arm/include/asm/arch-omap3/mmc_host_def.h
b/arch/arm/include/asm/arch-omap3/mmc_host_def.h
index 9f2896c4b9..39a7cba0f6 100644
--- a/arch/arm/include/asm/arch-omap3/mmc_host_def.h
+++ b/arch/arm/include/asm/arch-omap3/mmc_host_def.h
@@ -51,6 +51,7 @@ typedef struct t2 {
#define PBIASLITEPWRDNZ0 (1 << 1)
#define PBIASSPEEDCTRL0(1 << 2)
#define PBIASLITEPWRDNZ1 (1 << 9)
+#define PBIASLITEVMODE1(1 << 8)
#define PBIASLITEVMODE0(1 << 0)
#define CTLPROGIO1SPEEDCTRL(1 << 20)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 4d171f457e..8ab56d247d 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -216,6 +216,10 @@ static unsigned char mmc_board_init(struct mmc *mmc)
/* for cairo board, we need to set up 1.8 Volt bias level on MMC1 */
pbias_lite &= ~PBIASLITEVMODE0;
#endif
+#ifdef CONFIG_TARGET_OMAP3_LOGIC
+ /* For Logic PD board, 1.8V bias to go enable gpio127 for mmc_cd */
+ pbias_lite &= ~PBIASLITEVMODE1;
+#endif
#ifdef CONFIG_MMC_OMAP36XX_PINS
if (get_cpu_family() == CPU_OMAP36XX) {
/* Disable extended drain IO before changing PBIAS */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fwd: Parallel build is broken
On Tue, Sep 4, 2018 at 3:54 PM Andy Shevchenko wrote: > > On Tue, Sep 4, 2018 at 5:50 PM Andy Shevchenko > wrote: > > > > On Tue, Sep 4, 2018 at 5:00 PM Tom Rini wrote: > > > > > > On Tue, Sep 04, 2018 at 03:42:05PM +0300, Andy Shevchenko wrote: > > > > > > > -- Forwarded message - > > > > From: Andy Shevchenko > > > > Date: Tue, Sep 4, 2018 at 3:40 PM > > > > Subject: Parallel build is broken > > > > To: Tom Rini > > > > Cc: Bin Meng , Simon Glass > > > > > > > > > > > > U-Boot can't be build with make -j16. > > > > > > > > Second pass passes fine. > > > > > > > > Didn't investigate myself and probably will not have time (near to > > > > vacation time for me). > > > > So, please, fix it before release. > > > > > > > > sh: echo: I/O error > > > > make[1]: *** [scripts/Makefile.build:278: common/malloc_simple.o] Error > > > > 1 > > > > make[1]: *** Waiting for unfinished jobs > > > > CC drivers/serial/ns16550.o > > > > CC drivers/spi/spi.o > > > > CC cmd/mmc.o > > > > CC drivers/watchdog/tangier_wdt.o > > > > CC drivers/serial/serial_intel_mid.o > > > > CC cmd/net.o > > > > CC drivers/usb/common/common.o > > > > CC arch/x86/lib/acpi.o > > > > LD drivers/timer/built-in.o > > > > CC arch/x86/lib/acpi_table.o > > > > CC drivers/video/console_normal.o > > > > make: *** [Makefile:1377: common] Error 2 > > > > make: *** Waiting for unfinished jobs > > > > > > What build target (and O= or not?) is this with? Thanks! > > > > make clean && make edison_defconfig && make -j16 > > > > gcc (Debian 8.2.0-4) 8.2.0 > > Copyright (C) 2018 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > So, first time it's being built, consequent runs usually failed. > I've seen this problem - building inside a VMware VM. I've always found that logging out and back in appears to fix it, so possibly something related to the session... I've similarly failed to figure out what the problem is as it comes and goes. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/23] efi_loader: implement a pseudo "file delete"
On 05.09.18 04:51, AKASHI Takahiro wrote: > On Tue, Sep 04, 2018 at 11:16:38AM +0200, Alexander Graf wrote: >> >> >> On 04.09.18 09:49, AKASHI Takahiro wrote: >>> This patch is necessary to run SCT.efi (UEFI Self-Certification Test). >>> Returning EFI_SUCCESS can cheat SCT execution. >>> >>> Signed-off-by: AKASHI Takahiro >> >> How hard would it be to implement a real delete instead? > > Good question. > The hardest part of implementation, I believe, is about handling > nasty long file names in a directory, in particular, when > directory entries which comprise a single LFN extend across two clusters. > In this case, all the entries must be deleted first, and then go back > to the first one and modify it. Due to a current simple buffering of > cluster (only one cluster buffer a time), some tweak is necessary. > In addition, if there is an already-deleted entry ahead of the given file, > we need further rewind directory entries and update the "new" last valid > one to mark it as so. > Those kind of things would make the implementation a bit complicated > rather than simple as expected. > > So unless 'real' delete is a must for anything, I'm lukewarm to > work on it. > > # I admit that we don't have to have this patch just if *delete* returns > successfully without doing anything. I think both truncate-to-zero (this patch) and report-success-when-failure (suggested patch) are hacks that shouldn't really go upstream that way unfortunately. The way I read the long file name definitions, I think it should be perfectly ok to only remove the short file name directory entry. Sure, we're leaking a few directory entries for the LFN, but I don't think that's too bad. Any fsck should be able to find those later on... As for how to delete the entry without rewinding directory entries, you can just set name[0]=DELETED_FLAG; to indicate that the SFN is deleted, no? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/23] fs: fat: make directory iterator global for write use
On 05.09.18 04:14, AKASHI Takahiro wrote: > On Tue, Sep 04, 2018 at 12:57:54PM +0200, Alexander Graf wrote: >> >> >>> Am 04.09.2018 um 12:50 schrieb Heinrich Schuchardt : >>> >>> >>> On 09/04/2018 11:01 AM, Alexander Graf wrote: > On 04.09.18 09:49, AKASHI Takahiro wrote: > Directory iterator was introduced in major re-work of read operation by > Rob. We want to use it for write operation extensively as well. Please indicate in the commit message that write operations are implemented in a different .c file and so we have to export the respective functions. >>> >>> Why? Look at this ugly code: >>> >>> fs/fat/fat_write.c:17:#include "fat.c" >> >> In that case we don't need this patch at all, no? > > Oops, I didn't notice this before. > If, however, "include fat.c" makes any sense, theoretically we don't need > "depends on FS_FAT" for FS_FAT_WRITE. > There seems to be a contradiction between the code and config. I'm not sure it's contradictory. Someone just implemented a poor man's LTO by including the 2 files with each other. > I prefer just to remove the line, '#include "fat.c"' from fat_write.c > and add more "extern" definitions in fat.h if necessary. We can worry about refactoring things later down the road. By making functions go external, we lose the compiler's ability to inline functions which may again bloat code which may trip random boards above size limits. For now, I'd suggest you leave the ugly #include "fat.c" in and not move anything into fat.h. That way the file is self-contained and you don't have to worry about exporting just yet. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fwd: Parallel build is broken
On Tue, 2018-09-04 at 17:43 -0400, Tom Rini 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 Tue, Sep 04, 2018 at 09:05:55PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 4, 2018 at 9:00 PM Tom Rini wrote:
> > >
> > > On Tue, Sep 04, 2018 at 07:33:10PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Sep 4, 2018 at 6:47 PM Andy Shevchenko
> > > > wrote:
> > > > >
> > > > > On Tue, Sep 4, 2018 at 6:14 PM Tom Rini wrote:
> > > > > > On Tue, Sep 04, 2018 at 05:50:33PM +0300, Andy Shevchenko wrote:
> > > > > > > On Tue, Sep 4, 2018 at 5:00 PM Tom Rini
> > > > > > > wrote:
> > > > > > > > On Tue, Sep 04, 2018 at 03:42:05PM +0300, Andy Shevchenko wrote:
> > > > > > > make clean && make edison_defconfig && make -j16
> > > > > > >
> > > > > > > gcc (Debian 8.2.0-4) 8.2.0
> > > > > > > Copyright (C) 2018 Free Software Foundation, Inc.
> > > > > > > This is free software; see the source for copying conditions.
> > > > > > > There is NO
> > > > > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A
> > > > > > > PARTICULAR PURPOSE.
> > > > > >
> > > > > > I assume this is on Debian/unstable?
> > > > >
> > > > > testing
> > > > >
> > > > > > I can't directly replicate this on
> > > > > > my 24core (Debian/stretch) or 16core(Ubuntu/xenial) machines. I'll
> > > > > > setup a chroot soon, but since you've said -j64 is fine there too I
> > > > > > suspect you have more cores than I. This may be something you have
> > > > > > to
> > > > > > bisect for us if I can't replicate it myself. Can you confirm how
> > > > > > many
> > > > > > cores you have? I might be able to spin something up in Google
> > > > > > compute.
> > > > >
> > > > > $ sed -n -e '/cpu cores/ { p; q }' /proc/cpuinfo
> > > > > cpu cores : 22
> > > >
> > > > Did few runs (~6) on this machine with -j4, no failures so far.
> > > > Reruning same with -j16 brings failure on ~2-3 iteration.
> > > >
> > > > It seems the scope can be narrowed to:
> > > > - many cores build system, and
> > > > - Debian testing/unstable toolchain, and/or
> > > > - U-Boot build system
> > >
> > > I'm pretty sure it's a dependency problem somewhere. Since this was
> > > working reliably for you recently (right?) and I can't reproduce it and
> > > you can, if you can run a git bisect to figure out what commit is
> > > breaking things, that would be very helpful. Thanks!
> >
There was a patch recently to make 4.2.1 to fix some parallel build issue.
No idea if that fix applies to your case though.
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
