which nightly image for cubox

1st Official Post

    I have a Cubox i4 and wanted to test LE 9,8 nightly build.

    On the download page I find two images:

    -cubox-dl.img.gz 

    -cubox-q.img.gz

    Which one to use? What ist the differnce between this two images? I Could't find any explanation.

    Thanks

    • Official Post

    Do you have the cubox quad or the dual lite model?

    chewitt, you should know that I had better idea years back because I actually know how u-boot works on this SoC. But no one listen. And now I don't care anymore (but it still hurts after all this time).

    • Official Post
    Quote from vpeter

    chewitt, you should know that I had better idea years back because I actually know how u-boot works on this SoC. But no one listen. And now I don't care anymore (but it still hurts after all this time).

    It doesn't really matter how u-boot works. It was done the way it was because it can be the same for all supported SOCs. Likely this can be improved now to combine a few similar boards but it works well the way it does.

    lrusak, you are still talking nonsense ?( And doesn't care for users to make theirs live easier. And this post is proof: user doesn't need to know if he have dual or quad soc in his device. At least for i.MX6.

    chewitt, sorry but my i.MX6 days are past (and ruined thanks to LE). And you seem to have expert just few posts above.

    • Official Post

    vpeter so I can see that the dual/quad versions all share the same u-boot defconfig, which supports the idea of consolidating images to three: cubox, udoo, wandboard. I can also see that wandboard has more dtb's than we currently create images for (revb1, revd1 were added upstream). It's simple to repackage and accomodate that, see Commits · chewitt/LibreELEC.tv · GitHub and I think the simplicity of image naming trumps adding more dedicated images (and I'm doing the same thing with Odroid N2/N2+ in the next Amlogic bump). I'm interested to know what happens when users with a quad board don't change the dtb name and boot using the dual dtb? (or should the defaults be switched to quad?). Also, looking at the device-tree files in the kernel, didn't we (you) also used to ship an image for the Hummingboard devices?

    Quote from chewitt

    I'm interested to know what happens when users with a quad board don't change the dtb name and boot using the dual dtb? (or should the defaults be switched to quad?). Also, looking at the device-tree files in the kernel, didn't we (you) also used to ship an image for the Hummingboard devices?

    Users don't need to set any dtb name because all magic is happening automatically in u-boot. U-boot for solidrun check the SoC type and sets one part of the dtb (imx6dl or imx6q). Then it also checks the SoM type (cubox, hummingboard, hummingboard2) and at the end also SoM revision (v15 or nothing). So same image runs on every device from solidrun without knowing what type it is and without setting dtb name. Same thing is happening on u-boot for Wandboard and Udoo. But there is probably just setting SoC type (at least this was true for Udoo when I add support for it).

    But maybe mainline u-boot remove or broke all those things ;(

    So lrusak: you still think it doesn't matter how u-boot works? 8o

    • Official Post

    It looks like that logic has been ported to mainline u-boot: include/configs/mx6cuboxi.h · master · U-Boot / U-Boot · GitLab and there are similar configs for udoo and wandboard. It's not clear to me what changes might be needed for filenames and/or other files in the boot partition, I'm not sure extlinux is the best option here. Anyway.. it's late o'clock here so something to look into over the weekend.

    • Official Post
    Quote from vpeter

    Users don't need to set any dtb name because all magic is happening automatically in u-boot. U-boot for solidrun check the SoC type and sets one part of the dtb (imx6dl or imx6q). Then it also checks the SoM type (cubox, hummingboard, hummingboard2) and at the end also SoM revision (v15 or nothing). So same image runs on every device from solidrun without knowing what type it is and without setting dtb name. Same thing is happening on u-boot for Wandboard and Udoo. But there is probably just setting SoC type (at least this was true for Udoo when I add support for it).

    But maybe mainline u-boot remove or broke all those things ;(

    So lrusak: you still think it doesn't matter how u-boot works? 8o

    I'm aware of this logic. The problem is that this is only the case for a few platforms within iMX6 u-boot. Other platforms don't operate like this and I would rather leave it generic than change it because of some boards on one platform. So the user has to flash the correct image the first time they install it. It's 50/50 anyways.

    We also use extlinux and write the dtb filename to the extlinux.conf file at build time. This doesn't support specifying more than one dtb.

    I can only think: OMG. You should just say "I don't know how to do this generic for ALL devices including iMX6". Because I really doubt that there are technical incapacity.

    And why do you have to set dtb file anyway? Leave this to u-boot. Like this: Cubox-i - Gentoo Wiki I don't see file specified there.

    Anyway, I just had to to point on a stupid thing taking years. And it seems situation will just be like that forever. Good job!

    I guess we can boot all iMX6 targets with one image using boot.scr

    I tried this with Wandboard B1 and C1 and it works.

    The script I used:

    Code
    setenv image "/KERNEL"
setenv bootargs "boot=UUID=2511-1511 disk=UUID=3a00fe1a-8c24-42fd-83ae-69c4a2043aa0 quiet console=ttymxc0,115200"
load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${image}
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${fdtfile}
bootz ${kernel_addr_r} - ${fdt_addr_r}
    • Official Post
    Quote from by-gnome

    I guess we can boot all iMX6 targets with one image using boot.scr

    I tried this with Wandboard B1 and C1 and it works.

    The script I used:

    Code
    setenv image "/KERNEL"
setenv bootargs "boot=UUID=2511-1511 disk=UUID=3a00fe1a-8c24-42fd-83ae-69c4a2043aa0 quiet console=ttymxc0,115200"
load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${image}
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${fdtfile}
bootz ${kernel_addr_r} - ${fdt_addr_r}

    No one wants to use boot.scr files. If it works for you, awesome, but it doesn't work for the LibreELEC project as a whole.

    Because I was bored today I looked this issue just for fun. Like Gentoo Wiki link I posted.

    After examining how U-Boot works with extlinux.conf I noticed that there is a tag named FDTDIR which specifies the directory where FDT files are located. The actual filename is set by U-Boot and allows booting similar devices from same image. The requirement is that all dtb files must be in some folder pointed by FDTDIR tag.

    So there is no need to use 2 (or more) images and follows LE way of using modern extlinux.conf :)

    Seems I'm still the most knowledgeable man with i.MX6Q U-Boot :)

    Code
    LABEL LibreELEC
LINUX /KERNEL
FDTDIR /
APPEND boot=UUID=2812-4128 disk=UUID=0ed065e2-54e6-47ca-95e5-47a652053a43 quiet console=ttymxc0,115200 console=tty0