ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | Armbian 20.11 Tamandua released | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Type 'help' for help | Logs: -> irc.armbian.com
grae has joined #armbian
sunshavi has quit [Remote host closed the connection]
<grae>
hey Tonymac32, you don't happen to be around tonight?
<lanefu>
Sup grae
<grae>
not much, just looking at gettext while mulling how to approach an armbian-config POC
<grae>
yourself?
<lanefu>
some how ended up playin gwith borg backup adn syncthing
<threenp>
i started setting up syncthing ages ago but never finshed the setup - would you say it suits well as a "dropbox-replacement"?
<threenp>
gotta get my PKI and CA together, things are a bit fragmented rn xD
<stipa>
hi grae
torv has quit [Ping timeout: 268 seconds]
torv has joined #armbian
<threenp>
oh, hmmm, i think i may be on to something why i only have networking in initramfs but not after full boot on odroidhc4.
<threenp>
in `armbianEnv.txt`: `fdtfile=amlogic/meson-sm1-odroid-hc4.dtb`
<threenp>
The latter does not exist on the boot partition, and in either case is odroidc4, rather than odroidhc4 - so looks like for some reason it's booting with the wrong dtb for the board?
<threenp>
in `boot.cmd`: `load ${devtype} ${devnum} ${dtb_loadaddr} boot/dtb/amlogic/meson64_odroidc4.dtb`
<threenp>
* oh, hmmm, i think i may be on to something why i only have the eth0 networking interface coming up in initramfs but not after full boot on odroidhc4.
<threenp>
in `boot.cmd`: `load ${devtype} ${devnum} ${dtb_loadaddr} boot/dtb/amlogic/meson64_odroidc4.dtb`
<threenp>
The latter does not exist on the boot partition, and in either case is odroidc4, rather than odroidhc4 - so looks like for some reason it's booting with the wrong dtb for the board?
<threenp>
in `armbianEnv.txt`: `fdtfile=amlogic/meson-sm1-odroid-hc4.dtb`
<lanefu>
threenp: yeah now that i get it. its very much a dropbox replacement if you dont want to send files to other people
<grae>
threenp, the Linux kernel should already be running once it gets to the initramfs, it should have already loaded the DTB by then
<grae>
do you happen to mean u-boot, and not initramfs?
<threenp>
i mzy mean u-boot - tbh i don't grok how u-boot fits into the boot process
<grae>
u-boot is the bootloader, that's what happens before Linux takes over
<threenp>
but essentially, i can do cryptroot unlock just fine at boot (from u-boot but i guess thats still initramfs). once in the full system the interface just wont come up
<threenp>
but yeah, is the kernel the same throughout or does it load a new one?
<grae>
initramfs is sort of an early userspace. it's running after Linux starts, but before the root filesystem is mounted and SystemD takes over
<threenp>
oh right so u-boot is just instead of grub or systemd-boot that i would otherwise have
<grae>
but no, no kernel changes after that point
<grae>
but in u-boot (where you could run "printenv"), if you have Ethernet there, it's probably not loading the DTB
<threenp>
that's what i would have expected, but i start suspecting crazy things when i just can't point to anything else x)
<grae>
I mean, if you think boot.cmd is wrong, back up the file, and change it. see if that fixes it.
<grae>
if it does, submit a bug or PR to fix it
<threenp>
yeah, on that now :)
<threenp>
meh, now it won't come up initially either
<threenp>
what order are thjose dtbs supposed to be loaded in, the one in boot.cmd and the one iin armbianEnv.txt?
<threenp>
I read here but it's not clear how that relates to what's in boot.cmd, and whenin the boot process this happens
<grae>
you should only load one DTB
<threenp>
that's what i would have expected too
<grae>
you may load one or more DTB overlays (dtbo), which sort of do an in-place edit
<kprasadvnsi[m]>
is Armbian master branch is functional?
<grae>
previous ODroid C2 builds I've looked at had a section for legacy vs modern kernel, and may have different DTBs listed
<grae>
threenp, you might check to see if you're running a 5.X series kernel. I think that part of the boot.cmd script is only appropriate for the legacy kernel
<threenp>
5.10.19 indeed
<grae>
then lines 93-107 don't run
<threenp>
ah, could that explain why the hc4 won't bott at all when building with 4.x kernel? because it tries to load the wrong dtb
<threenp>
i guess originallymeson64 was odroidc4 only, and then hasn't been amended for supporting new boards in the family for the legacy kernel
<grae>
well, ODroid C2 was also Meson64. but they may have pushed the C2 to mainline before C4 support showed up?
<grae>
either way, that's probably at least an ugly hack
<threenp>
could be
<grae>
line 121 should load your DTB (or Flattened Device Tree)
<threenp>
it looks like odroidhc4 is actually in mainline since 5.11.1, is it easy to try that on an existing install?
<threenp>
i think my issue is somehow related to either an extranous or missing patch regaridng rgmii, it looks exactly liuke issues other reported on n2+ that has the same NIC
<grae>
kprasadvnsi[m], do you have reason to believe it's not?
<threenp>
the n2+ issue is reportedly fixed now (don't have one so can't verify but the reports say it's fixed)
<grae>
threenp, I've also seen reports that Ethernet disappeared on C4 builds, so might have affected a number of ODroid boards ...
<kprasadvnsi[m]>
grae: I am getting this on a fresh install
<threenp>
kprasadvnsi[m] [chat.freenode.net]: I had that one last night, I tried again a while later and it worked fine, iit seemd like an intermittent repo issue
<grae>
sorry C2, not C4. But looks like there was a patch that removed some "redundant" Ethernet code
<kprasadvnsi[m]>
<threenp "kprasadvnsi [chat.freenode.net]:"> this doesn't work with even with USE_TORRENT=yes option
<threenp>
yeah, i wonder if that either needs to be done here too, or if it is in effect when it shouldt
<kprasadvnsi[m]>
> <@freenode_threenp:matrix.org> kprasadvnsi [chat.freenode.net]: I had that one last night, I tried again a while later and it worked fine, iit seemd like an intermittent repo issue
<kprasadvnsi[m]>
* this doesn't work even with USE_TORRENT=yes option
<threenp>
kprasadvnsi[m] [chat.freenode.net]:
<threenp>
try to wipe all your caches and try again
grae has quit [Ping timeout: 260 seconds]
<threenp>
i think i had to wipe some file that wasnt properly downloaded and failed the verification
<kprasadvnsi[m]>
<threenp "try to wipe all your caches and "> its a fresh install. there is no cache to wipe
<threenp>
well, i guess the first time it legit failed due some issue (network/repo issue/fs issue/?) and then on subsequent retries you're using the stale data tsill
<threenp>
so i mean between attempts
<threenp>
in my case the culrpit was `gcc-linaro-7.4.1-something`
<threenp>
replace line 1382 in `general.sh` with `exit_with_error "verification of $filename failed"` and you will see which file is the issue
<threenp>
grae [chat.freenode.net]: wtf, i have no idea why this didnt work before as i tried it dozens of time yesteday, but now after doing an `update-initramfs` and rebooting (without changing `boot.cmd`) it actually brings up the eth0! Huge success!
<threenp>
On 5.10.19.
<threenp>
hmm, it doesn't seem to recognize the kernel sources properly though ( I did build the image with `INSTALL_KSRC=yes` and haven't changed/installed anything manually since)
<threenp>
`Module build for kernel 5.10.19-meson64 was skipped since the kernel headers for this kernel does not seem to be installed.`
<threenp>
though package `linux-source-5.10.19-current-meson64` is installed
<threenp>
installed the package `linux-headers-current-meson64` ; same
Guest64086 has quit [Remote host closed the connection]
Guest64086 has joined #armbian
Guest64086 has quit [Remote host closed the connection]
<threenp>
this did it: ln -s /usr/src/linux-headers-$(uname -r) /lib/modules/$(uname -r)/build
<threenp>
still at it - i git it up at ONE point but then as i messed around with kernel headers and sources to get zfs in there i must have regressed it and back to broken
<threenp>
ATM started from scratch and trying to get it up again
<Sajunara>
Frustrating. I've been banging my head against it today too.
<sunshavi>
branch fix_511
<threenp>
Sajunara [chat.freenode.net]: are you on an odroidhc4 as well?
<threenp>
or which board?
<Sajunara>
The pre-built image on the website works fine for me, but if I try to build on my own, I don't get networking on boot. Only in initramfs.
<Sajunara>
Yup.
<Sajunara>
HC4
<threenp>
ah, same then
<threenp>
i really shpoulkd have backed the whole image up when i got it up
<threenp>
such a perfect storm of frustration, would have been acceptable if it had USB3 so I could use an USB NIC :P
<Sajunara>
Has it worked for you properly before? This is my first time setting up the board so I wasn't sure if I was doing something wrong, or if a bug was introduced at some point.
<threenp>
apart from that intermittent moment i mentioned, i never got it working. first time trying to set it up now
<threenp>
i haven't figured out how to repoduce the build from the provided image (since rebuilding with the same config gets different minor version of kernel etc)
<Sajunara>
Was just about to say, if there was any way to build the exact same version.
<Sajunara>
Welp.
<Sajunara>
Do you think this is an issue with the kernel version?
<threenp>
well it's one possibility
<threenp>
fwiw if you didn't see, odroidhc4 is in mainline since 5.11.1. rebuilt with dev (changing the source to fetch 5.11.y branch from kernel.org repo) and it didnt change enything
_whitelogger has joined #armbian
<threenp>
let me know if you come up with something!
<Sajunara>
Yeah, will play around with it some more.
<Sajunara>
But I have a feeling this is beyond my skill level.
whoiswho has joined #armbian
<whoiswho>
Hi all.. having serious issues getting the kernel to build properly (or even output it) with my custom settings. Could someone have a look what could be going on? I have logs from the build script and list of output folders.
<whoiswho>
Trying to build a new kernel for Odroid N2+ with 1000 Hz timer (and with periodic scheduler) and have put my kernel configs in userpatches/linux-meson64-current.config which the script supposedly acknowledges (visible in log).
<whoiswho>
I could post the logs from the build script and list of output folders in pastebin if it's not possible to send via IRC. Appreciate all the help.
<Sajunara>
threenp, I can get the network up with a "ip link set dev eth0 down; rmmod realtek; modprobe realtek; ip link set dev eth0 up"
<threenp>
w000t
<Sajunara>
*shrug*
<Sajunara>
Are you able to reproduce?
<threenp>
sec :)
<threenp>
it's aliiiive
<Sajunara>
:p
<threenp>
you're the boss Sajunara [chat.freenode.net]
<threenp>
i guess questoin is best way to make it work reliably on boot
<Sajunara>
Now someone smarter than me figure out why this works and how we turn it into a permanent fix.
<Sajunara>
Yeah.
<kprasadvnsi[m]>
"/build/lib/main.sh: line 535: BO: command not found"
<kprasadvnsi[m]>
this what i am getting from this morning
<Sajunara>
Alright. I just made a oneshot service to reload the module on boot. That solves it for now, but hopefully it gets fixed properly eventually.
DaRock has joined #armbian
<whoiswho>
Anyone able to help regarding my issue with building the kernel? The logs all look good but the output file (which is listed in the log) is not present when the build script ends.
<threenp>
we don't have much to go with by just "it's not working; i have logs". don't ask if you can ask, just askl
<whoiswho>
Well, I realise my initial question was a bit vague yes.. but I didn't know if anyone was here to respond or help with the issue
<threenp>
such is the nature of these waters ;)
<threenp>
identifying any erraneous or exceptional entries in your log would be a good start; why and where is it failing?
mpmc is now known as toast
toast is now known as mpmc
<whoiswho>
So... I've been trying to build the kernel with a few custom settings -- 1000 Hz timer and periodic scheduler -- and have been having issues getting the script to actually USE the config. It just appeared to ignore any settings or config files that I gave it (via the TUI). Yesterday I chatted with Werner about this and I was to try putting the
<whoiswho>
kernel config file in userpatches/ as linux-meson64-current.config as outlined in the Armbian docs.
<whoiswho>
threenp, actually it doesn't appear to fail at any point, that's the weird thing.
<threenp>
so whats the last you see
<threenp>
otr different at every attempt?
<whoiswho>
So today I ran the build script (config.sh) having put my custom kernel config in userpatches/linux-meson64-current.config and based on the build logs it recognises it
<whoiswho>
I don't know if this is going to paste properly but lets see:
<whoiswho>
[[0;32m o.k. [0m] File name [[0;33m linux-image-current-meson64_21.05.0-trunk_arm64.deb [0m]
<whoiswho>
That's the last lines of the log, except for "Runtime ..." and "Repeat Build Options ...".
<threenp>
so it's hanging building the kernel (which could take a while depending on your hardware; if you're building on an SBC or other slow hw could be an hour or more)
<whoiswho>
But the funny (well, more annoying) thing is that linux-image-current-meson64...deb is actually not in /root/build/output/debs/ once the script is finished
<threenp>
maybe there's some other log file i'm not aware of.. what you could try is see the most recently modified files
<threenp>
`$ find $DIR -mmin -5 -type f` whou;ld for example find all files modified within 5min under $DIR
<whoiswho>
I'm running it on a virtual machine (via VMWare Workstation Pro) and using the mini.iso that is suggested by the Armbian docs
<threenp>
oh, so it actually exits, not hanging
<threenp>
yeah, so you do that inside there
<whoiswho>
Yep
<whoiswho>
Appears to finish without errors, but the final image is not to be found even though the logs say it is output
<whoiswho>
As I mentioned before, when supplying the kernel config manually via the menu script (as part of compile.sh) it at least generates the images properly.
<whoiswho>
But the issue I was having there was that it would not use my config settings regardless of what I did. So that's why I tried putting it in userpatches/linux-meson64-current.config
<whoiswho>
I should probably make a forum post for this instead but I thought I'd check with IRC if it was just some simple solution
<threenp>
sounds like a good idea. and i'd still suggest identifying a bunch of most recentl;y modified files and check thgriugh those for hints
<martinayotte>
sunshavi: Thanks ! CGarces also did a commit yesterday directly into jwrdegoede branch, I will check both today ...
<sunshavi>
martinayotte: Great. I did not know You were aware of that. I have the patch installed on mainline with opi+2e
<whoiswho>
threenp, so I did that now and it hasn't outputted the image file, that's for sure. Just linux-source-current...deb, linux-u-boot-current...deb and the armbian-config..deb, armbian-firmware..deb etc.
<whoiswho>
so either it fails outputting the image file or the script just plain lies, I guess ;-)
<threenp>
you should have a make log somewhere
<whoiswho>
ok.. you know where that would be perhaps?
<threenp>
no
<threenp>
hence suggesting you dig around to find it
<whoiswho>
I've just used tee to get the output from compile.sh but yep, I guess the make system should do a log internally
<threenp>
Sajunara [chat.freenode.net]: For me i need some delay between the rmmod and the modprobe for it to work reliably fyi
<whoiswho>
It seems likely that the make log is actually integrated into the output from compile.sh as I can see which files it's compiling (lines beginning with CC)
<whoiswho>
Anyways, I think I'll just have to make a post about this because there's several weird issues going on here. Thanks though
<threenp>
gl!
<Sajunara>
Good to know, thanks.
c0rnelius has left #armbian ["WeeChat 2.9"]
<martinayotte>
sunshavi: Which patch ? Do you mean the one from CGarces which is still in PR state ?
<sunshavi>
martinayotte: yes branch fix_511
rneese has joined #armbian
<rneese>
?
rneese has quit [Remote host closed the connection]
rneese has joined #armbian
<martinayotte>
sunshavi: Ok ! I'm currently adding a patch on normal branch so that Armbian build can benefit soon. I will test on my OPiPC+/OPiLite/OPiPlus2E
grae has joined #armbian
<martinayotte>
sunshavi: my OPiPC+ build succeeded ... :-)
rneese has quit [Remote host closed the connection]
rneese has joined #armbian
<sunshavi>
Awesome. :). Do You use them attached to a monitor?
<sunshavi>
martinayotte: ^^^
rneese has quit [Quit: Leaving]
<martinayotte>
No ! All my boards are headless ...
<sunshavi>
mine is plugged to a monitor. So I was affected as soon as I moved to 5.11
emanuele-f has quit [Quit: WeeChat 2.3]
<Tonymac32>
wow building with the merged desktop stuff is taking 4-evah
* Tonymac32
knows Martinayotte is too cool for graphical output
<IgorPec>
tonymac32: whaat?
<IgorPec>
i haven't notice any issues
<grae>
hey Tonymac32, you didn't happen to ID the source of that RK3399 I2S kernel spam, did you?
Sajunara has quit [Ping timeout: 240 seconds]
<Tonymac32>
sadly no, I haven't looked at it yet :/
<Tonymac32>
IgorPec it took 45 minutes on 6 threads, not terrible for a first run, I was just surprised to see it still crunching
<Tonymac32>
the kernel/u-boot were cached so that was all the packaging/desktop parts
<IgorPec>
ahaa, that can take awhile if not cached
<IgorPec>
we are caching only empty app and full app list for now
<IgorPec>
only on supported targets.
<IgorPec>
focal / buster
<grae>
no worries, I've been poking at it, and I haven't made any progress either
<grae>
however, I found out how to do internationalization in bash, so a multilingual armbian-config is possible. Might be nice for the non-native English speakers
<Tonymac32>
I'm learning some Git stuff, so hopefully I don't break my RK3399-dp branch. :/ on that note has anyone tested the Rockpi 4C using that branch? I built one for [TheBug] that doesn't work with DP but doesn't break anything else, I want to verify with tohers
<Tonymac32>
grae cool
<Tonymac32>
IgorPec I got the Tinker 2 booting with mainline atf/u-boot/kernel, still messy but I want to avoid any issues by introducing another Rockchip-based bootloader/blob situation
<Tonymac32>
<grumpy old man mode>
<Tonymac32>
That's the only way we should add any board at this point
<Tonymac32>
</grumpy old man mode>
<Tonymac32>
:)
<grae>
out of curiosity, are the rockchip binary blobs that different between boards, or is it more of a difference between SoC's?
rZZZr has joined #armbian
RzR has quit [Ping timeout: 272 seconds]
<Tonymac32>
it's the RAM that causes the issue
DaRock has quit [Ping timeout: 240 seconds]
<Tonymac32>
each SoC has it's own blobs, or mainline ATF
<Tonymac32>
but depending on the RAM type/banks/quality, different binaries need to be used
<Tonymac32>
which is just a $h!t show
<grae>
is it at least better than the uboot situation on the EspressoBin? reading the howto comments made me think someone might have wanted to hang themselves
<grae>
yeah, that seems like something that should just be in the DTB, and have uboot and the kernel do the right thing (TM)
<IgorPec>
haha
<IgorPec>
nobody can't beat espressobin :)
<Tonymac32>
:D
<Tonymac32>
OK, have to go fix a 10 year old van :P So much fun
<grae>
IgorPec, tempting fate seems a bad idea
e-i-k-e has quit [Ping timeout: 265 seconds]
Guest64086 has quit [Remote host closed the connection]
Guest64086 has joined #armbian
BCMM has joined #armbian
archetech_ has joined #armbian
<jschwart>
am I correct that it's not possible to create Jira tickets for regular users?
<grae>
unless you have a JIRA login, that's probably true. but you can create issues on guthub?
<grae>
*github
<IgorPec>
jschawart: we use jira for tracking development
archetech_ has quit [Quit: Konversation terminated!]
<jschwart>
yeah I can log on, but then I get that my account doesn't have access to the Armbian project
<jschwart>
which repo could I use to create a ticket on GitHub?
<IgorPec>
do you know who will work on the ticket?
whoiswho has quit [Quit: Connection closed]
<jschwart>
that's a good point, I wouldn't know for sure if it would get resolved
<jschwart>
in a way it's a RFE, but Tonymac32 recently expressed that he thought it had already been implemented (ability for Tinkerboard u-boot on eMMC to boot SD)
<jschwart>
I thought generally Armbian might have an issue tracker, but I don't want to polute anything either, if it's likely such things cannot be picked up
<IgorPec>
the problem with issue tracker is that it creates pressure
<IgorPec>
while we run extreme small resources
<jschwart>
yeah, that would not be good
<IgorPec>
allowing anyone to open ticketets could create more damage
<jschwart>
it would only make sense if it could be helpful to have collective discussions around issues, but maybe for those the forum could also be used
<jschwart>
is there any company that sells boards that provides good support to the project?
<IgorPec>
basically we sponsor them and not the other way around
<jschwart>
I think asus had better hire all of you over the people they actually have now
<IgorPec>
asus never gave us a cent
<stipa>
that's life
<jschwart>
it's noble what you guys are doing
<IgorPec>
but that's why we have to limit things
<IgorPec>
if you open a ticket, its almost entirely our private cash to solve it
<jschwart>
yeah or maybe people could contribute somehow, but it's a area that is quite challenging
<jschwart>
an*
<IgorPec>
"challening" is not the biggest problem
<jschwart>
companies are not even showing any interest to cooperate with the project?
BCMM has quit [Ping timeout: 240 seconds]
<IgorPec>
if people would cover general rubbish work and at least basic costs, that would change a lot
<IgorPec>
there are some companies that support us
<jschwart>
I'd be glad to buy an SBC off a group that also invests in Armbian support for their boards
<IgorPec>
covering R&D from that part is not possible
<IgorPec>
its way too little
<IgorPec>
HW sellers has their own game, costs and margings
<stipa>
you should make your own boards with money from kicstarter and that kind of stuff
<IgorPec>
why?
<stipa>
more income
<stipa>
and less bugs
<IgorPec>
why?
<IgorPec>
selling hw is not that simple
<IgorPec>
and is not something what we do
<jschwart>
yeah, it would make more sense to have an existing hardware seller compete on providing good software for their boards through strong Armbian support
<IgorPec>
we do that in some way
<IgorPec>
just that support is determined if we can do that in 1st place