Re: [U-Boot] [PATCH] rtc: mc146818: Correct alarm message for day alarm
Hi Tom, On Tue, Oct 17, 2017 at 11:19 PM, Bin Meng wrote: > RTC_CONFIG_D register contains the day within the month to generate > an alarm, not the month. This corrects the printf to indicate it. > > Signed-off-by: Bin Meng > --- > > drivers/rtc/mc146818.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Will you take this for v2017.11? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/2] sunxi: Fix boot of Cubietruk and al.
On Fri, Oct 20, 2017 at 02:16:12PM +0200, Maxime Ripard wrote: > Hi > > Most featureful boards, such as the Cubietruck, have been broken since > the release 2017.09 (the two variants of the Olinuxino-Lime2 and the > cubietruck at least, possibly more since then). > > This is due to a size increase of the binary that will trip us across > the size we've been using in our default configuration since forever, > and widely distributed through the u-boot-sunxi-with-spl.bin file. > > We would have several ways to work around it. The first one would be > to just increase the offset of the environment. However, since it > would break all the environments of our users and possibly the custom > partition scheme that they would have created, it doesn't really seem > like a smart move. > > The second one would be to move the environment to a filesystem file, > which would also break all the existing users. This can be envisionned > as a long term fix though. > > Another one would be to start trimming down a bit our enabled options > in order to reduce the size and to gain some extra space for users > customisations. However, this will always result in pointless and > endless discussions, so let's move away from that. > > The final one that has been implemented would be to just build U-Boot > using thumb2 to push back the issue until hopefully I'm no longer > maintainer or the switch to the env filesystem would have been done. > > I've also added a patch to make sure that the compilation breaks and > that we can notice. Applied both, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Build failure in u-boot-mmc/master: undefined reference to error
On 10/24/2017 12:22 AM, Stephen Warren wrote: > On 10/22/2017 08:53 PM, Jaehoon Chung wrote: >> Dear Stephen, >> >> On 10/21/2017 12:47 AM, Stephen Warren wrote: >>> With the latest content of u-boot-mmc/master, 41dc35a149b3 "drivers: mmc: >>> Avoid memory leak in case of failure", all Tegra boards (perhaps others >>> too; my system only tests Tegra) fail to build with the following error: >> >> I had found the same error at build testing, I will fix it on today. >> Thanks for noticing it. > > Thanks. > > I see that the build failures are fixed now, but the following unit-tests are > failing on sandbox: > > test_ut[ut_dm_blk_base] > test_ut[ut_dm_blk_devnum] > test_ut[ut_dm_blk_get_from_parent] > test_ut[ut_dm_mmc_base] > test_ut[ut_dm_mmc_blk] > > For example: > >> => ut dm blk_base >> Test: dm_test_blk_base: blk.c >> unable to select a mode >> mmc_init: -524, time 6 >> /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/test/dm/blk.c:40, >> dm_test_blk_base(): 0 == blk_first_device(IF_TYPE_HOST, &dev): Expected 0, >> got -524 >> Test: dm_test_blk_base: blk.c (flat tree) >> unable to select a mode >> mmc_init: -524, time 6 >> /var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/test/dm/blk.c:40, >> dm_test_blk_base(): 0 == blk_first_device(IF_TYPE_HOST, &dev): Expected 0, >> got -524 >> Failures: 2 > > You should be able to reproduce this by running the following from the U-Boot > source tree: > > ./test/py/test.py --bd sandbox --build Will check. thanks! > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: replace the printf() instead of error()
On 10/24/2017 11:38 AM, Masahiro Yamada wrote:
> Hi Jaehoon
>
> 2017-10-23 13:49 GMT+09:00 Jaehoon Chung :
>> On 10/23/2017 01:46 PM, Jaehoon Chung wrote:
>>> Replace the printf() instead of error().
>>> It is occurred the compiler error with "undefined reference to 'error'".
>>>
>>> Fixes: e0079fecd75b ("mmc: refacstor SD startup to make it easier to
>>> support new modes")
>>>
>>> Signed-off-by: Jaehoon Chung
>>
>> Applied to u-boot-mmc.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>> ---
>>> drivers/mmc/mmc.c | 8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index 55a53c2200..a5a521eec3 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -828,7 +828,7 @@ static int mmc_get_capabilities(struct mmc *mmc)
>>> return 0;
>>>
>>> if (!ext_csd) {
>>> - error("No ext_csd found!\n"); /* this should enver happen */
>>> + printf("No ext_csd found!\n"); /* this should enver happen */
>>> return -ENOTSUPP;
>>> }
>>>
>>> @@ -1433,7 +1433,7 @@ static inline int bus_width(uint cap)
>>> return 4;
>>> if (cap == MMC_MODE_1BIT)
>>> return 1;
>>> - error("invalid bus witdh capability 0x%x\n", cap);
>>> + printf("invalid bus witdh capability 0x%x\n", cap);
>>> return 0;
>>> }
>>>
>>> @@ -1638,7 +1638,7 @@ error:
>>> }
>>> }
>>>
>>> - error("unable to select a mode\n");
>>> + printf("unable to select a mode\n");
>>> return -ENOTSUPP;
>>> }
>>>
>>> @@ -1844,7 +1844,7 @@ error:
>>> }
>>> }
>>>
>>> - error("unable to select a mode\n");
>>> + printf("unable to select a mode\n");
>>>
>>> return -ENOTSUPP;
>>> }
>>>
>>
>
>
> No. Please use pr_err().
Ok..Will change.
>
>
> Why don't you squash this to e0079fecd75b?
Will rebase this. I will drop the PR.
Thanks for comment.
Best Regards,
Jaehoon Chung
>
> This loses bisect'ability.
>
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull u-boot-mmc master
Dear Tom, On 10/23/2017 01:54 PM, Jaehoon Chung wrote: > Dear Tom, > > Could you pull these patches to u-boot/master? > To develop the supporting HS200 mode, each host driver also needs to > implement something. > First step is the applying JJ's patches. Discard this PR. After checking more, i will resend the PR. Best Regards, Jaehoon Chung > > If there is a problem, let me know, plz. > > The following changes since commit 0def58f7fd26a237bb08cfbd58ec53372b1ad06b: > > Merge git://git.denx.de/u-boot-x86 (2017-10-19 11:19:38 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-mmc.git master > > for you to fetch changes up to f58da60cfdbe896d62a0ec61cd41a52cfc82c526: > > mmc: replace the printf() instead of error() (2017-10-23 13:48:39 +0900) > > > Jaehoon Chung (1): > mmc: replace the printf() instead of error() > > Jean-Jacques Hiblot (17): > mmc: dm: get the IO-line and main voltage regulators from the dts > mmc: split mmc_startup() > mmc: move the MMC startup for version above v4.0 in a separate function > mmc: make ext_csd part of struct mmc > mmc: add a function to read and test the ext csd (mmc >= 4) > mmc: introduce mmc modes > mmc: Add a function to dump the mmc capabilities > mmc: use mmc modes to select the correct bus speed > cmd: mmc: display the mode name and current bus speed in the mmc info > mmc: refactor SD startup to make it easier to support new modes > mmc: refactor MMC startup to make it easier to support new modes > mmc: Add a new callback function to perform the 74 clocks cycle sequence > mmc: Add support for UHS modes > mmc: disable UHS modes if Vcc cannot be switched on and off > mmc: Change mode when switching to a boot partition > mmc: use the right voltage level for MMC DDR and HS200 modes > mmc: add a library function to send tuning command > > Kishon Vijay Abraham I (9): > mmc: make mmc_set_ios() return status > mmc: Enable signal voltage to be selected from mmc core > mmc: add power cyle support in mmc core > mmc: add a new mmc parameter to disable mmc clock > mmc: disable the mmc clock during power off > mmc: Add a execute_tuning() callback to the mmc operations. > mmc: add HS200 support in MMC core > mmc: Retry some MMC cmds on failure > dm: mmc: Add a library function to parse generic dt binding > > Suniel Mahesh (2): > drivers: mmc: Change buffer type in ALLOC_CACHE_ALIGN_BUFFER macro > drivers: mmc: Avoid memory leak in case of failure > > cmd/mmc.c |3 +- > drivers/mmc/Kconfig | 23 + > drivers/mmc/exynos_dw_mmc.c |3 + > drivers/mmc/fsl_esdhc.c |2 +- > drivers/mmc/mmc-uclass.c| 87 +++ > drivers/mmc/mmc.c | 1517 > --- > include/mmc.h | 176 - > 7 files changed, 1423 insertions(+), 388 deletions(-) > ___ > 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] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51
Hi Benoît, On Mon, Oct 23, 2017 at 8:45 PM, Benoît Thébaudeau wrote: > The issue is the timeout in esdhc_setup_data() on line 309. If I > revert e978a31b and fb823981, then everything works fine. However, the > latest calculation is correct, so reverting these commits is not the > fix. Indeed, for HS transfers: > mmc->tran_speed = 5000, fls(mmc->tran_speed/4) = 24 > mmc->clock = 4800, fls(mmc->clock/2) = 25 > I've tested with 26 and 27, and they work fine. Therefore, > SYSCTL.DTOCV is broken for 25 - 13 = 12 here, so the i.MX25 has an > undocumented erratum, which could just happen to be > CONFIG_SYS_FSL_ERRATUM_ESDHC_A001. If it's not exactly this erratum, > then a new workaround could be implemented for it, or > ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE could be used instead. Can you ask > your design team to confirm this? I can try to ask it internally when I am back to the office next week. > Shouldn't CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 be changed into a quirk to > be defined in a SoC header file (such as > arch/arm/include/asm/arch-mx25/imx-regs.h) or in > drivers/mmc/fsl_esdhc.c if an affected SoC or IP version is detected > from the configuration, rather than keeping it as a configuration > setting to be defined in a board configuration file (such as > include/configs/mx25pdk.h)? > > Note that it would be possible to go further than fb823981 to optimize > this timeout because mmc->clock is also not always the actual SD clock > frequency resulting from set_sysctl(). However, timeout cases should > normally never occur, so optimizing them is a bit pointless. > > Note that mainline Linux always uses the maximum timeout regardless of > the SD clock frequency. Can we also do like this in U-Boot for now? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree
On Tue, Oct 24, 2017 at 11:38 AM, Marek Vasut wrote: > On 10/23/2017 01:43 PM, Eugeniy Paltsev wrote: >> On Thu, 2017-10-19 at 13:20 -0500, Dinh Nguyen wrote: >>> >>> On 10/19/2017 10:51 AM, Marek Vasut wrote: On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote: > On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote: >> On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin >> wrote: >>> Hi Jagan, >>> -Original Message- From: Eugeniy Paltsev [mailto:palt...@synopsys.com] Sent: Tuesday, October 17, 2017 4:33 PM To: jagannadh.t...@gmail.com Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value from Device Tree > > How hard it is to make others to use clock manager? do you have any > list? clock_manager.h is an old (and non-generic) way to deal with different clocks. For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h provides cm_get_spi_controller_clk_hz function to deal with spi controller clock. But today we have another, linux-like alternative: to bind clocks via device tree and manipulate with clocks via generic functions provided by clk.h In this patch I added option to get clock via device tree using standard bindings and restrict clock_manager.h functions usage only to targets which still use it, so new targets can simply bind clock via device tree and they do not need to implement/define something in clock_manager.h So we don't need to make others to use clock manager :) >>> >>> Maybe it worth trying the other way around and think about switching >>> SOCFPGA platforms to >>> generic clk framework? >> >> Yes, ie what exactly I thought of, thanks! > > I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and > SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as > it > manipulate with real hardware. > The only way to do it is to replace SOCFPGA* clock manager functions by > real > clock driver. > > And given I don't have mentioned hardware so I barely can help with > those improvements on SOCFPGA. That said if there're no short-term plans > to > switch SOCFPGA to clk framework maybe we'll be OK with my workaround with > #ifdefs? Wait for Dinh's reply ... >>> >>> Honestly, I don't have too much time to work on this right now. So I >>> really don't when it can get done. But it'll go on my to-do list. >>> >>> Dinh >> >> Yep, thanks for your comments. >> >> So, Jagan, >> given Dinh's reply, could you please apply this patch? > > I'd really hate it to start seeing soc-specific ifdefs in drivers, > that's IMO not acceptable. A __weak override might be a temporary > solution I'd be willing to live with though. I would rather like to see some check on clock manager itself whether CONFIG_IS_ENABLED(CLK) is using or not? this can tends not to use __weak as well soc #ifdefs in driver. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [UBOOT PATCH 2/2] zynqmp: zcu102: Add qspi driver support for ZynqMP ZCU102 board
This patch adds qspi driver support for ZynqMP ZCU102 board. Signed-off-by: Siva Durga Prasad Paladugu --- configs/xilinx_zynqmp_zcu102_revB_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig b/configs/xilinx_zynqmp_zcu102_revB_defconfig index 9dd8cc9..78085e5 100644 --- a/configs/xilinx_zynqmp_zcu102_revB_defconfig +++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig @@ -5,6 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x800 CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_IDENT_STRING=" Xilinx ZynqMP ZCU102" CONFIG_ZYNQMP_USB=y +CONFIG_ZYNQMP_QSPI=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102-revB" CONFIG_DEBUG_UART=y CONFIG_AHCI=y @@ -30,6 +31,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_TIME=y @@ -51,11 +53,15 @@ CONFIG_CMD_PCA953X=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_ISSI=y +CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_DM_ETH=y CONFIG_PHY_GIGE=y CONFIG_ZYNQ_GEM=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver
This patch adds qspi driver support for ZynqMP SoC. This
driver is responsible for communicating with qspi flash
devices.
Signed-off-by: Siva Durga Prasad Paladugu
---
arch/arm/cpu/armv8/zynqmp/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/zynqmp_qspi.c | 817 ++
3 files changed, 825 insertions(+)
create mode 100644 drivers/spi/zynqmp_qspi.c
diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig
b/arch/arm/cpu/armv8/zynqmp/Kconfig
index 5ffc9f6..278248a 100644
--- a/arch/arm/cpu/armv8/zynqmp/Kconfig
+++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
@@ -50,6 +50,13 @@ config BOOT_INIT_FILE
Add register writes to boot.bin format (max 256 pairs).
Expect a table of register-value pairs, e.g. "0x12345678 0x4321"
+config ZYNQMP_QSPI
+ bool "Configure ZynqMP QSPI"
+ select DM_SPI
+ help
+ This option is used to enable ZynqMP QSPI controller driver which
+ is used to communicate with qspi flash devices.
+
config ZYNQMP_USB
bool "Configure ZynqMP USB"
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ad56203..b465c71 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -50,3 +50,4 @@ obj-$(CONFIG_TI_QSPI) += ti_qspi.o
obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
obj-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
obj-$(CONFIG_ZYNQ_QSPI) += zynq_qspi.o
+obj-$(CONFIG_ZYNQMP_QSPI) += zynqmp_qspi.o
diff --git a/drivers/spi/zynqmp_qspi.c b/drivers/spi/zynqmp_qspi.c
new file mode 100644
index 000..7ec669e
--- /dev/null
+++ b/drivers/spi/zynqmp_qspi.c
@@ -0,0 +1,817 @@
+/*
+ * (C) Copyright 2014 - 2015 Xilinx
+ *
+ * Xilinx ZynqMP Quad-SPI(QSPI) controller driver (master mode only)
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../mtd/spi/sf_internal.h"
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ZYNQMP_QSPI_GFIFO_STRT_MODE_MASK BIT(29)
+#define ZYNQMP_QSPI_CONFIG_MODE_EN_MASK(3 << 30)
+#define ZYNQMP_QSPI_CONFIG_DMA_MODE(2 << 30)
+#define ZYNQMP_QSPI_CONFIG_CPHA_MASK BIT(2)
+#define ZYNQMP_QSPI_CONFIG_CPOL_MASK BIT(1)
+
+/* QSPI MIO's count for different connection topologies */
+#define ZYNQMP_QSPI_MIO_NUM_QSPI0 6
+#define ZYNQMP_QSPI_MIO_NUM_QSPI1 5
+#define ZYNQMP_QSPI_MIO_NUM_QSPI1_CS 1
+
+/*
+ * QSPI Interrupt Registers bit Masks
+ *
+ * All the four interrupt registers (Status/Mask/Enable/Disable) have the same
+ * bit definitions.
+ */
+#define ZYNQMP_QSPI_IXR_TXNFULL_MASK 0x0004 /* QSPI TX FIFO Overflow */
+#define ZYNQMP_QSPI_IXR_TXFULL_MASK0x0008 /* QSPI TX FIFO is full */
+#define ZYNQMP_QSPI_IXR_RXNEMTY_MASK 0x0010 /* QSPI RX FIFO Not Empty */
+#define ZYNQMP_QSPI_IXR_GFEMTY_MASK0x0080 /* QSPI Generic FIFO Empty */
+#define ZYNQMP_QSPI_IXR_ALL_MASK (ZYNQMP_QSPI_IXR_TXNFULL_MASK | \
+ ZYNQMP_QSPI_IXR_RXNEMTY_MASK)
+
+/*
+ * QSPI Enable Register bit Masks
+ *
+ * This register is used to enable or disable the QSPI controller
+ */
+#define ZYNQMP_QSPI_ENABLE_ENABLE_MASK 0x0001 /* QSPI Enable Bit Mask */
+
+#define ZYNQMP_QSPI_GFIFO_LOW_BUS BIT(14)
+#define ZYNQMP_QSPI_GFIFO_CS_LOWER BIT(12)
+#define ZYNQMP_QSPI_GFIFO_UP_BUS BIT(15)
+#define ZYNQMP_QSPI_GFIFO_CS_UPPER BIT(13)
+#define ZYNQMP_QSPI_SPI_MODE_QSPI (3 << 10)
+#define ZYNQMP_QSPI_SPI_MODE_SPI BIT(10)
+#define ZYNQMP_QSPI_SPI_MODE_DUAL_SPI (2 << 10)
+#define ZYNQMP_QSPI_IMD_DATA_CS_ASSERT 5
+#define ZYNQMP_QSPI_IMD_DATA_CS_DEASSERT 5
+#define ZYNQMP_QSPI_GFIFO_TX BIT(16)
+#define ZYNQMP_QSPI_GFIFO_RX BIT(17)
+#define ZYNQMP_QSPI_GFIFO_STRIPE_MASK BIT(18)
+#define ZYNQMP_QSPI_GFIFO_IMD_MASK 0xFF
+#define ZYNQMP_QSPI_GFIFO_EXP_MASK BIT(9)
+#define ZYNQMP_QSPI_GFIFO_DATA_XFR_MASKBIT(8)
+#define ZYNQMP_QSPI_STRT_GEN_FIFO BIT(28)
+#define ZYNQMP_QSPI_GEN_FIFO_STRT_MOD BIT(29)
+#define ZYNQMP_QSPI_GFIFO_WP_HOLD BIT(19)
+#define ZYNQMP_QSPI_BAUD_DIV_MASK (7 << 3)
+#define ZYNQMP_QSPI_DFLT_BAUD_RATE_DIV BIT(3)
+#define ZYNQMP_QSPI_GFIFO_ALL_INT_MASK 0xFBE
+#define ZYNQMP_QSPI_DMA_DST_I_STS_DONE BIT(1)
+#define ZYNQMP_QSPI_DMA_DST_I_STS_MASK 0xFE
+#define MODEBITS 0x6
+
+#define QUAD_OUT_READ_CMD 0x6B
+#define QUAD_PAGE_PROGRAM_CMD 0x32
+#define DUAL_OUTPUT_FASTRD_CMD 0x3B
+
+#define ZYNQMP_QSPI_GFIFO_SELECT BIT(0)
+
+#define ZYNQMP_QSPI_FIFO_THRESHOLD 1
+
+#define SPI_XFER_ON_BOTH 0
+#define SPI_XFER_ON_LOWER 1
+#define SPI_XFER_ON_UPPER 2
+
+#define ZYNQMP_QSPI_DMA_ALIGN 0x4
+#define ZYNQMP_QSPI_MAX_BAUD_RATE_VAL 7
+#define ZYNQMP_QSPI_DFLT_BAUD_RATE_VAL 2
+
+#define ZYNQMP_QSPI_TIMEOUT1
+
+/* QSPI register offsets */
+struct zynqmp_qspi_regs {
+
[U-Boot] qemu and baremetal arm prog
For a Hello world uboot project I am using
https://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/ tutorial.
I have used GNU ARM toolchain
Downloaded Uboot source : u-boot-2017.09
Compiled it
make vexpress_ca9x4_defconfig ARCH=arm
CROSS_COMPILE=../gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-
make all ARCH=arm
CROSS_COMPILE=../gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-
And the hello world project looks like
**test.c**
volatile unsigned int * const UART0DR = (unsigned int *)0x101f1000;
void print_uart0(const char *s) {
while(*s != '\0') { /* Loop until end of string */
*UART0DR = (unsigned int)(*s); /* Transmit char */
s++; /* Next char */
}
}
void c_entry() {
print_uart0("Hello world!\n");
}
**startup.s**
.global _Reset
_Reset:
LDR sp, =stack_top
BL c_entry
B .
**test.ld**
ENTRY(_Reset)
SECTIONS
{
. = 0x10; /*initial address*/
.startup . : { startup.o(.text) }
.text : { *(.text) }
.data : { *(.data) }
.bss : { *(.bss COMMON) }
. = ALIGN(8);
. = . + 0x1000; /* 4kB of stack memory */
stack_top = .;
}
**And the compilation**
../gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-gcc -c
-mcpu=arm926ej-s test.c -o test.o
../gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-as
-mcpu=arm926ej-s startup.s -o startup.o
../gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-ld -T test.ld
-Map=test.map test.o startup.o -o test.elf
../gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-objcopy -O
binary test.elf test.bin
**Create Image :**
mkimage -A arm -C none -O linux -T kernel -d test.bin -a 0x0010 -e
0x0010 test.uimg
**Output :**
Image Name:
Created: Mon Oct 23 20:58:01 2017
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:146 Bytes = 0.14 kB = 0.00 MB
Load Address: 0010
Entry Point: 0010
**Create a single binary :**
cat ../u-boot-2017.09/u-boot test.uimg > flash.bin
**Calculated uboot binary size**
printf "bootm 0x%X\n" $(expr $(stat -c%s u-boot.bin) + 65536)
bootm 0x218F20
**Then run :**
qemu-system-arm -M vexpress-a9 -kernel flash.bin -m 128M -nographic
Interrupted it and then run `bootm 0x218F20`
But it says
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Any suggestion?
[1]: https://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] image-sig: use designated initializers for algorithm
On 23 October 2017 at 03:03, Masahiro Yamada wrote: > > Designated initializers are more readable because we do not > have to check the order in the struct definitions. > > Signed-off-by: Masahiro Yamada > --- > > common/image-sig.c | 44 ++-- > 1 file changed, 22 insertions(+), 22 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8: sec_firmware: Add support for loadables in FIT
On 10/23/2017 09:21 PM, Sumit Garg wrote: >> >> Sumit, >> >> If I understand you correctly, you are parsing the secure firmware FIT image >> to >> find the loadable node and store the 64-bit load address in the scratch >> registers. How do you determine which scratch registers to use? >> >> York > > Yes your understanding is correct. The scratch registers which I used are as > follows: > > For Chassis gen 3 platforms: > /* Assign addresses to loadable ptrs */ > loadable_l = &gur->scratchrw[4]; > loadable_h = &gur->scratchrw[5]; > > For Chassis gen 2 platforms: > /* Assign addresses to loadable ptrs */ > loadable_l = &scfg->scratchrw[2]; > loadable_h = &scfg->scratchrw[3]; > > I choose above scratch registers to avoid any conflict with usage of scratch > registers > in Boot-ROM, u-boot and PPA. I see you write to these scratch registers but never read from them. What's the purpose to store the address in them? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió: > On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: > > El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > > > On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > > > > Hi, > > > > > > > > On 19/10/17 14:24, Maxime Ripard wrote: > > > > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Most featureful boards, such as the Cubietruck, have been > > > > > > > broken since > > > > > > > the release 2017.09. > > > > > > > > > > > > > > This is due to a size increase of the binary that will > > > > > > > trip > > > > > > > us across > > > > > > > the size we've been using in the u-boot-sunxi-with- > > > > > > > spl.bin > > > > > > > file. > > > > > > > > > > > > > > We would have two ways to work around it. The first one > > > > > > > would > > > > > > > be to > > > > > > > just increase the offset of the environment. However, > > > > > > > since > > > > > > > it would > > > > > > > break all the environments of our users and possibly the > > > > > > > custom > > > > > > > partition scheme that they would have created, it doesn't > > > > > > > really seem > > > > > > > like a smart move. > > > > > > > > > > > > Is that really such a problem? How many people rely on > > > > > > having > > > > > > their > > > > > > custom environment preserved over an update? (That's an > > > > > > honest > > > > > > question) > > > > > > > > > > All of them, I guess. In your U-boot upgrade script, do you > > > > > do a > > > > > 'env > > > > > default -a; saveenv' all the time ? > > > > > > > > > > I know I don't. > > > > > > > > Well, I never use the saved environment and always expected > > > > some > > > > user or > > > > board specific environment to come from some file (boot.scr or > > > > something > > > > loaded via TFTP). But that's just my personal use, hence I was > > > > asking. > > > > > > Well, even if you want to boot to tftp, you'll need to have some > > > setup > > > to do, even just to use a different server IP, and that will be > > > in > > > the > > > environment. > > > > I personally just use pxe boot > > It's not really about what personally you use, but what any user can > use. Not saying that it is. but how I use it is really simple for the user to use without needing to have a ton of specific knowledge about how u- boot works > > dhcp > > pxe get > > pxe boot > > and pick the right option. nothing needed on the client side. > > It has the assumption that the DHCP server is setup properly, which > might or might not be the case, especially when it comes to the > server > option being there and valid. > > Maxime Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp Dennis ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
Hi, On 24/10/17 18:05, Dennis Gilmore wrote: > El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió: >> On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: >>> El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > Hi, > > On 19/10/17 14:24, Maxime Ripard wrote: >> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara >> wrote: >>> Hi, >>> >>> On 19/10/17 09:26, Maxime Ripard wrote: Hi, Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09. This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with- spl.bin file. We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move. >>> >>> Is that really such a problem? How many people rely on >>> having >>> their >>> custom environment preserved over an update? (That's an >>> honest >>> question) >> >> All of them, I guess. In your U-boot upgrade script, do you >> do a >> 'env >> default -a; saveenv' all the time ? >> >> I know I don't. > > Well, I never use the saved environment and always expected > some > user or > board specific environment to come from some file (boot.scr or > something > loaded via TFTP). But that's just my personal use, hence I was > asking. Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment. >>> >>> I personally just use pxe boot >> >> It's not really about what personally you use, but what any user can >> use. > Not saying that it is. but how I use it is really simple for the user > to use without needing to have a ton of specific knowledge about how u- > boot works > >>> dhcp >>> pxe get >>> pxe boot >>> and pick the right option. nothing needed on the client side. >> >> It has the assumption that the DHCP server is setup properly, which >> might or might not be the case, especially when it comes to the >> server >> option being there and valid. >> >> Maxime > Anyone doing something like this on X86 has to have the same setup. its > not that hard of a ask to assume that a pxe environment is available. > you can skip the dhcp part and set the serrver ip and system ip > manually, its just simpler to use dhcp I agree to both of you ;-) As Maxime already pointed out, it's a bit of a pointless discussion, as x U-Boot users have possibly x different usage scenarios. Some very actively do work on the U-Boot prompt and rely on a customized and preserved environment, while others merely rely on some standardized boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI. That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly. And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there. I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] mtd: remove MTDDEBUG() and CONFIG_MTD_DEBUG
On Wed, Oct 18, 2017 at 12:10:49AM +0900, Masahiro Yamada wrote: > All users of this macro have been converted. Remove MTDDEBUG and > related CONFIG options. > > ubifs_dbg_msg_key() is kept. It is silent unless DEBUG is defined. > > I am not touching scripts/config_whitelist.txt. The deprecated options > will be dropped by the next resync. > > Signed-off-by: Masahiro Yamada 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] simple-bus: remove DECLARE_GLOBAL_DATA_PTR
On Tue, Oct 17, 2017 at 05:37:14PM +0900, Masahiro Yamada wrote: > No global pointer is used in this file. > > Signed-off-by: Masahiro Yamada > Reviewed-by: Bin Meng 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] [U-Boot, v2] chiliboard config: use CONFIG_DEFAULT_FDT_FILE as env variable
On Tue, Oct 17, 2017 at 02:06:33PM +0200, Michal Oleszczyk wrote: > Remove hardcoded ftd file name from environment variables. > Use CONFIG_DEFAULT_FDT_FILE macro instead. > > Signed-off-by: Michal Oleszczyk 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] [U-Boot, v3, 3/6] disk: efi: correct the overlap check on GPT header and PTE
On Wed, Oct 18, 2017 at 03:11:05PM +0200, Patrick Delaunay wrote: > the partition starting at 0x4400 is refused with overlap error: > $> gpt write mmc 0 "name=test,start=0x4400,size=0" > Writing GPT: Partition overlap > error! > > even if the 0x4400 is the first available offset for LBA35 with default > value: > - MBR=LBA1 > - GPT header=LBA2 > - PTE= 32 LBAs (128 entry), 3 to 34 > > And the command to have one partition for all the disk failed also : > $> gpt write mmc 0 "name=test,size=0" > > After the patch : > > $> gpt write mmc 0 "name=test,size=0" > Writing GPT: success! > $> part list mmc 0 > > Partition Map for MMC device 0 -- Partition Type: EFI > > PartStart LBA End LBA Name > Attributes > Type GUID > Partition GUID > 1 0x0022 0x01ce9fde "test" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: b4b84b8a-04e3-4000-0036-aff5c9c495b1 > > And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected > > Reviewed-by: Łukasz Majewski > Signed-off-by: Patrick Delaunay 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] rtc: mc146818: Correct alarm message for day alarm
On Tue, Oct 17, 2017 at 08:19:33AM -0700, Bin Meng wrote: > RTC_CONFIG_D register contains the day within the month to generate > an alarm, not the month. This corrects the printf to indicate it. > > Signed-off-by: Bin Meng 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] tools: image: fix node name of signature node in FIT
On Thu, Oct 19, 2017 at 07:16:21PM +0900, Masahiro Yamada wrote: > Both "conf_name" and "sig_name" point to the name of config node. > The latter should be the name of the signature node. > > Signed-off-by: Masahiro Yamada > Reviewed-by: Simon Glass 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] [U-Boot,v3,1/6] test/py: gpt: copy persistent file
On Wed, Oct 18, 2017 at 03:11:03PM +0200, Patrick Delaunay wrote: > copy the persistent gpt binary file as it can be modified during the test > that avoid issue if the test fail: the test always restart with clean file > > Acked-by: Stephen Warren > Signed-off-by: Patrick Delaunay 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] [U-Boot, v3, 2/6] test/py: gpt: add test for sub-command read and verify
On Wed, Oct 18, 2017 at 03:11:04PM +0200, Patrick Delaunay wrote: > add sandbox test for some gpt sub-command > - gpt read / part list : read the gpt partition created by sgdisk on host > test start, size, LBA and name output > - gpt verify : verify the gpt partition create by sgdisk on host > > PS: persistent data test_gpt_disk_image.bin are udpated > > Signed-off-by: Patrick Delaunay 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] [U-Boot,1/1] Kconfig: add CONFIG_BROKEN
On Thu, Oct 19, 2017 at 11:49:19PM +0200, Heinrich Schuchardt wrote: > Provide a Kconfig option that we can use as dependency for > features that are broken. This allows to easily disable them > without removing the code. > > As no short text is supplied the option will not appear in > menuconfig. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass 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] [U-Boot, v3, 6/6] cmd: gpt: solve issue for swap and rename command
On Wed, Oct 18, 2017 at 03:11:08PM +0200, Patrick Delaunay wrote: > don't use prettyprint_part_size() in create_gpt_partitions_list() > that avoid to align offset and size to 1 MiB and increase precision for > start and size. > This patch avoid the risk to change partition size and lost data during > rename or swap. > > Signed-off-by: Patrick Delaunay > Acked-by: Stephen Warren > Tested-by: Stephen Warren 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] [U-Boot, v3, 4/6] test/py: gpt: add test for sub-command write
On Wed, Oct 18, 2017 at 03:11:06PM +0200, Patrick Delaunay wrote: > + test write for one partition on all the device (size=0) > + test write with disk uuid and 2 partitions > > Signed-off-by: Patrick Delaunay 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] [U-Boot, v3, 5/6] test/py: gpt: test start LBA for sub-command rename and swap
On Wed, Oct 18, 2017 at 03:11:07PM +0200, Patrick Delaunay wrote: > Add test of first and last LBA in gpt for rename and swap. > Only the name is expected to change, so test 3 columns > for part command > 1: first LBA (start) > 2: last LBA (end) > 3: partition name > > After rename, the last LBA change and it is a error in current U-Boot code > + "first" = 0x7ff : invalid value ( + "second" = 0x17ff => size increasing ! > > Signed-off-by: Patrick Delaunay 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] doc: verified-boot: fix crypto algorithm examples
On Thu, Oct 19, 2017 at 07:37:59PM +0900, Masahiro Yamada wrote: > As you see in crypto_algos in common/image-sig.c, the algorithm > should be either "rsa2048" or "rsa4096". "rs2048" is a typo. > > Signed-off-by: Masahiro Yamada > Reviewed-by: Simon Glass 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] test/py: fix typos in README.md
On Thu, Oct 19, 2017 at 07:08:52PM +0900, Masahiro Yamada wrote: > Signed-off-by: Masahiro Yamada > Reviewed-by: Stephen Warren 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] qemu and baremetal arm prog
Dear Anupam, In message you wrote: > > printf "bootm 0x%X\n" $(expr $(stat -c%s u-boot.bin) + 65536) > bootm 0x218F20 The value 0x218F20 printed here is the offset where your image starts relative to the begin of the U-Boot binary. > **Then run :** > > qemu-system-arm -M vexpress-a9 -kernel flash.bin -m 128M -nographic > > Interrupted it and then run `bootm 0x218F20` > But it says > > Wrong Image Format for bootm command > ERROR: can't get kernel image! This can only be correct if your U-Boot binary was loaded to address 0x, which probably is not correct. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "We don't care. We don't have to. We're the Phone Company." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: SPL: FIT: fix DTC warnings on FIT generation
On 24/10/17 03:31, Masahiro Yamada wrote: Hi, > 2017-10-24 11:03 GMT+09:00 Lokesh Vutla : >> >> >> On Tuesday 24 October 2017 02:04 AM, Tom Rini wrote: >>> On Mon, Oct 23, 2017 at 11:08:57AM +0530, Lokesh Vutla wrote: On Tuesday 17 October 2017 02:43 AM, Tom Rini wrote: > On Tue, Oct 17, 2017 at 02:29:14AM +0530, Jagan Teki wrote: >> On Mon, Oct 9, 2017 at 10:15 AM, Simon Glass wrote: >>> Hi Andre, >>> >>> On 4 October 2017 at 17:24, Andre Przywara >>> wrote: Newer versions of the device tree compiler (rightfully) complain about mismatches between attributed node names (name@) and a missing reg property in that node. Adjust the FIT build script for 64-bit Allwinner boards to remove the bogus addresses from the node names and avoid the warnings. Signed-off-by: Andre Przywara --- board/sunxi/mksunxi_fit_atf.sh | 16 1 file changed, 8 insertions(+), 8 deletions(-) >>> >>> It looks like we have this problem all over the place. The >>> documentation in doc/uImage now seems to have this problem too. >>> >>> I wonder if instead we should add reg / #address-cells / #size-cells >>> properties? >> >> If the update on dts, might be an another-overhead to maintain u-boot >> dts wrt Linux dts sync. > > Anything that DTC is warning about in a dts that we get from the kernel, > should be fixed in the kernel. The kernel dtc is what we're using, and > is/will/can also complain about it. Kernel suppress these warning by default[1] and enables these warnings with W= compiler option. May be this should be included in u-boot as well? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.lib#n272 >>> >>> We have slightly different logic for that today in >>> scripts/Makefile.extrawarn, perhaps we need to re-sync? >>> >> >> ahh you are right. I do not see these warning with the latest U-Boot. >> But I still agree with the $patch as these warnings are meant to be >> fixed at some point. > > > Please use "-" instead of "@". > > Update all the FIT examples. > You may need to update some C files. Yeah! "find ./ -type f | xargs -1 sed -i -e s/@/-/g" didn't give the expected results, though :-D But I bit the bullet and fixed every @1 sucker I could find, just need some more time to make proper patches. Cheers, Andre. > > > This is the conclusion of Device Tree community. > See the following commit of Linux. > > > > commit b21569cf1de925e0a42c9964bd7f520cb4a4d875 > Author: Viresh Kumar > Date: Thu Jun 22 09:15:11 2017 +0530 > > PM / OPP: Use - instead of @ for DT entries > > Compiling the DT file with W=1, DTC warns like follows: > > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a > unit name, but no reg property > > Fix this by replacing '@' with '-' as the OPP nodes will never have a > "reg" property. > > Reported-by: Krzysztof Kozlowski > Reported-by: Masahiro Yamada > Suggested-by: Mark Rutland > Signed-off-by: Viresh Kumar > Acked-by: Rob Herring > Reviewed-by: Stephen Boyd > Signed-off-by: Rafael J. Wysocki > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fsl_esdhc driver is broken with DM
To all guys @ELCE, Can we setup a formal meeting to discuss about ' U-Boot regression and test suit setup' Do you think? On 16-Oct-2017 10:51 PM, "Jagan Teki" wrote: On Fri, Oct 13, 2017 at 7:03 PM, Fabio Estevam wrote: > Hi Lukasz, > > On Fri, Oct 13, 2017 at 5:16 AM, Lukasz Majewski wrote: > >> There is some ongoing work to provide such facility. for imx6 >> boards. I will keep you informed. > > That's good news! Please keep me in the loop as well. Would be good if we have some kind of discussion together on this topic on next week, ELCE Prague. Any plan? thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] spl: add support to booting with ATF
> diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c new file mode
> 100644 index 000..ec3f675
> --- /dev/null
> +++ b/common/spl/spl_atf.c
> @@ -0,0 +1,92 @@
> +/*
> + * Reference to the ARM TF Project,
> + * plat/arm/common/arm_bl2_setup.c
> + * Portions copyright (c) 2013-2016, ARM Limited and Contributors. All
> +rights
> + * reserved.
> + * Copyright (C) 2016 Rockchip Electronic Co.,Ltd
> + * Written by Kever Yang
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
I understand that this patch has been applied, but is it ok to use
"BSD-3-Clause" here?
Why not use GPL license here?
Thanks,
Peng.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static struct bl2_to_bl31_params_mem_t bl31_params_mem; static struct
> +bl31_params_t *bl2_to_bl31_params;
> +
> +/**
>
> +*
> + * This function assigns a pointer to the memory that the platform has
> +kept
> + * aside to pass platform specific and trusted firmware related
> +information
> + * to BL31. This memory is allocated by allocating memory to
> + * bl2_to_bl31_params_mem_t structure which is a superset of all the
> + * structure whose information is passed to BL31
> + * NOTE: This function should be called only once and should be done
> + * before generating params to BL31
> +
> +***
>
> +***/ struct bl31_params_t *bl2_plat_get_bl31_params(void) {
> + struct entry_point_info_t *bl33_ep_info;
> +
> + /*
> + * Initialise the memory for all the arguments that needs to
> + * be passed to BL31
> + */
> + memset(&bl31_params_mem, 0, sizeof(struct
> bl2_to_bl31_params_mem_t));
> +
> + /* Assign memory for TF related information */
> + bl2_to_bl31_params = &bl31_params_mem.bl31_params;
> + SET_PARAM_HEAD(bl2_to_bl31_params, PARAM_BL31, VERSION_1, 0);
> +
> + /* Fill BL31 related information */
> + SET_PARAM_HEAD(bl2_to_bl31_params->bl31_image_info,
> PARAM_IMAGE_BINARY,
> +VERSION_1, 0);
> +
> + /* Fill BL32 related information if it exists */ #ifdef BL32_BASE
> + bl2_to_bl31_params->bl32_ep_info =
> &bl31_params_mem.bl32_ep_info;
> + SET_PARAM_HEAD(bl2_to_bl31_params->bl32_ep_info, PARAM_EP,
> +VERSION_1, 0);
> + bl2_to_bl31_params->bl32_image_info =
> &bl31_params_mem.bl32_image_info;
> + SET_PARAM_HEAD(bl2_to_bl31_params->bl32_image_info,
> PARAM_IMAGE_BINARY,
> +VERSION_1, 0);
> +#endif /* BL32_BASE */
> +
> + /* Fill BL33 related information */
> + bl2_to_bl31_params->bl33_ep_info =
> &bl31_params_mem.bl33_ep_info;
> + bl33_ep_info = &bl31_params_mem.bl33_ep_info;
> + SET_PARAM_HEAD(bl33_ep_info, PARAM_EP, VERSION_1,
> EP_NON_SECURE);
> +
> + /* BL33 expects to receive the primary CPU MPID (through x0) */
> + bl33_ep_info->args.arg0 = 0x & read_mpidr();
> + bl33_ep_info->pc = CONFIG_SYS_TEXT_BASE;
> + bl33_ep_info->spsr = SPSR_64(MODE_EL2, MODE_SP_ELX,
> + DISABLE_ALL_EXECPTIONS);
> +
> + bl2_to_bl31_params->bl33_image_info =
> &bl31_params_mem.bl33_image_info;
> + SET_PARAM_HEAD(bl2_to_bl31_params->bl33_image_info,
> PARAM_IMAGE_BINARY,
> +VERSION_1, 0);
> +
> + return bl2_to_bl31_params;
> +}
> +
> +void raw_write_daif(uint32_t daif)
> +{
> + __asm__ __volatile__("msr DAIF, %0\n\t" : : "r" (daif) : "memory"); }
> +
> +void bl31_entry(void)
> +{
> + struct bl31_params_t *bl31_params;
> + void (*entry)(struct bl31_params_t *params, void *plat_params) =
> NULL;
> +
> + bl31_params = bl2_plat_get_bl31_params();
> + entry = (void *)CONFIG_SPL_ATF_TEXT_BASE;
> +
> + raw_write_daif(SPSR_EXCEPTION_MASK);
> + dcache_disable();
> +
> + entry(bl31_params, NULL);
> +}
> diff --git a/include/atf_common.h b/include/atf_common.h new file mode
> 100644 index 000..90c7fce
> --- /dev/null
> +++ b/include/atf_common.h
> @@ -0,0 +1,276 @@
> +/*
> + * This is from the ARM TF Project,
> + * Repository: https://github.com/ARM-software/arm-trusted-firmware.git
> + * File: include/common/bl_common.h
> + * Portions copyright (c) 2013-2016, ARM Limited and Contributors. All
> +rights
> + * reserved.
> + * Copyright (C) 2016-2017 Rockchip Electronic Co.,Ltd
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +#ifndef __BL_COMMON_H__
> +#define __BL_COMMON_H__
> +
> +#define SECURE 0x0
> +#define NON_SECURE 0x1
> +#define sec_state_is_valid(s) (((s) == SECURE) || ((s) == NON_SECURE))
> +
> +#define UP 1
> +#define DOWN 0
> +
> +/**
>
> +*
> + * Constants to identify the location of a memory region in a given
> +memory
> + * layout.
> +***
> ***/
> +#define TOP
Re: [U-Boot] [PATCH 2/2] armv8: sec_firmware: Add support for loadables in FIT
> -Original Message- > From: York Sun > Sent: Tuesday, October 24, 2017 8:00 PM > To: Sumit Garg ; u-boot@lists.denx.de > Cc: Ruchika Gupta ; Prabhakar Kushwaha > ; Z.q. Hou ; Pankaj > Gupta ; Arun Pathak ; Sahil > Malhotra > Subject: Re: [PATCH 2/2] armv8: sec_firmware: Add support for loadables in FIT > > On 10/23/2017 09:21 PM, Sumit Garg wrote: > > >> > >> Sumit, > >> > >> If I understand you correctly, you are parsing the secure firmware > >> FIT image to find the loadable node and store the 64-bit load address > >> in the scratch registers. How do you determine which scratch registers to > use? > >> > >> York > > > > Yes your understanding is correct. The scratch registers which I used are as > follows: > > > > For Chassis gen 3 platforms: > > /* Assign addresses to loadable ptrs */ > > loadable_l = &gur->scratchrw[4]; > > loadable_h = &gur->scratchrw[5]; > > > > For Chassis gen 2 platforms: > > /* Assign addresses to loadable ptrs */ > > loadable_l = &scfg->scratchrw[2]; > > loadable_h = &scfg->scratchrw[3]; > > > > I choose above scratch registers to avoid any conflict with usage of > > scratch registers in Boot-ROM, u-boot and PPA. > > I see you write to these scratch registers but never read from them. > What's the purpose to store the address in them? > > York These scratch registers are used to communicate loadable address to PPA similar to how return address is communicated in boot-location pointer registers to PPA. PPA uses this loadable address (Trusted OS address) to initialize Trusted OS. Sumit ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree
On 10/24/2017 11:52 AM, Jagan Teki wrote: > On Tue, Oct 24, 2017 at 11:38 AM, Marek Vasut wrote: >> On 10/23/2017 01:43 PM, Eugeniy Paltsev wrote: >>> On Thu, 2017-10-19 at 13:20 -0500, Dinh Nguyen wrote: On 10/19/2017 10:51 AM, Marek Vasut wrote: > On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote: >> On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote: >>> On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin >>> wrote: Hi Jagan, > -Original Message- > From: Eugeniy Paltsev [mailto:palt...@synopsys.com] > Sent: Tuesday, October 17, 2017 4:33 PM > To: jagannadh.t...@gmail.com > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com > Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value from > Device Tree >> >> How hard it is to make others to use clock manager? do you have any >> list? > > clock_manager.h is an old (and non-generic) way to deal with > different clocks. > For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h > provides > cm_get_spi_controller_clk_hz function to deal with spi controller > clock. > > But today we have another, linux-like alternative: to bind clocks via > device tree > and manipulate with clocks via generic functions provided by clk.h > > In this patch I added option to get clock via device tree using > standard bindings > and restrict clock_manager.h functions usage only to targets which > still use it, > so new targets can simply bind clock via device tree and they do not > need to > implement/define something in clock_manager.h > > So we don't need to make others to use clock manager :) Maybe it worth trying the other way around and think about switching SOCFPGA platforms to generic clk framework? >>> >>> Yes, ie what exactly I thought of, thanks! >> >> I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and >> SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as >> it >> manipulate with real hardware. >> The only way to do it is to replace SOCFPGA* clock manager functions by >> real >> clock driver. >> >> And given I don't have mentioned hardware so I barely can help with >> those improvements on SOCFPGA. That said if there're no short-term plans >> to >> switch SOCFPGA to clk framework maybe we'll be OK with my workaround >> with #ifdefs? > > Wait for Dinh's reply ... > Honestly, I don't have too much time to work on this right now. So I really don't when it can get done. But it'll go on my to-do list. Dinh >>> >>> Yep, thanks for your comments. >>> >>> So, Jagan, >>> given Dinh's reply, could you please apply this patch? >> >> I'd really hate it to start seeing soc-specific ifdefs in drivers, >> that's IMO not acceptable. A __weak override might be a temporary >> solution I'd be willing to live with though. > > I would rather like to see some check on clock manager itself whether > CONFIG_IS_ENABLED(CLK) is using or not? this can tends not to use > __weak as well soc #ifdefs in driver. I don't understand what you mean by this , can you elucidate ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
