Fastboot gadget, v2. repost
This is a repost of 19.10.2011. This series contains a small version of the fastboot gadget. I removed the flash/mmc/write to media part and re-add once I'm through with this basic thing :)
This "basic" gadget supports the retrieval of variables (like serial number), reboot functionality, download of binary data and booting them in case the binary data is a bootable image.
I did not include the fastboot client in this series. Remy asked about this. I could take it and stash it in tools if someone really wants this to have. This would include the fastboot and libzipfile folder from Andorid's system/core repository. An online version can be found at [0]. I haven't seen the library somewhere else than Android. For basic testing, the library could be excluded.
v1..v2:
fixed all issues that came up so far, including:
- s/andoir_img_get_kload/android_img_get_kload/ spotted by Mike
- adjusted Copyright message to GPLv2 or later for f_fastboot.c and removed "change" comments.
- removed two header files in example patch 3/3
I believe that the "All rights reserved" problem got resolved.
[0] http://www.netmite.com/android/mydroid/system/core/
Sebastian
PATCH 1/2 image: add support for Android's boot image format
This patch adds support for the Android boot-image format. The header file is from the Android project and got slightly alterted so the struct + its defines are not generic but have something like a namespace. The header file is from bootloader/legacy/include/boot/bootimg.h. The header parsing has been written from scratch and I looked at bootloader/legacy/usbloader/usbloader.c for some details.
The image contains the physical address (load address) of the kernel and ramdisk. This address is considered only for the kernel image. The "second image" is currently ignored. I haven't found anything that is creating this.
--- common/cmd_bootm.c | 87 +++++++++++++++++++++++++++++++++++++++++++++- common/image.c | 17 +++++++++ include/android_image.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++ include/image.h | 4 ++ 4 files changed, 196 insertions(+), 1 deletions(-) create mode 100644 include/android_image.h
common/cmd_bootm.c +86 -1
@@ -36,6 +36,7 @@#include <lmb.h> #include <linux/ctype.h> #include <asm/byteorder.h> +#include <android_image.h> #if defined(CONFIG_CMD_USB )#include <usb.h>
@@ -188,10 +189,33 @@ static void bootm_start_lmb(void)#endif } +#ifdef CONFIG_ANDROID_BOOT_IMAGE +static u32 android_img_get_end (struct andr_img_hdr *hdr) +{ +u32 size =0 ; +/* +* The header takes a full page, the remaining components are aligned +* on page boundary +*/ + size += hdr->page_size; + size +=ALIGN (hdr->kernel_size, hdr->page_size); + size +=ALIGN (hdr->ramdisk_size, hdr->page_size); + size +=ALIGN (hdr->second_size, hdr->page_size); + +return size; +} + +static u32 android_img_get_kload (struct andr_img_hdr *hdr) +{ +return hdr->kernel_addr; +} +#endif +static int bootm_start (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) {void *os_hdr;int ret; +int img_type;memset ((void *)&images,0 ,sizeof (images)); images.verify =getenv_yesno ("verify" );
@@ -207,7 +231,8 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] }/* get image parameters */ -switch (genimg_get_format (os_hdr)) { + img_type =genimg_get_format (os_hdr); +switch (img_type) {case IMAGE_FORMAT_LEGACY : images.os.type =image_get_type (os_hdr); images.os.comp =image_get_comp (os_hdr);
@@ -249,6 +274,16 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] }break ;#endif +#ifdef CONFIG_ANDROID_BOOT_IMAGE +case IMAGE_FORMAT_ANDROID : + images.os.type =IH_TYPE_KERNEL ; + images.os.comp =IH_COMP_NONE ; + images.os.os =IH_OS_LINUX ; + + images.os.end =android_img_get_end (os_hdr); + images.os.load =android_img_get_kload (os_hdr); +break ; +#endif default :puts ("ERROR: unknown image format type!\n" );return 1 ;
@@ -266,6 +301,10 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]return 1 ; }#endif +#ifdef CONFIG_ANDROID_BOOT_IMAGE + }else if (img_type ==IMAGE_FORMAT_ANDROID ) { + images.ep = images.os.load; +#endif }else {puts ("Could not find kernel entry point!\n" );return 1 ;
@@ -806,6 +845,36 @@ static int fit_check_kernel(const void *fit, int os_noffset, int verify) }#endif /* CONFIG_FIT */ +#ifdef CONFIG_ANDROID_BOOT_IMAGE +static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE +1 ]; +static int android_image_get_kernel (struct andr_img_hdr *hdr,int verify) +{ +/* +* Not all Android tools use the id field for signing the image with +* sha1 (or anything) so we don't check it. It is not obvious that the +* string is null terminated so we take care of this. +*/ +strncpy (andr_tmp_str, hdr->name,ANDR_BOOT_NAME_SIZE ); + andr_tmp_str[ANDR_BOOT_NAME_SIZE ] ='\0' ; +if (strlen (andr_tmp_str)) +printf ("Android's image name: %s\n" , andr_tmp_str); + +printf ("Kernel load addr 0x%08x size %u KiB\n" , + hdr->kernel_addr,DIV_ROUND_UP (hdr->kernel_size,1024 )); +strncpy (andr_tmp_str, hdr->cmdline,ANDR_BOOT_ARGS_SIZE ); + andr_tmp_str[ANDR_BOOT_ARGS_SIZE ] ='\0' ; +if (strlen (andr_tmp_str)) { +printf ("Kernel command line: %s\n" , andr_tmp_str); +setenv ("bootargs" , andr_tmp_str); + } +if (hdr->ramdisk_size) +printf ("RAM disk load addr 0x%08x size %u KiB\n" , + hdr->ramdisk_addr, +DIV_ROUND_UP (hdr->ramdisk_size,1024 )); +return 0 ; +} +#endif +/** * boot_get_kernel - find kernel image * @os_data: pointer to a ulong variable, will hold os data start address
@@ -833,6 +902,9 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,int cfg_noffset;int os_noffset;#endif +#ifdef CONFIG_ANDROID_BOOT_IMAGE +struct andr_img_hdr *ahdr; +#endif /* find out kernel image address */ if (argc <2 ) {
@@ -976,6 +1048,19 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, images->fit_noffset_os = os_noffset;break ;#endif +#ifdef CONFIG_ANDROID_BOOT_IMAGE +case IMAGE_FORMAT_ANDROID : +printf ("## Booting Android Image at 0x%08lx ...\n" , img_addr); + ahdr = (void *)img_addr; +if (android_image_get_kernel (ahdr, images->verify)) +return NULL ; + + *os_data = img_addr; + *os_data += ahdr->page_size; + *os_len = ahdr->kernel_size; + images->ahdr = ahdr; +break ; +#endif default :printf ("Wrong Image Format for %s command\n" , cmdtp->name);show_boot_progress (-108 );
common/image.c +17 -0
@@ -26,6 +26,7 @@#ifndef USE_HOSTCC #include <common.h> #include <watchdog.h> +#include <android_image.h> #ifdef CONFIG_SHOW_BOOT_PROGRESS #include <status_led.h>
@@ -672,7 +673,14 @@ int genimg_get_format(void *img_addr) format = IMAGE_FORMAT_FIT; }#endif +#ifdef CONFIG_ANDROID_BOOT_IMAGE +if (format ==IMAGE_FORMAT_INVALID ) { +const struct andr_img_hdr *ahdr = img_addr; +if (!memcmp (ANDR_BOOT_MAGIC , ahdr->magic,ANDR_BOOT_MAGIC_SIZE )) + format =IMAGE_FORMAT_ANDROID ; + } +#endif return format; }
@@ -1006,6 +1014,15 @@ int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images, (ulong)images->legacy_hdr_os);image_multi_getimg (images->legacy_hdr_os,1 , &rd_data, &rd_len); +#ifdef CONFIG_ANDROID_BOOT_IMAGE +if (images->ahdr && images->ahdr->ramdisk_size) { + rd_data = (unsigned long ) images->ahdr; + rd_data += images->ahdr->page_size; + rd_data +=ALIGN (images->ahdr->kernel_size, + images->ahdr->page_size); + rd_len = images->ahdr->ramdisk_size; + } +#endif }else {/* * no initrd image
include/android_image.h new file +89 -0
89 lines not on this page · raw message
include/image.h +4 -0
@@ -264,6 +264,9 @@ typedef struct bootm_headers {#ifdef CONFIG_LMB struct lmb lmb;/* for memory mgmt */ #endif +#ifdef CONFIG_ANDROID_BOOT_IMAGE +struct andr_img_hdr *ahdr; +#endif } bootm_headers_t;/*
@@ -329,6 +332,7 @@ void genimg_print_size(uint32_t size);#define IMAGE_FORMAT_INVALID 0x00#define IMAGE_FORMAT_LEGACY 0x01/* legacy image_header based format */ #define IMAGE_FORMAT_FIT 0x02/* new, libfdt based format */ +#define IMAGE_FORMAT_ANDROID 0x03/* Android boot image */ int genimg_get_format (void *img_addr);int genimg_has_config (bootm_headers_t *images);
Signature · 1 line
1.7.7.1
PATCH 1/2 image: add support for Android's boot image format
Dear Sebastian Andrzej Siewior,
Quoted 10 lines · In message <[email protected]> you wrote:
This patch adds support for the Android boot-image format. The header file is from the Android project and got slightly alterted so the struct + its defines are not generic but have something like a namespace. The header file is from
bootloader/legacy/include/boot/bootimg.h. The header parsing has been written from scratch and I looked atbootloader/legacy/usbloader/usbloader.cfor some details.
The image contains the physical address (load address) of the kernel and ramdisk. This address is considered only for the kernel image. The "second image" is currently ignored. I haven't found anything that is creating this.
Please provide _exact_ reference where this code has been copied from, see bullet 4 etc. at
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
Also please provide exact information about the applicable licenses for this copied code.
...
Quoted 4 lines
common/cmd_bootm.c +2
-1/* get image parameters */ -switch (genimg_get_format (os_hdr)) { + img_type =genimg_get_format (os_hdr); +switch (img_type) {
...
common/cmd_bootm.c static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] · line 307
Quoted 4 lines
common/cmd_bootm.c +4
-0+#ifdef CONFIG_ANDROID_BOOT_IMAGE + }else if (img_type ==IMAGE_FORMAT_ANDROID ) { + images.ep = images.os.load; +#endif
Why don't you handle the Andoid image case inside the switch() ?
Quoted 19 lines
common/cmd_bootm.c +19
-0+#ifdef CONFIG_ANDROID_BOOT_IMAGE +static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE +1 ]; +static int android_image_get_kernel (struct andr_img_hdr *hdr,int verify) +{ +/* +* Not all Android tools use the id field for signing the image with +* sha1 (or anything) so we don't check it. It is not obvious that the +* string is null terminated so we take care of this. +*/ +strncpy (andr_tmp_str, hdr->name,ANDR_BOOT_NAME_SIZE ); + andr_tmp_str[ANDR_BOOT_NAME_SIZE ] ='\0' ; +if (strlen (andr_tmp_str)) +printf ("Android's image name: %s\n" , andr_tmp_str); + +printf ("Kernel load addr 0x%08x size %u KiB\n" , + hdr->kernel_addr,DIV_ROUND_UP (hdr->kernel_size,1024 )); +strncpy (andr_tmp_str, hdr->cmdline,ANDR_BOOT_ARGS_SIZE ); + andr_tmp_str[ANDR_BOOT_ARGS_SIZE ] ='\0' ; +if (strlen (andr_tmp_str)) {
common/cmd_bootm.c static int fit_check_kernel(const void *fit, int os_noffset, int verify) · line 876
Quoted 10 lines
common/cmd_bootm.c +10
-0+printf ("Kernel command line: %s\n" , andr_tmp_str); + setenv("bootargs", andr_tmp_str); + } +if (hdr->ramdisk_size) +printf ("RAM disk load addr 0x%08x size %u KiB\n" , + hdr->ramdisk_addr, +DIV_ROUND_UP (hdr->ramdisk_size,1024 )); +return 0 ; +} +#endif
This and similar Android image related code shoudl eventually go into a separate file, exposing only a few functions.
common/image.c int genimg_get_format(void *img_addr) · line 683
Quoted 8 lines
common/image.c +7
-0+#ifdef CONFIG_ANDROID_BOOT_IMAGE +if (format ==IMAGE_FORMAT_INVALID ) { +const struct andr_img_hdr *ahdr = img_addr; +if (!memcmp (ANDR_BOOT_MAGIC , ahdr->magic,ANDR_BOOT_MAGIC_SIZE )) + format =IMAGE_FORMAT_ANDROID ; + } +#endif
This is all we have for testing for a valid image?
Quoted 10 lines
index 0000000..b231b66
include/android_image.h new file +6
-0@@ -0,0 +1,89 @@ +/* +* This is from the Android Project, +* bootloader/legacy/include/boot/bootimg.h +* +* Copyright (C) 2008 The Android Open Source Project +* All rights reserved.
include/android_image.h line 16
Quoted 10 lines
include/android_image.h new file +10
-0+* +* Redistribution and use in source and binary forms, with or without +* modification, are permitted provided that the following conditions +* are met: +* * Redistributions of source code must retain the above copyright +* notice, this list of conditions and the following disclaimer. +* * Redistributions in binary form must reproduce the above copyright +* notice, this list of conditions and the following disclaimer in +* the documentation and/or other materials provided with the +* distribution.
Sorry, but this is not GPL compatible.
Best regards,
Wolfgang Denk
Signature · 8 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Making files is easy under the UNIX operating system. Therefore, users tend to create numerous files using large amounts of file space. It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files. - System V.2 administrator's guide
PATCH 1/2 image: add support for Android's boot image format
Quoted 1 line · * Wolfgang Denk | 2011-11-21 21:19:07 [+0100]:
Dear Sebastian Andrzej Siewior,
Hi Wolfgang,
Quoted 6 lines
Please provide _exact_ reference where this code has been copied from, see bullet 4 etc. at
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_SignAlso please provide exact information about the applicable licenses for this copied code.
I added a detailed description to the repository and the commit head where I took it from.
Quoted 6 lines
...
Quoted 4 lines
common/cmd_bootm.c +2
-1/* get image parameters */ -switch (genimg_get_format (os_hdr)) { + img_type =genimg_get_format (os_hdr); +switch (img_type) {...
Quoted 6 lines
common/cmd_bootm.c static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] · line 307
Quoted 4 lines
common/cmd_bootm.c +4
-0+#ifdef CONFIG_ANDROID_BOOT_IMAGE + }else if (img_type ==IMAGE_FORMAT_ANDROID ) { + images.ep = images.os.load; +#endif Why don't you handle the Andoid image case inside the
switch()?
Because the code flow looks like:
| if (images.legacy_hdr_valid) {
| images.ep = image_get_ep(&images.legacy_hdr_os_copy);
| #if defined(CONFIG_FIT)
| } else if (images.fit_uname_os) {
...
| }
| #endif
| #ifdef CONFIG_ANDROID_BOOT_IMAGE
...
| #endif
| } else {
| puts("Could not find kernel entry point!\n");
| return 1;
| }
|So if I don't add an extra android block here, I end up in this else part complaining about the entrypoint.
I guess that this part could be merged into the previous switch statement if you want me to.
Quoted 24 lines
Quoted 24 lines
common/cmd_bootm.c +24
-0+#ifdef CONFIG_ANDROID_BOOT_IMAGE +static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE +1 ]; +static int android_image_get_kernel (struct andr_img_hdr *hdr,int verify) +{ +/* +* Not all Android tools use the id field for signing the image with +* sha1 (or anything) so we don't check it. It is not obvious that the +* string is null terminated so we take care of this. +*/ +strncpy (andr_tmp_str, hdr->name,ANDR_BOOT_NAME_SIZE ); + andr_tmp_str[ANDR_BOOT_NAME_SIZE ] ='\0' ; +if (strlen (andr_tmp_str)) +printf ("Android's image name: %s\n" , andr_tmp_str); + +printf ("Kernel load addr 0x%08x size %u KiB\n" , + hdr->kernel_addr,DIV_ROUND_UP (hdr->kernel_size,1024 )); +strncpy (andr_tmp_str, hdr->cmdline,ANDR_BOOT_ARGS_SIZE ); + andr_tmp_str[ANDR_BOOT_ARGS_SIZE ] ='\0' ; +if (strlen (andr_tmp_str)) { +printf ("Kernel command line: %s\n" , andr_tmp_str); +setenv ("bootargs" , andr_tmp_str); + } +if (hdr->ramdisk_size) + printf("RAM disk load addr 0x%08x size %u KiB\n",
Quoted 8 lines
common/cmd_bootm.c static int fit_check_kernel(const void *fit, int os_noffset, int verify) · line 876
Quoted 5 lines
common/cmd_bootm.c +5
-0+ hdr->ramdisk_addr, + DIV_ROUND_UP(hdr->ramdisk_size, 1024)); + return 0; +} +#endif This and similar Android image related code shoudl eventually go into a separate file, exposing only a few functions.
Okay.
Quoted 10 lines
common/image.c int genimg_get_format(void *img_addr) · line 683
Quoted 8 lines
common/image.c +7
-0+#ifdef CONFIG_ANDROID_BOOT_IMAGE +if (format ==IMAGE_FORMAT_INVALID ) { +const struct andr_img_hdr *ahdr = img_addr; +if (!memcmp (ANDR_BOOT_MAGIC , ahdr->magic,ANDR_BOOT_MAGIC_SIZE )) + format =IMAGE_FORMAT_ANDROID ; + } +#endif This is all we have for testing for a valid image?
More or less, yes. The fastboot client [0] does nothing else if you provide it a kernel (and it creates the ANDROID image out of it). The comment field is used by mkbootimg/mkbootimg.c tool to stash a sha1 checksum. The format how to create the sha1 checksum (i.e. pad, don't pad, include header or not, ...) isn't documented (atleast I did not find anything) so the only source of documentation is
the source code wich is under Apache2 license which is compatible with GPLv3 but not with v2 so I can't look at it.
[0] http://android-dls.com/wiki/index.php?title=Fastboot
Quoted 14 lines
Quoted 14 lines
index 0000000..b231b66
include/android_image.h new file +10
-0@@ -0,0 +1,89 @@ +/* +* This is from the Android Project, +* bootloader/legacy/include/boot/bootimg.h +* +* Copyright (C) 2008 The Android Open Source Project +* All rights reserved. +* +* Redistribution and use in source and binary forms, with or without +* modification, are permitted provided that the following conditions +* are met:
Quoted 8 lines
include/android_image.h line 16
Quoted 6 lines
include/android_image.h new file +6
-0+* * Redistributions of source code must retain the above copyright +* notice, this list of conditions and the following disclaimer. +* * Redistributions in binary form must reproduce the above copyright +* notice, this list of conditions and the following disclaimer in +* the documentation and/or other materials provided with the +* distribution. Sorry, but this is not GPL compatible.
Ehm. Is this the All rights reserved issue? If so then I assumed that I cleared up things in
http://lists.denx.de/pipermail/u-boot/2011-September/101793.html
Quoted 4 lines
Best regards,
Wolfgang Denk
Sebastian
PATCH 1/2 image: add support for Android's boot image format
Dear Sebastian Andrzej Siewior,
Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 11 lines
Quoted 10 lines
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright+ * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution.
Quoted 4 lines
Quoted 1 line
Sorry, but this is not GPL compatible.
Ehm. Is this the All rights reserved issue? If so then I assumed that I cleared up things in
No, it's the "Redistributions in binary form must reproduce..." clause.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I don't document something, it's usually either for a good reason,
or a bad reason. In this case it's a good reason. :-)
- Larry Wall in <[email protected]>PATCH 1/2 image: add support for Android's boot image format
Quoted 14 lines · * Wolfgang Denk | 2011-11-22 20:04:47 [+0100]:
Dear Sebastian Andrzej Siewior,
Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 11 lines
Quoted 10 lines
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright+ * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Sorry, but this is not GPL compatible.
Ehm. Is this the All rights reserved issue? If so then I assumed that I cleared up things in
No, it's the "Redistributions in binary form must reproduce..." clause.
How so? If you distribute it as source nothing changes. I don't see much difference in binary form either: section 1 of the GPL says
|.. keep intact all the notices that refer to this License and to the |absence of any warranty; and give any other recipients of the Program a |copy of this License along with the Program.
and this is no different. It does not mention whether the software has to be passed in source or binary form. The BSD part does not push any restrictions on the GPL, it "wants" the same thing. Section 6 of the GPL says that by redistributing the receiptient should receive a copy of this license. The section you mentioed is no different. If you distribute GPL in binary code you have let the receiptient know, that he is using GPL code. A note in the documentation is enough as far as I know [if remeber correctly Harald went after a few companies which were using Linux and were not letting the customers know about it].
If you look at the fresh released Quake3 source [0] you see that there is a readme file which points out that it is GPL code and enumerates various other licenses.
So right now, I don't see why those two should not be compatible. Plus the FSF claims that they are [1].
[0] https://github.com/TTimo/doom3.gpl
[1] http://www.gnu.org/licenses/license-list.html#FreeBSD
Quoted 3 lines
Best regards,
Wolfgang Denk
Sebastian
PATCH 1/2 image: add support for Android's boot image format
Dear Wolfgang,
Quoted 45 lines · Sebastian Andrzej Siewior
Quoted 14 lines · * Wolfgang Denk | 2011-11-22 20:04:47 [+0100]:
Dear Sebastian Andrzej Siewior,
Quoted 11 lines · In message<[email protected]> you wrote:
Quoted 11 lines
Quoted 10 lines
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright+ * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution.Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Sorry, but this is not GPL compatible.
Ehm. Is this the All rights reserved issue? If so then I assumed that I cleared up things in
No, it's the "Redistributions in binary form must reproduce..." clause.
How so? If you distribute it as source nothing changes. I don't see much difference in binary form either: section 1 of the GPL says
|.. keep intact all the notices that refer to this License and to the |absence of any warranty; and give any other recipients of the Program a |copy of this License along with the Program.and this is no different. It does not mention whether the software has to be passed in source or binary form. The BSD part does not push any restrictions on the GPL, it "wants" the same thing. Section 6 of the GPL says that by redistributing the receiptient should receive a copy of this license. The section you mentioed is no different. If you distribute GPL in binary code you have let the receiptient know, that he is using GPL code. A note in the documentation is enough as far as I know [if remeber correctly Harald went after a few companies which were using Linux and were not letting the customers know about it].
If you look at the fresh released Quake3 source [0] you see that there is a readme file which points out that it is GPL code and enumerates various other licenses.
Quoted 5 lines
So right now, I don't see why those two should not be compatible. Plus the FSF claims that they are [1].
[0] https://github.com/TTimo/doom3.gpl
[1] http://www.gnu.org/licenses/license-list.html#FreeBSD
What is your final call on this? The above arguments sound convincing to me, but I have to admit that I am no legal expert. Either way, it will be great to have a closure on this. Lack of fastboot support was the greatest impediment to adoption of mainline U-Boot in our previous platforms. It will be really unfortunate if the same happens to OMAP5 that has just arrived.
best regards,
Aneesh
PATCH 1/2 image: add support for Android's boot image format
Dear Wolfgang,
Quoted 57 lines · Aneesh V
Dear Wolfgang,
Quoted 48 lines · Sebastian Andrzej Siewior
Quoted 17 lines · * Wolfgang Denk | 2011-11-22 20:04:47 [+0100]:
Dear Sebastian Andrzej Siewior,
Quoted 14 lines · In message<[email protected]> you wrote:
Quoted 14 lines
Quoted 13 lines
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Sorry, but this is not GPL compatible.
Ehm. Is this the All rights reserved issue? If so then I assumed that I cleared up things in
No, it's the "Redistributions in binary form must reproduce..." clause.
How so? If you distribute it as source nothing changes. I don't see much difference in binary form either: section 1 of the GPL says
|.. keep intact all the notices that refer to this License and to the |absence of any warranty; and give any other recipients of the Program a |copy of this License along with the Program.and this is no different. It does not mention whether the software has to be passed in source or binary form. The BSD part does not push any restrictions on the GPL, it "wants" the same thing. Section 6 of the GPL says that by redistributing the receiptient should receive a copy of this license. The section you mentioed is no different. If you distribute GPL in binary code you have let the receiptient know, that he is using GPL code. A note in the documentation is enough as far as I know [if remeber correctly Harald went after a few companies which were using Linux and were not letting the customers know about it].
If you look at the fresh released Quake3 source [0] you see that there is a readme file which points out that it is GPL code and enumerates various other licenses.
Quoted 5 lines
So right now, I don't see why those two should not be compatible. Plus the FSF claims that they are [1].
[0] https://github.com/TTimo/doom3.gpl
[1] http://www.gnu.org/licenses/license-list.html#FreeBSD
Quoted 6 lines
What is your final call on this? The above arguments sound convincing to me, but I have to admit that I am no legal expert. Either way, it will be great to have a closure on this. Lack of fastboot support was the greatest impediment to adoption of mainline U-Boot in our previous platforms. It will be really unfortunate if the same happens to OMAP5 that has just arrived.
Ping.
br,
Aneesh
PATCH 1/2 image: add support for Android's boot image format
Quoted 77 lines · Aneesh V
Dear Wolfgang,
Quoted 65 lines · Aneesh V
Dear Wolfgang,
Quoted 54 lines · Sebastian Andrzej Siewior
Quoted 22 lines · * Wolfgang Denk | 2011-11-22 20:04:47 [+0100]:
Dear Sebastian Andrzej Siewior,
Quoted 19 lines · In message<[email protected]> you wrote:
Quoted 17 lines
Quoted 14 lines
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.Sorry, but this is not GPL compatible.
Quoted 6 lines
Quoted 2 lines
Ehm. Is this the All rights reserved issue? If so then I assumed that I cleared up things in
No, it's the "Redistributions in binary form must reproduce..." clause.
How so? If you distribute it as source nothing changes. I don't see much difference in binary form either: section 1 of the GPL says
|.. keep intact all the notices that refer to this License and to the |absence of any warranty; and give any other recipients of the Program a |copy of this License along with the Program.and this is no different. It does not mention whether the software has to be passed in source or binary form. The BSD part does not push any restrictions on the GPL, it "wants" the same thing. Section 6 of the GPL says that by redistributing the receiptient should receive a copy of this license. The section you mentioed is no different. If you distribute GPL in binary code you have let the receiptient know, that he is using GPL code. A note in the documentation is enough as far as I know [if remeber correctly Harald went after a few companies which were using Linux and were not letting the customers know about it].
If you look at the fresh released Quake3 source [0] you see that there is a readme file which points out that it is GPL code and enumerates various other licenses.
Quoted 5 lines
So right now, I don't see why those two should not be compatible. Plus the FSF claims that they are [1].
[0] https://github.com/TTimo/doom3.gpl
[1] http://www.gnu.org/licenses/license-list.html#FreeBSDQuoted 6 lines
What is your final call on this? The above arguments sound convincing to me, but I have to admit that I am no legal expert. Either way, it will be great to have a closure on this. Lack of fastboot support was the greatest impediment to adoption of mainline U-Boot in our previous platforms. It will be really unfortunate if the same happens to OMAP5 that has just arrived.
Quoted 1 line
Ping.
Part of the feedback (see http://patchwork.ozlabs.org/patch/126797/)
was not addressed, namely the complete reference (including hash) where the code came from.
Signature · 1 line
Tom
PATCH 1/2 image: add support for Android's boot image format
In reply to Aneesh VDear Aneesh V,
Quoted 7 lines · In message <[email protected]> you wrote:
What is your final call on this? The above arguments sound convincing to me, but I have to admit that I am no legal expert. Either way, it will be great to have a closure on this. Lack of fastboot support was the greatest impediment to adoption of mainline U-Boot in our previous platforms. It will be really unfortunate if the same happens to OMAP5 that has just arrived.
The license issue was a mistake on my side.
However, there is still cleanup needed for the commit message.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de It would be illogical to kill without reason -- Spock, "Journey to Babel", stardate 3842.4
PATCH 1/2 image: add support for Android's boot image format
Quoted 12 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 8 lines · In message<[email protected]> you wrote:
What is your final call on this? The above arguments sound convincing to me, but I have to admit that I am no legal expert. Either way, it will be great to have a closure on this. Lack of fastboot support was the greatest impediment to adoption of mainline U-Boot in our previous platforms. It will be really unfortunate if the same happens to OMAP5 that has just arrived.
The license issue was a mistake on my side.
Quoted 1 line
However, there is still cleanup needed for the commit message.
Thanks. I will see if somebody can take it forward.
br,
Aneesh
PATCH 1/2 image: add support for Android's boot image format
In reply to Sebastian Andrzej SiewiorDear Sebastian,
Quoted 3 lines · In message <[email protected]> you wrote:
Quoted 3 lines
No, it's the "Redistributions in binary form must reproduce..." clause.
...
Quoted 2 lines
So right now, I don't see why those two should not be compatible. Plus the FSF claims that they are [1].
Sorry, my fault. I confused the "reproduce the above copyright notice" with the "must display the following acknowledgement" phrase of the 4-clause original BSD license.
So please ignore this part of my remarks.
However, I still ask you to change the commit message to include _exact_ information where the code was derived from, as explained in bullet 4 etc. at
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
Mind the part "provide terse but precise information which exact version or even commit ID was used."
Thanks.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de You don't have to stay up nights to succeed; you have to stay awake days.
PATCH 2/2 usb/gadget: add the fastboot gadget
In reply to Sebastian Andrzej SiewiorThis patch contains an implementation of the fastboot protocol on the device side and a little of documentation.
The gadget expects the new-style gadget framework.
The gadget implements the getvar, reboot, download and reboot commands. What is missing is the flash handling i.e. writting the image to media.
--- common/Makefile | 2 + common/cmd_fastboot.c | 28 ++ doc/README.android-fastboot | 86 ++++++ doc/README.android-fastboot-protocol | 170 ++++++++++ drivers/usb/gadget/Makefile | 5 + drivers/usb/gadget/f_fastboot.c | 559 ++++++++++++++++++++++++++++++++++ drivers/usb/gadget/g_fastboot.h | 20 ++ drivers/usb/gadget/u_fastboot.c | 308 +++++++++++++++++++ include/usb/fastboot.h | 100 ++++++ 9 files changed, 1278 insertions(+), 0 deletions(-) create mode 100644 common/cmd_fastboot.c create mode 100644 doc/README.android-fastboot create mode 100644 doc/README.android-fastboot-protocol create mode 100644 drivers/usb/gadget/f_fastboot.c create mode 100644 drivers/usb/gadget/g_fastboot.h create mode 100644 drivers/usb/gadget/u_fastboot.c create mode 100644 include/usb/fastboot.h
common/Makefile +2 -0
@@ -162,6 +162,8 @@ COBJS-y += cmd_usb.o COBJS-y += usb.o COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o endif +COBJS-$(CONFIG_CMD_FASTBOOT) += cmd_fastboot.o + COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
common/cmd_fastboot.c new file +28 -0
@@ -0,0 +1,28 @@ +#include <common.h> +#include <command.h> +#include <usb/fastboot.h> + +static int do_fastboot (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) +{ +int ret =1 ; + +if (!fastboot_init ()) { +printf ("Fastboot entered...\n" ); + + ret =0 ; + +while (1 ) { +if (fastboot_poll ()) +break ; + } + } + +fastboot_shutdown (); +return ret; +} + +U_BOOT_CMD ( + fastboot,1 ,1 , do_fastboot, +"fastboot- use USB Fastboot protocol\n" , +"" +);
doc/README.android-fastboot new file +86 -0
86 lines not on this page · raw message
doc/README.android-fastboot-protocol new file +170 -0
170 lines not on this page · raw message
drivers/usb/gadget/Makefile +5 -0
@@ -42,6 +42,11 @@ COBJS-$(CONFIG_SPEARUDC) += spr_udc.o endif endif +ifdef CONFIG_CMD_FASTBOOT +COBJS-y += f_fastboot.o u_fastboot.o +COBJS-y += epautoconf.o usbstring.o +endif + COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS))
drivers/usb/gadget/f_fastboot.c new file +559 -0
559 lines not on this page · raw message
drivers/usb/gadget/g_fastboot.h new file +20 -0
@@ -0,0 +1,20 @@ +#ifndef _G_FASTBOOT_H_ +#define _G_FASTBOOT_H_ + +#define EP_BUFFER_SIZE 4096 +#define FASTBOOT_INTERFACE_CLASS 0xff +#define FASTBOOT_INTERFACE_SUB_CLASS 0x42 +#define FASTBOOT_INTERFACE_PROTOCOL 0x03 +#define FASTBOOT_VERSION "0.4" + +extern struct fastboot_config fb_cfg; +extern struct usb_ep *ep_in; +extern struct usb_request *req_in; +extern struct usb_ep *ep_out; +extern struct usb_request *req_out; + +void rx_handler_command (struct usb_ep *ep,struct usb_request *req); +int fastboot_tx_write (const char *buffer,unsigned int buffer_size); +const char *fb_find_usb_string (unsigned int id); + +#endif
drivers/usb/gadget/u_fastboot.c new file +308 -0
308 lines not on this page · raw message
include/usb/fastboot.h new file +100 -0
100 lines not on this page · raw message
Signature · 1 line
1.7.7.1
PATCH 2/2 usb/gadget: add the fastboot gadget
Hello.
Quoted 3 lines · Sebastian Andrzej Siewior
This patch contains an implementation of the fastboot protocol on the device side and a little of documentation.
The gadget expects the new-style gadget framework.
Which what hardware do you test this? So far I have only seen patches (not applied yet) for the Samsung UDC controller that are providing the usb_gadget_register_driver() functions. Consumer is only ether.c so far.
Any other hardware platforms that support the new style gadget framework yet? Do'n get me wrong, I like it and would like to see more drivers moving to it but I wonder what support on a hardware driver level we have for it yet.
Quoted 2 lines
The gadget implements the getvar, reboot, download and reboot commands. What is missing is the flash handling i.e. writting the image to media.
You may have seen the DFU patches on this list recently. There is also a split between the DFU protocol and the flashing backend. Would it make sense to see if fastboot and DFU could use the same flashing backend and platform specific bits?
regards
Stefan Schmidt
PATCH 2/2 usb/gadget: add the fastboot gadget
Quoted 1 line · * Stefan Schmidt | 2011-11-21 15:48:29 [+0100]:
Hello.
Hi,
Quoted 9 lines · Sebastian Andrzej Siewior
Quoted 3 lines
This patch contains an implementation of the fastboot protocol on the device side and a little of documentation.
The gadget expects the new-style gadget framework.Which what hardware do you test this? So far I have only seen patches (not applied yet) for the Samsung UDC controller that are providing the
usb_gadget_register_driver()functions. Consumer is onlyether.cso far.
DWC3. This one is new and already merged into the linux kernel. This one is on my list once I have the fastboot part merged :)
There should be an at91 udc driver in the uboot-usb git tree. The last time I checked, the at91 driver was in the next branch.
Quoted 4 lines
Any other hardware platforms that support the new style gadget framework yet? Do'n get me wrong, I like it and would like to see more drivers moving to it but I wonder what support on a hardware driver level we have for it yet.
All drivers in u-boot are using the old style interface which is linux from the late 2.4 time frame or very early 2.6. The dwc3 for which I plan to have fastboot is a huge usb3 drd controller. Having two different codebases does not make much sense.
Quoted 7 lines
Quoted 2 lines
The gadget implements the getvar, reboot, download and reboot commands. What is missing is the flash handling i.e. writting the image to media.
You may have seen the DFU patches on this list recently. There is also a split between the DFU protocol and the flashing backend. Would it make sense to see if fastboot and DFU could use the same flashing backend and platform specific bits?
I haven't seen it yet. From the protocol layer it is simple: You are told to receive X bytes. Once you sucked it up are told where you have to write it. The destination address is a partition name. So what I planned to do is to add the android partition format which is efi/guid based I think and then simply execute a "nand write data partition" command. If there is code that can be shared between DFU and this fastboot thingy then I'm the last person that does not want it.
Quoted 2 lines
regards
Stefan Schmidt
Sebastian
PATCH 2/2 usb/gadget: add the fastboot gadget
In reply to Sebastian Andrzej Siewiorcommon/Makefile COBJS-y += cmd_usb.o · line 167
Quoted 9 lines · On Monday 21 November 2011 09:09:35 Sebastian Andrzej Siewior wrote:
common/Makefile +2
-0COBJS-y += usb.o COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o endif +COBJS-$(CONFIG_CMD_FASTBOOT) += cmd_fastboot.o + COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
no newline here
common/cmd_fastboot.c line 3
Quoted 6 lines
common/cmd_fastboot.c new file +3
-0@@ -0,0 +1,28 @@ +#include <common.h> +#include <command.h> +#include <usb/fastboot.h>
missing comment block with license/copyright/etc...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120107/4c91f803/attachment.pgp>
PATCH 2/3 usb/gadget: add the fastboot gadget
Hi Wolfgang and Mike,
Quoted 3 lines
Quoted 3 lines
missing comment block with license/copyright/etc... -mike
[strip]
Quoted 2 lines
Are you 100% sure this is a GPLv2+ compatible license??? I don't think so...
[strip]
Quoted 8 lines
For U-Boot, we need GPLv2+. Please see bullet # 3 at
http://www.denx.de/wiki/view/U Boot/Patches#Attributing_Code_Copyrights_Sign and note # 1 at http://www.denx.de/wiki/view/U-Boot/Patches#NotesBest regards,
Wolfgang Denk
I have encountered some requests of porting Google's Fastboot protocol to u-boot from customers.
As your comment about supporting fastboot in uboot in
http://lists.linaro.org/pipermail/linaro-dev/2011-April/004136.html
I think the problem of supporting fastboot in uboot might not only be the license problem.
For clarifying the license issue, I think we may present some history as follows.
The original BSD license (4-clause license) was indeed incompatible with GPLv2. However, this conflict has finally be resolved in "The new BSD license" (2-clause license). After revising, the 2-clause BSD license is almost exactly the same as MIT X license, which is also compatible with GPLv2.
In detail, please check about the the page about the 3rd advertisement clause.
http://www.gnu.org/philosophy/bsd.html
And the content of the 4th clause which has been removed was "Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
The license of Google's fastboot is exactly 2-clause BSD license.
http://www.opensource.org/licenses/bsd-license.php
I think the well-known event of merging
BSD/GPL code in QEMU could be a reference.
The well-known Open Source Licensing and Patent consultant of Redhat -- Richard Fontana has also helped on this problem.
In order to merge SLiRP into QEMU, Richard has written e-mail to the author of SLiRP, which is "Danny Gasparovski" and the maintainer "Kelly Price" to get the agreement of removing the incompatible clauses.
And after the revising of license, they've successfully merged SLiRP.
http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg01765.html
Since the license of fastboot.c doesn't have the problem above, I think there is no compatible problem for merging "Google's fastboot".
Signature · 2 lines
Best regards, Macpaul Lin