Re: [yocto] #yocto bootchooser: Cannot get state 'state'
On Wed, 2020-01-15 at 15:36 +0100, Ahmad Fatoum wrote: > Hello Hans-Ulrich, > > On 1/15/20 3:25 PM, Hans-Ulrich Schlieben wrote: > > > Can you copy the device tree snippet you use for defining state? > > > > Is there a problem because ubi works now and garbles the data in the flash? > > > > > What does running the state command say? > > > > barebox@Phytec phyCORE-i.MX6 Quad with NAND:/ state > > registered state instances: > > > > is empty in zeus, whereas thud returned: (backend: raw, path: > > /dev/eeprom0.update-eeprom) The difference between 'zeus' and 'thud' is mainly the barebox version that you get from the meta-phytec layer. We had some changes in requirements for the state node alias within the two year, but unsure if that hits you. Note that you can find the build dtb in your BSP's deploy dir. You could run fdtdump tmp/deploy/images//.dtb to dump it. Regards, Enrico > According to the state command output under thud, your state is stored > on the EEPROM, not the NAND. Look for update-eeprom in your device tree. > There should also be an /dev/eeprom0.update-eeprom in barebox. > if not, try executing the drvinfo command and see if the driver has > probed the EEPROM. > > Can you also paste the full barebox output from power-on till failure? > > Your board should boot normally with upstream barebox, I think. > Can you try and see if v2020.01.0 suffers from the same problem? > > Cheers > Ahmad > > > > > Thank you and Regards > > > > hu > > > > > > -Original Message- > > From: Ahmad Fatoum > > Sent: Wednesday, 15 January 2020 14:40 > > To: Hans-Ulrich Schlieben ; Enrico Joerns > > ; yo...@lists.yoctoproject.org > > Cc: barebox@lists.infradead.org > > Subject: Re: [yocto] #yocto bootchooser: Cannot get state 'state' > > > > On 1/15/20 2:26 PM, Hans-Ulrich Schlieben wrote: > > > Hi Enrico, > > > > > > thank you very much for your help. > > > I'm using barebox_2019.01.0-phy4-r7.0 now. In thud I used > > > barebox_2017.12.0 The image is built using my own ims layer which > > > depends on core-image-minimal LAYERDEPENDS_ims-layer = > > > "core-image-minimal openembedded-layer phytec-layer" > > > Its using the meta-phytec Layer and a custom layer from phytec named > > > meta-ksp0663. > > > Forgot to mention that rauc is used too, which moved from 1.1 to now 1.2. > > > Just changed the LAYERSERIES_COMPAT to "zeus" here to check whether yocto > > > zeus works. > > > > > > Is there some info what to change in the devicetree and so on when moving > > > to warrior/zeus? > > > In thud this worked. > > > > Are there any other error messages? > > Can you copy the device tree snippet you use for defining state? > > What does running the state command say? > > > > (now again, but with CC-list intact) > > > > > > > > Thank you > > > Regards > > > > > > hu > > > > > > > -Original Message- > > > > From: Enrico Joerns > > > > Sent: Wednesday, 15 January 2020 14:03 > > > > To: Hans-Ulrich Schlieben ; > > > > yo...@lists.yoctoproject.org > > > > Cc: barebox@lists.infradead.org > > > > Subject: Re: [yocto] #yocto bootchooser: Cannot get state 'state' > > > > > > > > Hi, > > > > > > > > this is mainly a barebox-related question, thus I'd suggest asking it > > > > on the barebox ML. > > > > > > > > [cc-ing barebox mailing list] > > > > > > > > On Wed, 2020-01-15 at 04:10 -0800, hu.schlie...@codewrights.de wrote: > > > > > Hi, > > > > > > > > > > booting the new yocto zeus system manually by "boot mmc" works fine > > > > > but default bootchooser fails with: > > > > > > > > > > bootchooser: Cannot get state 'state' > > > > > Nothing bootable found on 'bootchooser' > > > > > Nothing bootable found > > > > > > > > Looks like the state node is missing in your device tree. > > > > Which version of barebox do you use? > > > > And from which layer / recipe? > > > > > > > > > Building the "same" image in yocto thud works fine. The boot > > > > > variables > > > > > are: > > > > > > > > > > * BOOT_system0_.default: 3 >
Re: [yocto] #yocto bootchooser: Cannot get state 'state'
Hi, this is mainly a barebox-related question, thus I'd suggest asking it on the barebox ML. [cc-ing barebox mailing list] On Wed, 2020-01-15 at 04:10 -0800, hu.schlie...@codewrights.de wrote: > Hi, > > booting the new yocto zeus system manually by "boot mmc" works fine > but default bootchooser fails with: > > bootchooser: Cannot get state 'state' > Nothing bootable found on 'bootchooser' > Nothing bootable found Looks like the state node is missing in your device tree. Which version of barebox do you use? And from which layer / recipe? > Building the "same" image in yocto thud works fine. The boot > variables are: > > * BOOT_system0_.default: 3 > * BOOT_system1_.default: 3 > * allow_color: 0 > * autoboot_timeout: 3 > * boot.default: bootchooser > boot.watchdog_timeout: 0 > bootchooser.default_attempts: 3 > bootchooser.default_priority: 1 > bootchooser.disable_on_zero_attempts: 0 > bootchooser.reset_attempts: (list: "power-on", "all-zero") > bootchooser.reset_priorities: > bootchooser.retry: 0 > * bootchooser.state_prefix: state.bootstate > * bootchooser.system0.boot: mmc > * bootchooser.system0.default_attempts: 3 > * bootchooser.system0.default_priority: 20 > * bootchooser.system1.boot: mmc1 > * bootchooser.system1.default_attempts: 3 > * bootchooser.system1.default_priority: 21 > * bootchooser.targets: system0 system1 > bootm.appendroot: 0 > ... > Regards, Enrico ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] nand: denali: remove undefined GFP_DMA flag
On 11/14/18 11:55 PM, Andrey Smirnov wrote: On Wed, Nov 14, 2018 at 7:15 AM Enrico Jorns wrote: This was a remnant from porting kernel code to barebox. While being uncritical so far, this will now cause a compiler error since kzalloc is not a define but a static inline function. As the kzalloc() 'mode' argument was ignored before and still will be, it is safe to remove the parameter. Signed-off-by: Enrico Jorns --- drivers/mtd/nand/nand_denali.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_denali.c b/drivers/mtd/nand/nand_denali.c index 8b09b3722f..ef3395864c 100644 --- a/drivers/mtd/nand/nand_denali.c +++ b/drivers/mtd/nand/nand_denali.c @@ -1387,7 +1387,7 @@ int denali_init(struct denali_nand_info *denali) } /* allocate a temporary buffer for nand_scan_ident() */ - denali->buf.buf = kzalloc(PAGE_SIZE, GFP_DMA | GFP_KERNEL); + denali->buf.buf = kzalloc(PAGE_SIZE, GFP_KERNEL); if (!denali->buf.buf) return -ENOMEM; Just as a suggestion, maybe just replace this call with xzalloc, getting rid of meaningless GFP_KERNEL as well, and dropping the OOM check below? Since kzalloc() is not a macro to xzalloc() anymore but uses calloc() instead, which actually may return NULL, I am not sure if this is a better approach. But I am not that deep into the topic of differences between *alloc calls to definitely decide that. Regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/5] commands: nv: argc cannot be < 1
On 09/14/2017 08:27 AM, Sascha Hauer wrote: On Wed, Sep 13, 2017 at 02:23:28PM +0200, Enrico Jorns wrote: argc == 1 will only contain the name of the program itself which must be present when invoking nv command code. This reasoning is not quite right. You miss the argc -= optind above the argc < 1 test. In fact in patch 4/5 you re-add the same test again (written as argc == 0 this time). Shouldn't this patch simply be merged with 4/5? In fact, you're right. Seems as if I splitted up changes a bit too much and confused myself. Merging it with 4/5 sound more reasonable (or simply drop both of them). Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 4/5] Add filetype and detection for squashfs images
Hi Yegor, On 10/06/2016 03:55 PM, Yegor Yefremov wrote: On Tue, Oct 4, 2016 at 12:10 PM, Enrico Jornswrote: This adds `filetype_squashfs` to the list of known filetypes and adds a detection for squashfs files to file_detect_type(). This currently matches on the `hsqs` start sequence of an image file. Additionally, the newly introduced filetype is registered as the type of the squashfs_driver which allows, for example, to mount squashfs without the need to specify a type parameter. This changes enable booting a squashfs with the simple `boot` command pointing to the location (device) that holds the squashfs. Note that booting with blspec is limited as the current squashfs driver is not capable of handling symbolic links. Glad to see SquashFS will be used not only by myself :-) glad to see that, too ;) Could you explain how one can write a rootfs.sqaushfs to a ubiblock from Linux and then what steps are needed in barebox? So far I've only found this info about ubiblock: http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock, but it doesn't say much. Yes, the informations provided are a bit sparse.. My actions were: ubiattach -p /dev/mtd5 ubiblock --create /dev/ubi0_0 ubiupdatevol /dev/ubi0_0 rootfs.squashfs Can I mount /dev/ubi0_0 via mount? If yes, what parameters I should use? The above commands look pretty similar to what I did. Mounting the ubiblock device does work too, with a little pitfall, mount will be confused by having a read-only file system but nobody told it before. So you must do mount -o ro /dev/ubiblock0_0 /mnt/test How can I mount this volume in barebox step-by-step? Using it in barebox is pretty easy, as the ubiblock layer is not required there: ubiattach /dev/nand0.root ubiupdatevol /dev/nand0.root.ubi.ubivolname rootfs.squashfs mkdir /mnt/test mount /dev/nand0.root.ubi.ubivolname /mnt/test To boot via bootspec form a ubi containing a squashfs, you simply need to boot /dev/nand0.root.ubi.ubivolname Hope that helps. Best regards, Enrico -- Pengutronix e.K. | Enrico Jörns| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/2] ARM: i.MX: Add i.MX5 debug functions
On 07/08/2015 02:18 PM, Sascha Hauer wrote: We recently introduced ungate_all_peripherals and SoC specific low level UART init functions. Add some more for i.MX5 SoCs. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de --- arch/arm/mach-imx/include/mach/debug_ll.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/mach-imx/include/mach/debug_ll.h b/arch/arm/mach-imx/include/mach/debug_ll.h index ab939b3..f2f4768 100644 --- a/arch/arm/mach-imx/include/mach/debug_ll.h +++ b/arch/arm/mach-imx/include/mach/debug_ll.h @@ -75,6 +75,11 @@ static inline void imx51_uart_setup_ll(void) __imx_uart_setup_ll(5400); } +static inline void imx53_uart_setup_ll(void) +{ + __imx_uart_setup_ll(); +} + Currently, the patch does not compile when CONFIG_DEBUG_LL is unset. Seems you forgot to add this line to your patch: From b0135fa957a0ebe053349f4442b20006ba5509bf Mon Sep 17 00:00:00 2001 From: Enrico Jorns e...@pengutronix.de Date: Wed, 8 Jul 2015 15:29:02 +0200 Subject: [PATCH] fixup! ARM: i.MX: Add i.MX5 debug functions --- arch/arm/mach-imx/include/mach/debug_ll.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-imx/include/mach/debug_ll.h b/arch/arm/mach-imx/include/mach/debug_ll.h index f2f4768..eceac40 100644 --- a/arch/arm/mach-imx/include/mach/debug_ll.h +++ b/arch/arm/mach-imx/include/mach/debug_ll.h @@ -108,6 +108,7 @@ static inline void imx_uart_setup_ll(void __iomem *uartbase, } static inline void imx51_uart_setup_ll(void) {} +static inline void imx53_uart_setup_ll(void) {} static inline void imx6_uart_setup_ll(void) {} #endif /* CONFIG_DEBUG_LL */ -- 2.1.4 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox