On Thu, Mar 19, 2015 at 02:42:16AM +0530, Dileep Katta wrote:
Hi Tom,
On 18 March 2015 at 21:41, Tom Rini trini@konsulko.com wrote:
On Wed, Mar 18, 2015 at 12:08:23AM +0530, Dileep Katta wrote:
- Added new configuration for Android fastboot - This is based on following patch modified accordinglyhttp://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=b2e04f92b5d91c708b6fd6...
Signed-off-by: Angela Stegmaier angelabaker@ti.com Signed-off-by: Dileep Katta dileep.katta@linaro.org
[snip]
@@ -43,6 +43,16 @@ "uuid_disk=${uuid_gpt_disk};" \ "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}"
+#ifdef CONFIG_DRA7XX_ANDROID +/* Fastboot */ +#define CONFIG_CMD_FASTBOOT +#define CONFIG_ANDROID_BOOT_IMAGE +#define CONFIG_USB_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR +#define CONFIG_USB_FASTBOOT_BUF_SIZE 0x2F000000 +#define CONFIG_FASTBOOT_FLASH +#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1 +#endif
#include <configs/ti_omap5_common.h>
No, just enable fastboot. There's a growing population of people whose workflow is "use fastboot to shove a new test kernel at my device" that aren't strictly using Android, lets enable them.
OK, will enable fastboot unconditional. Now there is no much difference for android_defconfig, but will still keep separate config for future changes.
I remain unconvinced that we need a separate config upstream still.
@@ -115,7 +125,11 @@ #define CONFIG_SPL_SPI_SUPPORT #define CONFIG_SPL_SPI_LOAD #define CONFIG_SPL_SPI_FLASH_SUPPORT +#ifdef CONFIG_DRA7XX_ANDROID +#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x80000 +#else #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x40000 +#endif
Why are you moving U-Boot so much higher in SPI flash?
This is done to accommodate larger size MLO.
Oh that's right. Some parts can be made with a larger SRAM and thus we could use a larger MLO. But are we? What functionality would we be shoving into a larger MLO that would make sense to do this really? Frankly I had been thinking that in these parts it makes more sense to jump to full U-Boot and skip SPL rather than make SPL be very complicated.
+#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_USB_GADGET_VBUS_DRAW 2 +#define CONFIG_G_DNL_MANUFACTURER "Texas Instruments" +#ifdef CONFIG_CMD_FASTBOOT +#define CONFIG_G_DNL_VENDOR_NUM 0x0451 +#define CONFIG_G_DNL_PRODUCT_NUM 0xd022 +#else +#define CONFIG_G_DNL_VENDOR_NUM 0x0403 +#define CONFIG_G_DNL_PRODUCT_NUM 0xBD00 +#endif +#define CONFIG_USB_GADGET_DUALSPEED
Why can't we always use one vid/pid?
As we are restricted to use the vid which fastboot host application knows, the other/original vid/pid kept intact for the dependent functionality, if any. Will check if 0x0403/0xBD00 could be removed.
I think we can just always use the VID/PID that fastboot knows, DFU isn't nearly so picky and other gadget use cases don't care I believe.