Werner__ changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | This channel is logged -> http://irc.armbian.com
archetech has joined #armbian
drobo_00 has quit [Ping timeout: 260 seconds]
emOne has joined #armbian
DaRock has joined #armbian
drobo_00 has joined #armbian
mrueg has quit [Remote host closed the connection]
mrueg has joined #armbian
Toast has quit [Quit: Toast]
xecuter has quit [Ping timeout: 260 seconds]
xecuter has joined #armbian
xec has joined #armbian
xecuter has quit [Ping timeout: 248 seconds]
drobo_00 has quit [Quit: drobo_00]
mirage335 has quit [Ping timeout: 268 seconds]
mirage335 has joined #armbian
DaRock has quit [Ping timeout: 240 seconds]
emOne has quit [Ping timeout: 246 seconds]
DaRock has joined #armbian
DaRock has quit [Ping timeout: 268 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined #armbian
DaRock has joined #armbian
DaRock has quit [Ping timeout: 240 seconds]
DaRock has joined #armbian
<lanefu> yo
<TRS-80> hi
<TRS-80> bye :)
TRS-80 has quit [Quit: WeeChat 2.3]
<archetech> hi lane
<lanefu> hows your kernel build going
<archetech> quit for while
<archetech> till someone with a 3328 shows up
<lanefu> bummer..
<archetech> par for the course when trying latest stuff
<lanefu> true. so if i recall you werent even getting output from uboot
xecutertool has joined #armbian
<lanefu> i wonder if skipping the u-boot deb package when youre installing the kernel would help
xec has quit [Ping timeout: 265 seconds]
<archetech> ill get it go tomorrow
<archetech> easy way is wait for somebody w/ the board to fig it out :)
<archetech> via forum post or in here
<archetech> mean the rc image not just the kernel
<archetech> laters
archetech has quit [Quit: Leaving]
<Werner__> Good Morning
dddddd has quit [Remote host closed the connection]
NeuroScr has quit [Quit: NeuroScr]
selfbg has joined #armbian
_whitelogger_ has joined #armbian
zhangn1985 has quit [Quit: Lost terminal]
johnwho has joined #armbian
<johnwho> hi there
<Werner__> Hi
<johnwho> i am trying to compile armbian with CREATE_PATCHES="yes" unfortunately, all of my changes i made to a file inside of cache/ are overwritten
<johnwho> also KERNEL_CONFIGURE="yes" doesnt show me a kernel config dialog.... altough SOURCE_COMPILE="yes" is set
<johnwho> do you have any ideas?
<Werner__> Not really...
<johnwho> ok so basically these compiler flags should still work?
<Werner__> I guess so. Maybe IgorPec has an idea
<johnwho> thank you for your proposal. I have contacted him directly
<johnwho> how can one rebuild the devicetree for linux within the armbian build framework?
<Werner__> Not sure if this is what you are looking for but a dtb .deb for the specific board/family will be create as well when you do KERNEL_ONLY compile.
_whitelogger has joined #armbian
torv has quit [Ping timeout: 240 seconds]
torv has joined #armbian
c0rnelius_ has joined #armbian
<IgorPec> johnwho: you solved?
<johnwho> no
<IgorPec> build system always starts with a clean gut
<IgorPec> git
<IgorPec> when you use CREATE_PATCHES ... you have to
<IgorPec> make changes when you are asked, then a patch from changes is created aftwerward
<johnwho> i never get asked to change anything
<johnwho> that is the problem actually
<johnwho> the build process just runs through....
<IgorPec> aha ...
<IgorPec> let me check. do you use master branch?
<johnwho> let me check which branch i am using
<IgorPec> and I assume official build script, not some 3rd party fork
<johnwho> revision 1f95a00
<johnwho> yes, in fact i have followed this tutorial:
<IgorPec> its few days old but ... it should work
<johnwho> ok i can also update
<johnwho> i saw, that there are already patch files under patches/ for my particular device tree file (rk3288-miniarm.dts) therefore i would like to just change this patch.
<johnwho> in fact i only want to change the DSI HW to interface with an other Display
<IgorPec> you don't touch anythinb but userpatches
<johnwho> will the patches under patch/kernel/... applied, before i am asked to change files?
<johnwho> nice, would be great if i would be prompted this message ^^
<IgorPec> this is how ./compile.sh CREATE_PATCHES="yes" should look like after you select which board and kernel version
<johnwho> strange... i did only changed config-default.conf
<johnwho> nothing else
<IgorPec> you compile under docker or something else?
<johnwho> but if i would prompted to change files, are the patches from patch/kernel... already applied?
<IgorPec> yes, that's correct.
<johnwho> i compile under Ubuntu 18.04 LTS x64
<johnwho> ok good that they are applied already. otherwise it would not make sense...
<IgorPec> that's a desired way. default patches might be mandatory, some are
<johnwho> and will the buildprocess also check if some patches has changed in userpatches and if so, recompile uboot for example or also just recompile the devicetree?
<IgorPec> userpatches are added in this process and a patch you are working on
<johnwho> ok but what happens if i have already compiled an image successfull, now i change some parts of a userpatch and restart ./compile.sh
<johnwho> will it recompile an devicetree which will be affected by a change in a userpatch?
<IgorPec> changes will be applied of course
<johnwho> ok good
<johnwho> what would you do to enable CREATE_PATCHES?
<IgorPec> only exception is a patch that is in creation mode
<johnwho> how does such one look?
<johnwho> when is a patch in creation mode?
<IgorPec> that is applied only in creation mode and its placed in output/patches ..
<johnwho> oh ok
Redferne has quit [Ping timeout: 240 seconds]
<IgorPec> in creation mode is when a switch PATCHES_CREATE="yes"
<IgorPec> sorry, CREATE_PATCHES :)
<johnwho> and then i have to move the patch from output/patches to userpatches/ ?
<IgorPec> when you are done modifiny it, exactly
<johnwho> ok good
Redferne has joined #armbian
<johnwho> but for that i must be prompted to make file changes first ^^
<IgorPec> yes, try to start with a clean build ... give me few minutes to check here. currently i have no idea why you don0t get the prompt
<IgorPec> perhaps permission issues, check logs if there is anything strange
<johnwho> ok. i will remove my current armbian directory and checkout the latest one from git
<johnwho> modify my configdefault to include CREATE_PATCHES="yes"
<johnwho> and try it again
<IgorPec> try also to run ./compile CREATE_PATCHES="yes" I usually use it this way, not encodint it to the config.
<johnwho> ok good idea
<johnwho> maybe this could be the difference
<johnwho> i have now cloned armbian again and now running the first ./compile.sh
<IgorPec> i know for one case that it makes a difference but its a service switch
<johnwho> why is USEALLCORES not documented?
<IgorPec> its probably not implemented as a switch
<IgorPec> we always compile with full force :)
<IgorPec> and even that is not good enough
<johnwho> oh good :)
<johnwho> cause here were some switches mentioned which i have not found in the docs
<IgorPec> yes, documentation is always behind, never complete. Its a common work - if you care, send an update
<johnwho> yes, i care and i will take a look whether i can send an update :)
<johnwho> but thank you anyway for your work! Its a great project
<IgorPec> tnx
<IgorPec> ok, be back in 1h
<johnwho> good, me too
Redferne has quit [Ping timeout: 265 seconds]
Redferne has joined #armbian
Redferne has quit [Read error: Connection reset by peer]
Redferne has joined #armbian
<johnwho> im back
dddddd has joined #armbian
<johnwho> ok now i did a ./compile CREATE_PATCHES="yes" and it asked me for changes to u-boot... now i hope it will also ask me for changes to the kernel sources
<IgorPec> yes, it will
<johnwho> yes it asked me :) and created a patch accordingly
<johnwho> if i now change something to the devicetree of my board (tinkerboard) i can change the content of my new created patch file
<johnwho> but do i have to compile the whole kernel everytime i change just the device-tree? or is there an other option wihin buildroot?
<johnwho> sorry i mean within armbian build system ^^
<johnwho> and... now i have got an error (due to the fact that i have made a mistake in my device-tree dts file)
<johnwho> [ error ] ERROR in function compile_kernel [ compilation.sh:378 ][ error ] Kernel was not built [ @host ]
<johnwho> is there a possibility to get more error informations?
<Werner__> Yes. Check the output/debug folder
<IgorPec> second compile is much fastger since it ueses ccache
<IgorPec> so we didn't add dtb compile as a separate option but it could be added once, its useful
<IgorPec> output/debug/compilation.log
<johnwho> perfect. thank you
<johnwho> pathing with the previously created patch has failes
<johnwho> failed
<johnwho> [ warn ] * [u][c] kernel-rockchip-legacy.patch [ failed ]
<johnwho> it seems, that the patch get applied according to its name
<johnwho> [ o.k. ] * [l][c] brcmfmac-add-ap6330-firmware.patch [ o.k. ] * [l][c] general-adjust-tinker-dts-hdmi-sound.patch [ warn ] * [u][c] kernel-rockchip-legacy.patch [ failed ][ o.k. ] * [l][c] patch-4.4.199-200.patch [ o.k. ] * [l][c] patch-4.4.200-201.patch
<IgorPec> warn means something was wrong
<johnwho> should i name my own patch something like zzz-mypatch that it will get applied after all others?
<IgorPec> see output/debug/patching.log
<IgorPec> yes, naming maters
<johnwho> i thought the system would frist apply all integrated patches from patch/... and then start applying patches from userpatches/....
<IgorPec> no, it combine them order by name
<johnwho> oh ok...
<johnwho> is there a special reason to not do it in the order of first applying patch/... and then userpatches/... ?
<johnwho> casue when im using CREATE_PATCHES then i will also apply changes to the files after all patch/... patches has got applied
<IgorPec> i think this is more appropriate for development. for patch engine, location is irrelevant
<johnwho> sure, the location doenst matter, but the order in which the patches will get applied
<IgorPec> this is the way we designed this, so i don't know if this have an easy modus change
<johnwho> ok no problem. as long as i know it i can avoid trouble by naming ma patch with z-some name
<johnwho> that it will be the last who is applied
<IgorPec> the logic behind is that one has to prepare patches and align order but not touch stock patches and when things are done, those patches can be moved to the base and send upstream as MR
<johnwho> ok i see.
<IgorPec> for our purpose, this is better suited. for end user - he is usually fine with one patch
<johnwho> yes i see the logic behind. But how would you handle the following scenario:
<johnwho> i am using a tinkerboard and i want to modify the device tree in such a way that it supports an other display by DSI
<johnwho> if i make a patch then this patch will only be usefull for my self
<johnwho> so should i only store this patch in userpatches forever?
<IgorPec> you send it upstream with .disabled
<johnwho> oh nice! good idea
<IgorPec> and its nice to sign a patch with a short comment
<johnwho> what would be the fastest way to just check if the device-tree has some oerrors? Only building kernel and uboot instead of full OS for SD-Card?
<johnwho> cause armbian is complining and installing the kernel now since around 10 minutes
<johnwho> just due to a small change in the patch which affects only the device-tree
<IgorPec> hmm
<IgorPec> ccache should take care of some speedup
<IgorPec> i have less then 1m
<IgorPec> for DT recimpile only some refacturing should be done
<johnwho> this is what ive got
<johnwho> or still getting
<johnwho> it has not finished
<IgorPec> you are creating whole image
<johnwho> yes
<johnwho> should i only create kernel and uboot?
<IgorPec> if you only make changes to DT, yes
<IgorPec> then copy dtb package to the tinkerboard, unpack and reboot
<johnwho> cause how could i otherwise test the finished device-tree?
<johnwho> ok sounds logical :)
<johnwho> now it has finished
<johnwho> now i will try to just build kernel an uboot
<IgorPec> you can also compile kernel only
<johnwho> and how?
<IgorPec> ./compile.sh 'compile_kernel'
<johnwho> nice :]
<johnwho> could it be that you mean KERNEL_ONLY=yes ?
<johnwho> ok i see, there is a 'compile_uboot'
<johnwho> the most time takes "Compressing sources for the linux-source package "
<IgorPec> what kind of machine you are working with?
<johnwho> virtual machine with v-tx enabled. Using 3 physical i7 cores
<johnwho> and with 12GB RAM
<IgorPec> ahaa, that's very basic
<johnwho> what are you using? :)
<IgorPec> 28 phy cores and 80GB virtualized
<johnwho> nice ^^
<johnwho> how important is RAM?
<johnwho> cause i recently got an older server with a xeon processor and about 196GB DDR3 memory
<johnwho> could it be that this machine will perform better?
<IgorPec> 12GB is enough for this, but I need memory for running multipe images rebuilding at once
<johnwho> ok isee
<johnwho> by the way... i have choosen kernel and u-boot only from the display menu
<johnwho> but it loks like that it is again building a full image
<IgorPec> check your config if KERNEL_ONLY="yes"
<johnwho> now i execute: ./compile.sh KERNEL_ONLY="yes"
<IgorPec> and 'compile_kernel'
<IgorPec> if you want to execute that procedure only
<johnwho> ok i will now execute ./compile.sh KERNEL_ONLY="yes" 'compile_kernel'
<johnwho> when executing the above command
<johnwho> the apllying of every single path fails...
<johnwho> except for 3 patches out of 20 or so
<johnwho> ok log tells that it has already patched
<johnwho> makes sense...
<johnwho> but there are compliation errors:
<johnwho> what i have did:
<johnwho> made a clean compilation with just ./compile.sh
<johnwho> then made ./compile.sh KERNEL_ONLY="yes" 'compile_kernel'
<IgorPec> i see, this is a bug then
<IgorPec> but it works if you go step by step
<johnwho> it works as long as i compile the whole image
<johnwho> which took me around 30 minutes... BUT!
<johnwho> i found a workaround
<IgorPec> i don't understand why it compiles you whole image ... huh
<johnwho> i can go into the linux source folder and then run:
<johnwho> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs
<johnwho> this will generate me only the device tree blobs...
<johnwho> but i must find a way to apply all patches from patch/ manually
<IgorPec> yes, that's option and mainly this will be ok
<johnwho> do you see a way to trigger the apply patch mechanism manually?
<IgorPec> but. different sources can have different compilers ... for DT probably not important, just to expect troubles
<johnwho> sure, you are right
<IgorPec> i am cooking, no time to debug now :)
<johnwho> ok no problem :)
<johnwho> have a nice meal
<johnwho> thanks for your help
on3pk has quit [Read error: Connection reset by peer]
on3pk has joined #armbian
xecutertool has quit [Remote host closed the connection]
xecuter has joined #armbian
maccraft321 has joined #armbian
<maccraft321> how does armbian build cubieboard2 images?
DaRock has quit [Ping timeout: 240 seconds]
<maccraft321> i have issues running other linux distros
<maccraft321> armbian is only thing that works
msev- has quit [Quit: Leaving]
archetech has joined #armbian
maccraft321 has quit [Ping timeout: 260 seconds]
selfbg has quit [Remote host closed the connection]
<johnwho> the same for me with the tinkerboard
<johnwho> take a look at armbian/build/patch folder
<johnwho> armbian does heavily patch u-boot and the kernels before compilation
<johnwho> this is where the magic comes from :)
<c0rnelius> in my experience its all about dem patches
<c0rnelius> you can literally use the build script, make a kernel and then take the source and rebuild that for another os.
<c0rnelius> i've done it with opensuse, void, crux and my own debian/ubuntu builds.
<johnwho> is someone familliar with the panel-simple driver with rockchip?
<johnwho> what happened if my device tree gives me "segmentation fault"?
maccraft321 has joined #armbian
maccraft321 is now known as macccraft123
TRS-80 has joined #armbian
johnwho has quit [Remote host closed the connection]
ashthespy has joined #armbian
dddddd has quit [Remote host closed the connection]
drobo_00 has joined #armbian
<TRS-80> Good morning! :)
* TRS-80 is enjoying a nice cup of coffee
<macccraft123> TRS-80: how does armbian build cubieboard2 images?
<macccraft123> armbian is only thing that works
<macccraft123> on my cubieboard2
<ashthespy> Greetings!
<TRS-80> hi ashthespy
<TRS-80> macccraft123: There is also https://forum.armbian.com/topic/6-how-to-build-my-own-image-or-kernel/ if you prefer videos. Me personally, I like to read. ;)
<ashthespy> I am playing around with different kernel options, and wanted to check if I was using the build system correctly! :-)
<ashthespy> If I build a minimal image once, then when I build a new kernel, I can just use the `linux-image` debs with the same image right?
<ashthespy> Instead of building a new image each time?
<TRS-80> ashthespy: I think maybe? But I am not sure. Hang around, you will probably get an answer though.
<ashthespy> Will do!
<ashthespy> ```
<TRS-80> Or, you could just try (and report back)... :)
<ashthespy> From the build logs, I see `Checking local cache buster-minimal-arm64....` and then it goes ahead and creates a new rootfs
<c0rnelius_> ashthespy - in theory you can, yes. i use to do it all the time. just make sure ur building the kernel with the armbian build script.
<TRS-80> Guides recommend VirtualBox, etc. but I have been playing with qemu lately and really enjoying it
<ashthespy> c0rnelius - yes, its all with the build script..
<TRS-80> it seems slightly less noob friendly (but not much, especially with virt-manager) but so much more powerful and different options...
<c0rnelius_> ashthespy - then you should be fine. as long as nothng is wonky with kernel.
<ashthespy> Can I just upack the kernel directly on the sd card?
<ashthespy> I only have serial access to the board, so not sure what workflow would be best..
<c0rnelius_> i would boot into the board and run a dpkg -i *.deb on the pkgs.
<c0rnelius_> image, headers and dtb
<ashthespy> Hmm, will try a `dpkg -x` to root of the sdcard and give it a go..
<c0rnelius_> i've never tried just mounting the sdcard and doing that. doesn't sound like a good idea.
<ashthespy> Fair
<ashthespy> Okay, I shall get back to trying to get WiFi working!
<TRS-80> TRS-80: test
<TRS-80> Testing anotify plugin. Maybe someone else has to do it, or I need to be in different window. Can someone mention me please? :)
<c0rnelius_> TRS-80
<TRS-80> c0rnelius_: Thanks! It works! :)
<TRS-80> TRS-80:
<c0rnelius_> np
<TRS-80> c0rnelius_: Can do once more? I'm curious if it works if I am in buffer.
<c0rnelius_> TRS-80 - sure can
<ashthespy> Meh, got the driver build and loaded, but now need to check why it can't do anything with the device.
<TRS-80> Yes, that works, too. Thanks for help! Doing it yourself, does not work...
<ashthespy> if someone is curious - https://pastebin.com/1uuQdKE0
<c0rnelius_> yep yep
<c0rnelius_> why you on 5.5? pretty unstable and it's an RC.
<ashthespy> c0rnelius rk3308 support landed quite recently, so picked that.. Else BSP is on 4.4.y
<ashthespy> It is meant to be a learning experience for me as well :-D
<c0rnelius_> i saw that when viewing the diff. not sure about the armbian builds, but in my experience running make scripts in the headers throws errors and fails.
<c0rnelius_> which usually isn't a good sign.
<ashthespy> c0rnelius Not sure I follow -
<ashthespy> I patched in support for the wifi chip using the other examples over at `compilation-prepare.sh`
<c0rnelius_> it means when trying to compile against the headers you'll fail. such as a wifi module or what have you. of course i haven't tried the armbian build of it, so i can't speak to that.
<c0rnelius_> thats just my own messing about.
<ashthespy> Ah, okay!
<ashthespy> will scrutinise the build log for some light now ;-)
* TRS-80 just got jabber.py working in weechat
<TRS-80> Neat! :)
<c0rnelius_> japper! i haven't used that in a whiles
<TRS-80> > using anything but completely open messaginv formats in $current_year
<TRS-80> :D
<TRS-80> I set up our own server at home on a Cubietruck, for 3 years it has been running flawless
<TRS-80> several family using it now
<c0rnelius_> thats kool.
<TRS-80> private, self-hosted IM is very nice :)
<c0rnelius_> i see a lot of peps using weechat these days. been on hexchat myself.
<ashthespy> TRS-80 No net outages in 3 years? Nice!
<TRS-80> it wasn't hard to set up, actually... If you are interested look into prosody; Also, Docs are great and they are very helpful in their support channel
<c0rnelius_> i don't talk to my family enough for all that :)
<TRS-80> ashthespy: Oh we have had some outages. We do belong to some outside servers also, "just in case." But outages always were from forgetting to pay our internet bill, power going out, etc... never prosody! :)
<TRS-80> Next maybe MQTT plug in for weechat, then I can get notifications from everything like the HA controller, etc...
ashthespy has quit [Ping timeout: 260 seconds]
<TRS-80> c0rnelius_: This is what got me interested in weechat: https://weechat.org/scripts/ Well, plus I just like command line stuff
<TRS-80> I like to be able to do whatever I want without limitation
<c0rnelius_> hexchat has scripts and addons as well. not sure if it has that many.
drobo_00 has quit [Ping timeout: 245 seconds]
drobo_00 has joined #armbian
<c0rnelius_> i was just looking and apparently freebsd doesn't feel like offering those. poor fbsd and its ways.
<TRS-80> Yeah I suppose most IRC programs probably do. I haven't tried a lot of different ones. Like you at some point I "heard about weechat" checked into it, started using it and in my case never looked back.
<c0rnelius_> i'll have to check out weechat and see what i thinks
<c0rnelius_> i always just used irssi up until a few months ago
<TRS-80> I heard good things about that, too. Interesting distributed idea.
<c0rnelius_> irssi is great. if u like the cli approach
c0rnelius_ has quit [Quit: Leaving]
s_frit has quit [Remote host closed the connection]
s_frit has joined #armbian
macccraft123 is now known as maccraft123
archetech has quit [Quit: Leaving]
TRS-80 has quit [Quit: WeeChat 2.3]
TRS-80 has joined #armbian
TRS-80 has quit [Quit: WeeChat 2.3]
TRS-80 has joined #armbian
archetech has joined #armbian
TRS-80 has quit [Quit: WeeChat 2.3]
TRS-80 has joined #armbian
emOne has joined #armbian
<emOne> is there a way to know if armbian has the module for wlan_mt76x8_sdio ?
<Werner__> Depends on your board. Check the matching kernel config
<emOne> Werner__: i think it is an mt7668 wifi driver
<emOne> wifi chipset*
<Werner__> Still depends on the board you are using Armbian on since Armbian supports many different boards with different kernel configuration files. Some may contain this specific driver, other may not.
<emOne> Werner__: how would you check the matching kernel config?
<emOne> It's a chinese android tv box with a s905x3 cpu
<Werner__> So Amlogic S905 based
<Werner__> meson board family
<Werner__> From a quick research I just did CONFIG_MT7603E may cover this particular wifi chip
<Werner__> Not included in Armbian or at least in this board family though. You can build your own Armbian image using the built script and enable this module for you.
<emOne> Werner__: can I cross compile?
<emOne> with the built script that is
Toast has joined #armbian
<Werner__> The script is meant to be run in an Ubuntu 18.04 amd64 environment. So it will do the cross compiling for you
<emOne> that is very cool! Thank you Werner__
<Werner__> You're welcome
TRS-80 has quit [Quit: WeeChat 2.3]
TRS-80 has joined #armbian
<archetech> manj-rock Kernel: 5.5.0-1-MANJARO-ARM aarch64 prolly not what you guys wanna see
<archetech> tried using uboot from arch on my rc1 armbian build didnt help
Redferne has quit [Ping timeout: 268 seconds]
Redferne has joined #armbian
ced117 has quit [Ping timeout: 268 seconds]
dddddd has joined #armbian
ced117 has joined #armbian
ced117 has joined #armbian
ced117 has quit [Changing host]
<TRS-80> OK, got XMPP working via BitlBee, including desktop notifications. :)
<TRS-80> vedddy naice
<TRS-80> now I will be aware of wife messages while working on computer, no more complains about ignoring her :D
Redferne has quit [Ping timeout: 240 seconds]
Redferne has joined #armbian
drobo_00 has quit [Ping timeout: 260 seconds]
TRS-80 has quit [Quit: WeeChat 2.3]
TRS-80 has joined #armbian
c0rnelius_ has joined #armbian
maccraft123 has quit [Quit: WeeChat 2.7]
oida has quit [Quit: byez]
NeuroScr has joined #armbian
TRS-80 has quit [Quit: WeeChat 2.3]
c0rnelius_ has quit [Quit: Leaving]
drobo_00 has joined #armbian
c0rnelius_ has joined #armbian
drobo_00 has quit [Ping timeout: 265 seconds]
DaRock has joined #armbian
<lanefu> busy day in the channel today
Toast has quit [Ping timeout: 265 seconds]
<archetech> not
<archetech> are there files I need to write to sectors at beg of sdcard like arch does ?
<archetech> or are they done during the image flash
NeuroScr has quit [Quit: NeuroScr]
<lanefu> hjandled by image
NeuroScr has joined #armbian
<lanefu> it creatws partition and uboot is where it needs to be
<archetech> ok im on that now trying to understad armbian vs arch which is simple