ArmbianHelper 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 | Logs: -> irc.armbian.com
Mony has quit [Ping timeout: 256 seconds]
Mony has joined #armbian
norwich_ has joined #armbian
norwich has quit [Ping timeout: 252 seconds]
norwich_ is now known as norwich
<Armbian-Discord> <M​anoftheSea> yay
<Armbian-Discord> <M​anoftheSea> apparently, my upgrade and reboot also worked, and I'm on 5.15.76
archetech has quit [Quit: Konversation terminated!]
archetech has joined #armbian
lemonzest has joined #armbian
archetech has quit [Quit: Konversation terminated!]
califax has quit [Ping timeout: 255 seconds]
califax has joined #armbian
junaid_ has joined #armbian
qqqhhh86199 has quit [Ping timeout: 260 seconds]
<zeewark1> hi everybody, how far is support of Pine's Quartz64 boards? Is there anything I can help?
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #armbian
califax has quit [Remote host closed the connection]
califax has joined #armbian
califax has quit [Remote host closed the connection]
califax has joined #armbian
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #armbian
oida has joined #armbian
<Armbian-Discord> <I​gorPec> zeewark1 here you can find list of open tasks https://armbian.atlassian.net/jira/dashboards/10000
<Armbian-Discord> <I​gorPec> or where staff is needed https://forum.armbian.com/staffapplications/
LanDi has joined #armbian
junaid_ has quit [Remote host closed the connection]
junaid_ has joined #armbian
maknho has quit [Remote host closed the connection]
maknho has joined #armbian
LanDi has quit [Remote host closed the connection]
arch3r has quit [Quit: bye]
arch3r has joined #armbian
<Armbian-Discord> <T​onymac32> Desktop on renegade is borked, saw a complaint on a board review. Build dates oct 23.
<Armbian-Discord> <T​onymac32> I verified before falling asleep, what have we been messing with.
junaid_ has quit [Ping timeout: 260 seconds]
alekksander has joined #armbian
<Armbian-Discord> <c​0rnelius> the hdmi out on my renegade produces a shaky display. not sure whats up with that.
<Armbian-Discord> <T​onymac32> Mine flashes the cursor/black for a few minutes before just settling on a cursor.
<Armbian-Discord> <T​onymac32> I'll check it out later, but I also remember someone complaining about horrible UI response on a rock64, so my guess is someone brilliantly managed to turn glamour/ etc back on for the whole rockchip64 family. X11 + GPU acceleration on Mali450 is 💀
<Armbian-Discord> <I​gorPec> where was this enabled / disabled?
junaid_ has joined #armbian
<Armbian-Discord> <T​onymac32> I don't even remember, it's been over a year since we took care of that issue across all the baby Mali's
<Armbian-Discord> <T​onymac32> I'll take a look and figure it out. Upstream unlatched stuff is still fine, so it's our doing somehow
<Armbian-Discord> <T​onymac32> Of course it boots extlinux and I didn't do that either, so apparently the renegade has a mind of it's own 🙂
<Armbian-Discord> <I​gorPec> hmm, most of my testings are headless 🙂
<Armbian-Discord> <I​gorPec> so this part i don't notice
<Armbian-Discord> <I​gorPec> where this is / was defined / changed?
<Armbian-Discord> <M​anoftheSea> If I boot a system, and reboot it before setting the password, do I put armbian_first_boot.txt in /boot to get it to ask again? Or is there something else easy that doesn't involve fully reflashing?
<Armbian-Discord> <c​0rnelius> This u-boot patch seems to resolve the flickering issue on rk3328: https://paste.debian.net/1261849/
<Armbian-Discord> <T​enkawa> nice
<Armbian-Discord> <c​0rnelius> yeah just tested it on the renegade. looks better.
<Armbian-Discord> <T​onymac32> U-boot? Wtf
<Armbian-Discord> <c​0rnelius> yeap
<Armbian-Discord> <T​onymac32> Ugh qos
<Armbian-Discord> <T​onymac32> But why is that an issue for the kernel
<Armbian-Discord> <T​onymac32> Unless it isn't setting anything up for qos
<Armbian-Discord> <T​onymac32> 😑
<Armbian-Discord> <T​onymac32> sigh, I haven't touched U-boot for that board since someone swapped it over to extlinux for no fucking reason. TBH it's hard to come up with excuses to even engage with the project these days when 3/4 of the effort is brought on by others in the project.
<Armbian-Discord> <T​onymac32> shrugs oh well I guess. Keep calm and carry on or something
<Armbian-Discord> <c​0rnelius> mine is currently using gpt/uefi/grub https://paste.debian.net/1261853/, but extlinux is way easier. thats good if armbian is using that with the board I thinks.
junaid_ has quit [Ping timeout: 265 seconds]
junaid_ has joined #armbian
<Armbian-Discord> <M​anoftheSea> I don't get what grub adds to UEFI boot
<Armbian-Discord> <M​anoftheSea> It's just what people know already, right?
<Armbian-Discord> <M​anoftheSea> Also, I think uboot calls it sysboot
attah has quit [Read error: Connection reset by peer]
<Armbian-Discord> <M​anoftheSea> Even though it's extlinux.conf
attah has joined #armbian
<Armbian-Discord> <c​0rnelius> Extlinux is a less feature rich version of syslinux. As for grub, it works on more platforms, where systemd-boot requires one to use gpt. which isn't always an option.
<Armbian-Discord> <J​ason123> grub adds an efi file that gets booted I think
<Armbian-Discord> <c​0rnelius> they all do from what I can tell
<Armbian-Discord> <J​ason123> extlinux is not even efi
<Armbian-Discord> <c​0rnelius> i know... but when dealing with efi you need to be able to create the file. extlinux isn't efi.
<Armbian-Discord> <J​ason123> yeah grub makes the efi files when it generates everything
<Armbian-Discord> <J​ason123> armbian with grub?
<Armbian-Discord> <M​anoftheSea> GRUB runs as an EFI file, sure, much like it can run from MBR.
<Armbian-Discord> <M​anoftheSea> systemd-boot requires GPT, yes, because it only runs out of ESP.
<Armbian-Discord> <M​anoftheSea> But if you're already booting EFI, you already pointed at a bootloader, then GRUB acts as another bootloader, one with a LOT of extra unnecessary code.
<Armbian-Discord> <M​anoftheSea> Of course, u-boot has a lot of extra code too... btrfs drivers? Come on!
<Armbian-Discord> <T​onymac32> None of the Armbian tools work with it, so it's an orphan
lemonzest has quit [Quit: WeeChat 3.6]
<Armbian-Discord> <M​anoftheSea> I guess the reason to use GRUB is because u-boot doesn't store EFI vars like BootOrder or NextBoot
<Armbian-Discord> <M​anoftheSea> The value of the environment variable bootargs is converted from UTF-8 to UTF-16 and passed as load options in the loaded image protocol to the UEFI binary.
<Armbian-Discord> <M​anoftheSea> Ah, that's how you set the cmdline with bootefi
riotz has quit [Ping timeout: 265 seconds]
<Armbian-Discord> <J​ason123> is there even any way to boot without uboot?
<Armbian-Discord> <J​ason123> uboot/edk2 something similar
<Armbian-Discord> <J​ason123> because then that makes it not really useless extra code because there are no alternatives
<Armbian-Discord> <M​anoftheSea> I mean having repeats of filesystem drivers between uboot and kernel
<Armbian-Discord> <M​anoftheSea> uboot reading FAT makes sense, because it's a lowest common denominator between lots of OSes and UEFI
<Armbian-Discord> <M​anoftheSea> But having ext4, btrfs, etc is unnecessary
<Armbian-Discord> <T​onymac32> u-boot isn't just for linux is a key here
<Armbian-Discord> <T​onymac32> I used it to load a bare metal binary on the old Mini2440 for example
<Armbian-Discord> <M​anoftheSea> of course it's not just for linux
<Armbian-Discord> <M​anoftheSea> But is it an OS, or just platform firmware?
<Armbian-Discord> <T​onymac32> yes
<Armbian-Discord> <T​onymac32> 😄
<Armbian-Discord> <M​anoftheSea> that's the problem
<Armbian-Discord> <c​0rnelius> btrfs support means in theory you could boot a board that has one btrfs partition that had both boot and the rootfs on it. the problem is uboot doesn't support subvolumes (as far as I know) so it makes btrfs support kind of stupid.
<Armbian-Discord> <M​anoftheSea> It needs to be platform firmware and get out of the way
<Armbian-Discord> <T​onymac32> for someone wanting a clean linux experience, of course
<Armbian-Discord> <M​anoftheSea> Why would you have a board with only btrfs partition with boot on it? Put that in FAT on an ESP
<Armbian-Discord> <c​0rnelius> so to support subvolumes you still need a boot partition.
<Armbian-Discord> <M​anoftheSea> For nearly anything, you need a boot partition.
<Armbian-Discord> <M​anoftheSea> So only support boot partitions, not "everything linux can support"
<Armbian-Discord> <c​0rnelius> why not? why do we do this with ext4? because we can.
<Armbian-Discord> <c​0rnelius> if I don't need a boot partition I don't create one
<Armbian-Discord> <M​anoftheSea> "Why do we reinvent the wheel? because we can. With new bugs this time!"
<Armbian-Discord> <c​0rnelius> there are no bugs in not having a boot partitio
<Armbian-Discord> <M​anoftheSea> u-boot claims a design goal of "keep it small"
<Armbian-Discord> <M​anoftheSea> A full blown UEFI implementation would contradict the U-Boot design principle “keep it small”.
<Armbian-Discord> <c​0rnelius> I find very few people use UEFI in the use case that most of us use these little arm boards. its kind of over kill really.
<Armbian-Discord> <c​0rnelius> its a matter of can we mostly and yes, we can. but its not really bringing anything to the table on say a board like the Renegade.
<Armbian-Discord> <J​ason123> something where its just generic image and then it can at least boot like on amd64 would be cool
<Armbian-Discord> <M​anoftheSea> That's not because of a technical reason
<Armbian-Discord> <J​ason123> not that everything would work just that it would at least boot
<Armbian-Discord> <M​anoftheSea> Vendor provides a shitty stack, but it mostly works, so no one goes back and does things right
<Armbian-Discord> <J​ason123> I have a random windows tablet that is just generic stupid windows tablet that has almost no information online about it but at least it boots linux even if it does not work the best
<Armbian-Discord> <J​ason123> i can't boot armbian because its 32bit efi
<Armbian-Discord> <M​anoftheSea> is that x86?
<Armbian-Discord> <J​ason123> x86_64
<Armbian-Discord> <J​ason123> efi
<Armbian-Discord> <M​anoftheSea> then why is it 32bit efi?
<Armbian-Discord> <J​ason123> because it is
<Armbian-Discord> <M​anoftheSea> but anyway, x86/x64 use ACPI, right? And linux has decades of interpreting ACPI for windows.
<Armbian-Discord> <M​anoftheSea> Whereas device tree is more commonly believed at face-value, yes?
<Armbian-Discord> <M​anoftheSea> And it ought to be that the Device Tree is a declarative description of the board that is written once, perfectly, and any OS can use it
<Armbian-Discord> <M​anoftheSea> "ought to be"
<Armbian-Discord> <M​anoftheSea> I also want a pony
<Armbian-Discord> <J​ason123> acpi is much better because at least it can boot linux and the only work that might have to be done on an x86_64 device is on individual parts
<Armbian-Discord> <M​anoftheSea> what?
<Armbian-Discord> <M​anoftheSea> what do you mean, "ACPI can boot linux"?
<Armbian-Discord> <J​ason123> the linux kernel has the device tree for every device in the kernel that uses device tree
<Armbian-Discord> <J​ason123> just every device where the device tree is in the mainline kernel
<Armbian-Discord> <J​ason123> but x86_64 does not need any of that
<Armbian-Discord> <J​ason123> with acpi
<Armbian-Discord> <M​anoftheSea> I don't think the linux kernel has the helios64, I think armbian patches that in.
<Armbian-Discord> <M​anoftheSea> ACPI is owned by UEFI Forum anyway, today.
<Armbian-Discord> <J​ason123> helios64 is rk3399?
<Armbian-Discord> <M​anoftheSea> But if you had a rock pi N which had platform firmware that passed an internal device tree, you'd have the same situation as x64's ACPI
<Armbian-Discord> <M​anoftheSea> We see the difference because the boards don't carry their own device trees, because the vendors don't take responsibility for their crap
<Armbian-Discord> <T​onymac32> The EFI Armbian images boot on the Phytium D2000 despite a 0% support in the Linux kernel
<Armbian-Discord> <J​ason123> the phytium has a port of edk2 to it even if its bad
<Armbian-Discord> <T​onymac32> Yeah, we need the source for this
<Armbian-Discord> <T​onymac32> Lol
<Armbian-Discord> <T​onymac32> Some adjustments and I think it would be great instead of ok
<Armbian-Discord> <T​onymac32> DVFS isn't working right now for example, lots of memory allocation overlaps on devices
<Armbian-Discord> <T​onymac32> There is a series of patches floating around in gitee that add a device tree so Linux can avoid stomping on the undefined bits
<Armbian-Discord> <J​ason123> it would be great if boards could boot with no support in the linux kernel
<Armbian-Discord> <M​anoftheSea> I don't know what that even means
<Armbian-Discord> <T​onymac32> I mean, they can, but only so far haha
<Armbian-Discord> <M​anoftheSea> Are you saying without device drivers, by relying on those passed by UEFI?
<Armbian-Discord> <J​ason123> without things like device tree support and whatever else is merged into the kernel for boards
<Armbian-Discord> <M​anoftheSea> Why wouldn't you have DT support?
<Armbian-Discord> <M​anoftheSea> DT is how ARM defines the hardware.
<Armbian-Discord> <M​anoftheSea> how arm devices define the hardware
<Armbian-Discord> <M​anoftheSea> But you don't merge a specific DT into the kernel, you read the passed in tree, the same as you make use of ACPI tables
<Armbian-Discord> <M​anoftheSea> And in an ideal world, you'd have the platform firmware pass a fully correct device tree to Linux. It might not have drivers for all the devices defined, but it would be a complete description of the computer.
<Armbian-Discord> <M​anoftheSea> at least up to other discoverable busses. Like, you don't need a DT to describe everything on PCIe, because they can self-report
<Armbian-Discord> <J​ason123> x86_64 does not have device trees
<Armbian-Discord> <J​ason123> most intel devices can at least boot a generic kernel
<Armbian-Discord> <M​anoftheSea> Sure, because it's got an older standard
<Armbian-Discord> <M​anoftheSea> much, much older
<Armbian-Discord> <M​anoftheSea> And mostly working ACPI, with decades of linux hacks to get around vendor bugs
<Armbian-Discord> <J​ason123> I tried to boot void linux distro kernel on my radxa zero and it does not boot
<Armbian-Discord> <M​anoftheSea> Who provided the platform firmware for that?
<Armbian-Discord> <M​anoftheSea> Random hackers unaffiliated with Radxa trying to reverse engineer the soc?
<Armbian-Discord> <J​ason123> there is no support for the radxa zero in void
<Armbian-Discord> <M​anoftheSea> beyond that, though, why didn't void linux boot?
<Armbian-Discord> <c​0rnelius> Void boots fine on the radxa zero
<Armbian-Discord> <M​anoftheSea> What "support" does void need to add?
<Armbian-Discord> <J​ason123> yeah with custom kernel
<Armbian-Discord> <M​anoftheSea> Do you mean radxa didn't upstream support for the SoC?
<Armbian-Discord> <M​anoftheSea> Why is that Void's problem?
<Armbian-Discord> <J​ason123> I think its more of a arm in general instead of void issue
<Armbian-Discord> <M​anoftheSea> Even if the DT is perfect, if Linux doesn't know how to use the described devices because the vendor didn't add support to linux, then yeah, it's not gonna work.
<Armbian-Discord> <c​0rnelius> yeah but thats absurd. Armbian is using a custom kernel?
<Armbian-Discord> <M​anoftheSea> If VIA didn't add device drivers for Padlock, I don't blam it on being an x86 system.
<Armbian-Discord> <c​0rnelius> booting an arm board. expect some level of customization.
<Armbian-Discord> <M​anoftheSea> Armbian carries patches for boards because the vendor doesn't do its job
<Armbian-Discord> <M​anoftheSea> It'd be great if you didn't have to customize the kernel for the board (ebin master race), but that's not because of Linux or Device Tree, it's because the vendor has failed you.
<Armbian-Discord> <J​ason123> and then random windows tablet also vender does no work for linux
<Armbian-Discord> <M​anoftheSea> And random android tablet has everything run as root because the vendor didn't understand the security model.
<Armbian-Discord> <J​ason123> android tablets run everything as root?
<Armbian-Discord> <M​anoftheSea> When the vendor is a failwhale
<Armbian-Discord> <M​anoftheSea> They're not supposed to
<Armbian-Discord> <J​ason123> and then my android phone does not even have root
junaid_ has quit [Ping timeout: 268 seconds]
junaid_ has joined #armbian
<Armbian-Discord> <J​ason123> I hope someone finds a way to unlock the bootloader on a verizon pixel 2
<c0rnelius> stop buying phones from service providers
<Armbian-Discord> <J​ason123> I bought it on amazon and its exactly the same as the regular model except for the bootloader lock
<Armbian-Discord> <J​ason123> no verizon branding on it
<Armbian-Discord> <J​ason123> your saying radxa has failed?
archetech has joined #armbian
junaid_ has quit [Quit: leaving]
junaid_ has joined #armbian
junaid_ has quit [Remote host closed the connection]
<Armbian-Discord> <M​anoftheSea> If a generic Linux kernel doesn't boot even though you used UEFI, yeah.
<Armbian-Discord> <M​anoftheSea> U-boot ought to read the ESP and variables from platform, load an fdt for the next stage, and run an efi app. Just like x64
<Armbian-Discord> <M​anoftheSea> Though, I suppose systemd-boot exists because of UEFI bootloader inadequacy. U-boot could use drop in files instead of a monolithic extlinux.conf, and that would be better.
<Armbian-Discord> <g​oodieteabag> Hi, i'm having issues getting docker to run on my tinkerboard. Don't know if i'm alowed to ask for help in this forum though? 😄
<Armbian-Discord> <g​oodieteabag> Getting err mess: ```Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown.````
<Armbian-Discord> <g​oodieteabag> Looked around and found answers that it could be the kernel being below 5.x. But that is not my issue
<Armbian-Discord> <g​oodieteabag> ````
<Armbian-Discord> <g​oodieteabag> uname -a
<Armbian-Discord> <g​oodieteabag> Linux tinkerboard 5.15.74-rockchip #22.08.6 SMP PREEMPT Tue Oct 18 06:40:37 UTC 2022 armv7l armv7l armv7l GNU/Linux
<Armbian-Discord> <g​oodieteabag> ````
riotz has joined #armbian
<Armbian-Discord> <M​anoftheSea> Is there a cmdline option you need to set for docker?
<Armbian-Discord> <I​gorPec> but it looks like you asked on forum already, didn't you?
<Armbian-Discord> <g​oodieteabag> i asked everywhere 🙂
<Armbian-Discord> <g​oodieteabag> @ManoftheSea i'm fairly new to both docker and linux. what kind of cmdline option?
<Armbian-Discord> <g​oodieteabag> trying to get home assistant running. Got it running before on debian strecth. but then i wanted to use a ssd instead of an sd-card. But i only managed to get that workinng on armbian.
<Armbian-Discord> <M​anoftheSea> I dunno. I thought there was something required, but that's only a vague feeling
<Armbian-Discord> <M​anoftheSea> Sorry, I don't know more
<Armbian-Discord> <g​oodieteabag> So i tried home-assistants "run script" there is a bunch of options tied to it. didnt work. So then i just tried the hello world example. But i get the same issue there
peterm6881 has joined #armbian
peterm6881 has quit [Remote host closed the connection]
archetech has quit [Quit: Konversation terminated!]
norwich has quit [Ping timeout: 264 seconds]
archetech has joined #armbian
alekksander has quit [Quit: Konversation terminated!]