<ndufresne>
someone in the family had that, but wasn't really using it, so it ended up in my desk
random_yanek has joined #linux-amlogic
<ndufresne>
chewitt, it is the exact definition of a random S912 ;-D
<chewitt>
they're all pretty homogenous these days .. the only things that normally vary from the reference design are the SDIO wifi/bt module and external PHY choices
vagrantc has quit [Quit: leaving]
<ndufresne>
so the external phy works, so I tihnk that one is settle, maybe I should disable wifi/bt and see if it get's further
<ndufresne>
chewitt, is there a trick to enter a shell in the librelec initrd ?
<chewitt>
add "textmode" to boot params and we don't attempt graphical boot and you'll end up on a console
<chewitt>
add "ssh" and it will force the daemon to start, otherwise it's not enabled by default and you have to enable in the GUI first-run wizard
<chewitt>
there's a systemd service called 'cpumac' in my branch/codebase which should set the MAC based on SoC serial so the MAC should be static
<chewitt>
else most of these devices change MAC on each boot, which is a PITA
<ndufresne>
ok, that gives me a fbcon shell
<ndufresne>
chewitt, yeah, notice the mac thing when trying to setup an nfs root
<ndufresne>
oof, my 4K screen is not exactly big, so that 4K fbcon is pretty small
<chewitt>
add video=HDMI-A-1:1920x1080@60 to boot params
<ndufresne>
good point, I got ssh running, so things are easier
<ndufresne>
now that quesiton is what makes it hang
<chewitt>
it would be best if someone came up with a patch/change/hack to set MAC via SoC serial directly in the Ethernet driver, but the current code only exposes serial for GXL/GXM
<chewitt>
older GXBB boards/devices don't expose it
<chewitt>
which is probably just some bug, but these days nobody is funding commercial work on GXBB so it's not on anyone's to-do list
<ndufresne>
and having random for gxbb and serial base for gxl/gxm isn't acceptable ?
<chewitt>
we have a reasonably large base of GXBB users
<ndufresne>
I see, gxbb is 32bit s80X ?
<chewitt>
and our userbase is full of n00bs so coding things to happen by magic results in fewer forum posts :)
<chewitt>
no, GXBB is 64-bit, original S905
<ndufresne>
ah, I see
<chewitt>
Odroid C2 is GXBB
<ndufresne>
ok, inspecting some logs now, kernel says "No soundcars .." so I guess audio isn't going to work
<ndufresne>
clearly usb works, since I'm using an usb keyboard
<ndufresne>
is this one meaningful ? "] kms: can't enable cloning when we probably wanted to."
<ndufresne>
connman, I had not seen that running since I worked on moblin ;-D
<chewitt>
first probing shows no soundcard but you should have 2.0 audio later on
<chewitt>
assuming the dts you're using has the right stuff included
<chewitt>
have a look at the linux-9999-* patches in my repo
<chewitt>
the conf that's embedded requires the sound card name to be changed
<chewitt>
(in dts)
<chewitt>
kms message can be ignored
<chewitt>
and connman works nicely for us
<ndufresne>
my guess is that I had couple of "working kernel" before, but as the terminal didn't go on the serial link, but on the display, I got confused
<ndufresne>
I wonder why it does not setup a console properly on ttyAML0
<ndufresne>
ah, /dev/ttyAML0 does not exist, maybe that's a hint
<ndufresne>
weird, why is there a ttyUSB0 ?
<ndufresne>
(nevermind, you know when you confuse terminals)
<chewitt>
if you're not seeing output on the UART cable (or only early stage boot then it stops) I suspect it's systemd starting and switching the output away
<ndufresne>
and the /dev/ttyAML0 is present, it showed traces during the boot
<ndufresne>
but it was not picked by systemd to become a terminal
<ndufresne>
and same seems to have append with my nfsroot
<ndufresne>
would be nice to figure-out why systemd-getty-generator does not pick it up
random_yanek has joined #linux-amlogic
<chewitt>
from fuzzy memory all we've done is forward-port the older 3.14 era service, so things probably need updating
return0e has quit [Remote host closed the connection]
<chewitt>
I normally go look for prior art from Arch Linux .. their documentation is usually reasonable
return0e has joined #linux-amlogic
<ndufresne>
really ? these box have an analog output ?
<ndufresne>
chewitt, yeah, I compares shell.service against the serial-console one, the first got few bits (mention in the error) that aren't in the second
<ndufresne>
so yeah, I'm pretty sure it's fixable
<chewitt>
most have composite video and analogue audio
<chewitt>
super low priority for development though .. I never tested either
<ndufresne>
so the "unable to clone" thing is probably related
<ndufresne>
I just notice through the expose connectors, and the fact there there is valid modes
<chewitt>
btw in LE /storage/.config/system.d allows you to create services ad-hoc
<chewitt>
disable the embedded .service and clone to that location to create a same-name replacement
<ndufresne>
I got an RCA to HDMI converter next to me, mayb i'll give it a try later
<ndufresne>
ah, I was wondering if I had to recreate the image, as it was in the cramfs
<chewitt>
depends on how fast the build machine is
<chewitt>
if using something speedy.. image rebuild is clean
<chewitt>
if needing to poke around and experiment .. local service is more flexible
<ndufresne>
that part I can alway solve, we assembled a Threadripper 2990wx recently at the office
<ndufresne>
but it's nice to test these things
<chewitt>
I have 2950X (TR2) here so I mostly just tweak/rebuild images
<ndufresne>
and I believe if you are using it as a desktop too, the 2950 is a better choice
<ndufresne>
should this one wanted by graphical target too ?
<chewitt>
mine is just a server .. I run a lot of VMs for work
<chewitt>
no idea on graphical target .. prob. not required for LE's use case
<ndufresne>
let's say I really like these TR2, specially for what you get per $
<ndufresne>
chewitt, should have said kodi.target on that OS
<chewitt>
I have a server box from quietpc.com .. best thing about it is, it's really (really) quiet
<chewitt>
kids have hamsters in the same room as the server, and even under full load the hamsters make more noise than the server
* ndufresne
whish there was alternative cases with cooling for the skullcanyon
<ndufresne>
nice
<ndufresne>
ok, sent you a PR (didn't know if it made sense for working branch, but it gets you the patch
<ndufresne>
good night
<chewitt>
thanks!
jakogut has quit [Remote host closed the connection]
jakogut_ has quit [Ping timeout: 245 seconds]
jakogut has joined #linux-amlogic
vagrantc has joined #linux-amlogic
chewitt has quit [Quit: Adios!]
Barada has joined #linux-amlogic
Barada has quit [Quit: Barada]
return0e_ has joined #linux-amlogic
return0e has quit [Ping timeout: 245 seconds]
afaerber has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
jakogut has quit [Remote host closed the connection]
jakogut has joined #linux-amlogic
default__ is now known as ldevulder
nsaenz has quit [Quit: Leaving]
nsaenz has joined #linux-amlogic
afaerber has quit [Ping timeout: 246 seconds]
JulienMasson has joined #linux-amlogic
ldevulder has quit [Quit: Leaving]
jakogut has quit [Ping timeout: 255 seconds]
sputnik_ has quit [Ping timeout: 245 seconds]
jakogut has joined #linux-amlogic
ldevulder has joined #linux-amlogic
ldevulder has quit [Ping timeout: 272 seconds]
ldevulder has joined #linux-amlogic
Darkmatter66 has joined #linux-amlogic
<Darkmatter66>
ndufresne, chewitt: better way to fix the serial-console service is ConditionPathExists=/dev/ttyAML0 in the Unit section of the service file
<Darkmatter66>
and also Requires=dev-ttyAML0.device
<Darkmatter66>
After=dev-ttyAML0.device
<Darkmatter66>
and if you need a wantedby target the right one would be sysinit
<Darkmatter66>
sysinit.target
<Darkmatter66>
this will ensure that the serial is setup early in the boot
JulienMasson has quit [Remote host closed the connection]
Darkmatter66 has quit [Ping timeout: 268 seconds]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 246 seconds]
Darkmatter66 has joined #linux-amlogic
<ndufresne>
Darkmatter66, sounds reasonable, I pretty much never hack these things, I just copied thing over from shell.service file
<ndufresne>
but this one is meant to be only in textmode.target
<Darkmatter66>
ndufresne, actually I don't know why LibreELEC is using a custom service file to enable the serial port, systemd already comes with a service for this
<Darkmatter66>
it's called serial-getty@.service
<ndufresne>
no idea, I'm new to this
<Darkmatter66>
hopefully chewitt can provide a reason
<ndufresne>
though you don't want to let systemd start a terminal on tty0, it would glitch the transition from splash to khodi
<ndufresne>
oh, and also if you look, these shell are root shell, no password, no login
<ndufresne>
it's base on the idea that if you have physical access to these box, it's fine, no need to security, it's running a cramfs after all
<Darkmatter66>
I'm not talking about tty0, serial-getty@.service takes an argument so just enable it as serial-getty@ttyAML0.service
<ndufresne>
ah I see, I saw that service file, maybe it's just not activated
<Darkmatter66>
ndufresne, autologin can be enabled for the getty generators, the right way would be to use an override file
<ndufresne>
as chewitt said yesterday, there is a lot of legacy being carried over for each release, and few people to clean it up
<ndufresne>
I was suspecting other issue, but later I'll try the libreELEC assembled kernel over my NFS setup, and see if Fedora will give a prompt on the serial
<ndufresne>
(that never worked with any of my kernels, and could not tell if it was a system hang, so terminal issues, same kernel worked on the S905X)
<Darkmatter66>
if you have ssh check if the /dev/ttyAML0 node is available if not maybe you don't have correct kernel cmdline
<ndufresne>
of course it's available
<ndufresne>
it's tracing to it, it stops when init is called
<Darkmatter66>
and still you don't have serial output
<ndufresne>
I have serial output
<Darkmatter66>
ohh, I thought that was your problem
<ndufresne>
but not after the init process is started
<ndufresne>
on my previous kernel, I didn't have some fixes, so DRM was not functional, so if the kernel output was moved to fbcon, that would explain why it looked like a system hang
<Darkmatter66>
so you only get the kernel messages and not systemd messages on the serial port
<ndufresne>
an example, the system was replying to ping, which normally does not work on most hangs
<ndufresne>
that's correct
<ndufresne>
with librelec message, with this hacky service fix, it works, so it proves it can work
<ndufresne>
s/message/image
<ndufresne>
might be confusing, but I'm in the process of booting mainline on my random TV box (but slowly, spare time)
<Darkmatter66>
well that's not very difficult, these tv boxes are mostly similar,they just use reference amlogic models with some changes, most of the time they only differ in the wifi chip
<Darkmatter66>
if you know the Soc on that tv box then it's just about finding the right dts file, most of the time the dts files in mainline will work
vagrantc has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 246 seconds]
Darkmatter66 has joined #linux-amlogic
<ndufresne>
Darkmatter66, I know, but the one I had didn't have the right u-boot for the selected ref-board, side effect I initially had no ethernet
<ndufresne>
and then vala 5.X don't boot, it crash at least on that board
<ndufresne>
Darkmatter66, chewitt assembled kernel is the first that actually boots, but for the LibreELEC part it does not work since the screen goes totally black as soon as khodi starts
<ndufresne>
need to try forcing lower resolution, would be 4k here
<ndufresne>
so I guess, yes, it wasn't very difficult, but it didn't exactly just worked
<Darkmatter66>
ndufresne, for the u-boot part I had the same issue on my board, mine had a u-boot with rgmii ethernet while my device is rmii so no ethernet either, I had to rebuild vendor u-boot and for mainline u-boot i had to add my board and submitted it as a patch for neil
<Darkmatter66>
ndufresne, before i had u-boot working I used to upload my kernel to the device by booting a well known working kernel (vendor kernel) and from their upload my kernel through scp and reboot to boot the new kernel using u-boot commands, I ended up writing a multi-boot system to test all my kernels and distros