Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Type 'help' for help | Logs: -> irc.armbian.com
MrFixIt has quit [*.net *.split]
mangix has quit [*.net *.split]
Guest3053 has quit [*.net *.split]
CrashTestDummy2 has quit [*.net *.split]
indy has quit [*.net *.split]
lanefu has quit [*.net *.split]
indy has joined #armbian
MrFixIt has joined #armbian
lanefu has joined #armbian
CrashTestDummy has joined #armbian
Net147 has joined #armbian
CrashTestDummy has quit [Read error: Connection reset by peer]
CrashTestDummy has joined #armbian
Net147 is now known as Guest504
mangix has joined #armbian
chewitt_ has joined #armbian
chewitt has quit [Ping timeout: 252 seconds]
chewitt_ has quit [Quit: Zzz..]
Malditron has joined #armbian
<Armbian-Discord>
<lanefu> im heerer
<Armbian-Discord>
<lanefu> where u at
<nekomancer[m]>
"im heerer" sounds like a dutch?
<Armbian-Discord>
<lanefu> lol
mangix has quit [Read error: Connection reset by peer]
mangix has joined #armbian
archetech has quit [Quit: Leaving]
archetech has joined #armbian
<[TheBug]>
im here now seem though your stuck over there on the dark side
<lanefu>
lies
<[TheBug]>
lol
<Armbian-Discord>
<kprasadvnsi> Anybody used ODROID-GO?
<lanefu>
yep
<lanefu>
its great
<Armbian-Discord>
<kprasadvnsi> Does it uses GPU? What kind of OS it's running?
<steev>
i've got the go super but using emuelec on it
<Armbian-Discord>
<NicoD> Also got the super. I run debian on it. Haven't checked how gpu drivers are in linux since I game with ubuntu with gamestation.
Malditron has quit [Quit: Konversation terminated!]
archetyp` has joined #armbian
archetyp has quit [Ping timeout: 245 seconds]
<Armbian-Discord>
<kprasadvnsi> How this all work? Do they ship games or we have to download it from elsewhere?
<Armbian-Discord>
<NicoD> You put on an eyepatch and become a pirate by downloading games yourself. They're easy to find. I mostly play SEGA Master System and Megadrive. Also PSX. Runs well. I should try other gaming images since N64 ain't running well on the ubuntu gamestation.
<Armbian-Discord>
<NicoD> I've also used it or watching movies and youtube. Also works well even without vpu drivers.
stipa has quit [Read error: Connection reset by peer]
stipa has joined #armbian
<IgorPec>
good morning
chives has joined #armbian
<chives>
I'm curious to find out if its possible to modify the firmware on my device to be able to boot wirelessly
stipa_ has joined #armbian
stipa has quit [Ping timeout: 256 seconds]
stipa_ is now known as stipa
<Armbian-Discord>
<kprasadvnsi> which version of armbian have VPU enabled for orange pi 4?
<Alex[m]1>
good morning
<Alex[m]1>
Could it be that a reboot with an nvme connected fails?
<Alex[m]1>
It works with a not-detectable m2 ssd (sata).
<Alex[m]1>
rockchip64
<IgorPec>
kprashdvnsi: current and edge
<IgorPec>
rockchip64 and nvme ... well, can't tell. could be a bug
<Alex[m]1>
ok, I will connect UART the next time and see what it throws in the console
<Alex[m]1>
although - this will take time, since I need another pcie m2
<IgorPec>
that is not a problem. nobody will look into it
<Alex[m]1>
I could make a bug report then but no one will check that?
<Alex[m]1>
hm... I would get an unsupported image failure because I use the armbian kernel on archlinux
<Alex[m]1>
even though, it's pretty sure a kernel issue
<Alex[m]1>
that's why I hate this way of bug reporting
<Armbian-Discord>
<Werner> Retry with official armbian image and report then. Armbian has no resources to look into issues of 3rd party/custom OS.
<Alex[m]1>
hm... yes, I guess I have to do that. I use my rockchip device more or less productive (gitea, grafana, postgres backup...), so I have to time that good
<archetech>
why use armbian kern on arch just use manjaro kern
<Alex[m]1>
I am kinda against manjaro because of their recent past
<Alex[m]1>
but this would be way too offtopic to discuss
<Armbian-Discord>
<kprasadvnsi> I am going nowhere with this rk3399 VPU. anybody tell me how to test it in userspace.
<Armbian-Discord>
<lanefu> Oh you mean one of the newer models. I have the original go that's an esp32 😁
<Armbian-Discord>
<kprasadvnsi> yah, the newer model with rk3326 chip.
<Alex[m]1>
I wanted to test any gpu driver and possibilities of using gpu accelerated processing on my rk3399 too someday
<Alex[m]1>
although, I have problems for now with a dkms module...
archetech has quit [Quit: Konversation terminated!]
archetech has joined #armbian
<Alex[m]1>
possibly stupid question - are there any usecases for the a "fallback"-initrd on embedded devices?
<Alex[m]1>
s/the//
<ArmbianHelper>
Alex[m]1 meant to say: possibly stupid question - are re any usecases for the a "fallback"-initrd on embedded devices?
<Alex[m]1>
wtf, it has edited my sentence wrong :D
<Armbian-Discord>
<IgorPec> no, we didn't develop such feature
<Alex[m]1>
ok, then it's some archlinux stuff leftover
<Alex[m]1>
another thing - on an aarch64/arm64 armbian, could someone show me the output of:
<Alex[m]1>
I fear that there is another archlinux thing going wrong
<Alex[m]1>
(missing a compiled fixdep)
newton688 has joined #armbian
lanefu has quit [Quit: WeeChat 3.2-dev]
lanefu has joined #armbian
<newton688>
Hello All, I have some questions about the kernel patches, such as the ones in patch/kernel/sunxi-edge. In what order do these get applied? How would I ensure that a patch gets applied after another one?
<Armbian-Discord>
<IgorPec> by adding numbers in front
<Alex[m]1>
With that idea you can generally power any kind of embedded lan device
<RoyK>
so not your off the shelf poe ;)
<Alex[m]1>
yup
<Alex[m]1>
poe has actually (afaik) 48V or some kind of dynamic change - I wouldn't try that on such a device
<RoyK>
popcorn!
<Alex[m]1>
roasted beef!
igorp_ has joined #armbian
igorp_ has quit [Ping timeout: 245 seconds]
<newton688>
IgorPec: Thanks, there's also other patches prefixed with board and enable. How best to handle ordering with those?
<Armbian-Discord>
<IgorPec> don't understand what is your intention - patches are applied on alphabetic / numeric order
<Armbian-Discord>
<IgorPec> this is the rule behind.
<Armbian-Discord>
<IgorPec> patch content is not affecting on order in any way
<newton688>
I'm hoping to create a patch that might be different depending on whether an enable patch was applied before/after to the same file. It's not part of the same feature as the enable patch, so I feel it should be kept separate from it.
<newton688>
Maybe my approach should be different?
Redentor has joined #armbian
<Alex[m]1>
I guess a separate patch for this would make sense
<Armbian-Discord>
<Tonymac32> newton688 what are you patching? I need to propose documentation for our patch naming, but I've spent a lot of time untangling and cleaning Rockchip64 and Meson64 (Meson64 is still a mess though, more to do)
<Armbian-Discord>
<Tonymac32> What Igor recommended is the easiest. If the patch you are needing to follow is named differently though (say "board_thing_add_stuff.patch"), then I would change it to board_thing_00_add stuff.patchband make the new patch "01"
<Armbian-Discord>
<Tonymac32> That shouldn't disrupt the existing "order"
<Armbian-Discord>
<Tonymac32> And make sure the new patch is after the old patch
<RoyK>
what's the thing about discord, anyway?
<lanefu>
what's everyone position on stability of odroid C4?
<IgorPec>
mine sits in the rack and i don't recall it ever hanged
<IgorPec>
unless on reboot
<IgorPec>
but i think that is also fixed in recent kernel / u-boot
<newton688>
Tonymac32: Thank you for the suggestion. I'll give that a try and see what everyone thinks in the pull request.
<newton688>
This is a annoying little thing with the pinecube where the enable/disable of the LED's is inverted. Currently, it's 1=off and 0=on, which is very counter-intuitive. The NixOS people have made the one-line change to make it more reasonable.
<newton688>
I'm hoping to bring the two distros closer to being inline while things take their time to get mainlined.
<lanefu>
newton688: is that just setting active_low 0 or vice-versa for the pin?
<lanefu>
newton688: armbian has a concept of board optimizations where little tweaks are applied at startup
<lanefu>
not everything has to be a device tree patch
<newton688>
lanefu: Yes, exactly. Where's the documentation on the board optimizations? I'll check it out and think about whether it makes more sense to do device tree patch or use this approach.
<lanefu>
newton688: if Device tre change.. probably want to just ship as an overlay
<lanefu>
rather than further diverging from the patch set we're following
<newton688>
:) Fair enough.
<newton688>
I'm not familiar with these concepts. So, what's the best way to learn about them? Any examples I could look at?
<lanefu>
so armbian-config recently addeda tool to help make custom device tree overlays.. i hvaen't really used it... I _think_ there's some stuff either in the documentation or at least some good forum posts on usin git
<lanefu>
sorry that isn't more helpful
* lanefu
is prone to being a middle-man only offering breadcrumbs
<lanefu>
"DTO" / Device Tree Overlay
<lanefu>
actually i thikn DTO is not a device tree overlay
<lanefu>
lol
<lanefu>
i cant mremnber
* lanefu
stops talking
<Alex[m]1>
sadly I don't really know where the rockchip64 kernel sources are (totally confusing), otherwise I would've looked there
<newton688>
Ok, thanks, I'll see what I can find. I'm kind of leaning towards patching the device tree at this moment. I think that it doesn't really make sense to anyone to have 0=on and 1=off. lol
<lanefu>
yeah i mean i assume it's a hardware design that's causing the behavior to seem inverted
<newton688>
Every day, I find more cool stuff I can do with armbian-config. What a great tool. Thanks so much all for it. :)
<lanefu>
but yeah.. its describing state of gpio pin, vs leogical state of led i guess
<lanefu>
armbian-config is powerful, but also in desperaete need of refactoring
<lanefu>
there'sa lot of forum conversation about it
<lanefu>
and feel free to check out its issue on its github repo as well if you're interested
<newton688>
I plan to use it as my provisioning tool so that I can make a base SD card image for all my cameras and then use it to set hostname, timezone, wifi, etc.
<lanefu>
newton688: cool.. have you trying using armbian.com/build to make your own image?
<lanefu>
there's customizaition hooks etc
<lanefu>
that you might be interseted in
<lanefu>
also see `/boot/armbian_first_run.txt.template`
<newton688>
Yes, I managed to get it working with Docker last week. Super cool way to test out my patches and such.
<lanefu>
i really need to do some vids or docs on using the tool for customing
<newton688>
Oh, sorry, it can build the entire SD card image. That's sweet.
<lanefu>
customizing
<lanefu>
yeah i usually just build custom images
<newton688>
Thanks, I might check that out.
<lanefu>
and use ROOTFS_TYPE=btrfs :P
<newton688>
I'm going to make a set of instructions on how to make the pinecube a USB webcam that involve some device tree customizations that probably don't make sense for everyone.
<lanefu>
yeah see teh build_otpions section and the customization section of our docs
<newton688>
I'm planning on starting with just some documentation on how to use armbian-config to edit the device tree and then look at better automation. Perhaps I could even publish some images automatically someday.
<lanefu>
ha... well the more you script the less you have to instruct :)
<newton688>
Automation will be great. :)
<lanefu>
yeah def play witjh the builder tool. it's very powerful... just takes some time to understand its quirks and features
<newton688>
Thanks again for your help and support lanefu and everyone.
<Armbian-Discord>
<lanefu> Thanks for choosing armbian
archetyp has joined #armbian
Redentor has quit [Quit: Leaving]
<Alex[m]1>
<lanefu> "and use ROOTFS_TYPE=btrfs :P" <- same
<Alex[m]1>
hm... it looks like some kernel versions have issues for building modules
<Armbian-Discord>
<lanefu> what are you building, where and how
loki_val has joined #armbian
crabbedhaloablut has quit [Ping timeout: 276 seconds]
<Alex[m]1>
/lib/modules/5.10.59-rockchip64/updates/rtw_core.ko: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), BuildID[sha1]=2546dae684a2a975458eba10689ef4be5262ae2d, not stripped
<Alex[m]1>
/lib/modules/5.10.59-rockchip64/updates/rtw_core.ko: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), BuildID[sha1]=2546dae684a2a975458eba10689ef4be5262ae2d, not stripped