[U-Boot] [PATCH v2 1/2] Revert "configs: Remove am335x_boneblack_defconfig"

Lokesh Vutla lokeshvutla at ti.com
Tue Sep 17 04:49:18 UTC 2019



On 16/09/19 4:53 PM, Sam Protsenko wrote:
> Hi Lokesh,
> 
> On Mon, Sep 16, 2019 at 11:34 AM Lokesh Vutla <lokeshvutla at ti.com> wrote:
>>
>>
>>
>> On 12/09/19 11:20 PM, Sam Protsenko wrote:
>>> Commit 8fa7f65dd02c ("configs: Remove am335x_boneblack_defconfig")
>>> removes defconfig for BeagleBone Black board, and it's advised to use
>>> am335x_evm_defconfig for all AM335x boards. But it's impossible to store
>>> environment in eMMC with am335x_evm_defconfig without modifications
>>> (NAND must be disabled, MMC enabled, etc). This is inconvenient for user
>>> to do such modifications via menuconfig (only developer knows what
>>> should be done). Furthermore, enabling MMC options in
>>> am335x_evm_defconfig leads to wrong pin-muxing scheme in
>>> board/ti/am335x/mux.c, because both NAND and MMC options are enabled in
>>> the config, so that pins are muxed for BBB with NAND cape, which in turn
>>> leads to non-functioning eMMC. There is no way to make the single defconfig
>>> working for both eMMC and NAND use-cases, because we can't figure out in
>>> run-time which board configuration is used by user (EVM, BBB, or BBB with
>>> NAND cape). Hence we rely on CONFIG options to figure out which
>>> configuration is used. Because of this we can't use single defconfig for
>>> AM335x EVM and BBB.
>>>
>>> All that said, let's bring back am335x_boneblack_defconfig, because
>>> right now users are not able to use U-Boot for BBB. Further patch will
>>
>> I did not understand why users are not able to use BBB using
>> am335x_evm_defconfig? ENV is stored in FAT and is working properly. What is
>> wrong with that? Is it that eMMC boot is failing?
>>
> 
> The eMMC boot works. But with that config it's impossible to store ENV
> on eMMC. Some users prefer to use eMMC exclusively, with SD card
> removed. In that case the user won't be able to store U-Boot
> environment on eMMC. Furthermore, when enabling environment in eMMC by

Hmm..Creating a defconfig for supporting separate env storage doesn't sound
right. U-boot has support for storing env in multiple places. Any chance you
tried that option?

Thanks and regards,
Lokesh

> next two options:>
>   1. CONFIG_ENV_IS_IN_MMC=y
>   2. CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
> 
> the boot will be broken due to wrong pin muxing when both CONFIG_NAND
> and CONFIG_EMMC_BOOT are enabled. And we can't fix pin muxing, because
> it relies on compile-time configuration, because we don't have means
> to figure out configurations like BBB + NAND cape in run-time. So the
> only way I see to provide a way to store ENV on eMMC is to keep
> separate config.
> 
> I agree that commit message should be fixed. Also, maybe we should
> rename configs like this:
> 
>    - am335x_evm_defconfig -> am335x_nand_defconfig
>    - am335x_boneblack_defconfig -> am335x_emmc_defconfig> Do you think it's correct way to do so? Or some better way exists?
> 
> Thanks!
> 
>> Thanks and regards,
>> Lokesh
>>
>>> update this defconfig by enabling Driver Model and pulling some other
>>> useful options from am335x_evm_defconfig.
>>>
>>> Fixes: 8fa7f65dd02c ("configs: Remove am335x_boneblack_defconfig")
>>> Signed-off-by: Sam Protsenko <semen.protsenko at linaro.org>
>>> ---
>>> Changes in v2:
>>>   - improve commit message by saying explicitly about eMMC env
>>>
>>>  configs/am335x_boneblack_defconfig | 50 ++++++++++++++++++++++++++++++
>>>  1 file changed, 50 insertions(+)
>>>  create mode 100644 configs/am335x_boneblack_defconfig
>>>
>>> diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
>>> new file mode 100644
>>> index 0000000000..439d0cba05
>>> --- /dev/null
>>> +++ b/configs/am335x_boneblack_defconfig
>>> @@ -0,0 +1,50 @@
>>> +CONFIG_ARM=y
>>> +CONFIG_ARCH_OMAP2PLUS=y
>>> +CONFIG_TI_COMMON_CMD_OPTIONS=y
>>> +CONFIG_AM33XX=y
>>> +CONFIG_SPL=y
>>> +CONFIG_DISTRO_DEFAULTS=y
>>> +CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
>>> +CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run envboot; run distro_bootcmd"
>>> +CONFIG_SYS_CONSOLE_INFO_QUIET=y
>>> +CONFIG_VERSION_VARIABLE=y
>>> +CONFIG_ARCH_MISC_INIT=y
>>> +CONFIG_SPL_MUSB_NEW_SUPPORT=y
>>> +# CONFIG_SPL_NAND_SUPPORT is not set
>>> +CONFIG_SPL_OS_BOOT=y
>>> +CONFIG_AUTOBOOT_KEYED=y
>>> +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
>>> +CONFIG_AUTOBOOT_DELAY_STR="d"
>>> +CONFIG_AUTOBOOT_STOP_STR=" "
>>> +CONFIG_CMD_SPL=y
>>> +# CONFIG_CMD_FLASH is not set
>>> +# CONFIG_CMD_SETEXPR is not set
>>> +CONFIG_ENV_IS_IN_MMC=y
>>> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>>> +CONFIG_BOOTCOUNT_LIMIT=y
>>> +CONFIG_DFU_TFTP=y
>>> +CONFIG_DFU_MMC=y
>>> +CONFIG_DFU_RAM=y
>>> +CONFIG_USB_FUNCTION_FASTBOOT=y
>>> +CONFIG_FASTBOOT_FLASH=y
>>> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>>> +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>>> +CONFIG_MMC_OMAP_HS=y
>>> +CONFIG_SPI_FLASH=y
>>> +CONFIG_SPI_FLASH_WINBOND=y
>>> +CONFIG_MII=y
>>> +CONFIG_DRIVER_TI_CPSW=y
>>> +CONFIG_SPI=y
>>> +CONFIG_OMAP3_SPI=y
>>> +CONFIG_USB=y
>>> +CONFIG_USB_MUSB_HOST=y
>>> +CONFIG_USB_MUSB_GADGET=y
>>> +CONFIG_USB_MUSB_DSPS=y
>>> +CONFIG_USB_GADGET=y
>>> +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
>>> +CONFIG_USB_GADGET_VENDOR_NUM=0x0451
>>> +CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
>>> +CONFIG_USB_ETHER=y
>>> +CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
>>> +CONFIG_LZO=y
>>> +CONFIG_OF_LIBFDT=y
>>>


More information about the U-Boot mailing list