Jojo

In the meantime I got HDMI also working through my AVR. I just changed the cable and that did the trick... One thing to mention: the system seems to be allergic to hot-plugging the HDMI cable. So if I connect/reconnect the cable during runtime, the HDMI output will be gone. It requires a reboot WITH CABLE CONNECTED. Not a big issue from my pov, but important to know...

Awesome! Thank you for adding it!

Good to hear that it worked for you 👍. The PR on Github seems to be on a good way, so "official" support might be there soon...

Currently Noble Server is not planned. I have the impression, that generally speaking Debian is the way to go for server stuff while Ubuntu is more targeting Desktop systems (at least Armbian). Of course there might be cases where both are provided. All my small servers here at home run Debian-based systems. Never had any issues or disadvantages compared to Ubuntu... If you read through this thread, you'll see what is needed to build it on your own: - clone the Armbian repo - get the correct dts file and place it in the correct folder - get the correct csc file and place it in the correct folder - run the compile script and choose M1S from the list The files and where to place them can be found in the corresponding PR on github. If you don't get it running on your own just wait/hope a little bit for the board to be officially (community-)supported by Armbian. Or I share the pre-compiled image with you (on your own risk). Greetings

Tested another Armbian, this time Noble with Gnome desktop. Although I personally do not like that UI, It performs relatively good. As @Werner predicted, glmark2-es2-wayland finished with a score of 277. WebGL Aquarium demo works significantly better. While 500 fishes still result in very low FPS, 100 fishes is mostly fluent. What I observed on all systems I have tested on the M1S, armbian-config takes extremely long to load/open. Sometimes around 5 minutes or so. It would be interesting to know, if this is expected to be normal... Now that I have tested four different images (Bookworm server, Noble Server, Noble Cinnamon and Noble Gnome), all with "current" kernel (6.12), I feel okay to do the PR. As said, I did not do that much but only adding the .csc file and the .dts file. This gave me the feeling on the other hand, that your build framework is working really great and makes it "relatively easy" to contribute and test own things, as seen as one knows how the things play together. So apart from all my "complains", your build framework is great!👍 If there are still other M1S users around: Hi!

Okay, thanks for the explanation! So, I got Armbian compiled and running by just adding the .dts file and the .csc file. The .csc file is a copy of the ODROID M1 .config file, but with some modifications: I threw out the SPI-related stuff, because the M1S does not have a SPI flash to boot from and it gave me arrors during compilation. I tested basic functionality with a Ubuntu Noble Cinnamon desktop image as well as a headless server image. Is this enough to create a pull request? How is the Download page created? Is that made by the Armbian team or do I need to add it there as well (how?) ? Greetings

WebGL1 and WebGL2 is reported to be working. But the performance is horrible...

Understood, all good. That is a good example for something that is not that clear. I tried to find a ready-to-use dts file for the M1S in the mainline repo, but it is not one single dts file, but a composition of several files where one file refers to the next one and so on (here). I was confused and so I asked ChatGPT how to merge the mainline dts into Armbian. This was how my patches were created. After compilation there was indeed one single all-in-one dts file for my board but not before... EDIT: I just tried another build with just taking the top-level dts file from the mainline repo and placing it in the location you mentioned. Worked like a charm, despite my confusion... 😅 From my point of view it seemed better to have the patches in place to be sure to always pull the most recent DT from the mainline kernel (that of course would require a defined place to put those patches). But what you say sounds as if it would be preferable to have dts files instead of patches. Is that correct and why?

Thank you for your reply! No, I did not check THIS SPECIFIC PR. But of course the other ones, for example those @Igor already pointed to. And because of the fact, that I already checked several PR and still being not sure how to do it correctly, I hoped for a more general explanation than just another link to another PR... I wished for some explanations about good practice and how/why things are done the way they are done. "Path xyz is the place for your .csc files. Path abc for your .dts files because of blablabla..." That would just have been nice to get a better overview. Beside all the respect and appreciation that I have for you and your colleagues at Armbian, please understand that it is sometimes somewhat exhausting when guys like me try their very best to contribute and then often get calmed by link-drops... Anyway, I'll check out your referred PR and see if that helps.

I am currently trying to add the board support "the official way" by forking the repo and adding the board in the "Community maintained" category. To me it seems that this requires not "normal" .config files, but ".csc" files. This is fine and I created one accordingly. But I dont know where to place it. What would be the best place for that? Additionally, I have created a patch that pulled the latest DTS file for the M1S from the mainline kernel repo. That worked fine as well and after compilation there was a local DTS file created and everything worked so far. But here I have the same problem/question: where to put these patches? Or is it preferable to use the created DTS file and place that somwhere without the patches that pull the mainline DTS? So basically I wish for a little bit support where to put which files to be "Board support Rules" compliant. Greetings!

Good point! I was not aware of that. I will try today and report back.

Just compiled and flashed a Cinnamon desktop image. Boots fine Video over HDMI working. Audio over HDMI working. The video experience is not that much satisfying. There seems to be no graphic acceleration, yet. WebGL aquarium runs at 5 FPS with 500 fishes, 15 FPS with 100 fishes. Youtube videos are relatively laggy and you'll experience high CPU load. All the GPIO hardware stuff has not been tested, yet. No clue how to do it... Now I'd like to have some more people on board to support me by adding graphic acceleration and how to merge the M1S support now into the Armbian repo. Greetings. EDIT 1: transferring the OS from SD card do eMMC works by using armbian-install tool EDIT 2: graphic acceleration IS kind of working, glmar2-es2 gives me a score of ~177. But the web browser seems not to be accelerated. also the desktop environment seems to have problems Cinnamon is not able to load applets, which means that the "Start" menue icon is missing...

M.2 NVMe slot is also WORKING. At least the SSD gets detected with "cat /proc/partitions". It is not listed under "df -h" but I think this is because it is not mounted yet...

Okay. Thank you!

Okay, one step further: HDMI output is WORKING! initially I had the M1S connected to the Aux input of my AV receiver. There seems to be a problem with display detection (EDID, available modes) and so the M1S does not know which display mode to set. I then connected the M1S directly to an HDMI input of the TV and nothing changed. Rebooted and ... Surprise! Video output works, EDID information and available modes are available (wasn't when connected to AV receiver). So how can I tell Armbian to force a specific display mode even when no screen information is available?

To be honest I currently don't know. I booted my first from SD card. That worked as described above. After that, I've shut down the M1S, set the M1S to UMS mode and cloned the SD card to the internal eMMC. Booted as described. But please tell me how to perform that test and I can give your kernel build a try . Greetings

Booting from internal eMMC also works. Regarding HDMI: I've made another build where I pulled the DTS definitions for the M1S from the Linux mainline repository directly during compilation (thanks ChatGPT!). But that also did not help. The system "works" as before, just no HDMI...

@usual userWell, this was also my feeling that there might be something wrong with the device tree. The Hardkernel section for HDMI looks a little bit different compared to the HDMI section in the device tree I have used. I thought it would be kind of okay, because the kernel is a different one. But maybe this assumption was wrong... So what could I do if I'd like to try the Hardkernel DTB? Is there a chance that it just works? Or would it be the better way to create an device tree overlay? I don't know anything at all about that, sry... EDIT: Could there be other reasons? Like an deactivated video output option somewhere? Or maybe it need to be actively activated? Please let me know if I can provide further information, file contents or so...

Hi, although this topic is quite old, I was trying to bring this forward. I think I had a partial success on this. I've built an Armbian image with a newly created defconfig file. I took the DTB file from above. Result: the board seems to boot (SD card). The blue LED starts to blink (heartbeat). Ethernet is working, I can SSH into the box. USB seems to work, at least my Logitech Unifying Receiver is recognized Problem: there is no HDMI output. with dmesg | grep -i hdm I got the following output: [ 0.083861] /vop@fe040000: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 0.083981] /hdmi@fe0a0000: Fixed dependency cycle(s) with /vop@fe040000 [ 0.118236] /hdmi@fe0a0000: Fixed dependency cycle(s) with /hdmi-con [ 0.118360] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 4.671032] dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 4.675209] dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 4.689857] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) I dont know if this help. Maybe someone can assist? @Igoreverybody here honors and respects you and your work and your effort. We (or at least me) do not expect you to bring up one after another working image for all boards out there. What we do is asking for help to help ourselves. It is more than clear and obvious, that you are frustrated by the numerous apparent "requests" on one side and a massive lack of volunteering support on the other side. BUT: for US it is also sometimes frustrating, that you try to end all those threads like this by saying "STFU, RTFM". I am (and many more are) NOT those people, who just pass by to say "Hey Armbian, when do you finally support board XYZ?????????". Many of us TRY to contribute. But sometimes the tasks are just too hard to teach ourselves. You do this on a daily basis. But for "beginners" building the first linux image is so damn challenging and especially when you are alone on the battlefield (like when trying to bring an unsupported board to life). Yes, I read the docs. And yes, I already did before you restructured the build system. So asking for help is not intended to upset you. And still, I don't expect any support from your side. We try to come as far as possible on our own. But maybe there has been a time, when even you needed some guidance which involved a little bit more than RTFM... I respect and appreciate your work!

Hey guys, I just wanted to mention, that I have not forgotten this topic . I just have currently no time to drive this further because of real-life stuff going. Additionally I currently have no hardware in spare which i could perform the tests on. So either you guys wait for a non-specified time or try something on your own. So long... Cheers

Alright, continuing talking to myself I think I will try to make a build for the OrangePi 3b, because this way I assume to get a mainline compatible u-boot for the RK3566 as well as a recent kernel/file system . Then I will replace the device tree with that one from the M1S. Any concerns? Of course not... I will drop myself a note here if this was successful...

So here are the DTB and the DTS file from the current Home Assistant OS boot partition. I hope this brings us forward. What could be the next steps? rk3566-odroid-m1s.dtb rk3566-odroid-m1s.dts

Yes, so basically my approach is not that wrong to overcome the differences between M1 Armbian image and M1S by using the correct device tree. I dont know the shortcomings you talk about, but AFAIK the device tree used by Home Assistant is fine and works stable, see HERE. I also got told that I would have to rebuild the u-boot for the M1S (basically what you also said by referring to the firmware to flash). Is there anything I miss or that I just understand wrong? How to build the firmware for the M1S? Sorry for asking so many dumb questions. All this is just far beyond my knowledge and I have never built a firmware - only a kernel with a detailed description 😅. I try to understand what is missing and how we can pull things together without re-inventing the wheel. Cheers

Hey guys, looks like the devs are heavily busy with other stuff. As we can read they are currently massively struggling with a lack of ... basically everything. So let's try to support them by helping ourselves and share it with the community . I have not read anything anywhere about an approach to create an Armbian image for the M1S, so lets try to sum up, what we have and what is needed. I am really not an expert in all that - really NOT! But I like to contribute as far as I can! I've read somewhere that someone has tried to boot the M1 image on a M1S which kind of "worked" surprisingly, but failed in many ways like HDMI output and so on. This makes me think that the required modifications are mainly regarding entire hardware definitions - the device tree. There is already an official Home Assistant image for the M1S where the most changes are also regarding the device tree (see link above). So my idea for the next steps would be: take the M1 Armbian image as a starting point replace the Device tree be the one from Home Assistant and see if/how far it starts. Does this approach make sense and has it chance to work?! The problem I have: when I download the Home Assistant image and mount it locally I just can not find any DTB file. The same applies to the M1 Armbian image. Does anyone know where to find the DTB files right after downloading the images? Let's bring this forward guys. We have a sound software base to start from and the omnipotent Armbian build system. If we get people onboard who know better about the bootloader/device tree stuff than me, we should be able to do it . Cheers

Hi, okay, your workflow regarding creating an own OS image is definitely beyond my knowledge 😅. Maybe I will give it a try to create an image for the N2 via the Armbian build system. That looks quite straight forward. Maybe I just screwed up something on my system when I can not get clinfo to detect my GPU, so there is a chance that it works OOTB after fresh install... Here is the output of the command you requested: $ sudo RUSTICL_ENABLE=panfrost clinfo Number of platforms 3 Platform Name ARM Platform Platform Vendor ARM Platform Version OpenCL 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58 Platform Profile FULL_PROFILE Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory Platform Extensions function suffix ARM Platform Name rusticl Platform Vendor Mesa/X.org Platform Version OpenCL 3.0 Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions with Version cl_khr_icd 0x400000 (1.0.0) Platform Numeric Version 0xc00000 (3.0.0) Platform Extensions function suffix MESA Platform Host timer resolution 0ns Platform Name Clover Platform Vendor Mesa Platform Version OpenCL 1.1 Mesa 22.3.6 Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix MESA Platform Name ARM Platform Number of devices 1 Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Device Name <printDeviceInfo:0: get CL_DEVICE_NAME size : error -6> Device Vendor ARM Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Device Vendor ID <printDeviceInfo:2: get CL_DEVICE_VENDOR_ID : error -6> Device Version OpenCL 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58 Driver Version 2.0 Device OpenCL C Version OpenCL C 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58 Device Type GPU Device Profile FULL_PROFILE Device Available Yes Compiler Available Yes Linker Available Yes Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max compute units <printDeviceInfo:32: get CL_DEVICE_MAX_COMPUTE_UNITS : error -6> Available core IDs (ARM) <printDeviceInfo:33: get CL_DEVICE_COMPUTE_UNITS_BITFIELD_ARM : error -30> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max clock frequency <printDeviceInfo:40: get CL_DEVICE_MAX_CLOCK_FREQUENCY : error -6> Device Partition (core) Max number of sub-devices 0 Supported partition types None Supported affinity domains (n/a) Max work item dimensions 3 Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max work item sizes <printDeviceInfo:62: get number of CL_DEVICE_MAX_WORK_ITEM_SIZES : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max work group size <printDeviceInfo:63: get CL_DEVICE_MAX_WORK_GROUP_SIZE : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Preferred work group size multiple (kernel) <getWGsizes:1950: create context : error -6> Preferred / native vector sizes char 16 / 4 short 8 / 2 int 4 / 1 long 2 / 1 half 8 / 2 (cl_khr_fp16) float 4 / 1 double 0 / 0 (n/a) Half-precision Floating-point support (cl_khr_fp16) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Single-precision Floating-point support (core) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Double-precision Floating-point support (n/a) Address bits 64, Little-Endian Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Global memory size <printDeviceInfo:108: get CL_DEVICE_GLOBAL_MEM_SIZE : error -6> Error Correction support No Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max memory allocation <printDeviceInfo:114: get CL_DEVICE_MAX_MEM_ALLOC_SIZE : error -6> Unified memory for Host and Device Yes Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Shared Virtual Memory (SVM) capabilities <printDeviceInfo:117: get CL_DEVICE_SVM_CAPABILITIES : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Shared Virtual Memory (SVM) capabilities (ARM) <printDeviceInfo:118: get CL_DEVICE_SVM_CAPABILITIES_ARM : error -6> Minimum alignment for any data type 128 bytes Alignment of base address 1024 bits (128 bytes) Preferred alignment for atomics SVM 0 bytes Global 0 bytes Local 0 bytes Max size for global variable 65536 (64KiB) Preferred total size of global vars 0 Global Memory cache type Read/Write Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Global Memory cache size <printDeviceInfo:139: get CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Global Memory cache line size <printDeviceInfo:140: get CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE : error -6> Image support Yes Max number of samplers per kernel 16 Max size for 1D images from buffer 65536 pixels Max 1D or 2D image array size 2048 images Base address alignment for 2D image buffers 32 bytes Pitch alignment for 2D image buffers 64 pixels Max 2D image size 65536x65536 pixels Max 3D image size 65536x65536x65536 pixels Max number of read image args 128 Max number of write image args 64 Max number of read/write image args 64 Max number of pipe args 16 Max active pipe reservations 1 Max pipe packet size 1024 Local memory type Global Local memory size 32768 (32KiB) Max number of constant args 8 Max constant buffer size 65536 (64KiB) Max size of kernel argument 1024 Queue properties (on host) Out-of-order execution Yes Profiling Yes Queue properties (on device) Out-of-order execution Yes Profiling Yes Preferred size 2097152 (2MiB) Max size 16777216 (16MiB) Max queues on device 1 Max events on device 1024 Prefer user sync for interop No Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Profiling timer resolution <printDeviceInfo:195: get CL_DEVICE_PROFILING_TIMER_RESOLUTION : error -6> Execution capabilities Run OpenCL kernels Yes Run native kernels No printf() buffer size 1048576 (1024KiB) Built-in kernels (n/a) Device Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory Platform Name rusticl Number of devices 0 Platform Name Clover Number of devices 0 NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) ARM Platform clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [ARM] Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContext(NULL, ...) [default] <checkNullCtx:4108: create context with device from default platform : error -6> clCreateContext(NULL, ...) [other] <error: no devices in non-default plaforms> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) <checkNullCtxFromType:4160: create context from type CL_DEVICE_TYPE_DEFAULT : error -6> clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) <checkNullCtxFromType:4160: create context from type CL_DEVICE_TYPE_GPU : error -6> clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) <checkNullCtxFromType:4160: create context from type CL_DEVICE_TYPE_ALL : error -6> ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.14 ICD loader Profile OpenCL 3.0