Re: [Buildroot] Interested in board support for BeagleV-Ahead

[Kilian Zinnecker via buildroot <buildroot@buildroot.org>]

Hello Robert,

[--SNIP--]

> > > BTW, i've created a special u-boot branch for mainline gcc situations,
> > > with *-ubuntu extension on the branch..
> > > 
> > > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-u-boot/-/tree/be
> > > agle v-v2020.01-1.1.2-ubuntu
> > 
> > So should I try using that branch then?
> 
> Correct, for u-boot, use that branch, that'll get things to build with
> gcc-13.x ;)

I already tried and it did build - thanks!

[--SNIP--]

> Nope, the mainline isn't really ready, unless you like hardware bring
> up, our microSD/eMMC is still in RFC and only one core works!
> 
> I just forked the linux branch:
> 
> https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/commits/beag
> lev-v5.10.113-1.1.2-ubuntu
> 
> Please use this one for gcc-12/gcc-13/etc...  The "*-ubuntu" branch
> name is to signify ubuntu/mainline toolchain and not the forked THEAD
> vector one..  So let's patch it up to work with
> x86_64-gcc-13.2.0-nolibc-riscv64-linux.tar.xz

kk, I will also use the *ubuntu branch for the beaglev-ahead-linux kernel.

> > You seem to also be a maintainer for the "beaglev-ahead-linux" repository?
> > Is the light_defconfig the proper one for the beaglev-ahead? What do you
> > think about the issues I encountered regarding vector extension v0.7.1
> > and recent gcc apparently not supporting it? What do you think about
> > maybe removing the CONFIG_VECTOR flags from the light_defconfig?
> 
> Yeah for the -ubuntu branch, we need to just disable vector, the revos
> guys have done this, i need to cherry pick it..

Thanks! No hurries though, it currently works with the linux.fragment file I 
created.

> > https://git.beagleboard.org/beaglev-ahead/beaglev-ahead-linux/-/blob/beagl
> > ev-v5.10.113-1.1.2/arch/riscv/configs/light_defconfig#L21-22
> Our shipping defconfig is: beaglev_defconfig the light_defconfig is
> the vendor example, they were targeting a basic yocto build..

Thanks, I didn't know. To be honest I find it a bit confusing that it is called 
beaglev_defconfig, because afaik there exists a BeagleV board, without the "-
Ahead" suffix (https://old.beagleboard.org/static/beagleV/beagleV.html). So if I 
don't know any better, I would assume that a beaglev_defconfig would correspond 
to the BeagleV and not to the BeagleV-Ahead.

[--SNIP--]

> > And one more question: I was able to generate some binaries, but so far I
> > don't have a clue how to assemble them to a proper image and how I would
> > flash that image to the BeagleV-Ahead's eMMC. Do you happen to have some
> > hint(s) for me, e.g., some link, some documentation, anything?
> 
> Okay, this is where things get fun.. since we never got full docs on
> the bootrom, we've been just using the Android fastboot tools, to be
> fair the TH1520 actually implemented a lot of Android in the bootrom..
> 
> From buildroot, today we need 2 generic partitions, (we can do more
> custom, but that requires end users tweak u-boot's partition layout,
> since we u-boot/fastboot to copy the partitions)..
> 
> "boot", this is a 200 MB 'ext4' partition:
> 
> You 'need' two magical closed source bins:
> 
> https://git.beagleboard.org/beaglev-ahead/xuantie-ubuntu/-/tree/master/bins
> 
> light_aon_fpga.bin
> light_c906_audio.bin
> 
> light_aon_fpga.bin: "aon" is an `Always On` fpga binary used for power
> management... If you don't have this, the board will boot, but things
> like cpufreq don't work..
> light_c906_audio.bin: Probably Audio, never really tested it too much...
> 
> Then fw_dynamic.bin from OpenSBI
> 
> Then Image from the linux kernel along with all *.dtb's
> 
> Special directory for all device-tree overlays *.dtbo's
> 
> ./overlays/
> 
> Then "extlinux.conf" for distroboot..
> 
> Our default is:
> 
> ```
> label Linux eMMC
>     kernel /Image
>     append root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait
> console=ttyS0,115200 earlycon clk_ignore_unused net.ifnames=0
>     fdtdir /
>     #fdtoverlays /overlays/<file>.dtbo
> ```
> 
> In the end, boot partition will look like:
> 
> ```
> ./ignore/.boot/
> ├── extlinux
> │   └── extlinux.conf
> ├── fw_dynamic.bin
> ├── Image
> ├── light_aon_fpga.bin
> ├── light-beagle.dtb
> ├── light_c906_audio.bin
> └── overlays
>     ├── BBORG_LOAD-00A2.dtbo
>     ├── BBORG_RELAY-00A2.dtbo
>     ├── BONE-LED_P8_03.dtbo
>     ├── BONE-LED_P9_11.dtbo
>     └── BVA-MIKROBUS-0.dtbo
> ```
> 
> Now here's the tricky part, I assume Buildroot can build whatever this
> is called from "mkfs.ext4"..
> 
> This is the first piece of hardware where I've just dumped everything
> into a directory and created a partition "-F" file with a "-d", so
> kinda cool..
> 
> ```
> dd if=/dev/zero of=./deploy/boot.ext4 bs=1 count=0 seek=190M
> mkfs.ext4 -F ./deploy/boot.ext4 -d ./ignore/.boot
> ```
> 
> That createst the boot.ext4 we dump thru Android tools..
> 
> The RootFS is pretty generic, note the 3rd partitions offset:
> `/dev/mmcblk0p3`
> 
> Our default etc/fstab is:
> /dev/mmcblk0p2  /boot/firmware/ auto  defaults  0  2
> /dev/mmcblk0p3  /  auto  errors=remount-ro  0  1
> debugfs  /sys/kernel/debug  debugfs  mode=755,uid=root,gid=gpio,defaults  0 
> 0'
> 
> Similar to generate rootfs.ext4:
> 
> ```
> dd if=/dev/zero of=./deploy/root.ext4 bs=1 count=0 seek=4000M
> mkfs.ext4 -F ./deploy/root.ext4 -d ./ignore/.root
> ```
> 
> 4000M was only set as we had large rootfs, tailor to what you need..
> 
> On first bootup, we just have systemd call:
> 
> ```
> /usr/sbin/resize2fs /dev/mmcblk0p3
> ```
> 
> The nice thing, android tools already extended the partition fully, we
> just need to tell ext4 to use it all..
> 
> Our generic flashing script is:
> 
> ```
> #!/bin/bash
> 
> if ! id | grep -q root; then
> echo "./fastboot_emmc.sh must be run as root:"
> echo "sudo ./fastboot_emmc.sh"
> exit
> fi
> 
> fastboot flash ram ./u-boot-with-spl.bin
> fastboot reboot
> sleep 10
> fastboot oem format
> fastboot flash uboot ./u-boot-with-spl.bin
> fastboot flash boot ./boot.ext4
> fastboot flash root ./root.ext4
> fastboot reboot
> ```
> 
> fastboot oem format = this will actually partition the eMMC based on
> what we defined in u-boot..
> 
> u-boot-with-spl.bin is magically stored in partition1..
> 
> As you develop your patchset, since uboot, boot and root are sorta
> independent partitions, you can flash only what you are working on and
> testing.. for OpenSBI and U-boot, just update u-boot/boot... for
> kernel, just boot/root..

Thanks a lot for all the info! I must admit I am very unexperienced with much 
of this, so I will try, and thereby maybe do something wrong and then maybe 
ask some more questions about it. 

> Side-note-extra credit.. We are working on distro extlinux support to
> just boot off microSD using the eMMC's parttion1/2 as a generic
> 'bootloader'..  We did have one user on our forum, get the "microSD"
> boto to actually work... once...  Vendor refused to share how to do
> that, i was amazed user got it to work, but since then it's not
> booting..  I think we are just going to asume eMMC will be the generic
> bootloader going forward..

Yeah, that "Kilian" on the BeagleBoard forum is actually me :D
I am super sorry: I cannot reproduce what I did myself and I also don't know 
so much what is going on. The boot log I posted is really true. I still have 
that exact SD card and today it still booted. I however could not reproduce it 
with another SD card, which is of the same type. Tbh. I have no clue ...

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot