2 2
Brad

Bring up for Odroid N2 (Meson G12B)

Recommended Posts

(edited)

I know this is not the correct area (I have no permissions to post there) but i'm looking to add some basic support for Odroid N2 (and a mainline linux kernel) which others can help utilise for development purposes.

 

Its very early stages as the board was released to testers only weeks ago and for the moment only vendor uboot is working so what is best practice here for Armbian?  The old Odroid C2 way of things with uboot might some back for a bit ;) as much as I would like it or not.

 

Baylibre and Neil Armstrong have made a very good start (Thanks Neil!!!!)  with alpha style patches for 5.0 and N1.  Although there priorities will be working to implement a similar SOC,  the g12a.   Much of this work (and their previous work on amlogic drivers) appear to work with g12b (Odroid N2).  https://gitlab.com/superna9999/linux/commits/amlogic/v5.1/g12b

 

I would think to aim at -next, armbian -dev or 5.1, have a very basic working kernel with minimal support at the moment running a hardkernel vanilla ubuntu....

 

- mmc working

- hdmi working

- USB limited to usb2 devices only (usb3 on its way)

- Ethernet working with kernel config mods (not irq, only polled but works relatively well)

- sd seems to have issues but maybe my card/setup

- much untested

 

Thanks,

Brad.

Edited by Brad

Share this post


Link to post
Share on other sites
5 hours ago, Tido said:
10 hours ago, Brad said:

so what is best practice here for Armbian?

@chwe, wrote a nice possible approach over here: https://forum.armbian.com/topic/9226-rockpi-4b-board-bring-up/

well it's just a workflow for an already supported board/SoC. Here we might have to sort out a bit more to get it working (never the less, the basic patch workflow is there).... ;)

 

10 hours ago, Brad said:

I would think to aim at -next, armbian -dev or 5.1, have a very basic working kernel with minimal support at the moment running a hardkernel vanilla ubuntu.... 

 

next and dev for meson64 are based on a vanilla kernel see: https://github.com/armbian/build/blob/5cabcca6b5a32cc7da8837773190e9ea067c78fe/config/sources/meson64.conf#L34-L49

 

probably you would need to make some exceptions for u-boot to ensure the bsp u-boot is used as long as there's no chance to patch upstream u-boot with the missing bits. We have already examples where we did it (e.g. the C2 had some history in being unique... https://github.com/armbian/build/blob/ad8c89db50256cf474c59279491bc47a30f482f0/config/sources/meson64.conf#L13-L17).

 

10 hours ago, Brad said:

best practice here for Armbian?

Start with it, report where you struggle and hope that one of us can give you a hint here and there to fix it. Cause (to my knowledge) non of us has the board at hand, we can only help with buildscript related issues. For sure, you need to do a lot of work on your own and you'll fail a few times that's normal. :P It's a way easier if you've some experience with kernel patching but even without you can learn it.

 

Make sure you've a USB-UART adapter to get out bootlogs of your fails.. Bordbring up without it isn't fun..

Share this post


Link to post
Share on other sites

OK thanks guys,  I will make a start and see how it goes., will take me a few days.    I notice -next is linux-4.19.y which will be more difficult than a 5.0 release but I should be able to muster up patches for 4.19.y easy enough I am hoping.  Is there a planned schedule for -next to go to 5.x?

 

It will need some patches on top of meson64 for the moment but should eventually be fully supported with Meson64 kernel.

Share this post


Link to post
Share on other sites
3 minutes ago, Brad said:

OK thanks guys,  I will make a start and see how it goes., will take me a few days.    I notice -next is linux-4.19.y which will be more difficult than a 5.0 release but I should be able to muster up patches for 4.19.y easy enough I am hoping.  Is there a planned schedule for -next to go to 5.x?

 

If you fork it, you can switch to 5.0 with next whenever you want.. Probably some patches will break and need some fixing (often trivial ones).. Actually I  would switch the dev kernel to 5.0 for that.. IMO it's good to have next on LTS kernels to avoid screw up boards running in production (cause they're quite often on next).

Share this post


Link to post
Share on other sites
3 hours ago, Brad said:

Is there a planned schedule for -next to go to 5.x?

 

At the point I have confidence in 4.19 being a suitable replacement for 4.14 on default (there were still some HDMI bugs on last test, although that's been a few weeks).  Then some interesting tests need to happen, like will the 4.19 stuff boot from the old bootloader, etc etc since As @chwe says, Dev is the preferred target for 5.x right now as it is development

Share this post


Link to post
Share on other sites
On 3/6/2019 at 11:35 AM, TonyMac32 said:

https://baylibre.com/u-boot-v2019-01-released-contributions/

 

So.  U-boot may be possible with upstream, but of course, as always, you have to build the crusty vendor garbage first to get the super-secret blob-tastrophy of doom.  Once you have the blobs, then you can build mainline u-boot like we do for Meson GX(L)

 

 

I tried to add bsp uboot support but failing to compile the BL301 as it requires a 2nd old toolchain and I don't favor the complexity it will add in lib/compiler.sh.  Maybe I can use something similar to https://github.com/armbian/odroidc2-blobs instead.

 

I also took a look at the mainline uboot changes from baylibre you linked, I think this will be the way to go as it means no downloading old toolchains if I can also make something like https://github.com/armbian/odroidc2-blobs for the builder to use.

 

Share this post


Link to post
Share on other sites
5 hours ago, Brad said:

Maybe I can use something similar thttps://github.com/armbian/odroidc2-blobs instead.

Well yes, you fork the BSP u-boot, compile it, then use the blobs in your process of building upstream.  Of course, you have to spit out the operations performed by the BSP to glue the blobs to the u-boot image.  But, you have to have the original sources available for the blobs you are using to avoid any licensing funny business.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
2 2