Brad Posted March 5, 2019 Posted March 5, 2019 (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 March 5, 2019 by Brad 0 Quote
TonyMac32 Posted March 5, 2019 Posted March 5, 2019 Cool. I haven't paid much mind to the G12x stuff, will it need a separate kernel family from Meson64? 0 Quote
Tido Posted March 5, 2019 Posted March 5, 2019 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/ 0 Quote
chwe Posted March 5, 2019 Posted March 5, 2019 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.. 0 Quote
TonyMac32 Posted March 6, 2019 Posted March 6, 2019 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) 0 Quote
Brad Posted March 6, 2019 Author Posted March 6, 2019 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. 0 Quote
chwe Posted March 6, 2019 Posted March 6, 2019 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). 0 Quote
TonyMac32 Posted March 6, 2019 Posted March 6, 2019 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 0 Quote
Brad Posted March 10, 2019 Author Posted March 10, 2019 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. 0 Quote
TonyMac32 Posted March 10, 2019 Posted March 10, 2019 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. 0 Quote
JuanjoAr Posted April 27, 2019 Posted April 27, 2019 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 0 Quote
Poincare Posted May 2, 2019 Posted May 2, 2019 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? 0 Quote
JuanjoAr Posted May 4, 2019 Posted May 4, 2019 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. 0 Quote
NicoD Posted May 4, 2019 Posted May 4, 2019 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. 0 Quote
Igor Posted May 9, 2019 Posted May 9, 2019 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 2 Quote
TonyMac32 Posted May 10, 2019 Posted May 10, 2019 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. 2 Quote
Igor Posted May 10, 2019 Posted May 10, 2019 (edited) 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 1 Quote
NicoD Posted May 10, 2019 Posted May 10, 2019 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. 0 Quote
Igor Posted May 10, 2019 Posted May 10, 2019 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. 1 Quote
rufik Posted May 10, 2019 Posted May 10, 2019 Download: https://www.armbian.com/odroid-n2/So it seems we (users) can buy this SBC now, thanks a lot 0 Quote
NicoD Posted May 10, 2019 Posted May 10, 2019 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...) 0 Quote
TonyMac32 Posted May 11, 2019 Posted May 11, 2019 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. 0 Quote
NicoD Posted May 11, 2019 Posted May 11, 2019 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. 0 Quote
TonyMac32 Posted May 11, 2019 Posted May 11, 2019 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 1 Quote
NicoD Posted May 11, 2019 Posted May 11, 2019 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. 0 Quote
TonyMac32 Posted May 11, 2019 Posted May 11, 2019 The reason is no one thinks about it, they just run the wires to the plug and call it a daySent from my Pixel using Tapatalk 0 Quote
umiddelb Posted May 11, 2019 Posted May 11, 2019 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 ... 0 Quote
NicoD Posted May 11, 2019 Posted May 11, 2019 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. 0 Quote
navzptc Posted May 12, 2019 Posted May 12, 2019 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. 0 Quote
balbes150 Posted May 12, 2019 Posted May 12, 2019 Never connect a VCC contact for USB-TTL. Use only three GND Tx Rx Pins on all models. 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.