[U-Boot] [PATCH] ARM: rmobile: Adjust text base on V3M Eagle
The latest ATF puts the U-Boot at 0x5000, just like on all the other boards. Adjust the text base to reflect that change. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- configs/r8a77970_eagle_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig index 889fc6e83b..abca2bf338 100644 --- a/configs/r8a77970_eagle_defconfig +++ b/configs/r8a77970_eagle_defconfig @@ -1,6 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_RMOBILE=y -CONFIG_SYS_TEXT_BASE=0x5828 +CONFIG_SYS_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y CONFIG_R8A77970=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-sh/master
The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7: ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to 891bf67611e93df3f3a6c451d945a7810435ed13: ARM: rmobile: Disable 4k SF sectors on V3M Eagle (2018-06-16 04:27:28 +0200) Marek Vasut (21): dts: gpio: Sync header with Linux 4.17 clk: rmobile: Add R8A77990 RPC clock clk: rmobile: Add R8A77995 RPC clock pinctrl: renesas: Sync Gen2 PFC tables with Linux v4.17 pinctrl: renesas: Sync Gen3 PFC tables with Linux v4.17 ARM: rmobile: Sync Gen2 DTS with Linux v4.17 ARM: rmobile: Sync Gen3 DTS with Linux v4.17 ARM: rmobile: Zap CONFIG_SYS_CLK_FREQ where applicable ARM: rmobile: Point load address to more sane area on Gen2 ARM: rmobile: Point load address to more sane area on Gen3 ARM: rmobile: Fix environment placement on Draak ARM: rmobile: Enable RPCHF on Draak ARM: dts: rmobile: Add Renesas RPC HF/QSPI DT node to R8A77990 ARM: dts: rmobile: Add SCIF2 pinmux to E3 Ebisu ARM: dts: rmobile: Add initial SDHI nodes to R8A77990 E3 ARM: dts: rmobile: Enable SDHI on E3 Ebisu ARM: dts: rmobile: Add AVB pinmux on V3M Eagle ARM: dts: rmobile: Add AVB PHY reset on V3M Eagle ARM: rmobile: Fix CPGW address on V3M Eagle ARM: rmobile: Enable cache command on V3M Eagle ARM: rmobile: Disable 4k SF sectors on V3M Eagle arch/arm/dts/r8a7790-lager.dts | 310 +- arch/arm/dts/r8a7790.dtsi | 2877 -- arch/arm/dts/r8a7791-koelsch.dts| 259 ++- arch/arm/dts/r8a7791-porter.dts | 151 --- arch/arm/dts/r8a7791.dtsi | 3008 +-- arch/arm/dts/r8a7792.dtsi | 587 + arch/arm/dts/r8a7793-gose.dts | 262 +++- arch/arm/dts/r8a7793.dtsi | 2409 +- arch/arm/dts/r8a7794-alt.dts| 56 ++- arch/arm/dts/r8a7794-silk.dts | 189 +--- arch/arm/dts/r8a7794.dtsi | 2416 -- arch/arm/dts/r8a7795.dtsi | 602 +- arch/arm/dts/r8a7796.dtsi | 556 ++-- arch/arm/dts/r8a77965.dtsi | 127 +- arch/arm/dts/r8a77970-eagle.dts | 77 ++-- arch/arm/dts/r8a77970.dtsi | 328 -- arch/arm/dts/r8a77990-ebisu.dts | 30 ++ arch/arm/dts/r8a77990.dtsi | 32 ++ arch/arm/dts/r8a77995-draak.dts | 124 ++ arch/arm/dts/r8a77995.dtsi | 423 +- arch/arm/dts/salvator-common.dtsi | 85 +++- arch/arm/dts/ulcb.dtsi | 22 +- board/renesas/eagle/eagle.c |7 +- configs/r8a77970_eagle_defconfig|2 + configs/r8a77995_draak_defconfig|1 + drivers/clk/renesas/r8a77990-cpg-mssr.c |5 + drivers/clk/renesas/r8a77995-cpg-mssr.c |5 + drivers/pinctrl/renesas/pfc-r8a7790.c |8 +- drivers/pinctrl/renesas/pfc-r8a7791.c | 84 +++- drivers/pinctrl/renesas/pfc-r8a7794.c | 473 drivers/pinctrl/renesas/pfc-r8a7795.c | 1954 +-- drivers/pinctrl/renesas/pfc-r8a7796.c | 1048 - drivers/pinctrl/renesas/pfc-r8a77970.c | 873 - drivers/pinctrl/renesas/pfc-r8a77990.c | 3446 +- drivers/pinctrl/renesas/pfc-r8a77995.c | 695 +- drivers/pinctrl/renesas/pfc.c | 29 +- drivers/pinctrl/renesas/sh_pfc.h| 66 ++- include/configs/draak.h |6 +- include/configs/ebisu.h |4 - include/configs/rcar-gen2-common.h |3 +- include/configs/rcar-gen3-common.h |3 +- include/configs/salvator-x.h|4 - include/configs/ulcb.h |4 - include/dt-bindings/gpio/gpio.h | 21 + 44 files changed, 16184 insertions(+), 7487 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
>> On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
>>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
On 06/15/2018 01:43 PM, Marek Vasut wrote:
> On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
>> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut wrote:
+ arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
+ 0, 0, 0, 0, 0, 0, 0, );
>>>
>>> Will this call work on platforms without patched ATF ?
>>> (I think not, don't you need to handle return value?)
>>
>> I have not actually tested that, but if I understand the ATF code
>> correctly, unimplemented calls return
>> SMC_UNK (0x), which should be handled by the default case (NOP)
>> below.
>
> Which means the board has a memory size of 0 and fails to boot ?
>
+ switch (res.a0) {
+ case 1:
+ base[0] = 0x04800ULL;
+ size[0] = 0x03800ULL;
+ base[1] = 0x5ULL;
+ size[1] = 0x04000ULL;
+ base[2] = 0x6ULL;
+ size[2] = 0x04000ULL;
+ base[3] = 0x7ULL;
+ size[3] = 0x04000ULL;
+ fdt_fixup_memory_banks(blob, base, size, 4);
+ break;
+ case 2:
+ base[0] = 0x04800ULL;
+ size[0] = 0x07800ULL;
+ base[1] = 0x5ULL;
+ size[1] = 0x08000ULL;
+ fdt_fixup_memory_banks(blob, base, size, 2);
+ break;
+ case 3:
+ base[0] = 0x04800ULL;
+ size[0] = 0x07800ULL;
+ base[1] = 0x5ULL;
+ size[1] = 0x08000ULL;
+ base[2] = 0x6ULL;
+ size[2] = 0x08000ULL;
+ base[3] = 0x7ULL;
+ size[3] = 0x08000ULL;
+ fdt_fixup_memory_banks(blob, base, size, 4);
+ break;
>>>
>>> Obvious design question is -- since you're adding new SMC call anyway,
>>> can't the call just return the memory layout table itself, so that it
>>> won't be duplicated both in U-Boot and ATF ?
>>
>> My gut feeling was to go with the smallest interface possible.
>
> But this doesn't scale. The API here uses some ad-hoc constants to
> identify memory layout tables which have to be encoded both in ATF and
> U-Boot, both of which must be kept in sync.
>
> The ATF already has those memory layout tables, it's only a matter of
> passing them to U-Boot. If you do just that, the ad-hoc constants and
> encoding of tables into U-Boot goes away and in fact simplifies the
> design.
>
> Yet, I have to wonder if ATF doesn't already contain some sort of
> standard SMC call to get memory topology. It surprises me that it
> wouldn't.
In fact, Laurent (CCed) was solving some similar issue with lossy decomp
and I think this involved some passing of memory layout information from
ATF to U-Boot too, or am I mistaken ?
>>>
>>> That's correct, ATF stores information about the memory layout at a fixed
>>> address in system memory, and U-Boot can read it.
>>
>> Well, that sounds good ! Maybe we can avoid adding SMC call altogether
>> then? :)
>
> I'd prefer that, yes.
>
> Let's not duplicate the mechanism used to pass FCNL information from ATF to U-
> Boot, but instead create a data table format that can store all the
> information we need, in an easily extensible way.
>
> To see how the mechanism is implemented for FCNL, search for 47FD7000 in the
> Renesas ATF sources (git://github.com/renesas-rcar/arm-trusted-firmware.git).
For everyone involved, can you explain what FCNL is ? ;-)
Any yes, I agree this sounds good. I had a discussion on the U-Boot IRC
about passing the memory configuration around and the result is
basically the same -- pass a table from ATF to U-Boot. If there's
already something, great.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] x86: zImage: Propagate acpi_rsdp_addr to kernel via boot parameters
Hi Andy,
On Fri, Jan 12, 2018 at 9:01 PM, Andy Shevchenko
wrote:
> On Fri, 2018-01-12 at 17:00 +0800, Bin Meng wrote:
>> Hi Andy,
>>
>> On Thu, Jan 11, 2018 at 1:40 AM, Andy Shevchenko
>> wrote:
>> > New field acpi_rsdp_addr, which has been introduced in boot protocol
>> > v2.14 [1], in boot parameters tells kernel the exact address of RDSP
>> > ACPI table. Knowing it increases robustness of the kernel by
>> > avoiding
>> > in some cases traversal through a part of physical memory.
>> > It will slightly reduce boot time by the same reason.
>> >
>> > [1] See Linux kernel commit
>> >
>> > 2f74cbf947f4 ("x86/boot: Add the ACPI RSDP address to struct
>> > setup_header::acpi_rdsp_addr")
>>
>> I don't see this commit id in my linux tree. Is this in some
>> custodian's tree?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2
> f74cbf947f45fa082dda8eac1a1f1299a372f49
>
I checked Linux kernel tree, seems the patch of adding acpi_rdsp_addr
to setup_header was never accepted. Can you please double check, to
see whether we still need this in U-Boot?
I built a v4.17 kernel, and the boot protocol is still 2.13.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Issue with fat16 format
On 06/15/2018 08:37 AM, Vipul Kumar wrote: > Hi, > > After formatting SD card in fat16 format in windows, we are facing issue. I > used git bisect and came to know that this issue is due to > 8eafae209c35932d9a6560809c55ee4641534236 commit. > > When we use "gparted" utility for formatting SD card in fat16 in linux, it > works fine. > > Please give your comments on this issue and point out what's causing this > issue. > > Regards, > Vipul Kumar > > Hello Vipul, >> we are facing issue could you, please, indicate what issue you face. Please, also tell which configuration file you are using. As you are complaining about Rob's patch I put him and the reviewers of the patch on CC. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 00/35] phy: sunxi: Add Allwinner sun4i USB PHY
On Tue, Jun 5, 2018 at 8:39 PM, Vasily Khoruzhick wrote: > On Tue, Jun 5, 2018 at 12:04 AM, Jagan Teki wrote: >> >> Let me look at it and will come back. > > I fixed it. See "usb: sunxi: sun50i: enable OHCI0 clock when OHCI1 is > in use" and "sunxi: clock: Fix EHCI and OHCI clocks on A64" on ML. I found another issue caused by this series, u-boot crashes while shutting down USB if any low-speed or full-speed device is plugged (e.g. keyboard): U-Boot 2018.07-rc1-00014-gec0a6e2f05 (Jun 16 2018 - 10:40:32 -0700) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: SoPine with baseboard DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from FAT... Unable to use mmc 1:2... Failed (-5) In: serial Out: vidconsole Err: vidconsole Net: phy interface7 eth0: ethernet@1c3 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) unable to get device descriptor (error=-1) 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => => => => usb reset resetting USB... EHCI failed to shut down host controller. "Synchronous Abort" handler, esr 0x9604 elr: 4a0317d8 lr : 4a0317a4 (reloc) elr: bdf7b7d8 lr : bdf7b7a4 x0 : b9f573104002 x1 : b9f5f040 x2 : 0002 x3 : 0300 x4 : bdfb6f80 x5 : b9f55700 x6 : 0101 x7 : b9f620f0 x8 : b9f265e0 x9 : 0008 x10: ffd0 x11: 0006 x12: 0001869f x13: 2170 x14: b9f2688c x15: 0002 x16: 1050 x17: x18: b9f29de8 x19: x20: b9f57040 x21: b9f2a7d0 x22: 0001 x23: bdfb96a8 x24: b9f2a840 x25: x26: x27: x28: b9f2d2f0 x29: b9f26650 I have no idea how to fix it and I'm not planning to work on it till end of next week. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Sat, Jun 16, 2018 at 2:47 AM, Jagan Teki wrote: > On Wed, Jun 6, 2018 at 10:26 AM, Vasily Khoruzhick wrote: >> eMMC seems to require new clocking mode and calibration on A64, >> otherwise it is pretty unstable on some boards (e.g. Pinebook) >> with some eMMCs. >> >> v2: - improve comment about calibration for eMMC on A64 >> - simplify ifdef-s around configuring delays >> v3: - fix fallout due to ifdef simplification in v2 >> v4: - really fix ifdefs this time >> v5: - add new option for SoCs without new mode switch in CCM >> >> Vasily Khoruzhick (3): >> sunxi-mmc: introduce new MMC_SUNXI_HAS_NEW_MODE_SWITCH option >> sunxi-mmc: use new mode on A64 >> mmc: sunxi: run calibration on A64 > > I have still observing eMMC boot issue, this need to debug further It boots for me from eMMC on Pinebook and Pine64-LTS, thus I have no hardware to debug it further. Moreover, Linux also does calibration on A64 for eMMC, do you experience any issues with eMMC in Linux? > U-Boot SPL 2018.07-rc1-00164-g117d5917d2 (Jun 16 2018 - 15:12:28 +0530) > DRAM: 1024 MiB > Trying to boot from MMC2 > unable to select a mode > mmc_load_image_raw_sector: mmc block read error > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/5] efi_loader: ARM: add support for ARMV7_NONSEC=y
On 06/15/2018 11:47 PM, Mark Kettenis wrote: > This series makes it possible to run EFI applications in non-secure > mode. It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and > Banana Pi boards using the PSCI implementation provided by U-Boot. > > The second version avoids using r3 to pass the original stack pointer. > For some reason that register gets clobbered on the Banana Pi. Instead > this version just migrates SP_svc to SP_hyp. > > The third version avoids saving r3 on the stack and fixes an include > guard as suggested by Alexander Graf. > > This fourth version enables ARMV7_LPAE if HYP mode is supported sych > that we enable the MMU and caches in HYP mode. It also makes sure we > don't attempt to enter non-secure mode twice if we execute a 2nd EFI > payload. > > Mark Kettenis (5): > ARM: HYP/non-sec: migrate stack > efi_loader: ARM: run EFI payloads non-secure > efi_loader: ARM: don't attempt to enter non-secure mode twice > ARM: HYP/non-sec: enable ARMV7_LPAE if HYP mode is supported > Revert "efi_loader: no support for ARMV7_NONSEC=y" > > arch/arm/cpu/armv7/Kconfig | 2 +- > arch/arm/cpu/armv7/nonsec_virt.S | 2 ++ > cmd/bootefi.c| 36 > doc/README.uefi | 2 -- > lib/efi_loader/Kconfig | 2 -- > 5 files changed, 39 insertions(+), 5 deletions(-) > Hello Mark, I have built with your 5 patches added to git master (f58e779513be36e30ce46838fb467e12ac6a5539). With your patch series iPXE starts normally. In iPXE I can use network commands ping and nslookup. I was not able to boot via iSCSI but I have the same problem without your patches 1-4. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Wed, Jun 6, 2018 at 10:26 AM, Vasily Khoruzhick wrote: > eMMC seems to require new clocking mode and calibration on A64, > otherwise it is pretty unstable on some boards (e.g. Pinebook) > with some eMMCs. > > v2: - improve comment about calibration for eMMC on A64 > - simplify ifdef-s around configuring delays > v3: - fix fallout due to ifdef simplification in v2 > v4: - really fix ifdefs this time > v5: - add new option for SoCs without new mode switch in CCM > > Vasily Khoruzhick (3): > sunxi-mmc: introduce new MMC_SUNXI_HAS_NEW_MODE_SWITCH option > sunxi-mmc: use new mode on A64 > mmc: sunxi: run calibration on A64 I have still observing eMMC boot issue, this need to debug further U-Boot SPL 2018.07-rc1-00164-g117d5917d2 (Jun 16 2018 - 15:12:28 +0530) DRAM: 1024 MiB Trying to boot from MMC2 unable to select a mode mmc_load_image_raw_sector: mmc block read error SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sun50i: h5: Add initial Orange Pi Zero Plus support
On Wed, Jun 13, 2018 at 12:58 PM, Maxime Ripard wrote: > On Sat, Jun 09, 2018 at 06:34:46PM +0200, Hauke Mehrtens wrote: >> Orange Pi Zero Plus is an open-source single-board computer >> using the Allwinner H5 SOC. >> >> H5 Orangepi Zero Plus has >> - Quad-core Cortex-A53 >> - 512MB DDR3 >> - micrSD slot >> - 16MBit SPI Nor flash >> - Debug TTL UART >> - 1GBit/s Ethernet (RTL8211E) >> - Wifi (RTL8189FTV) >> - USB 2.0 Host >> - USB 2.0 OTG + power supply >> >> The device tree file is copied from the Linux kernel 4.17. >> >> Signed-off-by: Hauke Mehrtens > > Acked-by: Maxime Ripard Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sun8i: h2: Add initial Orange Pi R1 support
On Wed, Jun 13, 2018 at 12:58 PM, Maxime Ripard wrote: > On Sat, Jun 09, 2018 at 06:33:37PM +0200, Hauke Mehrtens wrote: >> Orange Pi R1 is an open-source single-board computer using the >> Allwinner H2+ SOC. >> >> H2+ Orange Pi R1 has >> - Quad-core Cortex-A7 >> - 256MB DDR3 >> - micrSD slot >> - 128MBit SPI Nor flash >> - Debug TTL UART >> - 100MBit/s Ethernet (H2+) >> - 100MBit/s Ethernet (RTL8152B) >> - Wifi (RTL8189ETV) >> - USB 2.0 OTG + power supply >> This board is very similar to the Orange Pi Zero. >> >> The device tree file is copied from the Linux kernel 4.17. >> >> Signed-off-by: Hauke Mehrtens > > Acked-by: Maxime Ripard Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
