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 feed: #armbian-rss | Off-Topic: #armbian-offtopic | Logs: -> irc.armbian.com
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #armbian
shoragan has quit [Quit: quit]
shoragan has joined #armbian
norwich_ has joined #armbian
norwich has quit [Ping timeout: 265 seconds]
norwich_ is now known as norwich
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #armbian
TheCoffeMaker has joined #armbian
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
TheCoffeMaker has joined #armbian
alekksander has joined #armbian
lyri has joined #armbian
alekksander has quit [Quit: Konversation terminated!]
archetech has quit [Quit: Konversation terminated!]
<yang2>
Hello, anyone with Radxa Rock 5 ?
<yang2>
I am trying to flash it
<yang2>
can I flash it without connecting the board to HDMI TV ?
<popolon>
I have both pd and classic power supply, but with v1.42 revision of the board, it looks like it is more stable with pd
<popolon>
it boot on armbian, shows the logo, and after a while shows a prompt with failure about launching OpenSSH server (I use last stable gnome version)
<popolon>
is there any login/pass to connect in by default ?
<popolon>
I see only some tips about an autoconnect and access to install scripts
<popolon>
which version have the most chance to work between CI version, rolling weekly and CI, as minimal else ?
junaid_ has quit [Ping timeout: 268 seconds]
<yang2>
hi popolon
<yang2>
what is a PD ?
<popolon>
power supply apple compatible (just an USB-C connector), like QC, Qualcomme compatible, (just an USB), but both have stronger power
<yang2>
popolon: today I have installed Bullseye CLI minimal image onto rock5B. I had to use an SD card and hooked it up on TV over HDMI, because it will drop you to the installation menu to create passwords and suers
<yang2>
suers/users
<popolon>
at least this is not the case in 1.42, I was able to boot and work with default Radxa images
<popolon>
thanks
<popolon>
i tried on eeprom
<yang2>
also you will need a computer keyboard (USB)
<Armbian-Discord>
<IgorPec> this looks like corrupted sd card
<popolon>
sure :)
<Armbian-Discord>
<IgorPec> if ssh server throws out errors it means it couldn't recreate keys
<Armbian-Discord>
<IgorPec> and that happens when a) 1st boot was interrupted b) media is broken
<popolon>
maybe I didn't use the good tool, I used the tool that Radxa say to use with eeprom, but as I use an sdcard adapter, I think just a dd or the armbian tool should work better in this case ?
<Armbian-Discord>
<IgorPec> i would suggest to follow armbian instructions
<popolon>
maybe 1st boot was interrupted, I didn't have any signal on screen at first boot
<Armbian-Discord>
<IgorPec> hw dealers world is different
<Armbian-Discord>
<IgorPec> then this explains it
<popolon>
ok, thanks
<popolon>
need to wait for long time at fist boot maybe ?
<Armbian-Discord>
<IgorPec> yes, a bit as it does filesystem expand
<Armbian-Discord>
<IgorPec> depends on speed and size of your media
<popolon>
128GB, looks fast, it boot in few seconds, on default image, didn't benchmarked speed
<yang2>
popolon: in my case it was quick, less than 3 minutes with a 32GB SD Card
<Armbian-Discord>
<IgorPec> default image is not much different in this regard, perhaps expansion is done manual, never used it
<popolon>
ok, will try again then, by trying step by step, the included FAQ don't say anything about eeprom, so I was not sure about the process
<Armbian-Discord>
<IgorPec> what has eeprom here to do?
<Armbian-Discord>
<IgorPec> you don't need to do anything
<popolon>
that's the first time I wrote in, I know on some device, there is specific tools to write in, a specific driver
<popolon>
need to flash it at least :)
<popolon>
so just dd the iamge ?
<Armbian-Discord>
<IgorPec> ah, Rockchip have some tools that it looks scientific
<popolon>
it will grow by uitself
<Armbian-Discord>
<IgorPec> aha. ok. dd is not right tool for flashing to sd cards
<popolon>
no, some drivers was needed not included on the kernel on an AllWinner board
alekksander has joined #armbian
<popolon>
so linux-sunxi community made specific tools
<popolon>
(as an example)
<popolon>
every kind of eeprom need a specific driver
<Armbian-Discord>
<IgorPec> brb / lunch time
<yang2>
IgorPec: bon apetite
<popolon>
when the driver is mature you can use it as any block device
<yang2>
popolon: if you really want to use dd, this is how I write it on sd card: dd bs=4M if=Armbian_22.11.2_Rock-5b_bullseye_legacy_5.10.110_minimal.img | pv | dd of=/dev/sdb
<popolon>
ah thanks didn't know pv command :)
<yang2>
be cautious of the last /dev/sdb it needs to match your SD card, could be something else, check with lsblk
<popolon>
but just a simple dd is good enough
<popolon>
sure :)
<popolon>
thanks
<yang2>
and use "sync" when it finishes
<popolon>
yes yes
<yang2>
:)
junaid_ has joined #armbian
<Armbian-Discord>
<IgorPec> popolon its about trust. you can't trust sd media
<Armbian-Discord>
<IgorPec> dd does not verify what sends to block device
<Armbian-Discord>
<IgorPec> its perhaps marginal problem today, but it still is present
maknho has quit [Quit: WeeChat 3.0]
maknho has joined #armbian
junaid_ has quit [Read error: Connection reset by peer]
junaid_ has joined #armbian
junaid_ has quit [Quit: leaving]
<popolon>
ok, the HDMI port used is the left one on minimal, not the right one as default image :) It seems than the default serial console isn't at speed 115200 I've garbages on it.
<popolon>
@IgorPec, this is not SD, but eeprom, here (as said), no problems with the eeprom, the default image that is wider verify the flashing.
<popolon>
and it boot correctly with minimal, i pressed entry on serial console so need to start again the whole procedure (missed root pass etc... breaked, but at least I have something that work
<Armbian-Discord>
<Tenkawa> @popolon the rock5 uses these settings:
<Armbian-Discord>
<Tenkawa> baudrate: 1500000
<Armbian-Discord>
<Tenkawa> data bit: 8
<Armbian-Discord>
<Tenkawa> stop bit: 1
<Armbian-Discord>
<Tenkawa> parity : none
<Armbian-Discord>
<Tenkawa> flow control: none
<Armbian-Discord>
<Tenkawa> not 115200
<Armbian-Discord>
<Tenkawa> thats why you got the garbage output
<popolon>
aah thanks !
<Armbian-Discord>
<Tenkawa> np
<popolon>
nice to see a default speed at modern capabilities, but unusual :)
<Armbian-Discord>
<Tenkawa> Yeah they use a really odd speed
<Armbian-Discord>
<Tenkawa> everything else is fairly standard except the baudrate
<popolon>
I see that.
<Armbian-Discord>
<Tenkawa> btw If you ever need more info:
<Armbian-Discord>
<Tenkawa> That's Radxa's official SoC docs
<popolon>
Thanks, didn't find the informtion probably didn't look at the good place
<Armbian-Discord>
<Tenkawa> np
<popolon>
aah this page is very convenient to found other information. I wondered what was the usage of the M.2 E-key port
<popolon>
nice to see it's possible to add a sata :)
<popolon>
my goal is to use this board as main workstation as soon as possible, and I'm happy to see that Linux mainlining of the RK3588 progress quickly.
<Armbian-Discord>
<Tenkawa> its not "progressing" that quickly
<Armbian-Discord>
<Tenkawa> don't be that optimistic
<Armbian-Discord>
<Tenkawa> What you have been seeing has a timeline of probably a year-two
<Armbian-Discord>
<Tenkawa> minimum
<Armbian-Discord>
<IgorPec> its 1+ year away for workstation usage, server will be before surely
<Armbian-Discord>
<Tenkawa> Exactly
archetech has joined #armbian
<popolon>
depend on what you do on your workstation maybe?
<popolon>
if it's browsing + ssh + some tools it already works fine
<popolon>
well maybe still not in mainlining
<Armbian-Discord>
<Tenkawa> popolon: it does nothing in mainline but boot to a serial console
<Armbian-Discord>
<Tenkawa> and missing effectively all hardware
lyri has quit [Ping timeout: 272 seconds]
<popolon>
not all, a great part, but not all
lyri has joined #armbian
<popolon>
several parts have already introduced in mainline
<yang2>
popolon: welcome to teh club of Rock 5 !
<Armbian-Discord>
<Tenkawa> popolon: many of those parts were "already there"... the parts that are needed for the 3588 aren't
<Armbian-Discord>
<Tenkawa> the 3588 is using "ancient" code
<Armbian-Discord>
<Tenkawa> So the individual pieces of hardware are all over the place... the SoC though... no
<Armbian-Discord>
<Tenkawa> I was worried the 3568 was going to turn out like this.. fortunately it didn't
<popolon>
@yang2, thanks :)
<Armbian-Discord>
<Tenkawa> I need to put my new drive in my 3568 speaking of 3568's heh
<popolon>
I follow at the same time the progress on AllWinner D1 (RISC-V) and Rockchip RK3588, as some older Rockchip and AllWinner devices, and in my point of view it goes far faster than at the time of this older devices
<Armbian-Discord>
<Tenkawa> of course... the RK boards have been in development years longer than Risc-V
<Armbian-Discord>
<Tenkawa> RISC-V is still very young
<Armbian-Discord>
<Tenkawa> arm/arm64 isn't
<Armbian-Discord>
<Tenkawa> I'm workig on Risc-V too btw... just waiting on my hardware... already been developing images and a builder
<popolon>
???
<popolon>
you mix subjects
<popolon>
I speak about drivers
<popolon>
not architecture
<Armbian-Discord>
<Tenkawa> Your sentence confused me then... my bad
<Armbian-Discord>
<Tenkawa> and which are you saying is faster?
<popolon>
If you speak about RISC-V on system, on D1, GPU is really missing for some applications, and JIT was generally missing a year ago
<popolon>
no problem
<popolon>
I say the drivers are faster done than few years ago on the AW/RK platforms but for sure there are more bases due to previous iterations
<Armbian-Discord>
<Tenkawa> Drivers are "not" the problem
<Armbian-Discord>
<Tenkawa> The "core" is
<popolon>
JIT used in Lua/JS and some other languages are central in some applications
<Armbian-Discord>
<Tenkawa> You can't just throw the kernel in there and go
<popolon>
you need drivers to initialise power etc.. sure
<Armbian-Discord>
<Tenkawa> The one in there right now is years old
<Armbian-Discord>
<Tenkawa> popolon: no... you need a core before that
<popolon>
what do call a "core" here
<Armbian-Discord>
<Tenkawa> and that's the part that like Igor said.. the kernel core is at least 1-2 years away
<popolon>
what do call a "core" here?
<Armbian-Discord>
<Tenkawa> The core is the "cpu/ram/io"
<Armbian-Discord>
<Tenkawa> the minimum just to run the machine
<popolon>
aah, the controlers drivers so
<Armbian-Discord>
<Tenkawa> it will not run on its own other than to be a dumb terminal
<popolon>
if you run a terminal, you already have cpu ram io
<Armbian-Discord>
<Tenkawa> If you think you can mainline Android drivers from 5 years ago.. go for it
<popolon>
android is a specific case
<Armbian-Discord>
<Tenkawa> thats what its currently runninng
<Armbian-Discord>
<Tenkawa> its running converted Android code
<popolon>
this is a strongly modified kernel, the driver are often closed sources on a fixed old kernel :(
<Armbian-Discord>
<Tenkawa> Exactly... thats my point
junaid_ has joined #armbian
<Armbian-Discord>
<Tenkawa> this is not just a "update it to mainline"
<popolon>
I don't think that blobed version use android drivers, it would not work like this
<Armbian-Discord>
<Tenkawa> heheh....
<popolon>
this is an older problem than android
<Armbian-Discord>
<Tenkawa> Its ancient
<Armbian-Discord>
<Tenkawa> (90% of this boards problem)
<Armbian-Discord>
<Tenkawa> they used an ancient Android kernel then converted it...
<Armbian-Discord>
<Tenkawa> just a mess
<popolon>
D1 risc-V already work on (opensource) patched mainline
<Armbian-Discord>
<Tenkawa> yeah.. what I'm liking about risc-v
<popolon>
Witch RISC-V hardware did you wait for ?
<Armbian-Discord>
<Tenkawa> I really want my v2 board to get here
<Armbian-Discord>
<Tenkawa> vf2
<popolon>
don't hope too much from it
<Armbian-Discord>
<Tenkawa> why not?
<popolon>
no documentation, and they don't want to give any
<Armbian-Discord>
<Tenkawa> I don't use docs anyway
<popolon>
there will be a huge reverse engeenering work
<Armbian-Discord>
<Tenkawa> Didn't have any on the Rock5
<Armbian-Discord>
<Tenkawa> or most of the RPI's I worked on
<popolon>
and performances are very low compared to THead based board
<Armbian-Discord>
<Tenkawa> How do you know? The board isn't even out yet
<popolon>
they are :)
<popolon>
and follow the previous generation
<Armbian-Discord>
<Tenkawa> I've heard that from plenty of "devs" who didn
<popolon>
the perfs of SiFive Cpu are less good than THead one, and THead ones are open source at least :)
<popolon>
I know some people having VF2
<popolon>
the benchmark was already less good on vf1 vs D1
<Armbian-Discord>
<Tenkawa> I might be getting a D1 as well.. not sure yet.. waiting to see if its being sent
<popolon>
I have 2 since one year
<popolon>
but it is not interesting today, but to do a small server
<Armbian-Discord>
<Tenkawa> I use all of my SoCs as headless servers
<popolon>
Missing GPU is a real problem for desktop
<popolon>
ok, in this case it's fine
<popolon>
but limited
<popolon>
the new THead processor (that wuold be available next month) will be something between RK3399 and RK3588 in term of performances
<popolon>
I found interesting they added a RISC-V (CPU grade) corze (C906, the same that used in D1)+a DSP just for audio
califax has quit [Remote host closed the connection]
califax has joined #armbian
oida has joined #armbian
archetech has quit [Quit: Konversation terminated!]
<Sabotender>
It's been about a week that I've been using this driver, and it is still going strong without any problems, please let me know when it has been integrated within the distro. also, please include tethering libs for i phone and whatnot to make things more simple for those who do not have access to an Ethernet cable or other means of internet access.
<Sabotender>
it's such a good driver that supports AP mode, but some nights I wake up nervous that it would be suddenly gone, so I check my mobile that it is still broadcasting. yes. that's how much stress this situation had caused me.
<Armbian-Discord>
<Tonymac32> more Imagination Tech garbage for GPU
<Armbian-Discord>
<Tonymac32> they were very careful to not mention PowerVR 😄
<Armbian-Discord>
<Tonymac32> @IgorPec I added Jira tickets like a good boy, rockchip64 patchsets need completely refactored for about 2/3 of the supported boards
<Armbian-Discord>
<IgorPec> ok
<Armbian-Discord>
<Tonymac32> mainline caught up to our experiments and now we're the ones doing weird stuff
<Armbian-Discord>
<Tonymac32> most of our "add board" patches are blowing away the mainline DTS's and starting over 😄
<Armbian-Discord>
<IgorPec> Manjaro is stealing our patches
<Armbian-Discord>
<IgorPec> sending them upstream under their names
<Armbian-Discord>
<Tonymac32> hmmm, I didn't see evidence of that in this case, there is significant difference between what we have and what mainline did
<Armbian-Discord>
<Tonymac32> but I'm sure I could find it if I looked harder
<Armbian-Discord>
<IgorPec> would need to check, surely, but i woudn't be surprised
<Armbian-Discord>
<Tonymac32> I haven't taken the time to try to set up anything to submit to mainline because honestly it seems less than friendly and more than a little political
<Armbian-Discord>
<IgorPec> exactly
<Armbian-Discord>
<Tonymac32> I should probably bite the bullet
<Armbian-Discord>
<Tonymac32> and go for it
archetech has joined #armbian
<stipa>
go, waste some time
<stipa>
i would say the mainline team is more concerned with the paid projects
<Armbian-Discord>
<IgorPec> there is not such things as mainline team. yeah, more like a politics
<stipa>
expecting from someone something you alone don't do is not realistic
<Armbian-Discord>
<IgorPec> most of things which are getting there were already done
<stipa>
honestly mainlining boards shouldn't in any way be armbians responsibility but manufacturers
<stipa>
they have money to push stuff further
<Armbian-Discord>
<IgorPec> well, things are not that way
<stipa>
well they should be ASAP
<Armbian-Discord>
<IgorPec> its a dirty game behind
<Armbian-Discord>
<IgorPec> they also can't just throw case, as they would support comptetirorys
<Armbian-Discord>
<IgorPec> so the answer is far from simple
<Armbian-Discord>
<IgorPec> but in case of manjaro it is simple - they want to advance on others work
<Armbian-Discord>
<IgorPec> and they do everything they can to look good
<Armbian-Discord>
<rpardini> spent the weekend in rk's 3588 5.10 half-android shit, and can say rk does it badly but vendors do #if 0 and fuck it.
<Armbian-Discord>
<Tonymac32> they are $35 each
<popolon>
PCI, MMC, PinCtrl, I2S/TDM, gpio, serial for RK3588 was already on mainline, CLocks/reset (and CRu), PLL, have been merged on Linux mainline and all of this should be available in 6.2. As on previous RockChip SoC, they worked actively on mainline Linux. itself (here Elaine Zhang). Also audio support has been merged in november
<Armbian-Discord>
<rpardini> it's terrible on top of horrible
<stipa>
Tonymac32 oh right, 4 of them
<Armbian-Discord>
<Tenkawa> @rpardini it is a pita hacked up kernel
<Armbian-Discord>
<Tenkawa> oh.. thats its good points
<Armbian-Discord>
<Tenkawa> lol
<Armbian-Discord>
<Tonymac32> popolon to hit 80% support is not difficult, RK3399 was there for several years
<Armbian-Discord>
<Tonymac32> you have to be 95% to be usable
<Armbian-Discord>
<rpardini> I hammered Khadas and Xunlongs on top of Radxa's. That was a lot of alcohol
<Armbian-Discord>
<Tonymac32> the rockchip RK3328 is still a mess in reality
<Armbian-Discord>
<Tenkawa> @rpardini after throwing a lot of mainline patches at it.. I did catch it up to the most recent 5.10
<Armbian-Discord>
<Tenkawa> and it runs decent
<Armbian-Discord>
<Tenkawa> I would "hate" to see how painful 6.x is going to be
<Armbian-Discord>
<rpardini> @Tenkawa did you work from radxa's 5.10.110 or the .66?
<Armbian-Discord>
<Tenkawa> @rpardini started with radxa's 5.10.110
<Armbian-Discord>
<Tenkawa> the 66 was impossible
alekksander has quit [Ping timeout: 252 seconds]
<Armbian-Discord>
<rpardini> Xunlong's is rk shit base plus DTS plus a few driver hacks on .110
<Armbian-Discord>
<rpardini> Khadas wasted their damn time with their mcu drivers etc on .66
<popolon>
@tonymac32, I used rk3328 during years, at work everydays without problems
<popolon>
(on mainline)
<popolon>
that was about 5 years ago, what problems did you encounter with him?
<Armbian-Discord>
<Tonymac32> mainline RK3328 does not have official GPU, GPU opps, memory controller, etc etc etc etc
<Armbian-Discord>
<Tonymac32> you have to add all of that
<popolon>
What ???
<popolon>
this was already in mainline at this time, lol
<popolon>
That was one of the huge work of Alyssa to port RK3288 GPU in mesa
<popolon>
the GPU problem was not rockchip but mali that didn't open its driver
<Armbian-Discord>
<Tonymac32> 3288 is the A17 one, it is almost perfect
<popolon>
RK collaborate with Linux for years
<Armbian-Discord>
<Tonymac32> 3328 is the A53 one
<popolon>
and is 100% mainlined for it's own aprts
<Armbian-Discord>
<Tonymac32> I have Tinker Board and MiQi, both RK3288. Best support I've ever seen for Rockchip
<popolon>
ahh sorry I misread, didn't look at this one
<Armbian-Discord>
<Tonymac32> RK3328 isn't even close
<popolon>
I suppose there are less people using low end, or they are mode dedicated to crap android box
<popolon>
(I mean the ULP versions
<Armbian-Discord>
<Tonymac32> right, anything that is associates with Google has requirements
<Armbian-Discord>
<Tonymac32> the RK3328 is not
<popolon>
the more powerfull version are already ultralow power
<Armbian-Discord>
<Tonymac32> so a chromebook processor will always be better supported
<popolon>
that's true, I used it on a chromebook (whithout chromeOS)
<popolon>
100% mainlined so
<Armbian-Discord>
<Tonymac32> I have one I keep meaning to stick Armbian on, but I don't really use laptops so it sits
<Armbian-Discord>
<Tonymac32> their bootloader is just... ugh
<popolon>
mine is dead, can't start anymore :( Need to found someone to repair it, I think Asus will not care of it
<popolon>
coreboot :)
<popolon>
at least there is no this fuckin UEFI
<popolon>
and horrible blob BIOS
<Armbian-Discord>
<ManoftheSea> what's wrong with uefi?
<Armbian-Discord>
<Tonymac32> I prefer EFI, personally
<Armbian-Discord>
<ManoftheSea> u-boot dts is worse than kernel, because they have two per board
<Armbian-Discord>
<Tonymac32> sigh because they intend for the kernel dts to match the u-boot dts, and any special u-boot parts go in their own
<Armbian-Discord>
<ManoftheSea> uboot does?
<Armbian-Discord>
<Tonymac32> so you have the -u-boot.dts to hide whatever they need
<Armbian-Discord>
<ManoftheSea> yeah, that's what I was seeing for helios64, anyway
<Armbian-Discord>
<ManoftheSea> It's not true for all boards, though.
<Armbian-Discord>
<Tonymac32> yeah. In theory the "main dts between u-boot and kernel should be the same
<Armbian-Discord>
<Tonymac32> the vendor has to keep up 😄
<Armbian-Discord>
<ManoftheSea> What's the theory on having "u-boot specific bits"?
<popolon>
UEFI is just a broken things made by some people loving binaries blobs
<Armbian-Discord>
<Tonymac32> early config of devices/etc. anything the kernel isn't aware of that u-boot handles
<popolon>
DTS give you all specs, and you can reuse them
<Armbian-Discord>
<ManoftheSea> that doesn't make any sense
<Armbian-Discord>
<ManoftheSea> aren't those drivers for defined devices, though?
<Armbian-Discord>
<Tonymac32> not always. let me find an example
<popolon>
some work on using the kernel for everything
<popolon>
so you unify definitions to one place
<popolon>
the problem is that you need to activate some parts before loading the kernel
<popolon>
but this allow to use the same boot on other kernels than linux, that is a good point too
<Armbian-Discord>
<Tonymac32> so you can see in here the smbios stuff, and anything going into the spl
<Armbian-Discord>
<Tonymac32> and the RAM config
<Armbian-Discord>
<Tonymac32> since mainline knows nothing of that at all
<Armbian-Discord>
<Tonymac32> and it's the bootloaders job to init all that stuff with the ATF's help
<popolon>
that's not that
<Armbian-Discord>
<ManoftheSea> Sure, but they still ought to be in the same tree, because it's supposed to describe the hardware.
<popolon>
that's uboot need to initialise ram/disk/network to load the kernel and USB so you can type in when you are on console
<Armbian-Discord>
<ManoftheSea> If Linux doesn't have a role in initializing some described bit, it just doesn't, but that's no reason not to include it
<popolon>
after starting the kernel, the kernel itself manage all of this
<Armbian-Discord>
<ManoftheSea> popolon, can you explain what you mean about UEFI and binary blobs?
<popolon>
UEFI is mainly used with BIOS and was done to continue to use it
<popolon>
it is an useless layer
<Armbian-Discord>
<ManoftheSea> UEFI is explicitly NOT BIOS
<popolon>
dt have all necessary things
<popolon>
sure
<Armbian-Discord>
<ManoftheSea> It is an interface to platform firmware
<popolon>
it is just broken designed by the same people
<popolon>
yes firmware like bios and it's blob
<Armbian-Discord>
<ManoftheSea> I mean, I know it tends to look like DOS 5.0
<popolon>
(s)
<popolon>
blobs
<Armbian-Discord>
<ManoftheSea> But u-boot's implementation of UEFI interfaces aren't "binary blobs", they're open source code. Itanocore is opensource code
<popolon>
sure
alekksander has joined #armbian
<popolon>
uboot is open source
<popolon>
they implemented UEFI just because everyone want UEFI
<Armbian-Discord>
<ManoftheSea> Sure, Linux shouldn't do anything with this since it's already configured by the time the kernel starts, but nothing should be hurt by linux knowing about it, either
<popolon>
and everyone want UEFI just because BIOs industry push it
<popolon>
there is no advantage beside DTS
<Armbian-Discord>
<ManoftheSea> dts is orthogonal to UEFI
<Armbian-Discord>
<Tonymac32> you'll never get a dt node without a driver/documentation included in a device tree
<Armbian-Discord>
<ManoftheSea> you can have dts with or without UEFI
<Armbian-Discord>
<ManoftheSea> In the linux repo of dts, you mean?
<popolon>
sure
<Armbian-Discord>
<Tonymac32> an EFI image is hardware agnostic to a large extent. I can boot the same Armbian EFI image on a Le Potato and a Phytium D2000
<Armbian-Discord>
<ManoftheSea> And because the linux repo is "the canonical repo", thus does u-boot need to overlay their own stuff?
<Armbian-Discord>
<Tonymac32> the Phyium doesn't even have a device tree in mainline
<popolon>
but if all your drivers a free, documented and well referenced in dt, you don't need UEFI
<Armbian-Discord>
<ManoftheSea> What does it mean to reference a driver in DT? I thought dt just said what the hardware was, and it was the driver's job to say what it works with
<Armbian-Discord>
<Tonymac32> it is a description of the hardware
<Armbian-Discord>
<ManoftheSea> Like, the driver claims the dt node, not the other way around
<Armbian-Discord>
<Tonymac32> but that description is dependent on what the drivers need to function
<popolon>
sure, I write it wrongly
<Armbian-Discord>
<Tonymac32> the DT node content has to be defined somewhere
<Armbian-Discord>
<Tonymac32> and to define it, you need to know what the parameters the driver needs
<Armbian-Discord>
<ManoftheSea> Shouldn't that be in the EE papers of the chip?
<Armbian-Discord>
<Tonymac32> so all threee need comitted at the same time, the driver, the dt documentation, and the dt bindings
<Armbian-Discord>
<ManoftheSea> Like, if the dt node says there's a w25qt256 SPI-NOR, the whitepaper of the chip has the parameters that the driver needs
<Armbian-Discord>
<Tonymac32> that's nothing compared to a ram controller
<Armbian-Discord>
<Tonymac32> and the names need to be correct for everything
<Armbian-Discord>
<ManoftheSea> Sure, so the hardware bill of materials gets represented in the dt, along with the electrical engineering of how it all hooks together on the board
<Armbian-Discord>
<ManoftheSea> Well yeah, we already know rockchip is hot shit
<Armbian-Discord>
<Tonymac32> so it lives in u-boot
<Armbian-Discord>
<ManoftheSea> But this is evidence of failing to do a good job , not something that should be accepted
<Armbian-Discord>
<Tonymac32> with its own special entry
<Armbian-Discord>
<Tonymac32> reality doesn't bend to our will I'm afraid
<Armbian-Discord>
<Tonymac32> Or rockchip64 patch folder wouldn't look like it does
<popolon>
how will you boot without initialising the peripherals
<Armbian-Discord>
<Tonymac32> 😄
<Armbian-Discord>
<ManoftheSea> I'm not suggesting we don't initialize them.
<popolon>
how will you load kernel without accessing first to ram, power, processor and source of the kernel
<Armbian-Discord>
<ManoftheSea> I'm suggesting the SoC maker and the board vendor be competent.
<popolon>
do you prefer to delegate it to a closed source bios ?
<Armbian-Discord>
<ManoftheSea> A DT that's just a table of numbers is trash.
<popolon>
that take some times several minutes to boot
<Armbian-Discord>
<ManoftheSea> This comes out of right field. What does that have to do with anything
<Armbian-Discord>
<ManoftheSea> It is closed-source if all the DT is is a table of numbers
<popolon>
not in trash, that's a perfect description of all the specs of peripherals
<Armbian-Discord>
<Tonymac32> in this case the driver pulls that into a struct, you can figure out what it is
<popolon>
and with this you can easily port a driver from an os to another one
<Armbian-Discord>
<Tonymac32> a question is whether or not it's worth all the headache to break out each line delay/phase variable
lemonzest has quit [Quit: WeeChat 3.6]
<Armbian-Discord>
<Tonymac32> and put it in the device tree
<popolon>
it's better to have it in DTS, that describe every part, that include all of this in code line
<Armbian-Discord>
<ManoftheSea> That should be documented in the hardware documentation.
<Armbian-Discord>
<Tonymac32> for Soc Vendors that aren't NXP, the vendor kernel is the SoC documentation 😄
<popolon>
so you don't have to touch your code to add for example twice a device on a board, you can just references the two devices inside your board definittion
<Armbian-Discord>
<ManoftheSea> well, I'm glad to hear someone does it well.
<Armbian-Discord>
<ManoftheSea> But also, marvell's no good?
<Armbian-Discord>
<Tonymac32> no idea honestly
<popolon>
Rockchip give documentation about their SoCs, they are available on GIthub
<Armbian-Discord>
<Tonymac32> I've never looked at theirs
<popolon>
all timings, registers, address etc are well referenced
<Armbian-Discord>
<ManoftheSea> x to doubt
<Armbian-Discord>
<Tonymac32> Oh? They keep the TRM part 2 secret
<Armbian-Discord>
<Tonymac32> where is the github for this?
<Armbian-Discord>
<ManoftheSea> well, go back a second. You said uboot needs to know e.g. dram timing. But isn't that done by TF-A?
<Armbian-Discord>
<ManoftheSea> (or the vendor's closed-source blob version of BL1, BL2)
<archetech>
rpardini did you get a better result than whats current on 5.10.110 for all that work
<popolon>
the question is about which Ip they use, as ARM doesn't open their doc, as they use the ARM Mali GPU, they can't give all details about it
<Armbian-Discord>
<Tonymac32> There could be flowcharts the size of a wall to show all the possible routes the hardware conf takes 😄
<popolon>
ARM NDA, not rockchip itself
<Armbian-Discord>
<ManoftheSea> all things are easy when I don't know jack
<popolon>
that's at least a step in advance to some SoC that don't give anything...
<popolon>
* SoC vendors
<popolon>
@tonymac32, don't know precisely about which SoC TRM part 2 you want
<Armbian-Discord>
<Tonymac32> that's not a rockchip repo. I can "find" their docs in a few dusty corners of the web, but they are not distributing them freely
<Armbian-Discord>
<Tonymac32> I have that page bookmarked 😄
<Armbian-Discord>
<Tonymac32> datasheet and TRM part 1
<Armbian-Discord>
<Tonymac32> layout guide
<Armbian-Discord>
<Tonymac32> Before we go off into the woods any further, I have a lot of rockchip parts
<Armbian-Discord>
<Tonymac32> I know how they distribute their documents, I know how they look like
<Armbian-Discord>
<Tonymac32> They are not the worst by any means
<Armbian-Discord>
<Tonymac32> but they are not "good"
<popolon>
nobody is good or bad, there are just some levels of goodness and badness depending on topics
<popolon>
:)
<Armbian-Discord>
<Tonymac32> I'm not misdirecting into flawed philosophy either 😄
<Armbian-Discord>
<Tonymac32> They need to make the TRM part 2 publicly available as a first step
<Armbian-Discord>
<Tonymac32> that would be helpful
<popolon>
at least they work by themselve on mainlining, following Linux (and Linus) standards (but their is no choice ^^)
<Armbian-Discord>
<Tonymac32> and I can't imagine what issues they have sharing it
<Armbian-Discord>
<Tonymac32> haha yeah, if they want to have their parts in big name products they have to
<Armbian-Discord>
<Tonymac32> They really really need to scrap their in-house kernel and start over though, it's become unmanageable
<popolon>
kit if "big products" have closed source and buggy things that will never be debugged sadly :(
<Armbian-Discord>
<ManoftheSea> what?
<Armbian-Discord>
<ManoftheSea> oh, you're saying rockchip is attempting to get their drivers in mainline linux?
<Armbian-Discord>
<ManoftheSea> that's great
<Armbian-Discord>
<IgorPec> sounds too good to be true 😉
<Armbian-Discord>
<Tonymac32> they do, I watch the mailing list, but it's not usually complete, it's a "minimal support level" I'd call it
<Armbian-Discord>
<Tonymac32> with RK3288 and RK3399 being exceptions
<popolon>
they do that since several years (at least 3288, but that was before)
<Armbian-Discord>
<Tonymac32> I would hope to see better moving forward, their internal workload on that travesty of a kernel has to be extreme
<Armbian-Discord>
<IgorPec> aha, you mean they stick to this schema - rockchip opensource
<Armbian-Discord>
<IgorPec> 3288 was google deal around chromebooks
<Armbian-Discord>
<IgorPec> iirc
<popolon>
I would say instead they are not alone to work on the integration of their SoC, they are helped by people with more knowledge of the internal of the kernel.
<popolon>
I look at this one but there is work for ther too
<popolon>
mainlining of drivers is a long effort, with proposition, and kernel main devs asking some changes
<Armbian-Discord>
<Tenkawa> I was just looking at the Rockchip opensource list and they are far away from integrating anything new or recent into mainline that isn't already there
<Armbian-Discord>
<Tenkawa> There's not even reference to some of the chipsets yet
<popolon>
This is a main from Collabora. I think Collabora is paid by some companies to help to integrate their drivers: https://lwn.net/Articles/894045/
<Armbian-Discord>
<Tenkawa> That is from May and it went nowhere
<popolon>
Alyssia Rosenzweig that made most of the work on Mali Panfrost driver was hired by Collabora after about 1 year of work on this driver.
<popolon>
tenkawa: ahah that's your point of view
<popolon>
look at the previous link
<popolon>
all integration start like this
<popolon>
some huge patch that is answered by some needed improvments
<Armbian-Discord>
<Tenkawa> popolan: learn how to read:
<c0rnelius>
popolon: I don't have a board with that SoC. Only people with no real interest in making those boards work were given them or could afford them. For the most part... But I do keep an out as I imagine I will eventually get one. ;)
<Armbian-Discord>
<IgorPec> we also manage to move our patchset to 6.1, first test build of everything
<Armbian-Discord>
<rpardini> JetHub ok with 6.1 Igor?
<Armbian-Discord>
<IgorPec> on edge?
<Armbian-Discord>
<IgorPec> well, this is nightly build, so i don't think its a problem
<Armbian-Discord>
<rpardini> just wondering, the rest of meson64 I've tested myself or have good feedback from the good folks here
<Armbian-Discord>
<rpardini> 6.1
<Armbian-Discord>
<IgorPec> in my test farm, "Khadas VIM1" failed
<Armbian-Discord>
<IgorPec> but it could also be something else
<Armbian-Discord>
<rpardini> that I did not test indeed.
<Armbian-Discord>
<IgorPec> i don't know what's the problem as i don't have console there
<Armbian-Discord>
<rpardini> nothing changed for sure, and other similars work, so might be a fluke
<Armbian-Discord>
<rpardini> vim1 is blob uboot from Khadas
<Armbian-Discord>
<IgorPec> yeah, it could also be broken before ... logging is terrible
<Armbian-Discord>
<IgorPec> so its difficult to resolve
<Armbian-Discord>
<IgorPec> all other amlogic devices had no problems
<Armbian-Discord>
<rpardini> I had confirmed VIM1 working with 5.19 when we reworked patchset, 6.0 and 6.1 were just mostly fast-forwards
<Armbian-Discord>
<IgorPec> only rockchip and allwiner devices failed 😉
<Armbian-Discord>
<IgorPec> some
<popolon>
I don't have HDMI output with current armbian
<popolon>
tried on 2 ports
<archetech>
c0rnelius: ill try it but would need all patches up to around say...today
<Armbian-Discord>
<IgorPec> popolon: which hw?
<popolon>
Rock 5 Model B
<popolon>
everything works well but HDMI output
<Armbian-Discord>
<IgorPec> aha, hmm. well, yesterday worked
<popolon>
I can log in console & ssh
<popolon>
lightdm runs
<popolon>
verified by reflashing the image from Radxa, HDMI still work :)
<popolon>
but, here nothing
<popolon>
does the kernel used can display on both HDMI 1 and 2 ?
<popolon>
as I seen the Armbian logo one time (on left HDMI) where the Radxa Debian image use HDMI 2
<popolon>
sorry the right HDMI port
<Armbian-Discord>
<IgorPec> it depends on desktop i guess, i got working gnome, someone reported xfce does not work
<Armbian-Discord>
<IgorPec> dunno
<popolon>
but I don't even have console nord lightdm
<Armbian-Discord>
<IgorPec> and if you add panfork drivers ... mess just gets bigger
<popolon>
so not a desktop problem
<popolon>
what is bigger mess than absolutely nothing ? ^^
<Armbian-Discord>
<IgorPec> heh
<Armbian-Discord>
<IgorPec> i mean for most people it works
<popolon>
need to figure out what's wrong
<popolon>
then
<Armbian-Discord>
<IgorPec> no idea
<popolon>
I seen a video where WebGL worked with Mesa drivers on ARMbian
<Armbian-Discord>
<IgorPec> yes, i also tried
<popolon>
the author only shown one chromium demo with aquarium
<Armbian-Discord>
<IgorPec> thats kind of standard test, those fishes
<popolon>
yes
<popolon>
but I didn't even have that with radxa image :)
<popolon>
worst after updating debian package, X didn't work anymore, I had to change parameters in X.org conf, and then everything was using LLVMpipe ^^
<popolon>
firefox was still usable, was able to play 1080p videos on youtube (with some 60° SoC without the heatsink