[U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT
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;
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!
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; }
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!
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");
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?
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?...
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... 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
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?...
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... 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?
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?...
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... 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... omap3 beagle https://github.com/openSUSE/u-boot/commit/8ea945ff9d5f57f626167d41b1c59d9518... omap5/beagleboard x15 https://anonscm.debian.org/git/collab-maint/u-boot.git/tree/debian/patches/a...
others not yet used:
odroid x2/u3 https://anonscm.debian.org/git/collab-maint/u-boot.git/tree/debian/patches/o... mvebu/clearfog http://pkgs.fedoraproject.org/cgit/rpms/uboot-tools.git/tree/mvebu-enable-ge... nitrogen6x/sabre lite http://lists.denx.de/pipermail/u-boot/2016-August/262674.html
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@1' configuration Trying 'kernel@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@1' configuration Trying 'kernel@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@1' configuration Trying 'fdt@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
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@1' configuration Trying 'kernel@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@1' configuration Trying 'kernel@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@1' configuration Trying 'fdt@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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@1' configuration Trying 'kernel@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@1' configuration Trying 'kernel@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@1' configuration Trying 'fdt@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
participants (4)
-
Jonathan Gray -
Mario Six -
Stefan Roese -
Tom Rini