Re: [yocto] #yocto bootchooser: Cannot get state 'state'

2020-01-15 Thread Enrico Joerns
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'

2020-01-15 Thread Enrico Joerns
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

2018-11-16 Thread Enrico Joerns

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

2017-09-14 Thread Enrico Joerns

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

2016-10-06 Thread Enrico Joerns

Hi Yegor,

On 10/06/2016 03:55 PM, Yegor Yefremov wrote:

On Tue, Oct 4, 2016 at 12:10 PM, Enrico Jorns  wrote:

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

2015-07-08 Thread Enrico Joerns

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