Bring up for Odroid N2 (Meson G12B)

[Brad]

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 March 5, 2019 by Brad

[TonyMac32]

Cool.  I haven't paid much mind to the G12x stuff, will it need a separate kernel family from Meson64?

 

[Tido]

5 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/

 

[chwe]

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. 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..

[TonyMac32]

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)

 

 

[Brad]

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.

[chwe]

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).

[TonyMac32]

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

[Brad]

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.

 

[TonyMac32]

5 hours ago, Brad said:

Maybe I can use something similar to https://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.

[JuanjoAr]

Hi, I have an N2 and i have been running balbes150 version of armbian. maybe you can check out his build . i think it has basic support, but its been working as a local file/media/minecraft server for the last couple weeks without a fault. https://yadi.sk/d/srrtn6kpnsKz2/Linux/ARMBIAN/5.78_20190412/Odroid_N2

[Poincare]

On 4/27/2019 at 12:25 PM, JuanjoAr said:

Hi, I have an N2 and i have been running balbes150 version of armbian. maybe you can check out his build . i think it has basic support, but its been working as a local file/media/minecraft server for the last couple weeks without a fault. https://yadi.sk/d/srrtn6kpnsKz2/Linux/ARMBIAN/5.78_20190412/Odroid_N2

 

Does @JuanjoAr's build include the Hard Kernel Linux kernel specific to the N2?  Or does that ARMBIAN development release include any Hard Kernel N2 patches?

[JuanjoAr]

On 5/2/2019 at 10:29 AM, Poincare said:

 

Does @JuanjoAr's build include the Hard Kernel Linux kernel specific to the N2?  Or does that ARMBIAN development release include any Hard Kernel N2 patches?

It's balbes150's build, I dont think it includes any patches since it runs mainline 5.1RC1 kernel. I think balbes just added the right dtb and stuff necessary to make it boot.

[NicoD]

7 hours ago, JuanjoAr said:

It's balbes150's build, I dont think it includes any patches since it runs mainline 5.1RC1 kernel. I think balbes just added the right dtb and stuff necessary to make it boot.

Balbes now also has an Armbian image with the Odroid 4.9 kernel. All the recent fixes or already in the kernel since it's recently build. Go to Odroid N2 -> DEV -> in his download link.

For me it's a perfect image. If you need zram, then you need to do : sudo apt install zram-config

and then
sudo nano /etc/rc.local -> add
zramctl --find --size 1800M
mkswap /dev/zram0
swapon /dev/zram0

Everything else seems to work out of the box.

[Igor]

On 5/4/2019 at 10:39 PM, NicoD said:

Balbes now also has an Armbian image with the Odroid 4.9 kernel. All the recent fixes or already in the kernel since it's recently build. Go to Odroid N2 -> DEV -> in his download link.

Official build is coming later on http://ix.io/1Ivj

[TonyMac32]

11 hours ago, Igor said:

Official build is coming later on

 

Cool.  2 different people reached out to HardKernel about a board for me, so I have one coming.

[Igor]

7 hours ago, TonyMac32 said:

Cool.  2 different people reached out to HardKernel about a board for me, so I have one coming.

Good!
https://github.com/armbian/build/commit/2bd7f8efbd165e9e3a0db1cfb9d18dad1432cc4d

Download: https://www.armbian.com/odroid-n2/

Edited May 10, 2019 by Igor
Adjusted link

[NicoD]

4 hours ago, Igor said:

Download: https://www.armbian.com/odroid-n2/

I've tried "Armbian_5.86_Odroidn2_Ubuntu_bionic_default_4.9.173_desktop". Seems all fine. Performs as expected. Overclock works. It boots and reboots very quickly. With Balbes image it sometimes took long before reboot/shutdown. It hung on some closing task.
Only thing that doesn't work out of the box is zram-config. You need to manually configure it. This is the same on Balbes Armbian and on Odroid's Ubuntu Mate. Meveric uses his own script for this in his Stretch, and that does work automatically. But it only configures 1GB instead of 1.8GB. Probably because the C2/XU4 both have 2GB, and he probably didn't alter that.
You could advertise the image on the Odroid N2 forum.
https://forum.odroid.com/viewforum.php?f=179
This is the best Linux image for the N2 for now together with Balbes version. Odroid should update their Ubuntu Mate image since a lot of kernel fixes have been added after their last upload. The same with Meveric's Stretch. They always get the same complaints because of this.
Great job.

[Igor]

I noticed problems with zram but then it would need to wait few more days. It is strange why zram doesn't work oob while it does work on other boards by using the same build system. I checked kernel config, which seems fine and I will check and try to fix this next time, perhaps someone else will. It will be good to add a mainline kernel, no matter how good or bad support is there.

 

Advertisement + change log is WIP. Many more things has been changed/improved.

 

... but family duties cut them short  I hope to catch this up tomorrow.

[rufik]

Download: https://www.armbian.com/odroid-n2/

So it seems we (users) can buy this SBC now, thanks a lot

[NicoD]

44 minutes ago, Igor said:

It is strange why zram doesn't work oob while it does work on other boards by using the same build system.

It must be a kernel issue. On Balbes 5.1 it did work.
There were other problems with the kernel. At first zram and swap didn't work at all. Once over the memory limit it shut down the applications instead of using swap or zram.
These kernel arguments about low_memory_killer were activated.

CONFIG_ANDROID_LOW_MEMORY_KILLER=y
CONFIG_ANDROID_LOW_MEMORY_KILLER_AUTODETECT_OOM_ADJ_VALUES=y

https://forum.odroid.com/viewtopic.php?f=177&t=34540&start=50

 

They've used the Android kernel as a base. So there were a few of these things making problems. I guess the zram-config problem will be something related.

Those who want zram, I use this to activate it.

sudo nano /etc/rc.local -> add (before exit 0)

zramctl --find --size 1800M
mkswap /dev/zram0
swapon /dev/zram0 

Now trying OPi3 Bionic with 5.1. I tried 5.1 on the N2 and on the M4. Both I couldn't install the Armbian Desktop on it. I could install ubuntu-mate-desktop and get it to work(not mate-desktop). But it didn't work as it should. With the OPi3 desktop is installing. (I was confused with Ubuntu 19.04, there the Armbian desktop doesn't work. Too much things I'm testing...)

[TonyMac32]

23 hours ago, rufik said:

So it seems we (users) can buy this SBC now, thanks a lot

Remember this is alpha-level build, so anything and everything can change, it's like RK3399 or H6, stuff will break randomly all over for the next months, but especially at first.  (One thing pointed out was board family name, that will break any simple upgrade path if changed, it might be able to be lumped in with Meson64 or be "Meson_G12".

 

23 hours ago, NicoD said:

With Balbes image it sometimes took long before reboot/shutdown. It hung on some closing task.

 

Could be the BSP kernel, or any number of small things.  Any debug info grabbed from the hang for Balbes?

 

23 hours ago, Igor said:

I noticed problems with zram

 

Fun, Linux plumbing time.

[NicoD]

58 minutes ago, TonyMac32 said:

Could be the BSP kernel, or any number of small things.  Any debug info grabbed from the hang for Balbes?

I'll have to make an adapter cable for the N2 it's ttl. The pins are all in another order than all my ttl adapters(why isn't this the same on every device(so they can sell more $1 adapters?)), and the N2 uses a stupid connector that doesn't fit jumber wires.

Another very small datail I've notices is that my Ralink wifi dongle didn't work. After installing armbian-firmware-full it did. It's my most used dongle, so I know this works with all other Armbian images.

[TonyMac32]

The connector is a mini-spox connector, I'd say I'd make you one, but I think shipping would be an issue. ;-)

Sent from my Pixel using Tapatalk

[NicoD]

16 minutes ago, NicoD said:

I'll have to make an adapter cable for the N2 it's ttl.

@TonyMac32 And there goes 1 ttl adapter in the garbage can. Even the direction of the connector is reversed. I thought, ok so ground in the black wire left. While connected to the N2 the black wire is vcc. And 3.3V was of course GND. It was the smallest bang I've ever heard

Why the hell do they do that???? It's so easy to all do it the same way.
I don't care anymore. Don't want to risk another ttl adapter cause I need it for my NPi DUO2.

[TonyMac32]

The reason is no one thinks about it, they just run the wires to the plug and call it a day

Sent from my Pixel using Tapatalk

[umiddelb]

This is the pin layout of the serial console adapter for all Odroid models.  The Amlogic and Rockchip boards run the serial console with a 3.3 V UART therefore ...

 

 

[NicoD]

25 minutes ago, umiddelb said:

This is the pin layout of the serial console adapter for all Odroid models.  The Amlogic and Rockchip boards run the serial console with a 3.3 V UART therefore ... 

I knew that. What I didn't expect was that my cable with this connector has it's wires in reverse. I should have known, but always too bussy with too many things at the same time what makes my brain not pay attention.
And what's written there that you can use standard breadboard famale cables is incorrect. The pins are not in the middle of the connector, and there isn't enough room for the femole jumber wire connector.

I did try again with another ttl adapter. But it isn't a 3.3V one so I didn't connect VCC. It didn't work. I did get some strange behaviour of randomly moving cursor. 
I'll see to buy a Odroid adapter. It's going to be the easiest way not to mess up again. I've already lost my Pine64 adapter.

I've been lucky in the past that I've always took the correct adapter for every board. Never had issue's before. But I've never used it on an Odroid board.

 

[navzptc]

Many thanks to all those involved for their hard work in providing this armbian image for the N2.

 

I downloaded it, and got all my programs etc running on a sd card with no problems; however when I tried to transfer the system to the emmc card using armbian-config it would not boot.

Reloaded everything directly to the emmc card from scratch, and all running fine - maybe something I did wrong??

 

Very happy indeed to have armbian running on the N2 - have used for a while on my XU4's and very pleased with its performance.

 

Once again, VMT to all involved in this project.

[balbes150]

Never connect a VCC contact for USB-TTL. Use only three GND Tx Rx Pins on all models.