[U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT

[U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

ENOLINK is not required by POSIX and does not exist on OpenBSD
and likely other systems.

Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
---
 common/image-fit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index d8d4e95..79c0375 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1566,7 +1566,7 @@ int fit_get_node_from_config(bootm_headers_t *images, const char *prop_name,
 	noffset = fit_conf_get_prop_node(fit_hdr, cfg_noffset, prop_name);
 	if (noffset < 0) {
 		debug("*  %s: no '%s' in config\n", prop_name, prop_name);
-		return -ENOLINK;
+		return -ENOENT;
 	}
 
 	return noffset;
-- 
2.9.3

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Tom Rini]

On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:

> ENOLINK is not required by POSIX and does not exist on OpenBSD
> and likely other systems.
> 
> Signed-off-by: Jonathan Gray <jsg@jsg.id.au>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160907/23b36bc2/attachment.sig>

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> 
> > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > and likely other systems.
> > 
> > Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> 
> Applied to u-boot/master, thanks!

Thanks for applying this and the other patch.

In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
aren't on OpenBSD either.

They are in POSIX however so I am trying to get them into OpenBSD,
but it will need some time to be scheduled as introducing errnos
involves cranking the major version of libc due to the size of the array
with errno strings changing.

I wasn't sure if the following would be accepted for that reason,
thoughts?

FreeBSD and NetBSD seems to have definitions for both already.

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 26b3949..9b50b32 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -402,13 +402,13 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block)
 		rc = 0;
 		break;
 	case NAK:
-		errno = EBADMSG;
+		errno = ECONNREFUSED;
 		break;
 	case CAN:
 		errno = ECANCELED;
 		break;
 	default:
-		errno = EPROTO;
+		errno = EIO;
 		break;
 	}
 

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Tom Rini]

On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > 
> > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > and likely other systems.
> > > 
> > > Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> > 
> > Applied to u-boot/master, thanks!
> 
> Thanks for applying this and the other patch.
> 
> In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> aren't on OpenBSD either.
> 
> They are in POSIX however so I am trying to get them into OpenBSD,
> but it will need some time to be scheduled as introducing errnos
> involves cranking the major version of libc due to the size of the array
> with errno strings changing.
> 
> I wasn't sure if the following would be accepted for that reason,
> thoughts?

Well, looking over the code in question, we're talking about error
handling during xmodem transfers.  What are the errno values that get
used there by xmodem tools?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160908/fe02e622/attachment.sig>

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > 
> > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > and likely other systems.
> > > > 
> > > > Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> > > 
> > > Applied to u-boot/master, thanks!
> > 
> > Thanks for applying this and the other patch.
> > 
> > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > aren't on OpenBSD either.
> > 
> > They are in POSIX however so I am trying to get them into OpenBSD,
> > but it will need some time to be scheduled as introducing errnos
> > involves cranking the major version of libc due to the size of the array
> > with errno strings changing.
> > 
> > I wasn't sure if the following would be accepted for that reason,
> > thoughts?
> 
> Well, looking over the code in question, we're talking about error
> handling during xmodem transfers.  What are the errno values that get
> used there by xmodem tools?  Thanks!

I don't see how xmodem tools would use those errno values themselves?
From what I understood, kwboot attaches directly to serial /dev devices
and handles xmodem and terminal emulation itself.

In the kwboot case nothing in the return path seems to check for
specific errno values.  The return sequence looks like

kwboot_xm_sendblock
kwboot_xmodem
main
perror("xmodem");

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Tom Rini]

On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > 
> > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > and likely other systems.
> > > > > 
> > > > > Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> > > > 
> > > > Applied to u-boot/master, thanks!
> > > 
> > > Thanks for applying this and the other patch.
> > > 
> > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > > aren't on OpenBSD either.
> > > 
> > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > but it will need some time to be scheduled as introducing errnos
> > > involves cranking the major version of libc due to the size of the array
> > > with errno strings changing.
> > > 
> > > I wasn't sure if the following would be accepted for that reason,
> > > thoughts?
> > 
> > Well, looking over the code in question, we're talking about error
> > handling during xmodem transfers.  What are the errno values that get
> > used there by xmodem tools?  Thanks!
> 
> I don't see how xmodem tools would use those errno values themselves?
> From what I understood, kwboot attaches directly to serial /dev devices
> and handles xmodem and terminal emulation itself.
> 
> In the kwboot case nothing in the return path seems to check for
> specific errno values.  The return sequence looks like
> 
> kwboot_xm_sendblock
> kwboot_xmodem
> main
> perror("xmodem");

Right.  But we're also using it to indicate to the caller that there was
a problem.  I can see using EIO for unknown error but I don't like
ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
around in other tools when you get a NAK reply in xmodem?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160908/3ae54e41/attachment.sig>

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Thu, Sep 08, 2016 at 09:15:45AM -0400, Tom Rini wrote:
> On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> > On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > > 
> > > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > > and likely other systems.
> > > > > > 
> > > > > > Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> > > > > 
> > > > > Applied to u-boot/master, thanks!
> > > > 
> > > > Thanks for applying this and the other patch.
> > > > 
> > > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > > > aren't on OpenBSD either.
> > > > 
> > > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > > but it will need some time to be scheduled as introducing errnos
> > > > involves cranking the major version of libc due to the size of the array
> > > > with errno strings changing.
> > > > 
> > > > I wasn't sure if the following would be accepted for that reason,
> > > > thoughts?
> > > 
> > > Well, looking over the code in question, we're talking about error
> > > handling during xmodem transfers.  What are the errno values that get
> > > used there by xmodem tools?  Thanks!
> > 
> > I don't see how xmodem tools would use those errno values themselves?
> > From what I understood, kwboot attaches directly to serial /dev devices
> > and handles xmodem and terminal emulation itself.
> > 
> > In the kwboot case nothing in the return path seems to check for
> > specific errno values.  The return sequence looks like
> > 
> > kwboot_xm_sendblock
> > kwboot_xmodem
> > main
> > perror("xmodem");
> 
> Right.  But we're also using it to indicate to the caller that there was
> a problem.  I can see using EIO for unknown error but I don't like
> ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
> around in other tools when you get a NAK reply in xmodem?

I haven't found any that display an errno based string

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/cu/xmodem.c?rev=HEAD&content-type=text/plain

lrzsz src/lsz.c
zperr(_("NAK on sector")); (prints to stderr non-fatally without errno)

kermit code seems to be quite hard to follow...

The list of errnos currently implemented on OpenBSD can be found here:
http://man.openbsd.org/OpenBSD-current/man2/intro.2

The strings perror/strerror(errno) use can be found here
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/errlist.c?rev=HEAD&content-type=text/plain
And in the above manual page.

ENOMSG "No message of desired type." might work

Though it is documented as

"An IPC message queue does not contain a message of the desired type,
or a message catalog does not contain the requested message."

on OpenBSD and in POSIX as

"No message of the desired type. The message queue does not contain a
message of the required type during XSI interprocess communication."

Neither EBADMSG or ENOMSG appear to be documented in glibc beyond
mentioning that they are valid values?

https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Tom Rini]

On Thu, Sep 08, 2016 at 11:53:48PM +1000, Jonathan Gray wrote:
> On Thu, Sep 08, 2016 at 09:15:45AM -0400, Tom Rini wrote:
> > On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> > > On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > > > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > > > 
> > > > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > > > and likely other systems.
> > > > > > > 
> > > > > > > Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> > > > > > 
> > > > > > Applied to u-boot/master, thanks!
> > > > > 
> > > > > Thanks for applying this and the other patch.
> > > > > 
> > > > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > > > > aren't on OpenBSD either.
> > > > > 
> > > > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > > > but it will need some time to be scheduled as introducing errnos
> > > > > involves cranking the major version of libc due to the size of the array
> > > > > with errno strings changing.
> > > > > 
> > > > > I wasn't sure if the following would be accepted for that reason,
> > > > > thoughts?
> > > > 
> > > > Well, looking over the code in question, we're talking about error
> > > > handling during xmodem transfers.  What are the errno values that get
> > > > used there by xmodem tools?  Thanks!
> > > 
> > > I don't see how xmodem tools would use those errno values themselves?
> > > From what I understood, kwboot attaches directly to serial /dev devices
> > > and handles xmodem and terminal emulation itself.
> > > 
> > > In the kwboot case nothing in the return path seems to check for
> > > specific errno values.  The return sequence looks like
> > > 
> > > kwboot_xm_sendblock
> > > kwboot_xmodem
> > > main
> > > perror("xmodem");
> > 
> > Right.  But we're also using it to indicate to the caller that there was
> > a problem.  I can see using EIO for unknown error but I don't like
> > ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
> > around in other tools when you get a NAK reply in xmodem?
> 
> I haven't found any that display an errno based string
> 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/cu/xmodem.c?rev=HEAD&content-type=text/plain
> 
> lrzsz src/lsz.c
> zperr(_("NAK on sector")); (prints to stderr non-fatally without errno)
> 
> kermit code seems to be quite hard to follow...
> 
> The list of errnos currently implemented on OpenBSD can be found here:
> http://man.openbsd.org/OpenBSD-current/man2/intro.2
> 
> The strings perror/strerror(errno) use can be found here
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/errlist.c?rev=HEAD&content-type=text/plain
> And in the above manual page.
> 
> ENOMSG "No message of desired type." might work
> 
> Though it is documented as
> 
> "An IPC message queue does not contain a message of the desired type,
> or a message catalog does not contain the requested message."
> 
> on OpenBSD and in POSIX as
> 
> "No message of the desired type. The message queue does not contain a
> message of the required type during XSI interprocess communication."
> 
> Neither EBADMSG or ENOMSG appear to be documented in glibc beyond
> mentioning that they are valid values?
> 
> https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html

EBADMSG and ENOMSG just fall back to POSIX.1.  Is it really hard to
carry a patch to U-Boot in OpenBSD until the libc can be updated for
some POSIX errno values?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160908/57b989a2/attachment.sig>

[U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Thu, Sep 08, 2016 at 11:17:12AM -0400, Tom Rini wrote:
> On Thu, Sep 08, 2016 at 11:53:48PM +1000, Jonathan Gray wrote:
> > On Thu, Sep 08, 2016 at 09:15:45AM -0400, Tom Rini wrote:
> > > On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> > > > On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > > > > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > > > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > > > > 
> > > > > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > > > > and likely other systems.
> > > > > > > > 
> > > > > > > > Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> > > > > > > 
> > > > > > > Applied to u-boot/master, thanks!
> > > > > > 
> > > > > > Thanks for applying this and the other patch.
> > > > > > 
> > > > > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > > > > > aren't on OpenBSD either.
> > > > > > 
> > > > > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > > > > but it will need some time to be scheduled as introducing errnos
> > > > > > involves cranking the major version of libc due to the size of the array
> > > > > > with errno strings changing.
> > > > > > 
> > > > > > I wasn't sure if the following would be accepted for that reason,
> > > > > > thoughts?
> > > > > 
> > > > > Well, looking over the code in question, we're talking about error
> > > > > handling during xmodem transfers.  What are the errno values that get
> > > > > used there by xmodem tools?  Thanks!
> > > > 
> > > > I don't see how xmodem tools would use those errno values themselves?
> > > > From what I understood, kwboot attaches directly to serial /dev devices
> > > > and handles xmodem and terminal emulation itself.
> > > > 
> > > > In the kwboot case nothing in the return path seems to check for
> > > > specific errno values.  The return sequence looks like
> > > > 
> > > > kwboot_xm_sendblock
> > > > kwboot_xmodem
> > > > main
> > > > perror("xmodem");
> > > 
> > > Right.  But we're also using it to indicate to the caller that there was
> > > a problem.  I can see using EIO for unknown error but I don't like
> > > ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
> > > around in other tools when you get a NAK reply in xmodem?
> > 
> > I haven't found any that display an errno based string
> > 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/cu/xmodem.c?rev=HEAD&content-type=text/plain
> > 
> > lrzsz src/lsz.c
> > zperr(_("NAK on sector")); (prints to stderr non-fatally without errno)
> > 
> > kermit code seems to be quite hard to follow...
> > 
> > The list of errnos currently implemented on OpenBSD can be found here:
> > http://man.openbsd.org/OpenBSD-current/man2/intro.2
> > 
> > The strings perror/strerror(errno) use can be found here
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/errlist.c?rev=HEAD&content-type=text/plain
> > And in the above manual page.
> > 
> > ENOMSG "No message of desired type." might work
> > 
> > Though it is documented as
> > 
> > "An IPC message queue does not contain a message of the desired type,
> > or a message catalog does not contain the requested message."
> > 
> > on OpenBSD and in POSIX as
> > 
> > "No message of the desired type. The message queue does not contain a
> > message of the required type during XSI interprocess communication."
> > 
> > Neither EBADMSG or ENOMSG appear to be documented in glibc beyond
> > mentioning that they are valid values?
> > 
> > https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html
> 
> EBADMSG and ENOMSG just fall back to POSIX.1.  Is it really hard to
> carry a patch to U-Boot in OpenBSD until the libc can be updated for
> some POSIX errno values?

Having the patch until then is fine.

We already carry patches to convert a few targets to support
distro_bootcmd so our efi bootloader gets loaded automatically.

Mostly taken from looking at patches linux distributions have,
though some of these are marked as incomplete and I'm not clear
on which have been properly proposed on the u-boot list.

cm-fx6/utilite
http://pkgs.fedoraproject.org/cgit/rpms/uboot-tools.git/tree/port-utilite-to-distro-generic-boot-commands.patch
omap3 beagle
https://github.com/openSUSE/u-boot/commit/8ea945ff9d5f57f626167d41b1c59d9518fb60b2.patch
omap5/beagleboard x15
https://anonscm.debian.org/git/collab-maint/u-boot.git/tree/debian/patches/am57xx/omap5_distro_bootcmd?h=experimental-2016.09

others not yet used:

odroid x2/u3
https://anonscm.debian.org/git/collab-maint/u-boot.git/tree/debian/patches/odroid/0001-Convert-odroid-to-use-distro_bootcmd.patch?h=experimental-2016.09
mvebu/clearfog
http://pkgs.fedoraproject.org/cgit/rpms/uboot-tools.git/tree/mvebu-enable-generic-distro-boot-config.patch
nitrogen6x/sabre lite
http://lists.denx.de/pipermail/u-boot/2016-August/262674.html

[U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT

[Stefan Roese]

Hi Tom,
Hi Jonathan,

On 03.09.2016 00:30, Jonathan Gray wrote:
> ENOLINK is not required by POSIX and does not exist on OpenBSD
> and likely other systems.
> 
> Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> ---
>  common/image-fit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/image-fit.c b/common/image-fit.c
> index d8d4e95..79c0375 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1566,7 +1566,7 @@ int fit_get_node_from_config(bootm_headers_t *images, const char *prop_name,
>  	noffset = fit_conf_get_prop_node(fit_hdr, cfg_noffset, prop_name);
>  	if (noffset < 0) {
>  		debug("*  %s: no '%s' in config\n", prop_name, prop_name);
> -		return -ENOLINK;
> +		return -ENOENT;
>  	}
>  
>  	return noffset;
> 

This patch breaks Linux booting via FIT-image on Marvell Armada
XP for me. Here a short log with this patch applied:

## Loading kernel from FIT Image at 02000000 ...
   Using 'conf at 1' configuration
   Trying 'kernel at 1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x020000f4
     Data Size:    5065728 Bytes = 4.8 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    sha1
     Hash value:   11ddefa0b68cbc5db9d84b0fd74ec67da155fada
   Verifying Hash Integrity ... sha1+ OK
Ramdisk image is corrupt or invalid


And this is how is should look like:

## Loading kernel from FIT Image at 02000000 ...
   Using 'conf at 1' configuration
   Trying 'kernel at 1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x020000f4
     Data Size:    5065728 Bytes = 4.8 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00008000
     Entry Point:  0x00008000
     Hash algo:    sha1
     Hash value:   11ddefa0b68cbc5db9d84b0fd74ec67da155fada
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 02000000 ...
   Using 'conf at 1' configuration
   Trying 'fdt at 1' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x024d4de8
     Data Size:    16971 Bytes = 16.6 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   672f2964b334406749265f4508e2231fb54ccbf4
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x24d4de8
   Loading Kernel Image ... OK
   Loading Device Tree to 0fff8000, end 0ffff24a ... OK

Starting kernel ...


Unfortunately v2016.09 is useless with this patch - at least for me.
I really think that we should revert it and release v2016.09.01.

What do you think?

Thanks,
Stefan

[U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT

[Mario Six]

Hi Stefan,

I also see the same error on our Armada board. It stems from the fact that
boot_get_ramdisk in common/image.c treats a ENOLINK different from all other
errors (which the patch changed into a ENOENT). The following patch fixes the
problem on our board:

diff --git a/common/image.c b/common/image.c
index 7ad04ca..c8d9bc8 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1078,7 +1078,7 @@ int boot_get_ramdisk(int argc, char * const
argv[], bootm_headers_t *images,
             rd_addr = map_to_sysmem(images->fit_hdr_os);
             rd_noffset = fit_get_node_from_config(images,
                     FIT_RAMDISK_PROP, rd_addr);
-            if (rd_noffset == -ENOLINK)
+            if (rd_noffset == -ENOENT)
                 return 0;
             else if (rd_noffset < 0)
                 return 1;

So, yes, 2016.09 breaks Armada, apparently.

Best regards,

Mario

On Thu, Sep 15, 2016 at 2:49 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Tom,
> Hi Jonathan,
>
> On 03.09.2016 00:30, Jonathan Gray wrote:
>> ENOLINK is not required by POSIX and does not exist on OpenBSD
>> and likely other systems.
>>
>> Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
>> ---
>>  common/image-fit.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/common/image-fit.c b/common/image-fit.c
>> index d8d4e95..79c0375 100644
>> --- a/common/image-fit.c
>> +++ b/common/image-fit.c
>> @@ -1566,7 +1566,7 @@ int fit_get_node_from_config(bootm_headers_t *images, const char *prop_name,
>>       noffset = fit_conf_get_prop_node(fit_hdr, cfg_noffset, prop_name);
>>       if (noffset < 0) {
>>               debug("*  %s: no '%s' in config\n", prop_name, prop_name);
>> -             return -ENOLINK;
>> +             return -ENOENT;
>>       }
>>
>>       return noffset;
>>
>
> This patch breaks Linux booting via FIT-image on Marvell Armada
> XP for me. Here a short log with this patch applied:
>
> ## Loading kernel from FIT Image at 02000000 ...
>    Using 'conf at 1' configuration
>    Trying 'kernel at 1' kernel subimage
>      Description:  Linux kernel
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x020000f4
>      Data Size:    5065728 Bytes = 4.8 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x00008000
>      Entry Point:  0x00008000
>      Hash algo:    sha1
>      Hash value:   11ddefa0b68cbc5db9d84b0fd74ec67da155fada
>    Verifying Hash Integrity ... sha1+ OK
> Ramdisk image is corrupt or invalid
>
>
> And this is how is should look like:
>
> ## Loading kernel from FIT Image at 02000000 ...
>    Using 'conf at 1' configuration
>    Trying 'kernel at 1' kernel subimage
>      Description:  Linux kernel
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x020000f4
>      Data Size:    5065728 Bytes = 4.8 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x00008000
>      Entry Point:  0x00008000
>      Hash algo:    sha1
>      Hash value:   11ddefa0b68cbc5db9d84b0fd74ec67da155fada
>    Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 02000000 ...
>    Using 'conf at 1' configuration
>    Trying 'fdt at 1' fdt subimage
>      Description:  Flattened Device Tree blob
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x024d4de8
>      Data Size:    16971 Bytes = 16.6 KiB
>      Architecture: ARM
>      Hash algo:    sha1
>      Hash value:   672f2964b334406749265f4508e2231fb54ccbf4
>    Verifying Hash Integrity ... sha1+ OK
>    Booting using the fdt blob at 0x24d4de8
>    Loading Kernel Image ... OK
>    Loading Device Tree to 0fff8000, end 0ffff24a ... OK
>
> Starting kernel ...
>
>
> Unfortunately v2016.09 is useless with this patch - at least for me.
> I really think that we should revert it and release v2016.09.01.
>
> What do you think?
>
> Thanks,
> Stefan
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Thu, Sep 15, 2016 at 04:08:33PM +0200, Mario Six wrote:
> Hi Stefan,
> 
> I also see the same error on our Armada board. It stems from the fact that
> boot_get_ramdisk in common/image.c treats a ENOLINK different from all other
> errors (which the patch changed into a ENOENT). The following patch fixes the
> problem on our board:
> 
> diff --git a/common/image.c b/common/image.c
> index 7ad04ca..c8d9bc8 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1078,7 +1078,7 @@ int boot_get_ramdisk(int argc, char * const
> argv[], bootm_headers_t *images,
>              rd_addr = map_to_sysmem(images->fit_hdr_os);
>              rd_noffset = fit_get_node_from_config(images,
>                      FIT_RAMDISK_PROP, rd_addr);
> -            if (rd_noffset == -ENOLINK)
> +            if (rd_noffset == -ENOENT)
>                  return 0;
>              else if (rd_noffset < 0)
>                  return 1;
> 
> So, yes, 2016.09 breaks Armada, apparently.

The callers of the proposed/rejected kwboot.c errno diff were all
checked but the test of the result in the caller of this one
seems to have been missed indeed.

Sorry for missing this and

Reviewed-by: Jonathan Gray <jsg@jsg.id.au>

> 
> Best regards,
> 
> Mario
> 
> On Thu, Sep 15, 2016 at 2:49 PM, Stefan Roese <sr@denx.de> wrote:
> > Hi Tom,
> > Hi Jonathan,
> >
> > On 03.09.2016 00:30, Jonathan Gray wrote:
> >> ENOLINK is not required by POSIX and does not exist on OpenBSD
> >> and likely other systems.
> >>
> >> Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
> >> ---
> >>  common/image-fit.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/common/image-fit.c b/common/image-fit.c
> >> index d8d4e95..79c0375 100644
> >> --- a/common/image-fit.c
> >> +++ b/common/image-fit.c
> >> @@ -1566,7 +1566,7 @@ int fit_get_node_from_config(bootm_headers_t *images, const char *prop_name,
> >>       noffset = fit_conf_get_prop_node(fit_hdr, cfg_noffset, prop_name);
> >>       if (noffset < 0) {
> >>               debug("*  %s: no '%s' in config\n", prop_name, prop_name);
> >> -             return -ENOLINK;
> >> +             return -ENOENT;
> >>       }
> >>
> >>       return noffset;
> >>
> >
> > This patch breaks Linux booting via FIT-image on Marvell Armada
> > XP for me. Here a short log with this patch applied:
> >
> > ## Loading kernel from FIT Image at 02000000 ...
> >    Using 'conf at 1' configuration
> >    Trying 'kernel at 1' kernel subimage
> >      Description:  Linux kernel
> >      Type:         Kernel Image
> >      Compression:  uncompressed
> >      Data Start:   0x020000f4
> >      Data Size:    5065728 Bytes = 4.8 MiB
> >      Architecture: ARM
> >      OS:           Linux
> >      Load Address: 0x00008000
> >      Entry Point:  0x00008000
> >      Hash algo:    sha1
> >      Hash value:   11ddefa0b68cbc5db9d84b0fd74ec67da155fada
> >    Verifying Hash Integrity ... sha1+ OK
> > Ramdisk image is corrupt or invalid
> >
> >
> > And this is how is should look like:
> >
> > ## Loading kernel from FIT Image at 02000000 ...
> >    Using 'conf at 1' configuration
> >    Trying 'kernel at 1' kernel subimage
> >      Description:  Linux kernel
> >      Type:         Kernel Image
> >      Compression:  uncompressed
> >      Data Start:   0x020000f4
> >      Data Size:    5065728 Bytes = 4.8 MiB
> >      Architecture: ARM
> >      OS:           Linux
> >      Load Address: 0x00008000
> >      Entry Point:  0x00008000
> >      Hash algo:    sha1
> >      Hash value:   11ddefa0b68cbc5db9d84b0fd74ec67da155fada
> >    Verifying Hash Integrity ... sha1+ OK
> > ## Loading fdt from FIT Image at 02000000 ...
> >    Using 'conf at 1' configuration
> >    Trying 'fdt at 1' fdt subimage
> >      Description:  Flattened Device Tree blob
> >      Type:         Flat Device Tree
> >      Compression:  uncompressed
> >      Data Start:   0x024d4de8
> >      Data Size:    16971 Bytes = 16.6 KiB
> >      Architecture: ARM
> >      Hash algo:    sha1
> >      Hash value:   672f2964b334406749265f4508e2231fb54ccbf4
> >    Verifying Hash Integrity ... sha1+ OK
> >    Booting using the fdt blob at 0x24d4de8
> >    Loading Kernel Image ... OK
> >    Loading Device Tree to 0fff8000, end 0ffff24a ... OK
> >
> > Starting kernel ...
> >
> >
> > Unfortunately v2016.09 is useless with this patch - at least for me.
> > I really think that we should revert it and release v2016.09.01.
> >
> > What do you think?
> >
> > Thanks,
> > Stefan
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT

[Mario Six]

Hi Jonathan

On Thu, Sep 15, 2016 at 11:27 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>
> The callers of the proposed/rejected kwboot.c errno diff were all
> checked but the test of the result in the caller of this one
> seems to have been missed indeed.
>
> Sorry for missing this and
>
> Reviewed-by: Jonathan Gray <jsg@jsg.id.au>
>

The whole FIT image loading complex still is quite messy in regards to return
values and the like (I still have two patches I want to send that fix masked
and incorrect return values), so it's basically still a work-in-progress :-)

I'll send a formal patch in a few.

Best regards,

Mario