<jo0nas>
avernos: Debian developer here - what more specifically did you try which failed?
<jo0nas>
I mean, which board do you have, and which Debian build of u-boot did you try?
nuuuciano_ has joined #linux-sunxi
<avernos>
jo0nas, tried all the stable options, perhaps should try the daily ones as well. but i see several broken links to older builds which i couldnt find. tried setting bootm_boot_mode to "sec". tried ISO on usb, uboot on usb. all attempts on netinstall
<avernos>
uboot loads just fine, just any attempt to boot, gets stuck on kernel loading
<fALSO>
dts ?
<avernos>
i've tried several ways to disable hdmi (fb?) and vga, setenv bootargs fb=false stderr=serial stdout=serial to disable vga
<avernos>
diego71, with firmware and partition on SD alone and the installer boots?
<avernos>
without serial?
<jo0nas>
avernos: sorry if I missed it - which board do you have?
<avernos>
cubieboard1
<diego71>
it boots, but usually you need a serial
<avernos>
diego71, im using mostly serial, want it headless, but im concerned hdmi is enabled somewhere else.. or that one with other conflicts
<diego71>
the serial console is indipendent from hdmi
<diego71>
you can try to add this to the kernel parameter for debug: setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p<partition> rootwait panic=10
<jo0nas>
avernos: with "stock on kernel loading" do you mean u-boot refuses to load the kernel you feed it, or failure at initramfs stage, or somewhere later?
<avernos>
diego71, you add fw and partition to SD and the netinstaller just boots?
<jo0nas>
avernos: is it that specific part of the wiki page you followed, or some other part?
<avernos>
jo0nas, say we stick to that part, followed it exactly as is. it just gets stuck on that kernel loading
fevv8[m] has joined #linux-sunxi
davidebeatrici has joined #linux-sunxi
freddor has joined #linux-sunxi
MartijnBraam has joined #linux-sunxi
Guest92818 has joined #linux-sunxi
romainmahoux[m] has joined #linux-sunxi
z3ntu has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
oliv3r[m] has joined #linux-sunxi
thefloweringash1 has joined #linux-sunxi
EmilKarlson has joined #linux-sunxi
Jeremy_Rand_Talo has joined #linux-sunxi
t4h4[m] has joined #linux-sunxi
<avernos>
jo0nas, tried that one the most. but have attempted USB, same results. and tftp but didnt follow through most since looks like the problem will be same at loading kernel
<jo0nas>
did you try set console to tty1 and attach a monitor?
<avernos>
installing from SD, gets me the newer uboot, which is very nice has more options. would like to write it to nand and update current one as well.
<diego71>
avernos: try to add the console and earlyprintk parameter to the kernel. It should give you more information
<jo0nas>
and since you mentioned daily images: you should *not* need to use a daily image - the notes about that in this wiki section are old and reference a bug that has since been fixed (the link to the bug is stroken out)
<avernos>
jo0nas, didnt. would that affect the kernel. thought monitor would probably complicate load process more and wont change kernel loading
<avernos>
diego71, thanks! a bit more verbose would jelp
<avernos>
help*
<jo0nas>
yes, setting console in u-boot affects what kernel cmdline u-boot computes and passes to linux
<avernos>
alirght, going to a try then
YannSoubeyrand[m has joined #linux-sunxi
mic-e[m] has joined #linux-sunxi
tilpner_ has joined #linux-sunxi
<jo0nas>
possibly what you experience when not passing any options is that linux runs serial interface at a different speed
clementp[m] has joined #linux-sunxi
thefloweringash is now known as thefloweringash_
tilpner has quit [Remote host closed the connection]
<avernos>
jo0nas, serial baudrate is on uboot by default, sould be passed to kernel, right? at any rate, tried as well to run it with hdmi in case serial messed up with same results.
<jo0nas>
...so if it works sending output to monitor by setting tty1, you might try setting it to ttyS0,115200 to see if that helps catch kernel output on serial line
afaerber has joined #linux-sunxi
<KotCzarny>
jo0nas, you dont use any leds to signal boot stages?
<jo0nas>
KotCzarny: not sure what you mean
<KotCzarny>
ie. i personally light up some led pattern in boot, then in kernel, then in rc.local
<KotCzarny>
makes it easier to pinpoint what failed even before grabbing serial console
<jo0nas>
avernos: possibly u-boot default serial port settings and linux default serial port settings are not equal
<jo0nas>
KotCzarny: that sounds cool - care to point me to how that is doable?
<KotCzarny>
usually requires leds defined in dts, but often they are
<KotCzarny>
then its just toggling gpios in uboot, and setting led trigger in dts
<jo0nas>
I am new to messing with u-boot details like GPIOs and leds, so will need some guidance on that
<jo0nas>
...and am interested also in your experience - e.g. which kind of signalling you've found intuitive
<KotCzarny>
for example on my opipc board (self brewed, so nothing generic)
<jo0nas>
...or better yet, point me to some (pseudo)standard for bootup signalling
<KotCzarny>
i like to use green as 'power-on' and red/blue as disk activity (mmc0 trigger)
<jo0nas>
there is not standardization? Would it be possible to try standardize e.g. across Allwinner boards?
<KotCzarny>
would require naming leds in uboot's dts i guess
<jo0nas>
yes, some (pseudo-)standardized naming in dts is what I was thinking
lurchi__ is now known as lurchi_
<jo0nas>
I see there is the notion of aliases in dts
<KotCzarny>
in kernel they are often named, but still random at times
gnufan_home has joined #linux-sunxi
<jo0nas>
from a distro perspective, I find it far more rewarding to work on standardizing across boards than to tune boards one by one independently at a higher level
<jo0nas>
KotCzarny: sounds like a good start if kernel has _some_ general naming - can you point me to concrete examples of that?
gnufan_home1 has quit [Ping timeout: 264 seconds]
<KotCzarny>
ls /sys/./firmware/devicetree/base/leds/status_led/
<KotCzarny>
and pwd_led
<KotCzarny>
that's from 4.16 kernel, dont know if it didnt change
<KotCzarny>
otherwise: ls /sys/./devices/platform/leds/leds/
<KotCzarny>
s/pwd_/pwr_/
<jo0nas>
KotCzarny: is your own work public somewhere? I am deep into other things at the moment, but would like to get back to this later
marble_visions has quit [Quit: bye]
<jo0nas>
thanks for the pointers!
<KotCzarny>
nah, just some simple hacks in uboot.cmd, kernel config and rc.local, didnt think its big enough to publicize. although might be wiki material
<jo0nas>
fair enough - please do consider throwing it on a wiki (for my sake if nothing else)
<KotCzarny>
i personally found it nice to blink once in uboot, then set pwr_led to hearbeat in kernel, then make it either 'on' or trigger on mmc0 in rc.local
<KotCzarny>
in similar way routers blink their power led
<KotCzarny>
and set to 'on' once system finished booting
<jo0nas>
that sounds sensible
<jo0nas>
...and requires only a single led so should be doable across many types of boards
<KotCzarny>
if you have two leds on particular board, its nice to set green to 'on' and red to 'mmc0'
<KotCzarny>
to see when things get read/written
<jo0nas>
you mean like hdd activity?
<jo0nas>
right
libv has quit [Ping timeout: 245 seconds]
<KotCzarny>
but since it's up to user's preference it's easily done in rc.local
<jo0nas>
I'm thinking on how it could be more elegantly configurable in Debian - i.e. hooking into multiple packages instead of requiring manually editing a file
<avernos>
im a bit lost at the partition parameter
<jo0nas>
it is a digit - typically 0 or 1 depending on how you formatted your device
<KotCzarny>
jo0nas: since it could affect more systems, it's surely something to be thought over by distro maintainer ;)
<jo0nas>
avernos: root parameter is important to _finalize_ a boot but not important to test if you receive kernel messages
reinforce has quit [Ping timeout: 252 seconds]
reinforce has joined #linux-sunxi
fkluknav_ has joined #linux-sunxi
tilpner_ is now known as tilpner
<diego71>
avernos: you just need to add the console and earlyprintk parameter. You should already have a root parameter somewhere, probably computed by uboot script.
lurchi_ is now known as lurchi__
<diego71>
avernos: I suggest to learn a bit of uboot scripting. It can be useful to debug boots problem
reinforce has quit [Ping timeout: 246 seconds]
<avernos>
diego71, would like to learn more about uboot, fascinating project, but im a bit at a loss without some stupidme guide. havent done much about this in a while.. gotta keep some more notes around else forget things