[U-Boot] [RFC] odroid DTB support

Tue Oct 13 12:15:24 CEST 2015

Hello,

On 10/13/2015 11:33 AM, Guillaume Gardet wrote:
> Hi Przemyslaw, Tom,
>
>
> Le 13/10/2015 11:11, Przemyslaw Marczak a écrit :
>> Hi Tom, Guillaume,
>>
>> On 10/13/2015 09:37 AM, Guillaume Gardet wrote:
>>>
>>>
>>> Le 12/10/2015 16:24, Tom Rini a écrit :
>>>> On Mon, Oct 12, 2015 at 10:54:04AM +0200, Guillaume Gardet wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> Le 12/10/2015 01:45, Tom Rini a écrit :
>>>>>> On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:
>>>>>>> Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :
>>>>>>>> Hello Guillaume,
>>>>>>>>
>>>>>>>> On 10/09/2015 02:11 PM, Guillaume Gardet wrote:
>>>>>>>>> Hi Przemyslaw,
>>>>>>>>>
>>>>>>>>> I would like to add DTB support for odroid board to be able to
>>>>>>>>> boot
>>>>>>>>> upstream kernel easily.
>>>>>>>>>
>>>>>>>>> I see 2 ways to do it:
>>>>>>>>> * Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support to set
>>>>>>>>> 'board_rev'
>>>>>>>>> and 'board_name' env vars. Then, you need a 'findfdt' script to
>>>>>>>>> check
>>>>>>>>> 'board_rev' and set fdtfile accordingly (as done for OMAP4 panda
>>>>>>>>> board)
>>>>>>>>> * Set fdtfile name directly (as done for rpi or igep00x0).
>>>>>>>>>
>>>>>>>>> What would you prefer?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Guillaume
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Is, that the reason of adding the boot script by your last patches?
>>>>>>> No, we need a boot script, because this is the way we boot our
>>>>>>> openSUSE images (we boot with an initrd and some special bootargs).
>>>>>> Hang on, exynos stuff uses the generic distro hooks.  Can you take a
>>>>>> look at doc/README.distro and see what openSUSE can hook into /
>>>>>> provide
>>>>>> some feedback on what needs doing?  Thanks!
>>>>> This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
>>>>> based) has no generic distro hooks at the moment.
>>>> No, exynos-common pulls in generic distro.  And in the event of boards
>>>> that do not the answer is to pull in the generic distro framework.
>>>
>>> It seems that exynos-common includes only "config_distro_defaults.h",
>>> not "config_distro_bootcmd.h".
>>> And "config_distro_bootcmd.h" is needed for generic distro boot flow. Am
>>> I missing something?
>>>
>>> Guillaume
>>>
>>>
>>
>> Tom,
>> it's true that, exynos5-common.h defines the
>> CONFIG_EXTRA_ENV_SETTINGS, which provides "BOOTENV".
>> Odroid XU3 redefines CONFIG_EXTRA_ENV_SETTINGS, but in the fact it
>> uses the same settings, appended by some private env variables.
>>
>> Guillaume,
>> You're right, Exynos4 boards doesn't use the generic distro boot
>> commands. And each board defines CONFIG_EXTRA_ENV_SETTINGS.
>
> Thanks for clarification.
>
>>
>> All boards works with the mainline kernel by default, so it's not a
>> high priority for us to switch it to common env, but will do this soon.
>
> ok.
>
>>
>> You can check the bootscript example in the directory:
>>  board/samsung/common/bootscripts/
>
> Here, if $fdtfile is not defined, then it boots without it. This won't
> work for us, since we need DTB (kernel multiplatform enabled).
>

Right, because it supports both fdt and non-fdt kernel images, the 
second one is to support old Hardkernel zImages.

Odroid XU3 defines fdtfile in board config extra envs, but the U3 sets 
it automatically on boot, since it supports both X2 and U3, the name 
depends on the board detection. This part of code is in set_board_info() 
in board/samsung/common/misc.c.

This is working well, if you have a minimum files on the boot partition 
(mmc 0:1):
- zImage
- exynos4412-odroidu3.dtb

then you will see:
---------------------------------------------------------------

Hit any key to stop autoboot: 0
reading exynos4412-odroidu3.dtb
46356 bytes read in 415 ms (108.4KiB/s)
reading uInitrd
** Unable to read file uInitrd **
reading zImage
5161952 bytes read in 685 ms (7.2 MiB/s)
Kernel image @ 0x40007fc0 [ 0x000000 - 0x4ec3e0]
## Flattened Device Tree blob at 40800000
Booting using the fdt blob at 0x40800000
Loading Device Tree to 4fff1000, end 4ffff513 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

---------------------------------------------------------------

After apply your patches and put the menioned boot.scr I can see this:

---------------------------------------------------------------
Hit any key to stop autoboot:0
reading boot.scr
3034 bytes read in 312 ms (8.8 KiB/s)
## Executing script at 42000000
Found kernel image: zImage
reading exynos4412-odroidu3.dtb
46356 bytes read in 415 ms (108.4 KiB/s)
Warning! Booting without RAMDISK: uInitrd!
reading zImage
5161952 bytes read in 686 ms (7.2 MiB/s)
Kernel image @ 0x40007fc0 [ 0x000000 - 0x4ec3e0 ]
## Flattened Device Tree blob at 40800000
  Booting using the fdt blob at 0x40800000
  Loading Device Tree to 4fff1000, end 4ffff513 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
---------------------------------------------------------------

So this works for my setup. Maybe you have a problem with the filesystem?

Please check it manual if you can load dtb file, if not, maybe you 
should do mkfs.ext4/vfat on your boot partition to clean in, and then 
check again.

>>
>> As temporary, your patch for Odroid can be applied to support the
>> boot.scr, but anyway it support mainline kernel and probably can boot
>> Ubuntu images.
>
> Yes, please apply it to get boot.scr support until odroid switch to
> generic boot system.
>

Yes, I will ack your patches. Do you use DFU or Lthor tools?
If, not this is useful tool, for testing e.g. your boot scripts,
and then you should add boot.scr to CONFIG_DFU_ALT(odroid.h), near the 
uInitrd entry.

>>
>> Some mainline release of U-Boot is used for Arch Linux images for
>> Odroid U3, you can check the changes for ARCH here:
>>
>> https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-odroid/0001-arch-linux-arm-modifications.patch
>>
>>
>> So if you need write custom boot.scr, maybe this will help you.
> Big patches! ^^ openSUSE workflow is different. We try to minimize
> source patches, upstream our patches and do our custom things in boot
> scripts which is much more flexible.
> Our boot.scr is (nearly) ready. The only thing missing is the fdtfile
> definition (which is board dependent). We hardcoded it to U3 version for
> now to make tests but this should be fixed.
>
>
> Guillaume
>
>

Ok, that's good approach.

>>
>> One more thing, if you need append the bootargs for your kernel, then
>> you can set the $opts variable which is always appended to bootargs.
>>
>> Best regards,
>
>

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com