Bug#584166: uboot-mkimage: add compatibility flag for broken u-boot versions

2011-01-29 Thread Loïc Minier
Hey!

 This is a followup to Debian http://bugs.debian.org/584166

 This bug was originally filed against uboot-mkimage which used to
 provide the mkimage command in Debian.  uboot-mkimage was a fork of
 u-boot and we now have upstream u-boot in Debian instead; mkimage is in
 a new u-boot-tools binary package built from the u-boot source package.

On Wed, Jun 02, 2010, Thibaut GIRKA wrote:
 Some versions of U-Boot (especially the one in the OpenMoko Freerunner
 NOR) are broken and don't handle multi-file images the right way.
 Multi-file images are U-Boot images with a table of sizes (size of the several
 files), then the abovementionned files, aligned to multiples of 4 bytes.
 Some broken versions of U-Boot expect a 4-byte padding for already aligned
 files.

 Before we dive into the fix, let me try to summarize:
 * original (old) u-boot found in OpenMoko Freerunner flash had a bug
 * this bug has been fixed, and only people running the original u-boot
   binary suffer from it

 It is also my understanding that the recommended bootloader for
 Freerunner is Qi and not u-boot.

 The Freerunner appers to still be on sale, are new phones shipped with
 a broken u-boot?  When users get their Freerunner, do they typically
 get a firmware update which will flash a new bootloader (Qi or u-boot)?


 As I understand it, it's really easy to flash u-boot on a Freerunner,
 and while it's not something we should be done lightly, it seems to
 have been done in a relatively safe way, and there is only a little
 chance that you would brick your hardware.

 My preference would be for Debian to:
 * communicate on this u-boot bug and point at Qi/updated u-boot
   binaries and at http://wiki.openmoko.org/wiki/NeoTool to flash it
   (we should package it?)
 * either provide a standalone mini-image which will just upgrade u-boot
   to a recent and corrected version
 * or fix installer images for Freerunner to be built using the
   workaround described in the bug report (padding the image before
   passing it to mkimage)


 Possibly a third way to address this would be if the Freerunner can
 load the bootloader from e.g. serial or SD, bypassing the flash one?
 If that's the case, we could provide installer media using a recent and
 corrected u-boot.


 I'm very much against working around bugs in old u-boot binaries
 permanently in mkimage, and I don't think there is any chance of
 upstream taking such a patch; even less so with a new command-line
 flag.  We could also have a trivial freerunner-mkimage wrapper
 achieving the same thing, but again, I very much dislike these options.

   Cheers,
-- 
Loïc Minier



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#584166: uboot-mkimage: add compatibility flag for broken u-boot versions

2011-01-29 Thread Thibaut Girka
Le samedi 29 janvier 2011 à 15:08 +0100, Loïc Minier a écrit : 
 Hey!
[...] 
 Before we dive into the fix, let me try to summarize:
  * original (old) u-boot found in OpenMoko Freerunner flash had a bug
  * this bug has been fixed, and only people running the original u-boot
binary suffer from it

Accurate summary.

 It is also my understanding that the recommended bootloader for
  Freerunner is Qi and not u-boot.

Well, that's a questionable recommandation.

 The Freerunner appers to still be on sale, are new phones shipped with
  a broken u-boot?  When users get their Freerunner, do they typically
  get a firmware update which will flash a new bootloader (Qi or u-boot)?

As far as I know, all GTA02 phones are shipped with a broken u-boot.
This may not be the case with the forthcoming GTA04 model. It should be
a good thing to check before the GTA04 is mass-produced.

When users get their Freerunner (GTA02), they can do whatever they want,
including switching from u-boot to Qi.
However, the backup bootloader remains a broken u-boot.

 As I understand it, it's really easy to flash u-boot on a Freerunner,
  and while it's not something we should be done lightly, it seems to
  have been done in a relatively safe way, and there is only a little
  chance that you would brick your hardware.

Indeed. Plus, unless you somehow manage to overwrite the NOR u-boot,
your device isn't really bricked, as you can enter NOR u-boot by holding
AUX while booting.

 My preference would be for Debian to:
  * communicate on this u-boot bug and point at Qi/updated u-boot
binaries and at http://wiki.openmoko.org/wiki/NeoTool to flash it
(we should package it?)

We should definitely communicate on this bug somewhere on the OpenMoko
wiki.

 * either provide a standalone mini-image which will just upgrade u-boot
to a recent and corrected version

I'm against that, as it is really easy to upgrade NAND u-boot or replace
it by Qi. I don't think we can make it much easier.
Furthermore, the installer should rely on the bootloader that's
available on all GTA02: the u-boot version stored in NOR.

 * or fix installer images for Freerunner to be built using the
workaround described in the bug report (padding the image before
passing it to mkimage)

It's the easiest, and IMHO, the cleanest way to do this.

 Possibly a third way to address this would be if the Freerunner can
  load the bootloader from e.g. serial or SD, bypassing the flash one?
  If that's the case, we could provide installer media using a recent and
  corrected u-boot.

As far as I know, it can't.

 I'm very much against working around bugs in old u-boot binaries
  permanently in mkimage, and I don't think there is any chance of
  upstream taking such a patch; even less so with a new command-line
  flag.  We could also have a trivial freerunner-mkimage wrapper
  achieving the same thing, but again, I very much dislike these options.

I can understand that, and indeed, upstream is not keen on accepting
such a workaround.
I don't have a strong opinion on a freerunner-mkimage wrapper, but it
isn't needed if we fix the really specific images we need boot.

So, I guess this bug should be closed, and worked around in the really
specific places we need to.

Regards,
Thibaut Girka.


signature.asc
Description: This is a digitally signed message part


Bug#584166: uboot-mkimage: add compatibility flag for broken u-boot versions

2010-06-01 Thread Thibaut GIRKA
Package: uboot-mkimage
Version: 0.4
Severity: normal
Tags: patch

Some versions of U-Boot (especially the one in the OpenMoko Freerunner NOR) are
broken and don't handle multi-file images the right way.
Multi-file images are U-Boot images with a table of sizes (size of the several
files), then the abovementionned files, aligned to multiples of 4 bytes.
Some broken versions of U-Boot expect a 4-byte padding for already aligned
files.

This patch adds a switch to add one zero byte at the end of a file whose size
is a multiple of 4.
This permits readability by both broken and non-broken versions of U-Boot,
while being safe.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.34-rc5 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages uboot-mkimage depends on:
ii  libc6 2.10.2-9   Embedded GNU C Library: Shared lib

uboot-mkimage recommends no packages.

uboot-mkimage suggests no packages.

-- no debconf information
diff -r 4281db2bcda6 mkimage.c
--- a/mkimage.c	Tue Jun 01 22:46:18 2010 +0200
+++ b/mkimage.c	Wed Jun 02 00:00:12 2010 +0200
@@ -170,6 +170,7 @@
 int lflag= 0;
 int vflag= 0;
 int xflag= 0;
+int pflag= 0;
 int opt_os   = IH_OS_LINUX;
 int opt_arch = IH_CPU_PPC;
 int opt_type = IH_TYPE_KERNEL;
@@ -254,6 +255,9 @@
 	usage ();
 name = *++argv;
 goto NXTARG;
+			case 'p':
+pflag++;
+break;
 			case 'v':
 vflag++;
 break;
@@ -408,6 +412,8 @@
 		cmdname, file, strerror(errno));
 	exit (EXIT_FAILURE);
 }
+if (pflag  (sbuf.st_size % 4) == 0)
+	sbuf.st_size += 1;
 size = htonl(sbuf.st_size);
 			} else {
 size = 0;
@@ -584,7 +590,8 @@
 		exit (EXIT_FAILURE);
 	}
 
-	if (pad  ((tail = size % 4) != 0)) {
+	tail = size % 4;
+	if (pad  (pflag || tail != 0)) {
 
 		if (write(ifd, (char *)zero, 4-tail) != 4-tail) {
 			fprintf (stderr, %s: Write error on %s: %s\n,
@@ -613,6 +620,7 @@
 			   -e == set entry point to 'ep' (hex)\n
 			   -n == set image name to 'name'\n
 			   -d == use image data from 'datafile'\n
+			   -p == force padding in multi-file images (work around a bug in u-boot)\n
 			   -x == set XIP (execute in place)\n
 		);
 	exit (EXIT_FAILURE);


Bug#584166: uboot-mkimage: add compatibility flag for broken u-boot versions

2010-06-01 Thread Marc Singer
On Tue, Jun 1, 2010 at 3:08 PM, Thibaut GIRKA t...@sitedethib.com wrote:

 Package: uboot-mkimage
 Version: 0.4
 Severity: normal
 Tags: patch

 Some versions of U-Boot (especially the one in the OpenMoko Freerunner NOR)
 are
 broken and don't handle multi-file images the right way.
 Multi-file images are U-Boot images with a table of sizes (size of the
 several
 files), then the abovementionned files, aligned to multiples of 4 bytes.
 Some broken versions of U-Boot expect a 4-byte padding for already aligned
 files.

 This patch adds a switch to add one zero byte at the end of a file whose
 size
 is a multiple of 4.
 This permits readability by both broken and non-broken versions of U-Boot,
 while being safe.


Thanks.  I'll look at it.




 -- System Information:
 Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.34-rc5 (SMP w/2 CPU cores)
 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages uboot-mkimage depends on:
 ii  libc6 2.10.2-9   Embedded GNU C Library: Shared
 lib

 uboot-mkimage recommends no packages.

 uboot-mkimage suggests no packages.

 -- no debconf information