<rperier>
linux 4.9.x is working as expected with the kernel is flashed in NAND and if I boot a rootfs over NFS
<rperier>
ethernet is working fine
<rperier>
(with the default bootloader)
<rperier>
so that means that the proprietary bootloader configures iomux things that makes the ethernet working (and that's missing in uboot), the iomux things is probably missing in the current kernel
<rperier>
I think, that's something like this, imho
moneymaker has quit [Remote host closed the connection]
moneymaker has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
LongWork has quit [Quit: LongWork]
<stdint>
rperier, you mean the miniloader? I don't think it does
PoueT has joined #linux-rockchip
PoueT has quit [Remote host closed the connection]
PoueT has joined #linux-rockchip
nighty- has joined #linux-rockchip
fireglow has quit [Ping timeout: 246 seconds]
fireglow has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
<rperier>
stdint: I mean the loader that is found in prebuilt images for the radxa rock
<rperier>
yeah
<rperier>
there is something different, with the same kernel image the behaviour for ethernet is completly different
Aussie_matt has joined #linux-rockchip
moneymaker has quit [Quit: Page closed]
moneymaker has joined #linux-rockchip
moneymaker has quit [Remote host closed the connection]
moneymaker has joined #linux-rockchip
kloczek has quit [Remote host closed the connection]
kloczek has joined #linux-rockchip
moneymaker1 has joined #linux-rockchip
moneymaker1 has quit [Client Quit]
moneymaker1 has joined #linux-rockchip
moneymaker1 has quit [Client Quit]
cnxsoft has quit [Quit: cnxsoft]
moneymaker1 has joined #linux-rockchip
cyteen has quit [Ping timeout: 240 seconds]
moneymaker2 has joined #linux-rockchip
moneymaker1 has quit [Ping timeout: 260 seconds]
Aussie_matt has quit [Remote host closed the connection]
PoueT has quit [Ping timeout: 246 seconds]
PoueT has joined #linux-rockchip
moneymaker2 has quit [Remote host closed the connection]
moneymaker1 has joined #linux-rockchip
moneymaker1 has quit [Quit: moneymaker1]
cyteen has joined #linux-rockchip
cyteen has quit [Ping timeout: 240 seconds]
cyteen has joined #linux-rockchip
vagrantc has joined #linux-rockchip
<vagrantc>
so, with a firefly-rk3399, i'm trying to get mainline u-boot to work, and it loads the kernel+initrd+devicetree just fine, boots, but at some point it freezes with messages about PWM
matthias_bgg has quit [Remote host closed the connection]
<vagrantc>
if i revert to a heavily patched u-boot 2017.05-rc2 + kever_dev patches, it works
<vagrantc>
using mainline u-boot plus all the patches from rockchip/next, it gets this hang
fischerm has quit [Read error: Connection reset by peer]
<vagrantc>
also tried with a 4.12-rc7+ with no difference
<vagrantc>
but switching to an older u-boot works fine...
<vagrantc>
other weirdnesses are loading u-boot from microSD seems to occasionally require ejecting and inserting the microSD ... might be some timing issue in the miniloader or something?
<vagrantc>
haven't been able to get u-boot-spl to work at all
<beeble>
not helping with your problem, but mainline uboot has spl support now. since i see miniloader output
<vagrantc>
would much prefer using SPL, if i could figure out how to get it to boot :)
<vagrantc>
one less piece of the puzzle i need to cobble together from various repositories...
<vagrantc>
really need to get arm-trusted-firmware into debian, too
<vagrantc>
so i guess the main difference is i'm not able to copy bl31.bin and rk3399m0.bin at package build time, as they're not present in Debian
<vagrantc>
at u-boot build time
<vagrantc>
instead, manually creating the .itb from all the various components, but maybe something is missing
<beeble>
as it uses blobs for the atf and the m0 firmware i though you would be interested in a source version
<vagrantc>
indeed
<vagrantc>
long-term, i'd rather get it that way
<vagrantc>
beeble: looks like firefly-rk3399 doesn't yet generate a u-boot.itb
bit_lySLH2uSZHed has joined #linux-rockchip
bit_lySLH2uSZHed has left #linux-rockchip [#linux-rockchip]
<beeble>
vagrantc: CONFIG_SPL_FIT_SOURCE=<your fit_spl_atf.its> in .config
<beeble>
that should do it
afaerber has quit [Quit: Leaving]
<vagrantc>
beeble: so, in theory, if i just manually run the mkimage command with the fit_spl_atf.its with all the relevant binaries, it should work correctly?
<vagrantc>
as, that's what i've been doing...
<beeble>
yes it should
<beeble>
have done it by hand too before adding the target
<vagrantc>
in my experience, the bl31 gets loaded when doing it that way, but never see u-boot
<vagrantc>
well, i've narrowed it down to loading the pwm_rockchip module...
<vagrantc>
which isn't loaded by default in the initramfs....
cyteen has quit [Ping timeout: 248 seconds]
<vagrantc>
soon as i load that, it freezes the system
lkcl has quit [Ping timeout: 258 seconds]
BenG83 has joined #linux-rockchip
cyteen has joined #linux-rockchip
<vagrantc>
beeble: how did you know i was using the miniloader rather than SPL?
* vagrantc
is trying to figure out if SPL actually worked this time
<beeble>
your logoutput showed miniloader output. spl prints something like "uboot spl"
<beeble>
quite early
* vagrantc
just sees a bunch of output and doesn't know what is what
<vagrantc>
:)
<beeble>
DDR Version 1.07 20161103
<beeble>
thats not spl
<vagrantc>
ah, it spits that out even if i don't have a microSD inserted...
<vagrantc>
probably loading off of the eMMC
<beeble>
emmc has an higher boot priority
<vagrantc>
sure makes it hard to boot off of removable media :)
<beeble>
don't have firefly schematics by hand. maybe there is something to disable the emmc
<beeble>
so you don't have to erase the bytes at offset 32k
<vagrantc>
you can physically short some pins
<vagrantc>
last time i tried wiping the eMMC, i had to play the short the pins and hope it actually boots off of microSD until i could reflash it with rkdeveloptool over rockusb
<vagrantc>
or wait, no, i just reflashed it with rkdeveloptool
<beeble>
i have a slider on my board to do that. a lot more convinient
<vagrantc>
but it involved shorting the eMMC pins
<vagrantc>
agreed! :)
<beeble>
you could short clock or a dataline against ground (or vcc. but not sure if it uses 1.8v or 3.3v io on the firefly)
<vagrantc>
well, i've got it running with a moderately patched u-boot 2017.07-rc3 and linux 4.11, it detects all ram, USB works, eMMC works, microSD only works from u-boot ... and loading pwm-rockchip crashes it...
<vagrantc>
not too bad :)
<beeble>
s/against/with
<vagrantc>
would be nice to get the u-boot-spl working for good measure
<beeble>
pwm controls the regulator for a core voltage
<beeble>
so messing that up could crash your board
<vagrantc>
yeah, that doesn't seem so good
<vagrantc>
*seems* to work fine without it
<beeble>
yeah it defaults to a sane voltage if you have it high z or as an input
<beeble>
you only need it for dfvs
<vagrantc>
still haven't been able to test PCIe...
<vagrantc>
should check ethernet again... that was a bit flaky
<beeble>
i only tested it with vendor kernel yet on my board
<beeble>
that worked fine
<beeble>
mainline is still on my todo list
<beeble>
pcie reset gpio has some issue. but if you don't assign it it works fine as pretty much any pcie card will do a power on self reset
<vagrantc>
u-boot still spits out a warning: Cannot find regulator pwm init_voltage
<beeble>
sorry, have my power supply turned off. so i can't take a look at my build
<vagrantc>
thanks for all the suggestions thus far, all the same :)
<beeble>
during weekdays i can do more
<beeble>
and CET :)
<vagrantc>
i guess i could just short the eMMC and see if u-boot spl on the microSD picks up...
<beeble>
boot order is spi, emmc, sd somwhere inbetween maybe nand
<beeble>
and if all fails the usb loader will start
<beeble>
so you should always be able to recover
<vagrantc>
i managed to get it into a state where i think eMMC worked well enough, but failed badly and the usb loader didn't start
<vagrantc>
so shorting the eMMC was needed to get it to get rockusb working...
<beeble>
in that case shorting will help. if you have soldering iron a button would be a good idea during bootloader development/testing
* vagrantc
is always doing bootloader testing, being the debian maintainer for u-boot :)
<vagrantc>
i'm not too soldering iron savvy, but i know people who are :)
<vagrantc>
all the other times once i finally get it booting again i breath a sigh of releif and hope it doesn't happen again :)
<beeble>
i could help out if you like if you are interested in other platforms too. also we do have debian as a standard rootfs
<beeble>
so getting more integrated would be nice for me
<vagrantc>
happy to help get things integrated
<beeble>
from your logfile i have seen you are using extlinux for distroboot. is this the recommended way? cause at the moment i use mainly a custom boot.scr in /boot
<beeble>
and whats about the debian installer is this supported on such boards or are you going the prebuild image way?
<beeble>
i should read releases/stretch/arm64/install.txt.en
<vagrantc>
in debian typically it uses a boot.scr generated by the flash-kernel package, but i'm hoping to change that in future debian releases
<beeble>
looks like it requires uefi. so going the suse patches chain loading route would be the way
<vagrantc>
boot.scr makes it hard to switch between kernel versions or provide extra commandline options from a menu
<vagrantc>
uefi is another approach i've been meaning to take a look at, although i didn't have much luck with the early testing i did last year
<vagrantc>
beeble: there are a handful of boards where we can generate a bootable installer image from debian-installer, but many boards require some things not present in debian due to licensing or other reasons
<beeble>
i have it seen working one time but couldn't reproduce it yet. but didn't put a lot of effort into it
<vagrantc>
a little firmware blob, signed boot images, etc.
<beeble>
we are blob free into userland. only hardware accel needs mali
<beeble>
i should really take a look into debian installer. then i could delete all the debootstrap info from the usermanual :)
<vagrantc>
i think for the arm64 boards, we still need arm-trusted-firmware, which i think isn't packaged just because someone hasn't done the work, although also most boards have vendor forks for arm-trusted-firmware too
<vagrantc>
so that makes it harder...
<beeble>
we try to get our changes merged into upstream
<vagrantc>
beeble: i am considering trying to get debian to move away from debian installer too :)
<vagrantc>
beeble: sounds like you're the sort of folks i like to work with :)
<beeble>
so providing a package wouldnt be that hard. but generating the fit image for spl would not fit a standalone atf package
<beeble>
if not generated at post-install
<vagrantc>
if we have ATF binaries as part of some package, i could depend on them during u-boot build-time and include bootable images
<vagrantc>
or post-install hacks, or scripts to assemble all the pieces, etc.
<beeble>
happy to help. we have also a lot of xgene boards. as these seems to be a tier1 platform for aarch64 i could help there too
<vagrantc>
first, need to get the binaries into debian in a debian-freindly way :)
<vagrantc>
oh, nice
<beeble>
we do compiler work for apm, so i have rack full of all there boards :)
<beeble>
their
<beeble>
damn, getting late i type like shit
<vagrantc>
well, good chatting
<beeble>
goold luck with your bootloader and let's keep in touch about getting things packaged for buster :)
<vagrantc>
now's the time to get started on it! :)
<vagrantc>
hrm... still no SPL after shorting eMMC ...
<vagrantc>
it pauses, complains about eMMC a bit, and then re-inits the eMMC and loads miniloader and company
afaerber has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
kloczek has quit [Remote host closed the connection]