ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log | Community GH | Rockchip GH | ML
LongWork has joined #linux-rockchip
nighty- has joined #linux-rockchip
fischerm has quit [Quit: ZNC 1.6.2 -]
Shlin has joined #linux-rockchip
Shlin is now known as shawnlin
<shawnlin> quit
shawnlin has quit [Quit: leaving]
lt_ has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
fischerm has joined #linux-rockchip
lt_ has quit [Quit: Lost terminal]
lkcl has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
vagrantc has joined #linux-rockchip
moneymaker has joined #linux-rockchip
moneymaker29 has joined #linux-rockchip
moneymaker has quit [Quit: Page closed]
ijrvgfcdk0l has joined #linux-rockchip
ijrvgfcdk0l has quit [Client Quit]
moneymaker29 is now known as moneymaker
twink0r has quit [Ping timeout: 240 seconds]
Ancient has quit [Quit: Have a nice day. :)]
cosm has quit [Remote host closed the connection]
cosm has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
twink0r has joined #linux-rockchip
Ancient has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
lkcl has quit [Ping timeout: 248 seconds]
lkcl has joined #linux-rockchip
lkcl has quit [Ping timeout: 255 seconds]
lkcl has joined #linux-rockchip
PoueT has quit [Ping timeout: 268 seconds]
afaerber has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
BenG83 has joined #linux-rockchip
<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]
fischerm has joined #linux-rockchip
<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> hrm ... can't find the branch on github, but i was using the kever_dev branch at
<vagrantc> my git repository seems to be able to find it...
<vagrantc> maybe SPL only works writing to the eMMC ?
<vagrantc> at least with u-boot-rockchip/next it detects ~4GB of ram :)
<beeble> vagrantc: board/theobroma-systems/puma_rk3399/README
<beeble> for mainline spl instruction
<beeble> does work with sd, emmc and spi
<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]
kloczek has joined #linux-rockchip