Add proper support for openwrt and ramdisk image.

[Mat-Alm]

Hello! Any one are interested to add proper support for openwrt on ssd202d devices? There is some repos from wireless-tag and quite hacky and does not works properly. I can't even make it boots. It just stuck at kernel loading. Just one question how to build and boot a ramdisk from the chenxing repo for testing purposes?

Thanks for your hard working!

B.R

[fifteenhex]

I'm not against it. I use buildroot for my stuff as that's what I'm used to.

[fifteenhex]

If the aim is to get stuff in mainline I can't really work against a kernel version that is multiple releases out of date.

If someone wants to take an LTS kernel and put the patches on top to make stuff work that can do that. I don't really have the time to do that. I think that might be difficult as well as stuff is still churning.

I think the delta between mainline and my tree needs to be much smaller before doing proper releases. To do that we need more people taking the commits, cleaning them up and sending them upstream.

[Mat-Alm]

I understand your "mainline" point... But I don't think in general this project will benefit of this, again in my opinion it's better to have a "stable version" not necessary the mainline.. Especially that to track it to mainline is really a big effort and "tomorrow a new kernel will be released" and more bugs to be fixed, more work etc.. I think merge board support (at least the same soc) will also be beneficial and avoid multiple repos for almost "the same stuff"

[fifteenhex]

I understand your "mainline" point... But I don't think in general this project will benefit of this

Mainline is the only thing I'm interested in to be honest. No one is paying me to do this so I decide what I want to do :)

again in my opinion it's better to have a "stable version" not necessary the mainline..

If you want to do that I can give you repo access to create a stable branch. I think though the effort is better spent on getting stuff mainlined. Say we get everything mainlined in the next 6 months. We might just hit the next LTS release with most stuff working. The amount of effort to maintain a stable release would be tiny after that.

Especially that to track it to mainline is really a big effort

From experience of rebasing my tree everyday for the last 3 years I don't think it is.
I rebase u-boot a lot less frequently and that is a massive pain because the if you don't rebase for a few months the amount of fixes you have to make to get your patches to apply increases a lot.

and "tomorrow a new kernel will be released" and more bugs to be fixed, more work etc..

That's not really how it works. I rebase everyday from Linus' master. Over the merge window period things get broken and I have to fix them up or revert things. Once rc1 is out anything going into Linus' master will be fixes and should not break anything.

I think merge board support (at least the same soc) will also be beneficial and avoid multiple repos for almost "the same stuff"

I'm not sure what this means really.

Anyhow, I'm not trying to be unpleasant. I'm just being honest. If you think there is a better way to do something you'll need to be the one to do it because my aim isn't to maintain some 3 or 4 release out of date franken kernel. If you need help to do what you want to do I can do that but I only have so much time.

[Mat-Alm]

ok! I got your points. But as I said for me it's quite hard to follow the development that is being done. (I'am not an expert on linux development btw). One small question... I managed to build the br2idosom2d01 repo and I get the output images. My board already comes with spl and uboot flashed. But I can't make ubbot load the idosom2d01-kernel-rescue.fit. What i made was just copy the files to and sd and copy it to the addr 0x22000000 and tried to boot it from bootm command but it simple refuses to boot(wrong kernel image). This image does need the uboot from this repo to get loaded? It's possible to use an external programmer to write uboot directly to the nand? Or I need to care about the nand oob stuff and so on?

[fifteenhex]

But as I said for me it's quite hard to follow the development that is being done.

That's probably because there isn't really a plan. I get stuff working as I work it out. We don't have a lot of documentation I'm working stuff out as I need it and then writing code.

My board already comes with spl and uboot flashed. But I can't make ubbot load the idosom2d01-kernel-rescue.fit.

If you have the original really old u-boot it can't load FIT images. It also doesn't handle passing the DTB to the kernel properly either.

If you use snander or the MStar ISP tool you can write bits the page linked on the idosom2d01 buildroot page and go from there.
It is possible to boot our kernel on the old u-boot but it's a pain.

[iamdavidcz]

If someone wants to take an LTS kernel and put the patches on top to make stuff work that can do that.

Sorry for interjecting you guys, but this is exactly what I want to achieve as a first step. I will probably choose linux-4.9.y branch, because vendor kernel is 4.9.84.

@fifteenhex Is there any reason why we don't follow the structure from the vendor kernel in the mainline kernel tree when it comes to dts files? I am aware that the vendor tree is a mess, but in the long run wouldn't it be better if we follow the vendor convention (more generic):

arch/arm/boot/dts/infinity2.dtsi
arch/arm/boot/dts/infinity2m-*.dts
arch/arm/boot/dts/infinity2-*.dts
arch/arm/boot/dts/infinity3-*.dts
arch/arm/boot/dts/infinity5.dtsi
arch/arm/boot/dts/infinity5-*.dts
arch/arm/boot/dts/infinity6b0.dtsi
arch/arm/boot/dts/infinity6b0-*.dts
arch/arm/boot/dts/infinity6.dtsi
arch/arm/boot/dts/infinity6e-*.dts
arch/arm/boot/dts/infinity6e.dts
arch/arm/boot/dts/infinity6e.dtsi
arch/arm/boot/dts/infinity6-*.dts

instead of introducing legacy mstar-infinity- prefix? I believe that infinity{2,2m,3,5,6,6b0,6e}- prefixes make more sense and are far more consistent with sun{4,5,6,7}i- from linux-sunxi.

[fifteenhex]

Is there any reason why we don't follow the structure from the vendor kernel in the mainline kernel tree when it comes to dts

Because mainline said to prefix all of our files with mstar-.

[iamdavidcz]

I am not sure that MStar Semiconductor still exists as a separate entity and their chips are rather obsolete, but if they said to do that...

[fifteenhex]

MStar is dead but the platform is called mstar because that's where is came from.. Like NXP stuff is still called freescale/fsl in the kernel

[ltrsunny]

Hello! Any one are interested to add proper support for openwrt on ssd202d devices? There is some repos from wireless-tag and quite hacky and does not works properly. I can't even make it boots. It just stuck at kernel loading. Just one question how to build and boot a ramdisk from the chenxing repo for testing purposes?

Thanks for your hard working!

B.R

I have tried rpi2's rootfs (21.02&22.03) with curent kernal, usable. I think you can start with arm_cortex-a7_neon-vfpv4 SDK.
I already gave up, Openwrt is a great OS with a disastrous building toolchain.