Re: [U-Boot] [PATCH] initcall: Move to inline function
> Am 08.02.2019 um 05:11 schrieb Simon Glass : > > Hi Alex, > >> On Sat, 2 Feb 2019 at 09:07, Alexander Graf wrote: >> >> >> >>> Am 02.02.2019 um 15:13 schrieb Simon Glass : >>> >>> Hi Alex, >>> On Thu, 31 Jan 2019 at 08:06, Alexander Graf wrote: The board_r init function was complaining that we are looping through an array, calling all our tiny init stubs sequentially via indirect function calls (which can't be speculated, so they are slow). >>> >>> Is this a compiler warning? Could you let me know what this is? >> >> It's the code comment I'm removing with this patch :). >> >>> The solution to that is pretty easy though. All we need to do is inline the function that loops through the functions and the compiler will automatically convert almost all indirect calls into direct inlined code. >>> >>> You mean it calls the functions one after the other without a >>> function-table array? >> >> Exactly. Magical, eh? It even inlines them! > > Yes it is surprising. I am also surprised that it reduces code size, > but I suppose that is why it does it. Presumably the inlining is what > does that. Yes, of course. With separate object files, the compiler can not inline anything at all, because it does not know how the function pointers get used. The alternative to this *might* be LTO, which we could think about as well. It should help reduce indirection and code size overall. But I don't know how well gold works with the linker scripts we have. > But what happens if we #define DEBUG? Define it where? ;) Alex > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] configs: sama5d27_som1_ek: Activate misc init for uSD variant
On 06.02.2019 16:19, Alexander Dahl wrote: > This was already set for 'sama5d27_som1_ek_mmc_defconfig' (first SD > card, full size). Without this option set, the MAC address is not read > from the I²C EEPROM at boot, and remains unset: > > U-Boot 2019.01 (Jan 01 2019 - 00:00:00 +) > > CPU: SAMA5D27 1G bits DDR2 SDRAM > Crystal frequency: 24 MHz > CPU clock: 492 MHz > Master clock : 164 MHz > DRAM: 128 MiB > MMC: sdio-host@a000: 0, sdio-host@b000: 1 > Loading Environment from FAT... OK > In:serial > Out: serial > Err: serial > Net: > Error: ethernet@f8008000 address not set. > eth-1: ethernet@f8008000 > Hit any key to stop autoboot: 0 > > Signed-off-by: Alexander Dahl Applied to u-boot-atmel/master Thanks ! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/60] mpc83xx: Introduce ARCH_MPC830*
On Mon, Jan 28, 2019 at 9:13 AM Mario Six wrote: > > Hi York, > On Tue, Jan 22, 2019 at 5:17 PM York Sun wrote: > > > > On 1/21/19 12:19 AM, Mario Six wrote: > > > Replace CONFIG_MPC830* with proper CONFIG_ARCH_MPC830* Kconfig options. > > > > > > Signed-off-by: Mario Six > > > > > > --- > > > > I browse through the entire patch set. The patches look good. Since NXP > > doesn't make new mpc83xx SoCs and I have no board to verify, I don't > > comment on specific changes. > > > > There were many config macros which have been replace with hard-coded > > value inline by you. That's OK. The original plan was to allow different > > config but that didn't happen mostly. > > > > Sounds good. Thanks for reviewing! > > > York > > > Best regards, > Mario Whole series applied to u-boot/mpc83xx/next. Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Align U-Boot I2C DM bus ID handling with Linux
Hi Simon, On 08. 02. 19 5:11, Simon Glass wrote: > Hi Michal, > > On Tue, 5 Feb 2019 at 00:58, Michal Simek wrote: >> >> Hi Simon, >> >> On 02. 02. 19 15:10, Simon Glass wrote: >>> Hi Michal, >>> >>> On Thu, 31 Jan 2019 at 08:31, Michal Simek wrote: U-Boot with I2C_DM enabled is not capable to list i2c busses connected to i2c mux. For getting this work there is a need to find out highest alias ID and use this uniq number for new buses connected to I2C mux. This series is making this happen. There is only one missing piece which is that also i2c controllers which are not listed in DT are not using this feature. Removing setting up aliases from i2c mux code and unifying it in the same code ensures that numbering schema is proper if no alias is specified. ZynqMP> i2c bus Bus 0: i2c@ff02 20: gpio@20, offset len 1, flags 0 21: gpio@21, offset len 1, flags 0 75: i2c-mux@75, offset len 1, flags 0 Bus 1: i2c@ff02->i2c-mux@75->i2c@0 Bus 2: i2c@ff02->i2c-mux@75->i2c@1 Bus 3: i2c@ff02->i2c-mux@75->i2c@2 Bus 4: i2c@ff03 (active 4) 74: i2c-mux@74, offset len 1, flags 0 75: i2c-mux@75, offset len 1, flags 0 Bus 5: i2c@ff03->i2c-mux@74->i2c@0 (active 5) 54: eeprom@54, offset len 1, flags 0 Bus 6: i2c@ff03->i2c-mux@74->i2c@1 Bus 7: i2c@ff03->i2c-mux@74->i2c@2 Bus 8: i2c@ff03->i2c-mux@74->i2c@3 Bus 9: i2c@ff03->i2c-mux@74->i2c@4 Bus 10: i2c@ff03->i2c-mux@75->i2c@0 Bus 11: i2c@ff03->i2c-mux@75->i2c@1 Bus 12: i2c@ff03->i2c-mux@75->i2c@2 Bus 13: i2c@ff03->i2c-mux@75->i2c@3 Bus 14: i2c@ff03->i2c-mux@75->i2c@4 Bus 15: i2c@ff03->i2c-mux@75->i2c@5 Bus 16: i2c@ff03->i2c-mux@75->i2c@6 Bus 17: i2c@ff03->i2c-mux@75->i2c@7 Thanks, Michal Changes in v2: - Update kernel-doc binding - Return -1 in case of error. -1 means that the next free alias is 0. - New patch - New patch - Use dev_read_alias_highest_id() - Use uclass private data - Use private uclass data - Fix headers - Change patch description to focus only on bus name >>> >>> I don't have strong objections to this series, but I'd still like to >>> try a bit harder on the existing req_seq/seq stuff. >>> >>> I don't think we necessarily need to set the 'seq' before probe, >>> although I suppose we could. >>> >>> But is there anything to stop us moving some of the logic which sets >>> seq to setting req_seq? We could check the aliases and then set >>> req_seq during bind(), perhaps? >> >> Let me put this to my TODO list. But it is not a task which you know >> will be done in some hours. It requires to study the whole logic if this >> works for all cases. >> >>> This would be better for code size since it would help all subsystems. >> >> This approach is used in the linux kernel that's why there is no way to >> get rid of dev_read_alias_highest_id() as function. > > Yes that function seems useful to me. > >> It means only i2c_uclass_init() and little code in i2c_post_bind() could >> be removed. That's why I don't think we will improve size a lot. >> If this is copied to other subsystems then yes it will be more useful. >> If we have just one now we can't save a lot. > > Well maybe, but of course the problem you are fixing applies to other > subsystems too, doesn't it? In Linux i2c came with this solution in connection to DT guys where aliases are stable and even adding overlay can't update it/change it. If you grep of_alias_get_highest_id you will find out that there is one more which is spi and that's it. This is commit message from Linux regarding spi. commit 226584aedd94acd61ffa51fb69bcf6b3309a7b8f Author: Lucas Stach AuthorDate: Mon Oct 16 12:27:58 2017 +0200 Commit: Mark Brown CommitDate: Mon Oct 16 21:02:54 2017 +0100 spi: fix IDR collision on systems with both fixed and dynamic SPI bus numbers On systems where some controllers get a dynamic ID assigned and some have a fixed number from DT, the current implemention might run into an IDR collision if the dynamic controllers gets probed first and get an IDR number, which is later requested by the controller with the fixed numbering. When this happens the fixed controller will fail to register with the SPI core. Fix this by skipping all known alias numbers when assigning the dynamic IDs. Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) Signed-off-by: Lucas Stach Signed-off-by: Mark Brown Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [U-Boot] [PATCH 00/11] sound: Add sound support for Nyan
Hi Tom, On Mon, 21 Jan 2019 at 16:43, Simon Glass wrote: > > Hi Tom, > > On Mon, 21 Jan 2019 at 10:46, Tom Warren wrote: > > > > Let's have Jon Hunter take a look, I'll take it in to tegra/master if he > > acks it. > > OK thank you. For now I've picked up the non-Tegra patches from that > series so I can get this out. Any news on this? is it still pending? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] fdt: Introduce fdtdec_get_alias_highest_id()
On Thu, 31 Jan 2019 at 08:31, Michal Simek wrote: > > Find out the highest alias ID used for certain subsystem. > This call will be used for alocating IDs for i2c buses which are not > described in DT. > > Signed-off-by: Michal Simek > --- > > Changes in v2: None > > include/fdtdec.h | 13 + > lib/fdtdec.c | 33 + > 2 files changed, 46 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] initcall: Move to inline function
Hi Alex, On Sat, 2 Feb 2019 at 09:07, Alexander Graf wrote: > > > > > Am 02.02.2019 um 15:13 schrieb Simon Glass : > > > > Hi Alex, > > > >> On Thu, 31 Jan 2019 at 08:06, Alexander Graf wrote: > >> > >> The board_r init function was complaining that we are looping through > >> an array, calling all our tiny init stubs sequentially via indirect > >> function calls (which can't be speculated, so they are slow). > > > > Is this a compiler warning? Could you let me know what this is? > > It's the code comment I'm removing with this patch :). > > > > >> > >> The solution to that is pretty easy though. All we need to do is inline > >> the function that loops through the functions and the compiler will > >> automatically convert almost all indirect calls into direct inlined code. > > > > You mean it calls the functions one after the other without a > > function-table array? > > Exactly. Magical, eh? It even inlines them! Yes it is surprising. I am also surprised that it reduces code size, but I suppose that is why it does it. Presumably the inlining is what does that. But what happens if we #define DEBUG? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] tpm: simplify: tpm_set_global_lock()
On Mon, 4 Feb 2019 at 17:38, Heinrich Schuchardt wrote: > > When in pack_byte_string() memcpy() is called for size 0 the source buffer > address has no relevance. So we can use NULL here. > > Signed-off-by: Heinrich Schuchardt > --- > lib/tpm-v1.c | 4 +--- > 1 file changed, 1 insertion(+), 3 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 v2 0/7] Align U-Boot I2C DM bus ID handling with Linux
Hi Michal, On Tue, 5 Feb 2019 at 00:58, Michal Simek wrote: > > Hi Simon, > > On 02. 02. 19 15:10, Simon Glass wrote: > > Hi Michal, > > > > On Thu, 31 Jan 2019 at 08:31, Michal Simek wrote: > >> > >> U-Boot with I2C_DM enabled is not capable to list i2c busses connected > >> to i2c mux. For getting this work there is a need to find out highest > >> alias ID and use this uniq number for new buses connected to I2C mux. > >> This series is making this happen. > >> > >> There is only one missing piece which is that also i2c controllers which > >> are not listed in DT are not using this feature. > >> > >> Removing setting up aliases from i2c mux code and unifying it in the > >> same code ensures that numbering schema is proper if no alias is > >> specified. > >> > >> ZynqMP> i2c bus > >> Bus 0: i2c@ff02 > >>20: gpio@20, offset len 1, flags 0 > >>21: gpio@21, offset len 1, flags 0 > >>75: i2c-mux@75, offset len 1, flags 0 > >> Bus 1: i2c@ff02->i2c-mux@75->i2c@0 > >> Bus 2: i2c@ff02->i2c-mux@75->i2c@1 > >> Bus 3: i2c@ff02->i2c-mux@75->i2c@2 > >> Bus 4: i2c@ff03 (active 4) > >>74: i2c-mux@74, offset len 1, flags 0 > >>75: i2c-mux@75, offset len 1, flags 0 > >> Bus 5: i2c@ff03->i2c-mux@74->i2c@0 (active 5) > >>54: eeprom@54, offset len 1, flags 0 > >> Bus 6: i2c@ff03->i2c-mux@74->i2c@1 > >> Bus 7: i2c@ff03->i2c-mux@74->i2c@2 > >> Bus 8: i2c@ff03->i2c-mux@74->i2c@3 > >> Bus 9: i2c@ff03->i2c-mux@74->i2c@4 > >> Bus 10: i2c@ff03->i2c-mux@75->i2c@0 > >> Bus 11: i2c@ff03->i2c-mux@75->i2c@1 > >> Bus 12: i2c@ff03->i2c-mux@75->i2c@2 > >> Bus 13: i2c@ff03->i2c-mux@75->i2c@3 > >> Bus 14: i2c@ff03->i2c-mux@75->i2c@4 > >> Bus 15: i2c@ff03->i2c-mux@75->i2c@5 > >> Bus 16: i2c@ff03->i2c-mux@75->i2c@6 > >> Bus 17: i2c@ff03->i2c-mux@75->i2c@7 > >> > >> Thanks, > >> Michal > >> > >> Changes in v2: > >> - Update kernel-doc binding > >> - Return -1 in case of error. -1 means that the next free alias is 0. > >> - New patch > >> - New patch > >> - Use dev_read_alias_highest_id() > >> - Use uclass private data > >> - Use private uclass data > >> - Fix headers > >> - Change patch description to focus only on bus name > > > > I don't have strong objections to this series, but I'd still like to > > try a bit harder on the existing req_seq/seq stuff. > > > > I don't think we necessarily need to set the 'seq' before probe, > > although I suppose we could. > > > > But is there anything to stop us moving some of the logic which sets > > seq to setting req_seq? We could check the aliases and then set > > req_seq during bind(), perhaps? > > Let me put this to my TODO list. But it is not a task which you know > will be done in some hours. It requires to study the whole logic if this > works for all cases. > > > This would be better for code size since it would help all subsystems. > > This approach is used in the linux kernel that's why there is no way to > get rid of dev_read_alias_highest_id() as function. Yes that function seems useful to me. > It means only i2c_uclass_init() and little code in i2c_post_bind() could > be removed. That's why I don't think we will improve size a lot. > If this is copied to other subsystems then yes it will be more useful. > If we have just one now we can't save a lot. Well maybe, but of course the problem you are fixing applies to other subsystems too, doesn't it? > > Heiko: Can you please take a look at this series? I have another 7 > patches on the top of this series which depends on it which cleanup all > zynq/zynqmp platforms and I would like to close this to be able to move. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cros: Expand the Chromium OS documentation
Hi Tristan, On Mon, 4 Feb 2019 at 08:01, Tristan Bastian wrote: > > Hi Simon, > > I'm using the nyan-big chromebook (tegra124). > Is it possible to replace coreboot + depthcharge with just u-boot on the > internal spi flash? > If so, do you have some instructions for that? Possibly, although I would suggest being careful about that. Make sure you have a tool to revert the flash contents. Note that you will not have signed firmware so won't get updates. Presumably you are in dev mode anyway, The instructions are just to flash the image.bin file that comes out of the build, once it exists. But there is no chromeos_nyan target as yet. So your only option right now is to build an image without verified boot, and use a script to boot Chrome OS. I have not tried on this nyan. > > At the moment I'm chainloading u-boot, but this is causing some issues with > not working LPAE so I'm only getting 2 of my 4GB of memory.. > So I would like to try and run u-boot natively to see if chainloading is the > problem or u-boot itself.. > Or maybe you have some instructions to run coreboot + u-boot without > depthcharge? I suppose you could put U-Boot in the image in instead of dc and it might work. [..] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] dm: core: Introduce dev_read_alias_highest_id()
On Thu, 31 Jan 2019 at 08:31, Michal Simek wrote: > > It is wrapper for calling of_alias_get_highest_id() when live tree is > enabled and fdtdec_get_alias_highest_id() if not. > > Signed-off-by: Michal Simek > --- > > Changes in v2: > - New patch > > drivers/core/read.c | 8 > include/dm/read.h | 16 > 2 files changed, 24 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] dm: core: Add of_alias_get_highest_id()
On Wed, 6 Feb 2019 at 23:46, Heiko Schocher wrote: > > Hello Michal, > > Am 31.01.2019 um 16:30 schrieb Michal Simek: > > The same functionality was added to Linux for i2c bus registration with this > > commit message: > > > > " > > of: base: add function to get highest id of an alias stem > > > > I2C supports adding adapters using either a dynamic or fixed id. The > > latter is provided by aliases in the DT case. To prevent id collisions > > of those two types, install this function which gives us the highest > > fixed id, so we can then let the dynamically created ones come after > > this highest number. > > > > Signed-off-by: Wolfram Sang > > Acked-by: Rob Herring > > Signed-off-by: Wolfram Sang > > " > > > > Add it also to U-Boot for DM I2C support. > > > > Signed-off-by: Michal Simek > > --- > > > > Changes in v2: > > - Update kernel-doc binding > > - Return -1 in case of error. -1 means that the next free alias is 0. > > > > drivers/core/of_access.c | 18 ++ > > include/dm/of_access.h | 10 ++ > > 2 files changed, 28 insertions(+) > > Looks good to me > > Reviewed-by: Heiko Schocher Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dm: core: Add tests for dev_read_alias_highest_id()
On Thu, 31 Jan 2019 at 08:31, Michal Simek wrote: > > It is checking the highest alias ID for eth, gpio, pci, i2c and error > code on non existing alias. > > Signed-off-by: Michal Simek > --- > > Changes in v2: > - New patch > > test/dm/test-fdt.c | 23 +++ > 1 file changed, 23 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] MAINTAINERS: update u-boot-atmel tree
On Tue, Feb 05, 2019 at 10:20:39AM +, eugen.hris...@microchip.com wrote: > From: Eugen Hristev > > Update Atmel AT91 maintainership > > Signed-off-by: Eugen Hristev > Acked-by: Nicolas Ferre 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] MAINTAINERS: Change fsl-qoriq, mpc85xx, mpc86xx maintainers
On Mon, Feb 04, 2019 at 05:08:49PM +, York Sun wrote: > >From 19d9e77a6df1f1820f0e8a2bd987849bce14625e Mon Sep 17 00:00:00 2001 > From: York Sun > Date: Mon, 4 Feb 2019 08:22:58 -0800 > Subject: [PATCH v2] MAINTAINERS: Change fsl-qoriq, mpc85xx, mpc86xx > maintainers > > Change maintainers to Prabhakar Kushwaha for fsl-qoriq, mpc85xx > and mpc86xx. > > Signed-off-by: York Sun > Reviewed-by: Tom Rini > Acked-by: Prabhakar Kushwaha 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] arm: dts: am33xx: introduce 'am33xx-u-boot.dtsi'
On Wed, Feb 06, 2019 at 12:49:50PM +0100, Hannes Schmelzer wrote:
> commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
> did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
> introduced with
> commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")
>
> Due to this all boards having CONFIG_SPL_OF_CONTROL enabled are broken
> because they cannot bind/probe the boot-media interface during SPL
> stage.
>
> This commit introduces the 'am33xx-u-boot.dtsi' which is included with
> the auto include mechanism. The am33xx-u-boot-dtsi adds the important
> "u-boot,dm-pre-reloc" to the 'ocp bus' (the root bus of almost all
> peripherals, at least the bootable ones).
>
> The peripherials (mmc, spi, ...) needed during SPL stage need to be
> equipped with the 'u-boot,dm-pre-reloc' in their responsible dts file.
>
> Signed-off-by: Hannes Schmelzer
>
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 request: u-boot-spi/master
On Fri, Feb 08, 2019 at 01:17:21AM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this SPI-NOR sync. > > thanks, > Jagan. > > The following changes since commit e5fd39c886485e3dec77f4438a6e364c2987cf5f: > > Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip > (2019-02-02 10:11:20 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-spi.git master > > for you to fetch changes up to 4d40e009c06742df9582f8b54f37f6cea0680ba1: > > MAINTAINERS: Add an entry for SPI NOR (2019-02-07 15:36:00 +0530) > 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] Please pull u-boot-marvell/master
On Tue, Feb 05, 2019 at 02:36:19PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell related patches, mostly dealing > with the move to driver model (DM_VIDEO & DM_PCI) for the MVEBU > Armada XP / 38x platforms: > 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-rockchip: tags/for-master-20190205
On Tue, Feb 05, 2019 at 10:38:30AM +0100, Philipp Tomsich wrote: > Tom, > > A merge-artifact slipped in with the last round of merges. > Here’s a PR to remove these (I didn’t throw this at Travis for obvious > reasons...). > > Thanks, > Philipp. > > > The following changes since commit e5fd39c886485e3dec77f4438a6e364c2987cf5f: > > Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip > (2019-02-02 10:11:20 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip tags/for-master-20190205 > > for you to fetch changes up to 30477f0500dac67e988498df3b6783372a31c22c: > > rockchip: Remove rejected files with .rej suffix (2019-02-05 10:34:04 +0100) > 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
[U-Boot] [ANN] U-Boot v2019.04-rc1 released
Hey all, So, the scheduled release day for v2019.04-rc1 was a while ago, and so we are quite late. But that's because I really wanted to get a few things in and I've gotten feedback about taking in big changes post -rc1 being not a good thing. So in that vein, -rc1 is out now. I don't see "update my platform / SoC / etc over to DM" as a big change, so we can still get those in before -rc2, but, no big changes now. I'm not going to summarize the output of: git log --merges v2019.01..v2019.04-rc1 But, looking it over, if I was to summarize it, I would just be piping that output in and reformatting it. So, good job folks on giving me good content for the merge commits! I appreciate it as do the people trying to make changelogs from it. I'm planning on doing -rc2 on the 18th, -rc3 on March 4th, -rc4 on March 18th, -rc5 on April 1st (and no jokes, I promise) and a release on April 8th. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] efi_selftest: LoadImage from file device path
Provide a unit test that calls LoadImage() with a file device path and
executes the application via StartImage().
Signed-off-by: Heinrich Schuchardt
---
v2
correct a comment
---
lib/efi_selftest/Makefile | 3 +
lib/efi_selftest/efi_selftest_loadimage.c | 529 ++
2 files changed, 532 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_loadimage.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 779f549940..2194dc7e33 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -51,6 +51,7 @@ endif
ifeq ($(CONFIG_SANDBOX)$(CONFIG_CPU_V7M)$(CONFIG_X86_64),)
obj-y += \
+efi_selftest_loadimage.o \
efi_selftest_startimage_exit.o \
efi_selftest_startimage_return.o
@@ -68,6 +69,8 @@ $(obj)/efi_miniapp_file_image_return.h:
$(obj)/efi_selftest_miniapp_return.efi
$(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_return.efi
> \
$(obj)/efi_miniapp_file_image_return.h
+$(obj)/efi_selftest_loadimage.o: $(obj)/efi_miniapp_file_image_exit.h
+
$(obj)/efi_selftest_startimage_exit.o: $(obj)/efi_miniapp_file_image_exit.h
$(obj)/efi_selftest_startimage_return.o: $(obj)/efi_miniapp_file_image_return.h
diff --git a/lib/efi_selftest/efi_selftest_loadimage.c
b/lib/efi_selftest/efi_selftest_loadimage.c
new file mode 100644
index 00..7369714281
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_loadimage.c
@@ -0,0 +1,529 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * efi_selftest_loadimage
+ *
+ * Copyright (c) 2019 Heinrich Schuchardt
+ *
+ * This test checks the LoadImage and StartImage boot service.
+ *
+ * The efi_selftest_miniapp_exit.efi application is loaded via a file device
+ * path and started.
+ */
+
+#include
+/* Include containing the miniapp.efi application */
+#include "efi_miniapp_file_image_exit.h"
+
+/* Block size of compressed disk image */
+#define COMPRESSED_DISK_IMAGE_BLOCK_SIZE 8
+
+/* Binary logarithm of the block size */
+#define LB_BLOCK_SIZE 9
+
+#define FILE_NAME L"app.efi"
+#define VOLUME_NAME L"EfiDisk"
+
+static struct efi_boot_services *boottime;
+static efi_handle_t handle_image;
+static efi_handle_t handle_volume;
+
+static const efi_guid_t guid_device_path = DEVICE_PATH_GUID;
+static const efi_guid_t guid_simple_file_system_protocol =
+ EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
+static const efi_guid_t guid_file_info = EFI_FILE_INFO_GUID;
+static const efi_guid_t guid_file_system_info = EFI_FILE_SYSTEM_INFO_GUID;
+
+/* One 8 byte block of the compressed disk image */
+struct line {
+ size_t addr;
+ char *line;
+};
+
+/* Compressed file image */
+struct compressed_file_image {
+ size_t length;
+ struct line lines[];
+};
+
+/* File info including file name */
+struct file_info {
+ struct efi_file_info info;
+ u16 file_name[sizeof(FILE_NAME)];
+};
+
+/* File system info including volume name */
+struct file_system_info {
+ struct efi_file_system_info info;
+ u16 file_name[sizeof(VOLUME_NAME)];
+};
+
+/* Compressed file image */
+static struct compressed_file_image img = EFI_ST_DISK_IMG;
+
+/* Pointer to decompressed file image */
+static u8 *image;
+
+/* File info */
+static struct file_info priv_file_info = {
+ {
+ .size = sizeof(struct file_info),
+ .attribute = EFI_FILE_READ_ONLY,
+ },
+ FILE_NAME,
+};
+
+/* Pointer to file info */
+struct efi_file_info *file_info = _file_info.info;
+
+/* Volume device path */
+static struct {
+ struct efi_device_path_vendor vendor;
+ struct efi_device_path end;
+} __packed dp_volume = {
+ .vendor = {
+ .dp = {
+ .type = DEVICE_PATH_TYPE_HARDWARE_DEVICE,
+ .sub_type = DEVICE_PATH_SUB_TYPE_VENDOR,
+ .length = sizeof(struct efi_device_path_vendor),
+ },
+ .guid = EFI_GUID(0x4f9a0ebf, 0xa179, 0x88a6, 0x25, 0x68,
+0x10, 0x72, 0xb1, 0x93, 0x51, 0x71),
+ },
+ .end = {
+ .type = DEVICE_PATH_TYPE_END,
+ .sub_type = DEVICE_PATH_SUB_TYPE_END,
+ .length = sizeof(struct efi_device_path),
+ }
+};
+
+/* File device path */
+static struct {
+ struct efi_device_path_vendor vendor;
+ struct efi_device_path path;
+ u16 file[sizeof(FILE_NAME)];
+ struct efi_device_path end;
+} __packed dp_file = {
+ .vendor = {
+ .dp = {
+ .type = DEVICE_PATH_TYPE_HARDWARE_DEVICE,
+ .sub_type = DEVICE_PATH_SUB_TYPE_VENDOR,
+ .length = sizeof(struct efi_device_path_vendor),
+ },
+ .guid = EFI_GUID(0x4f9a0ebf, 0xa179, 0x88a6, 0x25, 0x68,
+0x10, 0x72, 0xb1, 0x93, 0x51, 0x71),
+ },
+ .path = {
+ .type = DEVICE_PATH_TYPE_MEDIA_DEVICE,
+
Re: [U-Boot] [PATCH v3 0/5] spi-flash: switch to "jedec, spi-nor" binding
Le 07/02/2019 13:28, Jagan Teki a écrit : > On Tue, Jan 15, 2019 at 6:29 PM Neil Armstrong > wrote: >> >> There is no reason not to use the Linux "jedec,spi-nor" binding in u-boot. >> This patchset : >> - adds this compatible into sf_probe and will avoid changing the >> device tree files to add a u-boot specific compatible to probe a spi flash. >> - switches all DTS/DTSI files to "jedec,spi-nor" >> - remove the "spi-flash" compatible from sf-probe >> - switch GENERIC_SPI_FLASH to jedec,spi-nor in fdtdec >> - switches dt bindings examples files to "jedec,spi-nor" >> >> Changes since v2: >> - collected tags >> - extracted x86 dts changed and merged it with the fdtdec change >> - updated for new boards >> >> Neil Armstrong (5): >> mtd: sf_probe: add jedec,spi-nor compatible >> dts: switch spi-flash to jedec,spi-nor compatible >> x86: dts: switch spi-flash to jedec,spi-nor compatible >> mtd: sf_probe: remove spi-flash compatible >> doc: device-tree-bindings: switch from spi-flash to jedec,spi-nor > > Reviewed-by: Jagan Teki > > Please send v4 on top of u-boot-spi/master and skip the 1/5 (picked > this from Vignesh series) > OK, will re-spin. Neil ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this SPI-NOR sync. thanks, Jagan. The following changes since commit e5fd39c886485e3dec77f4438a6e364c2987cf5f: Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip (2019-02-02 10:11:20 -0500) are available in the Git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 4d40e009c06742df9582f8b54f37f6cea0680ba1: MAINTAINERS: Add an entry for SPI NOR (2019-02-07 15:36:00 +0530) Vignesh R (20): configs: Move CONFIG_SPI_FLASH into defconfigs bitops: Fix GENMASK definition for Sandbox spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes spi: spi-mem: Extend spi_mem_adjust_op_size() to honor max xfer size spi: spi-mem: Claim SPI bus before spi mem access spi: Add non DM version of SPI_MEM sh: bitops: add hweight*() macros mtd: spi: Port SPI NOR framework from Linux mtd: spi: spi-nor-core: Add SPI MEM support mtd: spi: spi-nor-core: Add 4 Byte addressing support mtd: spi: spi-nor-core: Add SFDP support mtd: spi: spi-nor-core: Add back U-Boot specific features mtd: spi: sf_probe: Add "jedec, spi-nor" compatible string mtd: spi: Switch to new SPI NOR framework mtd: spi: Remove unused files mtd: spi: Add lightweight SPI flash stack for SPL spl: Kconfig: Enable SPI_FLASH_TINY by default for SPL configs: Remove SF_DUAL_FLASH configs: Don't use SPI_FLASH_BAR as default MAINTAINERS: Add an entry for SPI NOR MAINTAINERS | 10 +- arch/arm/mach-omap2/am33xx/Kconfig |1 - arch/sh/include/asm/bitops.h |4 + common/spl/Kconfig | 23 +- configs/alt_defconfig|1 - configs/am57xx_evm_defconfig |1 - configs/am57xx_hs_evm_defconfig |1 - configs/ap121_defconfig |1 - configs/ap143_defconfig |1 - configs/avnet_ultra96_rev1_defconfig |1 - configs/axs101_defconfig |1 - configs/axs103_defconfig |1 - configs/bg0900_defconfig |1 - configs/blanche_defconfig|1 - configs/cgtqmx6eval_defconfig|1 + configs/chromebit_mickey_defconfig |1 + configs/chromebook_jerry_defconfig |1 + configs/chromebook_minnie_defconfig |1 + configs/cl-som-am57x_defconfig |1 - configs/clearfog_defconfig |1 - configs/cm_t43_defconfig |1 - configs/db-88f6820-amc_defconfig |1 - configs/display5_defconfig |1 - configs/display5_factory_defconfig |1 - configs/dra7xx_evm_defconfig |1 - configs/dra7xx_hs_evm_defconfig |1 - configs/ds109_defconfig |1 - configs/ds414_defconfig |1 - configs/evb-rk3036_defconfig |1 + configs/evb-rk3128_defconfig |1 + configs/evb-rk3288_defconfig |1 + configs/evb-rk3328_defconfig |1 + configs/evb-rv1108_defconfig |1 - configs/fennec-rk3288_defconfig |1 + configs/firefly-rk3288_defconfig |1 + configs/gose_defconfig |1 - configs/helios4_defconfig|1 - configs/k2g_evm_defconfig|1 - configs/k2g_hs_evm_defconfig |1 - configs/koelsch_defconfig|1 - configs/kylin-rk3036_defconfig |1 + configs/lager_defconfig |1 - configs/ls2080aqds_SECURE_BOOT_defconfig |1 + configs/ls2080aqds_defconfig |1 + configs/ls2080aqds_nand_defconfig|1 + configs/ls2080aqds_qspi_defconfig|1 + configs/ls2080aqds_sdcard_defconfig |1 + configs/maxbcm_defconfig |1 - configs/miqi-rk3288_defconfig|1 + configs/mt7629_rfb_defconfig |1 - configs/mx6sxsabreauto_defconfig |1 - configs/mx6sxsabresd_defconfig |1 - configs/mx6ul_14x14_evk_defconfig|1 - configs/mx6ul_9x9_evk_defconfig |1 - configs/mx6ull_14x14_evk_defconfig |1 - configs/mx6ull_14x14_evk_plugin_defconfig|1 - configs/mx7dsabresd_qspi_defconfig |1 - configs/phycore-rk3288_defconfig
Re: [U-Boot] [PATCH 1/2] fdt: Allow indicating a node is for U-Boot proper only
On 2/7/19 6:40 PM, Patrick DELAUNAY wrote:
> Hi Marek,
>
>> From: Marek Vasut
>> Sent: mardi 5 février 2019 09:55
>>
>> On 2/4/19 3:40 PM, Simon Glass wrote:
>>> On Mon, 4 Feb 2019 at 03:15, Patrick Delaunay
>> wrote:
This add missing parts for previous commit 06f94461a9f4
("fdt: Allow indicating a node is for U-Boot proper only")
At present it is not possible to specify that a node should be used
before relocation (in U-Boot proper) without it also ending up in SPL
and TPL device trees. Add a new "u-boot,dm-pre-proper" boolean property
>> for this.
Signed-off-by: Patrick Delaunay
>>>
>>> Reviewed-by: Simon Glass
>>>
>>> There was discussion some time ago about using a property instead:
>>>
>>> chosen {
>>>u-boot,dm-spl = < >;
>>> u-boot,dm-tpl = <>;
>>> };
>>>
>>> At the time I decided that this was more painful since it separates
>>> out the tag from its node.
>>>
>>> I wonder if that is still true? We do now in fact generally use a
>>> u-boot.dtsi file to hold these tags.
>>>
>>> I'm not suggesting a change, just raising the question.
>>
>> It's a good suggestion. In fact, you can then use some tool to walk back up
>> the
>> tree and only retain the branches which are referenced by phandle from u-
>> boot,dm-spl/tpl node for U-Boot SPL/TPL DTs. I think that could save a bit of
>> space too. I wonder if we can even use /omit-if-no-ref/ DTC syntax somehow.
>
> If I correctly understood the new feature of dtc "/omit-if-no-ref/", in
> kernel dtc since 4.18,
> dtc remove node when nobody use reference on this node, so it is useful for
> U-Boot
> nodes when they are used as reference : for example pincontrol nodes.
> cf: https://elinux.org/Device_Tree_Source_Undocumented
>
> U-Boot dtb use dtc to compile dts files , so it can be used here.
>
> But for SPL / TPL the parsing in done in fdtgrep, on dtb
> And the tags "/omit-if-no-ref/" are already removed in dtb.
Maybe we need feature which is similar, not the same.
> NB: we could also remove the tags u-boot,dm-pre-reloc/u-boot,dm-spl : we can
> gain place in spl dtb
>These tags are not needed as binding is mandatory in SPL build for ALL
> node present in SPL device tree
> others node are cleaned by fdtgrep (but impact in SPL code)
>
> PS: a other boring point: if we need to tag all the tree to have one sub-node
> in SPL
> For me spl tag on the children should be enough ...
Indeed, referencing the child node with a phandle from some chosen node
would be much better than adding u-boot,dm-... throughout the tree.
> But is perhaps difficult in ftdgrep (need to parse all the fathers node)
>
> For example to have pins1 and pins2,
> we have to also tag qspi-bk2-0 and pin-controller
>
> pin-controller@50002000 {
> u-boot,dm-pre-reloc;
> qspi-bk2-0 {
> u-boot,dm-spl;
> pins1 {
> u-boot,dm-spl;
> };
> pins2 {
> u-boot,dm-spl;
> };
> };
> };
I still like using the phandle better than the u-boot,dm-spl all over
the place.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fdt: Allow indicating a node is for U-Boot proper only
Hi Marek,
> From: Marek Vasut
> Sent: mardi 5 février 2019 09:55
>
> On 2/4/19 3:40 PM, Simon Glass wrote:
> > On Mon, 4 Feb 2019 at 03:15, Patrick Delaunay
> wrote:
> >>
> >> This add missing parts for previous commit 06f94461a9f4
> >> ("fdt: Allow indicating a node is for U-Boot proper only")
> >>
> >> At present it is not possible to specify that a node should be used
> >> before relocation (in U-Boot proper) without it also ending up in SPL
> >> and TPL device trees. Add a new "u-boot,dm-pre-proper" boolean property
> for this.
> >>
> >>
> >> Signed-off-by: Patrick Delaunay
> >
> > Reviewed-by: Simon Glass
> >
> > There was discussion some time ago about using a property instead:
> >
> > chosen {
> >u-boot,dm-spl = < >;
> > u-boot,dm-tpl = <>;
> > };
> >
> > At the time I decided that this was more painful since it separates
> > out the tag from its node.
> >
> > I wonder if that is still true? We do now in fact generally use a
> > u-boot.dtsi file to hold these tags.
> >
> > I'm not suggesting a change, just raising the question.
>
> It's a good suggestion. In fact, you can then use some tool to walk back up
> the
> tree and only retain the branches which are referenced by phandle from u-
> boot,dm-spl/tpl node for U-Boot SPL/TPL DTs. I think that could save a bit of
> space too. I wonder if we can even use /omit-if-no-ref/ DTC syntax somehow.
If I correctly understood the new feature of dtc "/omit-if-no-ref/", in kernel
dtc since 4.18,
dtc remove node when nobody use reference on this node, so it is useful for
U-Boot
nodes when they are used as reference : for example pincontrol nodes.
cf: https://elinux.org/Device_Tree_Source_Undocumented
U-Boot dtb use dtc to compile dts files , so it can be used here.
But for SPL / TPL the parsing in done in fdtgrep, on dtb
And the tags "/omit-if-no-ref/" are already removed in dtb.
NB: we could also remove the tags u-boot,dm-pre-reloc/u-boot,dm-spl : we can
gain place in spl dtb
These tags are not needed as binding is mandatory in SPL build for ALL
node present in SPL device tree
others node are cleaned by fdtgrep (but impact in SPL code)
PS: a other boring point: if we need to tag all the tree to have one sub-node
in SPL
For me spl tag on the children should be enough ...
But is perhaps difficult in ftdgrep (need to parse all the fathers node)
For example to have pins1 and pins2,
we have to also tag qspi-bk2-0 and pin-controller
pin-controller@50002000 {
u-boot,dm-pre-reloc;
qspi-bk2-0 {
u-boot,dm-spl;
pins1 {
u-boot,dm-spl;
};
pins2 {
u-boot,dm-spl;
};
};
};
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards
On 07.02.19 17:49, Marek Vasut wrote:
On 2/7/19 4:28 PM, Oleksandr wrote:
On 05.02.19 20:48, Marek Vasut wrote:
Hi Marek
Hi,
Hi,
On 1/31/19 6:38 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Both Lager and Stout boards are based on r8a7790 SoC.
Leave platform specific functions for bringing seconadary CPUs up empty,
since our target is to use PSCI for that.
Also take care of updating arch timer while we are in secure mode.
Signed-off-by: Oleksandr Tyshchenko
---
arch/arm/mach-rmobile/Kconfig.32 | 4
board/renesas/lager/lager.c | 51
board/renesas/stout/stout.c | 51
include/configs/lager.h | 3 +++
include/configs/stout.h | 3 +++
5 files changed, 112 insertions(+)
diff --git a/arch/arm/mach-rmobile/Kconfig.32
b/arch/arm/mach-rmobile/Kconfig.32
index 076a019..a2e9e3d 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -76,6 +76,8 @@ config TARGET_LAGER
select SUPPORT_SPL
select USE_TINY_PRINTF
imply CMD_DM
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
Shouldn't this be a H2 CPU property instead of a board property ?
Probably yes, sounds reasonable. I will move these options under "config
R8A7790".
Does this apply to M2* too , since it has CA15 cores as well ?
I think, yes. But, without PSCI support being implemented for M2*, I
think it is not worth to select these options for it as well.
It's basically the same SoC with two CPU cores less, how would that PSCI
be any different on M2 ?
I need some time to investigate. I will come up with an answer later.
config TARGET_KZM9G
bool "KZM9D board"
@@ -115,6 +117,8 @@ config TARGET_STOUT
select SUPPORT_SPL
select USE_TINY_PRINTF
imply CMD_DM
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
endchoice
diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index 062e88c..9b96cc4 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -76,6 +76,53 @@ int board_early_init_f(void)
return 0;
}
+#ifdef CONFIG_ARMV7_NONSEC
+#define TIMER_BASE 0xE608
+#define TIMER_CNTCR 0x00
+#define TIMER_CNTFID0 0x20
+
+/*
+ * Taking into the account that arch timer is only configurable in
secure mode
+ * and we are going to enter kernel/hypervisor in a non-secure mode,
update
+ * arch timer right now to avoid possible issues. Make sure arch
timer is
+ * enabled and configured to use proper frequency.
+ */
+static void rcar_gen2_timer_init(void)
+{
+ u32 freq = RMOBILE_XTAL_CLK / 2;
+
+ /*
+ * Update the arch timer if it is either not running, or is not
at the
+ * right frequency.
+ */
+ if ((readl(TIMER_BASE + TIMER_CNTCR) & 1) == 0 ||
+ readl(TIMER_BASE + TIMER_CNTFID0) != freq) {
What is this check about ?
Actually, this code for updating arch timer was borrowed from Linux
almost as is.
Code in Linux uses this check in order to update timer only if required
(either timer disabled or uses wrong freq).
This check avoids abort in Linux if loader has already updated timer and
switched to non-secure mode.
But here in U-Boot, while we are still in secure mode, we can safely
remove this check and always update the timer. Shall I remove this check?
Shouldn't the timer be correctly configured by U-Boot in the first
place? And shouldn't this be done by timer driver rather than some
ad-hoc init code?
Yes, this timer should be correctly configured by U-Boot. And yes, the timer
configuration code should be in a proper place.
+ /* Update registers with correct frequency */
+ writel(freq, TIMER_BASE + TIMER_CNTFID0);
+ asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
+
+ /* Make sure arch timer is started by setting bit 0 of CNTCR */
+ writel(1, TIMER_BASE + TIMER_CNTCR);
Shouldn't this be in the timer driver instead ?
Which timer driver? Probably, I missed something, but I didn't find any
arch timer driver being used for Gen2.
I see that TMU timer (arch/sh/lib/time.c) is used as a system timer, but
it is yet another IP.
Would it be correct, if I move arch timer updating code to
arch/arm/mach-rmobile directory?
Actually, at the same location the corresponding code lives in Linux:
https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/setup-rcar-gen2.c#L61
Presumably if this is something else than TMU, it needs proper driver
that goes into drivers/ .
Did I get your point correctly that new driver (specially for Gen2 arch
timer) should be introduced in U-Boot and
the only one thing it is intended to do is to configure that timer for
the future use by Linux/Hypervisor?
If yes, the only question I have is how that new driver is going to be
populated? There is no corresponding node for arch timer in the device tree.
Re: [U-Boot] [PATCH v2] arm: dts: am33xx: introduce 'am33xx-u-boot.dtsi'
On 2/7/19 5:47 PM, Felix Brack wrote:
Hi Hannes,
Hi Felix,
On 06.02.19 12:49, Hannes Schmelzer wrote:
commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
introduced with
commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")
Due to this all boards having CONFIG_SPL_OF_CONTROL enabled are broken
because they cannot bind/probe the boot-media interface during SPL
stage.
Not all boards were broken, only those not having set that property in
their proper -u-boot.dtsi or dts file (like am335x-pdu001-u-boot.dtsi).
true.
This commit introduces the 'am33xx-u-boot.dtsi' which is included with
the auto include mechanism. The am33xx-u-boot-dtsi adds the important
"u-boot,dm-pre-reloc" to the 'ocp bus' (the root bus of almost all
peripherals, at least the bootable ones).
If the new am33xx-u-boot.dtsi file gets include automatically then
setting the same property in the board specific dts/dtsi file is
redundant. Hence please remove the property from those files (like from
am335x-pdu001-u-boot.dtsi) and add those modified files to your patch.
Thus we have one single patch fixing this issue. Many thanks!
retards Felix
Nope.
If i understood the mechanism correctly the mechanism searches
this way:
-u-boot.dtsi where is the base name of the .dts file
-u-boot.dtsi
-u-boot.dtsi
-u-boot.dtsi
u-boot.dtsi
and stops after the first match.
In your case: *am335x-pdu001*-u-boot.dtsi
Have a look, to: tools/binman/README
So i still think, that my patch is on the right track.
The peripherials (mmc, spi, ...) needed during SPL stage need to be
equipped with the 'u-boot,dm-pre-reloc' in their responsible dts file.
Signed-off-by: Hannes Schmelzer
---
Changes in v2:
- use u-boot,dm-pre-reloc instead u-boot,dm-spl
- add am33xx-u-boot.dtsi instead modifying the am33xx.dtsi
arch/arm/dts/am33xx-u-boot.dtsi | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 arch/arm/dts/am33xx-u-boot.dtsi
diff --git a/arch/arm/dts/am33xx-u-boot.dtsi b/arch/arm/dts/am33xx-u-boot.dtsi
new file mode 100644
index 000..78f5e2c
--- /dev/null
+++ b/arch/arm/dts/am33xx-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 B Industrial Automation GmbH -
+ * https://www.br-automation.com/
+ */
+
+/ {
+ ocp {
+ u-boot,dm-pre-reloc;
+ };
+};
___
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 v2] arm: dts: am33xx: introduce 'am33xx-u-boot.dtsi'
Hi Hannes,
On 06.02.19 12:49, Hannes Schmelzer wrote:
> commit fdce9d35dc36 ("arm: dts: am33xx: Sync dts with Linux 4.20.0")
> did remove the "u-boot,dm-spl" flag from the 'ocp' bus which was
> introduced with
> commit 19aa4ac09db9 ("dts: am33xx: add u-boot, dm-spl to ocp bus")
>
> Due to this all boards having CONFIG_SPL_OF_CONTROL enabled are broken
> because they cannot bind/probe the boot-media interface during SPL
> stage.
>
Not all boards were broken, only those not having set that property in
their proper -u-boot.dtsi or dts file (like am335x-pdu001-u-boot.dtsi).
> This commit introduces the 'am33xx-u-boot.dtsi' which is included with
> the auto include mechanism. The am33xx-u-boot-dtsi adds the important
> "u-boot,dm-pre-reloc" to the 'ocp bus' (the root bus of almost all
> peripherals, at least the bootable ones).
>
If the new am33xx-u-boot.dtsi file gets include automatically then
setting the same property in the board specific dts/dtsi file is
redundant. Hence please remove the property from those files (like from
am335x-pdu001-u-boot.dtsi) and add those modified files to your patch.
Thus we have one single patch fixing this issue. Many thanks!
retards Felix
> The peripherials (mmc, spi, ...) needed during SPL stage need to be
> equipped with the 'u-boot,dm-pre-reloc' in their responsible dts file.
>
> Signed-off-by: Hannes Schmelzer
>
> ---
>
> Changes in v2:
> - use u-boot,dm-pre-reloc instead u-boot,dm-spl
> - add am33xx-u-boot.dtsi instead modifying the am33xx.dtsi
>
> arch/arm/dts/am33xx-u-boot.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
> create mode 100644 arch/arm/dts/am33xx-u-boot.dtsi
>
> diff --git a/arch/arm/dts/am33xx-u-boot.dtsi b/arch/arm/dts/am33xx-u-boot.dtsi
> new file mode 100644
> index 000..78f5e2c
> --- /dev/null
> +++ b/arch/arm/dts/am33xx-u-boot.dtsi
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 B Industrial Automation GmbH -
> + * https://www.br-automation.com/
> + */
> +
> +/ {
> + ocp {
> + u-boot,dm-pre-reloc;
> + };
> +};
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards
On 2/7/19 4:28 PM, Oleksandr wrote:
>
> On 05.02.19 20:48, Marek Vasut wrote:
>
> Hi Marek
Hi,
>> On 1/31/19 6:38 PM, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> Both Lager and Stout boards are based on r8a7790 SoC.
>>>
>>> Leave platform specific functions for bringing seconadary CPUs up empty,
>>> since our target is to use PSCI for that.
>>>
>>> Also take care of updating arch timer while we are in secure mode.
>>>
>>> Signed-off-by: Oleksandr Tyshchenko
>>> ---
>>> arch/arm/mach-rmobile/Kconfig.32 | 4
>>> board/renesas/lager/lager.c | 51
>>>
>>> board/renesas/stout/stout.c | 51
>>>
>>> include/configs/lager.h | 3 +++
>>> include/configs/stout.h | 3 +++
>>> 5 files changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-rmobile/Kconfig.32
>>> b/arch/arm/mach-rmobile/Kconfig.32
>>> index 076a019..a2e9e3d 100644
>>> --- a/arch/arm/mach-rmobile/Kconfig.32
>>> +++ b/arch/arm/mach-rmobile/Kconfig.32
>>> @@ -76,6 +76,8 @@ config TARGET_LAGER
>>> select SUPPORT_SPL
>>> select USE_TINY_PRINTF
>>> imply CMD_DM
>>> + select CPU_V7_HAS_NONSEC
>>> + select CPU_V7_HAS_VIRT
>> Shouldn't this be a H2 CPU property instead of a board property ?
>
> Probably yes, sounds reasonable. I will move these options under "config
> R8A7790".
>
>> Does this apply to M2* too , since it has CA15 cores as well ?
>
> I think, yes. But, without PSCI support being implemented for M2*, I
> think it is not worth to select these options for it as well.
It's basically the same SoC with two CPU cores less, how would that PSCI
be any different on M2 ?
>>> config TARGET_KZM9G
>>> bool "KZM9D board"
>>> @@ -115,6 +117,8 @@ config TARGET_STOUT
>>> select SUPPORT_SPL
>>> select USE_TINY_PRINTF
>>> imply CMD_DM
>>> + select CPU_V7_HAS_NONSEC
>>> + select CPU_V7_HAS_VIRT
>>> endchoice
>>> diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
>>> index 062e88c..9b96cc4 100644
>>> --- a/board/renesas/lager/lager.c
>>> +++ b/board/renesas/lager/lager.c
>>> @@ -76,6 +76,53 @@ int board_early_init_f(void)
>>> return 0;
>>> }
>>> +#ifdef CONFIG_ARMV7_NONSEC
>>> +#define TIMER_BASE 0xE608
>>> +#define TIMER_CNTCR 0x00
>>> +#define TIMER_CNTFID0 0x20
>>> +
>>> +/*
>>> + * Taking into the account that arch timer is only configurable in
>>> secure mode
>>> + * and we are going to enter kernel/hypervisor in a non-secure mode,
>>> update
>>> + * arch timer right now to avoid possible issues. Make sure arch
>>> timer is
>>> + * enabled and configured to use proper frequency.
>>> + */
>>> +static void rcar_gen2_timer_init(void)
>>> +{
>>> + u32 freq = RMOBILE_XTAL_CLK / 2;
>>> +
>>> + /*
>>> + * Update the arch timer if it is either not running, or is not
>>> at the
>>> + * right frequency.
>>> + */
>>> + if ((readl(TIMER_BASE + TIMER_CNTCR) & 1) == 0 ||
>>> + readl(TIMER_BASE + TIMER_CNTFID0) != freq) {
>> What is this check about ?
>
> Actually, this code for updating arch timer was borrowed from Linux
> almost as is.
>
> Code in Linux uses this check in order to update timer only if required
> (either timer disabled or uses wrong freq).
>
> This check avoids abort in Linux if loader has already updated timer and
> switched to non-secure mode.
>
>
> But here in U-Boot, while we are still in secure mode, we can safely
> remove this check and always update the timer. Shall I remove this check?
Shouldn't the timer be correctly configured by U-Boot in the first
place? And shouldn't this be done by timer driver rather than some
ad-hoc init code?
>>
>>> + /* Update registers with correct frequency */
>>> + writel(freq, TIMER_BASE + TIMER_CNTFID0);
>>> + asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
>>> +
>>> + /* Make sure arch timer is started by setting bit 0 of CNTCR */
>>> + writel(1, TIMER_BASE + TIMER_CNTCR);
>> Shouldn't this be in the timer driver instead ?
>
> Which timer driver? Probably, I missed something, but I didn't find any
> arch timer driver being used for Gen2.
>
> I see that TMU timer (arch/sh/lib/time.c) is used as a system timer, but
> it is yet another IP.
>
> Would it be correct, if I move arch timer updating code to
> arch/arm/mach-rmobile directory?
>
> Actually, at the same location the corresponding code lives in Linux:
>
> https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/setup-rcar-gen2.c#L61
Presumably if this is something else than TMU, it needs proper driver
that goes into drivers/ .
>>> + }
>>> +}
>>> +
>>> +/*
>>> + * In order not to break compilation if someone decides to build
>>> with PSCI
>>> + * support disabled, keep these dummy functions.
>>> + */
>> That's currently the only use-case.
>
> Shall I drop this comment and dummy functions
Re: [U-Boot] [PATCH] Kconfig: fix BUILD_TARGET for ARCH_MVEBU
On 07.02.19 12:21, Baruch Siach wrote:
Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made the
mvebu default build target depend on CONFIG_SPL_BUILD. Unfortunately,
there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead to
fix that.
Cc: Jagan Teki
Signed-off-by: Baruch Siach
Thanks for spotting.
Reviewed-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards
On 05.02.19 20:48, Marek Vasut wrote:
Hi Marek
On 1/31/19 6:38 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Both Lager and Stout boards are based on r8a7790 SoC.
Leave platform specific functions for bringing seconadary CPUs up empty,
since our target is to use PSCI for that.
Also take care of updating arch timer while we are in secure mode.
Signed-off-by: Oleksandr Tyshchenko
---
arch/arm/mach-rmobile/Kconfig.32 | 4
board/renesas/lager/lager.c | 51
board/renesas/stout/stout.c | 51
include/configs/lager.h | 3 +++
include/configs/stout.h | 3 +++
5 files changed, 112 insertions(+)
diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32
index 076a019..a2e9e3d 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -76,6 +76,8 @@ config TARGET_LAGER
select SUPPORT_SPL
select USE_TINY_PRINTF
imply CMD_DM
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
Shouldn't this be a H2 CPU property instead of a board property ?
Probably yes, sounds reasonable. I will move these options under "config
R8A7790".
Does this apply to M2* too , since it has CA15 cores as well ?
I think, yes. But, without PSCI support being implemented for M2*, I
think it is not worth to select these options for it as well.
config TARGET_KZM9G
bool "KZM9D board"
@@ -115,6 +117,8 @@ config TARGET_STOUT
select SUPPORT_SPL
select USE_TINY_PRINTF
imply CMD_DM
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
endchoice
diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index 062e88c..9b96cc4 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -76,6 +76,53 @@ int board_early_init_f(void)
return 0;
}
+#ifdef CONFIG_ARMV7_NONSEC
+#define TIMER_BASE 0xE608
+#define TIMER_CNTCR0x00
+#define TIMER_CNTFID0 0x20
+
+/*
+ * Taking into the account that arch timer is only configurable in secure mode
+ * and we are going to enter kernel/hypervisor in a non-secure mode, update
+ * arch timer right now to avoid possible issues. Make sure arch timer is
+ * enabled and configured to use proper frequency.
+ */
+static void rcar_gen2_timer_init(void)
+{
+ u32 freq = RMOBILE_XTAL_CLK / 2;
+
+ /*
+* Update the arch timer if it is either not running, or is not at the
+* right frequency.
+*/
+ if ((readl(TIMER_BASE + TIMER_CNTCR) & 1) == 0 ||
+ readl(TIMER_BASE + TIMER_CNTFID0) != freq) {
What is this check about ?
Actually, this code for updating arch timer was borrowed from Linux
almost as is.
Code in Linux uses this check in order to update timer only if required
(either timer disabled or uses wrong freq).
This check avoids abort in Linux if loader has already updated timer and
switched to non-secure mode.
But here in U-Boot, while we are still in secure mode, we can safely
remove this check and always update the timer. Shall I remove this check?
+ /* Update registers with correct frequency */
+ writel(freq, TIMER_BASE + TIMER_CNTFID0);
+ asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
+
+ /* Make sure arch timer is started by setting bit 0 of CNTCR */
+ writel(1, TIMER_BASE + TIMER_CNTCR);
Shouldn't this be in the timer driver instead ?
Which timer driver? Probably, I missed something, but I didn't find any
arch timer driver being used for Gen2.
I see that TMU timer (arch/sh/lib/time.c) is used as a system timer, but
it is yet another IP.
Would it be correct, if I move arch timer updating code to
arch/arm/mach-rmobile directory?
Actually, at the same location the corresponding code lives in Linux:
https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/setup-rcar-gen2.c#L61
+ }
+}
+
+/*
+ * In order not to break compilation if someone decides to build with PSCI
+ * support disabled, keep these dummy functions.
+ */
That's currently the only use-case.
Shall I drop this comment and dummy functions below?
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+}
+
+void smp_kick_all_cpus(void)
+{
+}
+
+void smp_waitloop(unsigned int previous_address)
+{
+}
+#endif
+
#define ETHERNET_PHY_RESET185 /* GPIO 5 31 */
int board_init(void)
@@ -89,6 +136,10 @@ int board_init(void)
mdelay(10);
gpio_direction_output(ETHERNET_PHY_RESET, 1);
+#ifdef CONFIG_ARMV7_NONSEC
Define empty function in case the macro is not set instead of ifdefing
every place that calls the rcar_gen2_timer_init() function.
Agree, will do
+ rcar_gen2_timer_init();
+#endif
+
return 0;
}
diff --git a/board/renesas/stout/stout.c
Re: [U-Boot] Booting linux zImage on vexpress-a15
On Thu, Feb 07, 2019 at 01:55:00PM +0100, Andre Wagner wrote: > Hi Liviu, > > thank you very much for your reply. A very good hint was that I need to set > the extra kernel parameter earlyprintk for showing further debug output. I > expected that setting the 'Early Printk' option in Kconfig is enough. After > adding this kernel parameter i can see the kernel boot messages, but the > kernel stucks now at 'smp: Bringing up secondary CPUs ...'. As a cross-check > I booted the kernel directly on the qemu vexpress machine and there are also > error messages at the SMP step shown, but the boot process continues. In the > running system I can only see one CPU, so SMP does not work at all. So I > disabled all CPUs expect the first one in the device tree, so my boot > procedure in u-boot is as following: > > 1. Set boot args: setenv bootargs console=ttyAMA0 earlyprintk debug verbose May I suggest you use $ setenv bootargs 'console=ttyAMA0 earlyprintk debug verbose' i.e. put single quotes around the value of the variable. > > 2. Load the zImage at start of RAM + 8000h offset: ext4load mmc 0:1 80008000 > zImage > > 3. Load Device Tree: ext4load mmc 0:1 8a00 vexpress-v2p-ca15-tc1.dtb > > 4. Init fdt subsystem: fdt addr 8a00 In my test with mainline kernel and U-Boot from yesterday I didn't had to do this, because > > 5. Deactivate second CPU: fdt rm /cpus/cpu@1 I didn't have to disable the other CPUs either. > > 6. Boot with bootz command: bootz 80008000 - 8a00 > > 7. In the SMP boot step only one CPU it recognized, the boot process > continues > > 8. Now the boot process stucks at 'DMA: preallocated 256 KiB pool for atomic > coherent allocations' > > > Further I found that: > > 1. The space between kernel loadaddr and DTB load address of 2ff8000h Bytes > (about 50MB) was big enough, since there is no difference if I use the old > (8500h) or the new DTB loadaddr (8a00h). Just for being on the sure > site I continue using 8a00 for DTB load address > > 2. All vexpress DTBs contain a ARM HBI number with seems to be a > identificator for the ARM board. The ARM HBI of vexpress-v2p-ca15-tc1.dtb > fits the expected ARM HBI of the qemu vexpress-a15, the > vexpress-v2p-ca15_a7.dtb fits not. So I keep using the > vexpress-v2p-ca15-tc1.dtb device tree Like I've said, those dtbs are for real hardware CoreTiles placed inside the Versatile Express motherboard. I don't know (or remember exactly) if qemu emulates all the aspects, but it should not matter much. > > 3. I recompiled the vexpress-v2p-ca15-tc1.dtb device tree without the > /cpus/cpu@1 and let it run directly by qemu. The boot process succeeds. The > next message after 'DMA: preallocated 256 KiB pool for atomic coherent > allocations' is in this case 'cpuidle: using governor ladder' > > 4. I didn't mentioned the versions I'm using: It's qemu version > 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.8), Linux version 5.0.0-rc5 and U-Boot > version 2019.01-00523-ge5fd39c886. I'm aware that these are development > versions. My versions are qemu 3.1.0, U-Boot 2019.01-00058-g23b00a07fc-dirty, Linux version 5.0.0-rc5+. Attached is a log of my session. Best regards, Liviu > > > At this point I assume that kernel and DTB are loaded correctly, but I > haven't any idea what influence u-boot can have initializing DMA and/or > cpuidle. Any suggestions? > > > P.S. I will continue testing other stable vanilla kernels. > > P.S. I attached the boot logs: The file boot_qemu_only is the successful > boot with qemu only via kernel and dtb option, the file boot_qemu_uboot is > the boot with qemu + u-boot. > > > Thanks for your help. > > Greetings, > > André > > > > > On 06.02.19 17:58, Liviu Dudau wrote: > > On Tue, Feb 05, 2019 at 07:05:55PM +0100, Andre Wagner wrote: > > > Hi @all, > > Hi Andre, > > > > > > I'm trying to build a linux kernel as zImage and boot it with u-boot on a > > > qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04. > > > > > > What I tried until now: > > > > > > 1. Get Linux from git, export ARCH=arm and > > > CROSS_COMPILE=arm-linux-gnueabihf- > > > > > > 2. Make Defconfig: make vexpress_defconfig > > > > > > 3. Enable 'Early Printk' with make menuconfig > > > > > > 4. Make Kernel: make > > > > > > 5. Get U-Boot from git, export ARCH=arm and > > > CROSS_COMPILE=arm-linux-gnueabihf- > > > > > > 6. Make Defconfig: make vexpress_ca15_tc2_defconfig > > > > > > 7. Make U-Boot: make > > > > > > 8. Generate empty image file and mount it: truncate -s 100M image; > > > mkfs.ext4 > > > image; mount -o loop image /mnt > > > > > > 9. Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp > > > arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt > > > > > > 10. Unmount Image: umount /mnt > > > > > > 11. Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu > > > cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I > > > can hit a key to stop automount,
Re: [U-Boot] Booting linux zImage on vexpress-a15
Hi Liviu, thank you very much for your reply. A very good hint was that I need to set the extra kernel parameter earlyprintk for showing further debug output. I expected that setting the 'Early Printk' option in Kconfig is enough. After adding this kernel parameter i can see the kernel boot messages, but the kernel stucks now at 'smp: Bringing up secondary CPUs ...'. As a cross-check I booted the kernel directly on the qemu vexpress machine and there are also error messages at the SMP step shown, but the boot process continues. In the running system I can only see one CPU, so SMP does not work at all. So I disabled all CPUs expect the first one in the device tree, so my boot procedure in u-boot is as following: 1. Set boot args: setenv bootargs console=ttyAMA0 earlyprintk debug verbose 2. Load the zImage at start of RAM + 8000h offset: ext4load mmc 0:1 80008000 zImage 3. Load Device Tree: ext4load mmc 0:1 8a00 vexpress-v2p-ca15-tc1.dtb 4. Init fdt subsystem: fdt addr 8a00 5. Deactivate second CPU: fdt rm /cpus/cpu@1 6. Boot with bootz command: bootz 80008000 - 8a00 7. In the SMP boot step only one CPU it recognized, the boot process continues 8. Now the boot process stucks at 'DMA: preallocated 256 KiB pool for atomic coherent allocations' Further I found that: 1. The space between kernel loadaddr and DTB load address of 2ff8000h Bytes (about 50MB) was big enough, since there is no difference if I use the old (8500h) or the new DTB loadaddr (8a00h). Just for being on the sure site I continue using 8a00 for DTB load address 2. All vexpress DTBs contain a ARM HBI number with seems to be a identificator for the ARM board. The ARM HBI of vexpress-v2p-ca15-tc1.dtb fits the expected ARM HBI of the qemu vexpress-a15, the vexpress-v2p-ca15_a7.dtb fits not. So I keep using the vexpress-v2p-ca15-tc1.dtb device tree 3. I recompiled the vexpress-v2p-ca15-tc1.dtb device tree without the /cpus/cpu@1 and let it run directly by qemu. The boot process succeeds. The next message after 'DMA: preallocated 256 KiB pool for atomic coherent allocations' is in this case 'cpuidle: using governor ladder' 4. I didn't mentioned the versions I'm using: It's qemu version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.8), Linux version 5.0.0-rc5 and U-Boot version 2019.01-00523-ge5fd39c886. I'm aware that these are development versions. At this point I assume that kernel and DTB are loaded correctly, but I haven't any idea what influence u-boot can have initializing DMA and/or cpuidle. Any suggestions? P.S. I will continue testing other stable vanilla kernels. P.S. I attached the boot logs: The file boot_qemu_only is the successful boot with qemu only via kernel and dtb option, the file boot_qemu_uboot is the boot with qemu + u-boot. Thanks for your help. Greetings, André On 06.02.19 17:58, Liviu Dudau wrote: On Tue, Feb 05, 2019 at 07:05:55PM +0100, Andre Wagner wrote: Hi @all, Hi Andre, I'm trying to build a linux kernel as zImage and boot it with u-boot on a qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04. What I tried until now: 1. Get Linux from git, export ARCH=arm and CROSS_COMPILE=arm-linux-gnueabihf- 2. Make Defconfig: make vexpress_defconfig 3. Enable 'Early Printk' with make menuconfig 4. Make Kernel: make 5. Get U-Boot from git, export ARCH=arm and CROSS_COMPILE=arm-linux-gnueabihf- 6. Make Defconfig: make vexpress_ca15_tc2_defconfig 7. Make U-Boot: make 8. Generate empty image file and mount it: truncate -s 100M image; mkfs.ext4 image; mount -o loop image /mnt 9. Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt 10. Unmount Image: umount /mnt 11. Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I can hit a key to stop automount, ok so far 12. In u-boot, checking filesystem on image: ext4ls mmc 0:0 => I can see my zImage and my DTB file, ok so far 13. In u-boot, loading kernel: ext4load mmc 0:0 82008000 zImage => bytes read is shown, ok so far 14. In u-boot, loading DTB: ext4load mmc 0:0 8500 vexpress-v2p-ca15_a7.dtb => bytes read, ok so far 15. In u-boot, boot: bootz 82008000 - 8500 => 'Starting kernel ' and 'Uncompressing kernel done' is shown and then nothing at all... I think your problem is that you're putting the device tree too close to the kernel, so it might be trampled on by the kernel decompression. Steps I suggest you try that worked in my environment: 1. set the bootargs variable in U-Boot to 'console=ttyAMA0 earlyprintk debug verbose' 2. Load the kernel at 0x80008000 Cross-checks I have done right now: - Booting kernel and DTB directly from qemu with 'qemu-system-arm -m 1024M -M vexpress-a15 -cpu cortex-a15 -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -serial stdio' works,
Re: [U-Boot] [PATCH v4 00/20] SF: Migrate to Linux SPI NOR framework
On Tue, Feb 5, 2019 at 11:29 AM Vignesh R wrote: > > Here is the v4 of SPI NOR migration(github branch at [1]) with minor > cleanups > > Travis ci report: > https://travis-ci.org/r-vignesh/u-boot/builds/488868207 > > Change log: > Since v3: > Rebase on to the latest u-boot/master > Drop MODULE_LICENSE, EXPORT_SYMBOL_GPL macros > Make SPI_FLASH_BAR default for ZYNQ_QSPI as suggested by Jagan. > > Since v2: > Split sync up patches into smaller versions so that its easier for review. > Address comments by Jagan and Simon Goldschmidt on v2. > Make SPI_FLASH_TINY(read only SF stack) as default for SPL build to > offset against size increase due to new code. > > Since v1: > Remove #ifindef __UBOOT__ > Add back BAR support, but dont enable as default for all platform (see > 10/11 for more details) > Enable SPI_FLASH_TINY on boards where there is SPL size constraint as > seen on travis ci builds. > Drop sf_mtd changes for now as it seems to cause issues. > v1: https://patchwork.ozlabs.org/cover/1012146/ > > Since RFC v2: > Fix issues reported by Simon Goldschmidt wrt 4 use of byte addressing opcode > Fix issues in compiling SFDP code > Re organize file names and Makefile to simply spi-nor-tiny inclusion > Remove SPI_FLASH_BAR and SF_DUAL_FLASH as these are no longer used > RFC v2: https://patchwork.ozlabs.org/cover/1007589/ > > Since RFC v1: > Add lightweight SPI flash stack for boards with SPL size constraints > Provide non DM version of spi-mem > Fix build issues on different platforms as reported by travis-ci on v1 > > RFC v1: https://patchwork.ozlabs.org/cover/1004689/ > > Background: > > U-Boot SPI NOR support (sf layer) is quite outdated as it does not > support 4 byte addressing opcodes, SFDP table parsing and different types of > quad mode enable sequences. Many newer flashes no longer support BANK > registers used by sf layer to a access >16MB space. > Also, many SPI controllers have special MMIO interfaces which provide > accelerated read/write access but require knowledge of flash parameters > to make use of it. Recent spi-mem layer provides a way to support such > flashes but sf layer isn't using that. > This patch series syncs SPI NOR framework from Linux v4.19. It also adds > spi-mem support on top. > So, we gain 4byte addressing support and SFDP support. This makes > migrating to U-Boot MTD framework easier. > > Tested with few Spansion, micron and macronix flashes with TI's dra7xx, > k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, > I would greatly appreciate testing on other platforms. Complete series > with dependencies here[1] > > [1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v4 > > Vignesh R (20): > configs: Move CONFIG_SPI_FLASH into defconfigs > bitops: Fix GENMASK definition for Sandbox > spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes > spi: spi-mem: Extend spi_mem_adjust_op_size() to honor max xfer size > spi: spi-mem: Claim SPI bus before spi mem access > spi: Add non DM version of SPI_MEM > sh: bitops: add hweight*() macros > mtd: spi: Port SPI NOR framework from Linux > mtd: spi: spi-nor-core: Add SPI MEM support > mtd: spi: spi-nor-core: Add 4 Byte addressing support > mtd: spi: spi-nor-core: Add SFDP support > mtd: spi: spi-nor-core: Add back U-Boot specific features > mtd: spi: sf_probe: Add "jedec,spi-nor" compatible string > mtd: spi: Switch to new SPI NOR framework > mtd: spi: Remove unused files > mtd: spi: Add lightweight SPI flash stack for SPL > spl: Kconfig: Enable SPI_FLASH_TINY by default for SPL > configs: Remove SF_DUAL_FLASH > configs: Don't use SPI_FLASH_BAR as default > MAINTAINERS: Add an entry for SPI NOR Update trivial change on this patch. Applied to u-boot-spi/master, thanks for the big changes and welcome aboard! Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/5] spi-flash: switch to "jedec, spi-nor" binding
On Tue, Jan 15, 2019 at 6:29 PM Neil Armstrong wrote: > > There is no reason not to use the Linux "jedec,spi-nor" binding in u-boot. > This patchset : > - adds this compatible into sf_probe and will avoid changing the > device tree files to add a u-boot specific compatible to probe a spi flash. > - switches all DTS/DTSI files to "jedec,spi-nor" > - remove the "spi-flash" compatible from sf-probe > - switch GENERIC_SPI_FLASH to jedec,spi-nor in fdtdec > - switches dt bindings examples files to "jedec,spi-nor" > > Changes since v2: > - collected tags > - extracted x86 dts changed and merged it with the fdtdec change > - updated for new boards > > Neil Armstrong (5): > mtd: sf_probe: add jedec,spi-nor compatible > dts: switch spi-flash to jedec,spi-nor compatible > x86: dts: switch spi-flash to jedec,spi-nor compatible > mtd: sf_probe: remove spi-flash compatible > doc: device-tree-bindings: switch from spi-flash to jedec,spi-nor Reviewed-by: Jagan Teki Please send v4 on top of u-boot-spi/master and skip the 1/5 (picked this from Vignesh series) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] elf: fix cache flushing in 'bootelf -p' command
Currently there are two problems in 'bootelf -p' (load elf by segments) command: - bss section is not flushed, so booted elf can have non zero values in bss; - at least on ARM there are 'CACHE: Misaligned operation at range...' warnings Use p_memsz instead of p_filesz during cache flushing for elf segment. p_filesz doesn't include zero initialized memory (e.g. bss section), which also should be flushed. Align these cache flushes to line boundaries. Signed-off-by: Kurban Mallachiev --- cmd/elf.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/cmd/elf.c b/cmd/elf.c index 7bad1f80d4..d883be4193 100644 --- a/cmd/elf.c +++ b/cmd/elf.c @@ -53,7 +53,8 @@ static unsigned long load_elf64_image_phdr(unsigned long addr) if (phdr->p_filesz != phdr->p_memsz) memset(dst + phdr->p_filesz, 0x00, phdr->p_memsz - phdr->p_filesz); - flush_cache((unsigned long)dst, phdr->p_filesz); + flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN), + roundup(phdr->p_memsz, ARCH_DMA_MINALIGN)); ++phdr; } @@ -167,7 +168,8 @@ static unsigned long load_elf_image_phdr(unsigned long addr) if (phdr->p_filesz != phdr->p_memsz) memset(dst + phdr->p_filesz, 0x00, phdr->p_memsz - phdr->p_filesz); - flush_cache((unsigned long)dst, phdr->p_filesz); + flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN), + roundup(phdr->p_memsz, ARCH_DMA_MINALIGN)); ++phdr; } -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Kconfig: fix BUILD_TARGET for ARCH_MVEBU
Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made the
mvebu default build target depend on CONFIG_SPL_BUILD. Unfortunately,
there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead to
fix that.
Cc: Jagan Teki
Signed-off-by: Baruch Siach
---
Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Kconfig b/Kconfig
index 2a48f5325663..512c7beb89f9 100644
--- a/Kconfig
+++ b/Kconfig
@@ -227,7 +227,7 @@ config BUILD_ROM
config BUILD_TARGET
string "Build target special images"
default "u-boot-with-spl.sfp" if ARCH_SOCFPGA
- default "u-boot-spl.kwb" if ARCH_MVEBU && SPL_BUILD
+ default "u-boot-spl.kwb" if ARCH_MVEBU && SPL
default "u-boot-elf.srec" if RCAR_GEN3
default "u-boot.itb" if SPL_LOAD_FIT && ARCH_SUNXI
default "u-boot.kwb" if KIRKWOOD
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/15] SiFive FU540 Support
> -Original Message-
> From: Anup Patel
> Sent: Tuesday, February 5, 2019 6:34 PM
> To: Rick Chen ; Bin Meng ;
> Joe Hershberger ; Michal Simek
> ; Michal Simek ; Lukas Auer
> ; Masahiro Yamada
> ; Simon Glass
> Cc: Alexander Graf ; Palmer Dabbelt ;
> Paul Walmsley ; Atish Patra
> ; Anup Patel ; Christoph
> Hellwig ; U-Boot Mailing List
> Subject: [PATCH v5 00/15] SiFive FU540 Support
>
> This patchset adds SiFive Freedom Unleashed (FU540) support to RISC-V U-
> Boot.
>
> The patches are based upon latest RISC-V U-Boot tree
> (git://git.denx.de/u-boot-riscv.git) at commit id
> 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
>
> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance MACB Ethernet
> work fine on actual SiFive Unleashed board and QEMU sifive_u machine.
>
> Changes since v4:
> - Removed #ifndef from macb_enable_clk() in PATCH7
> - Updated test/dm/clk.c in PATCH10 to test fixed factor clock
>using sandbox
>
> Changes since v3:
> - Added patch to un-ignore arch/riscv/include/asm/arch
> - Added patch to fix mrproper make target to only remove
>arch/*/include/asm/arch paths which are symlinks
> - Added patch to have place-holder asm/arch/clk.h for RISC-V
> - Removed "#ifndef CONFIG_RISCV" from macb clk API patch
>
> Changes since v2:
> - Fixed typo in PATCH3 comments
> - Removed "#if" from clk_fixed_factor_ofdata_to_platdata() in PATCH7
> - Added PATCH12 for SiFive FU540 README guide
>
> Changes since v1:
> - Re-ordered SoB in patches with multiple SoB
> - Simplified board_get_usable_ram_top() added by PATCH3
>
> Anup Patel (10):
> .gitignore: Don't ignore arch/riscv/include/asm/arch
> Makefile: Fix mrproper make target
> riscv: Rename cpu/qemu to cpu/generic
> riscv: Add asm/dma-mapping.h for DMA mappings
> riscv: Add place-holder asm/arch/clk.h for driver compilation
> riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems
> net: macb: Fix clk API usage for RISC-V systems
> clk: Add SiFive FU540 PRCI clock driver
> clk: Add fixed-factor clock driver
> riscv: Add SiFive FU540 board support
>
> Atish Patra (5):
> net: macb: Fix GEM hardware detection
> drivers: serial_sifive: Fix baud rate calculation
> drivers: serial_sifive: Skip baudrate config if no input clock
> cpu: Bind timer driver for boot hart
> doc: Add a readme guide for SiFive FU540
>
> Makefile | 2 +-
> arch/.gitignore | 1 +
> arch/riscv/Kconfig| 6 +-
> arch/riscv/cpu/{qemu => generic}/Kconfig | 2 +-
> arch/riscv/cpu/{qemu => generic}/Makefile | 0
> arch/riscv/cpu/{qemu => generic}/cpu.c| 0
> arch/riscv/cpu/generic/dram.c | 37 ++
> arch/riscv/cpu/qemu/dram.c| 17 -
> arch/riscv/include/asm/arch/clk.h | 14 +
> arch/riscv/include/asm/dma-mapping.h | 38 ++
> arch/sandbox/dts/test.dts | 8 +
> board/emulation/qemu-riscv/Kconfig| 4 +-
> .../qemu-riscv => sifive/fu540}/Kconfig | 36 +-
> board/sifive/fu540/MAINTAINERS| 9 +
> board/sifive/fu540/Makefile | 5 +
> board/sifive/fu540/fu540.c| 17 +
> configs/sifive_fu540_defconfig| 11 +
> doc/README.sifive-fu540 | 302 +
> drivers/clk/Kconfig | 1 +
> drivers/clk/Makefile | 5 +-
> drivers/clk/clk_fixed_factor.c| 72 +++
> drivers/clk/sifive/Kconfig| 19 +
> drivers/clk/sifive/Makefile | 5 +
> .../clk/sifive/analogbits-wrpll-cln28hpc.h| 101 +++
> drivers/clk/sifive/fu540-prci.c | 604 ++
> drivers/clk/sifive/wrpll-cln28hpc.c | 390 +++
> drivers/cpu/riscv_cpu.c | 7 +-
> drivers/net/macb.c| 11 +-
> drivers/serial/serial_sifive.c| 60 +-
> include/configs/sifive-fu540.h| 43 ++
> include/dt-bindings/clk/sifive-fu540-prci.h | 29 +
> test/dm/clk.c | 5 +-
> 32 files changed, 1794 insertions(+), 67 deletions(-) rename
> arch/riscv/cpu/{qemu => generic}/Kconfig (91%) rename
> arch/riscv/cpu/{qemu => generic}/Makefile (100%) rename
> arch/riscv/cpu/{qemu => generic}/cpu.c (100%) create mode 100644
> arch/riscv/cpu/generic/dram.c delete mode 100644
> arch/riscv/cpu/qemu/dram.c create mode 100644
> arch/riscv/include/asm/arch/clk.h create mode 100644
> arch/riscv/include/asm/dma-mapping.h
> copy board/{emulation/qemu-riscv => sifive/fu540}/Kconfig (57%) create
> mode 100644 board/sifive/fu540/MAINTAINERS create mode 100644
> board/sifive/fu540/Makefile create mode 100644 board/sifive/fu540/fu540.c
> create mode 100644 configs/sifive_fu540_defconfig create mode 100644
>
Re: [U-Boot] [PATCH v3 04/22] vybrid: clock: Provide enable_i2c_clk() function for Vybrid
On 03.02.2019 00:02, Lukasz Majewski wrote:
> Provide function to enable I2C clocks for vf610 - in the generic code.
> This function overrides the default weak function implementation (which
> only returns 1).
>
> Signed-off-by: Lukasz Majewski
Reviewed-by: Stefan Agner
--
Stefan
>
> ---
>
> Changes in v3:
> - Add code to enable I2C0 code as suggested by Stefan (so the code can be
> reused by other boards without regressions)
> - Exclude the pcm052.c related code to a separate patch
>
> Changes in v2: None
>
> arch/arm/cpu/armv7/vf610/generic.c | 22 ++
> arch/arm/include/asm/arch-vf610/clock.h | 3 +++
> 2 files changed, 25 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/vf610/generic.c
> b/arch/arm/cpu/armv7/vf610/generic.c
> index cbd3391918..e0c0b1bcb0 100644
> --- a/arch/arm/cpu/armv7/vf610/generic.c
> +++ b/arch/arm/cpu/armv7/vf610/generic.c
> @@ -375,3 +375,25 @@ void enable_caches(void)
> mmu_set_region_dcache_behaviour(IRAM_BASE_ADDR, IRAM_SIZE, option);
> }
> #endif
> +
> +#ifdef CONFIG_SYS_I2C_MXC
> +/* i2c_num can be from 0 - 3 */
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
> +{
> + struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
> +
> + switch (i2c_num) {
> + case 0:
> + clrsetbits_le32(>ccgr4, CCM_CCGR4_I2C0_CTRL_MASK,
> + CCM_CCGR4_I2C0_CTRL_MASK);
> + case 2:
> + clrsetbits_le32(>ccgr10, CCM_CCGR10_I2C2_CTRL_MASK,
> + CCM_CCGR10_I2C2_CTRL_MASK);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +#endif
> diff --git a/arch/arm/include/asm/arch-vf610/clock.h
> b/arch/arm/include/asm/arch-vf610/clock.h
> index 3bd73a01f3..72184fd608 100644
> --- a/arch/arm/include/asm/arch-vf610/clock.h
> +++ b/arch/arm/include/asm/arch-vf610/clock.h
> @@ -22,6 +22,9 @@ enum mxc_clock {
> void enable_ocotp_clk(unsigned char enable);
> unsigned int mxc_get_clock(enum mxc_clock clk);
> u32 get_lpuart_clk(void);
> +#ifdef CONFIG_SYS_I2C_MXC
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num);
> +#endif
>
> #define imx_get_fecclk() mxc_get_clock(MXC_FEC_CLK)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
