[Buildroot] [PATCHv3] beaglebone: add BeagleBone Black support

Thiago A. Corrêa thiago.correa at gmail.com
Thu Nov 7 19:30:21 UTC 2013


I was looking at the other mails about bbb, and there was also a patch
to enable the add on boards (capes). If we consider that patch, then
it would be better to keep this patch with the linux config as it is
right now, which supports most of the capes peripherals.

Is there anything else that is keeping this patch from being accepted?
If so, would it be ok if I make the changes in follow up patches?

Kind Regards,
     Thiago A. Correa


On Thu, Nov 7, 2013 at 12:01 PM, Jason Kridner <jkridner at beagleboard.org> wrote:
> On Thu, Nov 7, 2013 at 7:28 AM, Thiago A. Corrêa
> <thiago.correa at gmail.com> wrote:
>> I was looking forward to this being accepted in buildroot.
>>
>> Jason, could you send a V4 with the trimmed kernel config? Or Peter,
>> could we accept this patch and make changes with follow up patches?
>
> It's on my to-do list, but messing with the 3.12 kernel is higher
> priority right now.
>
>>
>> Kind Regards,
>>      Thiago A. Correa
>>
>>
>> On Tue, Oct 15, 2013 at 4:27 PM, Arnout Vandecappelle <arnout at mind.be> wrote:
>>> [Peter in CC to answer the question which kernel config is preferred]
>>>
>>>
>>>
>>> On 15/10/13 03:57, Jason Kridner wrote:
>>>>
>>>> On Mon, Oct 14, 2013 at 6:39 PM, Arnout Vandecappelle <arnout at mind.be>
>>>> wrote:
>>>>>
>>>>>   Hi Jason,
>>>>>
>>>>>
>>>>> On 11/10/13 22:09, Jason Kridner wrote:
>>>
>>> [snip]
>>>
>>>>>   However, using ext2 for a ramdisk image is horribly inefficient. You'd
>>>>> normally use a cpio image. Also, lzma (smaller size) or lzop (larger but
>>>>> faster uncompression) are better choices than gzip.
>>>>
>>>>
>>>> I thought I had pushback on using initramfs, which is what I'd prefer
>>>> to have as the default. I'm simply trying to minimize the patch to get
>>>> Black in there in the defaults.
>>>
>>>
>>>  Fair enough. Switching to cpio (and lzma or lzop) can be done later.
>>>
>>>  Actually, I'm not sure what "pushback" means. Does that mean you got
>>> approval or opposition?
>>>
>>>  Looking back at the earlier conversation (which I didn't really follow),
>>> you wrote about initramfs:
>>>
>>>> Just enabling rapid testing. This can boot off of a FAT formatted SD
>>>> card, over USB, over serial or over Ethernet without passing a
>>>> separate ramdisk. The ext2 required a separate download or special
>>>> formatting of the card and wasted memory if used as a ramdisk.
>>>> Nothing too special here, but it simplifies use as a recovery system,
>>>> validation system or bootloader.
>>>
>>>
>>>  The cpio image will achieve exactly the same, but more efficiently - you
>>> just need the additional mkimage step and the uEnv.txt to load it. Maybe
>>> that's what you really want to avoid with the initramfs?
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>    # mkimage -A arm -O linux -T ramdisk -C gzip -a 0x81000000 -d
>>>>>> rootfs.ext2.gz ramdisk.gz
>>>>>
>>>>>
>>>>>
>>>>>   Ideally, you should make a post-image script
>>>>> (BR2_ROOTFS_POST_IMAGE_SCRIPT)
>>>>> in the board/beaglebone directory that does these steps automatically.
>>>>> And
>>>>> since this script uses mkimage, I'd also explicitly enable
>>>>> BR2_PACKAGE_HOST_UBOOT_TOOLS (even though it is implicitly build for the
>>>>> kernel uImage).
>>>>
>>>>
>>>> Thanks for pointing this out and I'll certainly make personal use of
>>>> it. I'm doubtful if including it would help get my patch accepted.
>>>
>>>
>>>  We're moving in the direction that the board configs should produce
>>> something that can be copied easily on an SD card to boot the board. So yes,
>>> it would help. But as mentioned before, it may help even more if it's in a
>>> follow-up patch.
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>    # The URL is where I stored the ouptut of 'make beaglebone_defconfig;
>>>>>> make'
>>>>>>    $ wget -r
>>>>>>
>>>>>> https://s3.amazonaws.com/beagle/buildroot/2013-10-11-16%3A52%3A21/index.html
>>>>>>    $ cd s3.amazonaws.com/beagle/buildroot/2013-10-11-16:52:21
>>>>>>    $ cat >uEnv.txt <<EOF
>>>>>>    bootpart=0:1
>>>>>>    bootdir=
>>>>>>    uenvcmd=run loaduimage;run loadramdisk;run findfdt;run loadfdt;run
>>>>>> ramboot
>>>>>>    EOF
>>>>>
>>>>>
>>>>>
>>>>>   You can add uEnv.txt to board/beaglebone and copy it to images/ in the
>>>>> post-image script.
>>>>
>>>>
>>>> k, but again, I'm not sure if it is desired upstream. If I add it to
>>>> v4, will it get accepted?
>>>
>>>
>>>  I think so, yes. Note that this step is only relevant if you also create
>>> the ramdisk image. So again, maybe better for a follow-up patch.
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>    # With /mnt being a FAT formatted uSD card with partition marked as
>>>>>> bootable
>>>>>>    $ cp MLO u-boot.img uImage ramdisk.gz uEnv.txt *.dtb /mnt
>>>>>>    # eject /mnt
>>>>>>    # Insert uSD card into BeagleBone Black
>>>>>>    # Hold "BOOT" button
>>>>>>    # Apply power and release "BOOT" button
>>>>>>    # Serial log at screenlog.0
>>>>>
>>>>>
>>>>>
>>>>>   With the post-image script, the readme can be limited to these 7 lines
>>>>> :-)
>>>>>
>>>>>
>>>>>>
>>>>>> Ideally for me, I'd switch to an initramfs and patch u-boot to avoid
>>>>>> uEnv.txt,
>>>>>> but I'll do that separately.
>>>>>
>>>>>
>>>>>
>>>>>   I'm not a fan of initramfs because every rootfs change requires a slow
>>>>> re-link of the kernel... And I don't see the harm in uEnv.txt.
>>>>
>>>>
>>>> k, but you want a cpio image instead of a ramdisk? I guess I'll take a
>>>> look at how to use a cpio image as an initrd.
>>>
>>>
>>>  It's used exactly the same. The difference is that you don't have ext2
>>> filesystem overhead - the cpio image is copied into a tmpfs, and then
>>> removed.
>>>
>>>
>>>
>>>> What I'd like to know is what will be accepted upstream. I feel like I
>>>> am wasting my time right switching approaches that don't have that
>>>> much to do with BeagleBone Black when what I most fundamentally want
>>>> to introduce is a pointer to a different kernel and the combination of
>>>> .dtb files for BeagleBone and BeagleBone Black.
>>>
>>>
>>>  Good point.
>>>
>>> [snip]
>>>
>>>>>> ---
>>>>>>    board/beaglebone/linux-3.8.config | 1035
>>>>>> ++++++++++++++++++++++++++++++++++---
>>>>>>    configs/beaglebone_defconfig      |   13 +-
>>>>>>    2 files changed, 975 insertions(+), 73 deletions(-)
>>>>>>
>>>>>> diff --git a/board/beaglebone/linux-3.8.config
>>>>>> b/board/beaglebone/linux-3.8.config
>>>>>> index 4242771..08ab221 100644
>>>>>> --- a/board/beaglebone/linux-3.8.config
>>>>>> +++ b/board/beaglebone/linux-3.8.config
>>>>>> @@ -1,103 +1,409 @@
>>>>>>    CONFIG_EXPERIMENTAL=y
>>>>>> -CONFIG_DEFAULT_HOSTNAME="beaglebone"
>>>>>> +CONFIG_KERNEL_LZO=y
>>>>>>    CONFIG_SYSVIPC=y
>>>>>>    CONFIG_POSIX_MQUEUE=y
>>>>>>    CONFIG_NO_HZ=y
>>>>>>    CONFIG_HIGH_RES_TIMERS=y
>>>>>>    CONFIG_BSD_PROCESS_ACCT=y
>>>>>> +CONFIG_BSD_PROCESS_ACCT_V3=y
>>>>>> +CONFIG_TASKSTATS=y
>>>>>> +CONFIG_TASK_DELAY_ACCT=y
>>>>>> +CONFIG_TASK_XACCT=y
>>>>>> +CONFIG_TASK_IO_ACCOUNTING=y
>>>>>
>>>>>
>>>>>
>>>>>   You're adding a lot of kernel features here that were not enabled
>>>>> before.
>>>>> We generally prefer the kernel configs to be pretty minimal (except that
>>>>> all
>>>>> drivers for hardware that is present on the board should be included, of
>>>>> course. What's the history of this kernel config? You don't mention it at
>>>>> all in the commit message.
>>>>
>>>>
>>>> This comes from the kernel config we use in the demo image shipped
>>>> with the boards.
>>>>
>>>> https://github.com/beagleboard/kernel/commits/3.8/configs/beaglebone
>>>>
>>>> Should I include a link like this?
>>>>
>>>> I can use something more minimal, but the idea was to try to provide
>>>> something that showed off as much capability as possible. I'll see
>>>> what I can cut out.
>>>
>>>
>>>  If it's an upstream defconfig, I think it's OK as it is.
>>>
>>>  It looks like you have commit access to the beagleboard linux tree on
>>> github; perhaps you can add the beaglebone defconfig to arch/arm/configs,
>>> where it belongs? Then you can use BR2_LINUX_KERNEL_USE_DEFCONFIG.
>>>
>>>  I think we would prefer that approach rather than a buildroot-specific
>>> defconfig, because it makes bumping the kernel version easier. Peter, can
>>> you confirm that an upstream defconfig is preferred even if it is not
>>> minimal?
>>>
>>>  If an in-kernel defconfig is not possible for whatever reason, you can
>>> leave the defconfig as it is and mention in the readme and/or the commit
>>> message where it comes from.
>>>
>>>
>>> [snip]
>>>
>>>>>> +CONFIG_MTD=y
>>>>>
>>>>>
>>>>>
>>>>>   Beaglebones don't even have any flash, right?
>>>>
>>>>
>>>> They have eMMC, which isn't the same as MTD, so, right, there isn't
>>>> any MTD flash built-in. However, with add-on board it is possible to
>>>> add it. Many of the things added are for being able to support add-on
>>>> boards.
>>>
>>>
>>>  Ah of course. But I guess only EEPROM is relevant then - or is the GPMC bus
>>> exported on the cape connector?
>>>
>>>
>>> [snip]
>>>
>>>>>>
>>>>>> -BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git"
>>>>>>
>>>>>>
>>>>>> -BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="935f6c2f82056d538b528272e2bdbb5c08d69a58"
>>>>>>
>>>>>>
>>>>>> +BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://github.com/beagleboard/linux.git"
>>>>>>
>>>>>>
>>>>>> +BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="ddd36e546e53d3c493075bbebd6188ee843208f9"
>>>
>>>
>>>  Didn't notice before, but: on github you can download it as a tarball.
>>> That's factors faster than cloning a git repository.
>>>
>>>  Regards,
>>>  Arnout
>>>
>>>
>>>
>>>>>>    BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
>>>>>>
>>>>>> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/beaglebone/linux-3.8.config"
>>>>>>    BR2_LINUX_KERNEL_DTS_SUPPORT=y
>>>>>> -BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-bone"
>>>>>> +BR2_LINUX_KERNEL_USE_INTREE_DTS=y
>>>>>> +BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-bone am335x-boneblack"
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Arnout Vandecappelle                          arnout at mind be
>>>>> Senior Embedded Software Architect            +32-16-286500
>>>>> Essensium/Mind                                http://www.mind.be
>>>>> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
>>>>> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>>>>> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Arnout Vandecappelle                          arnout at mind be
>>> Senior Embedded Software Architect            +32-16-286500
>>> Essensium/Mind                                http://www.mind.be
>>> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
>>> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>>> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot



More information about the buildroot mailing list