<Kamikaze84>
Hi again. I've been working on getting my 2GB Firefly-RK3399 booting with a mainline kernel via SDCard. I've managed to get the kernel going by not loading the FAN53555 module (or any CONFIG_REGULATOR_* modules) as one of my hangs seemed to be related to this.
<Kamikaze84>
I also had to include 'clk_ignore_unused' as a kernel parameter for some reason, as I noticed another hang happened in a function call that disabled unused clocks.
<Kamikaze84>
This now gets me to the point of finding the rootfs, however for some reason my kernel fails to detect my SD or my eMMC.
<Kamikaze84>
I have a few things to try for the eMMC (as I'm not sure if the kernel I last used had MTD_PARTS_CMDLINE in built or not), but I'm not sure why the SD is not detected. Any hints?
<Kamikaze84>
I feel like something might be wrong with my DTB, just because I also noticed a few errors when trying to retrieve values from the DTB.
<Kamikaze84>
e.g. this: "Looking up vmmc-supply property in node /dwmmc@fe320000 failed" perhaps it's normal though.
<Kamikaze84>
hmm maybe not. also i just realised i pulled that message from the wrong bootup log. don't have my FF on me today and I can't find my pastebin that I made yesterday... so ignore that message.
anarsoul|2 has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-rockchip
<Kamikaze84>
Do you need to update u-boot to a later version to have it work with a later mainline kernel? Is there an effect on the kernel if booting from an older u-boot?
lurchi_ is now known as lurchi__
ujerry_ has joined #linux-rockchip
ujerry_ has quit [Quit: Leaving]
ujerry_ has joined #linux-rockchip
busterbcook has quit [*.net *.split]
fireglow has quit [*.net *.split]
aalm has quit [Ping timeout: 256 seconds]
aalm has joined #linux-rockchip
akaizen has joined #linux-rockchip
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 is now known as cnxsoft
return0e has quit [Read error: Connection reset by peer]
lurchi_ has joined #linux-rockchip
return0e has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 248 seconds]
ujerry_ has quit [Read error: Connection timed out]
vstehle has joined #linux-rockchip
ujerry_ has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 244 seconds]
hanetzer has quit [Ping timeout: 260 seconds]
hanetzer has joined #linux-rockchip
Kamikaze84 has quit [Quit: Page closed]
gnufan1 has quit [Quit: Leaving.]
Omegamoon has joined #linux-rockchip
kaspter has joined #linux-rockchip
lukasz__ has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
kaspter has quit [Read error: Connection reset by peer]
cyteen has quit [Read error: Connection reset by peer]
cyteen has joined #linux-rockchip
akaizen has joined #linux-rockchip
wens has quit [Ping timeout: 245 seconds]
wens has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
wens has quit [Ping timeout: 244 seconds]
wens has joined #linux-rockchip
cyteen has quit [Read error: Connection reset by peer]
Kamkaze84 has joined #linux-rockchip
<Kamkaze84>
Hi, I was here earlier. I'll be afk at times, but I've got a pastebin (here: https://pastebin.com/U0pFLYLq ) of a mainline kernel booting from sdcard on my Firefly RK3399. I cannot get it to see any partitions on my sdcard or eMMC when it goes to find the rootfs. I
<Kamkaze84>
I'm wondering what particular kernel config needs to be set to enable the sdcard in mainline?
zzarr_ has joined #linux-rockchip
zzarr_ has quit [Client Quit]
<diego71_>
Kamkaze84: I wonder if it is a problem of DT (device tree)
Omegamoon has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 244 seconds]
<Kamkaze84>
deigo71_: I thought that too at one point, hrmm... i'll mess with the resource img
<Kamkaze84>
diego71_: thanks
kaspter has joined #linux-rockchip
<Kamkaze84>
diego71_: wow yeah thanks that was it.. I must have forgot to reflash the resource last time I re-did the sdcard image... it must have had an old dtb there that it picked up.
Omegamoon has joined #linux-rockchip
mrfixit2001 has joined #linux-rockchip
mrfixit2001 has quit [Client Quit]
tllim has joined #linux-rockchip
tllim has quit [Remote host closed the connection]
mrfixit2001 has joined #linux-rockchip
lurchi_ is now known as lurchi__
<Kamkaze84>
finally got a login in arch linux.. woohoo. thanks all. I seem to be getting the bugs that vagrantc reported with the fan53555 module, but I also have one with the pwm-regulator module too. I've had to blacklist them both and use clk_ignore_unused as a kernel param too
LargePrime has joined #linux-rockchip
LargePrime has quit [Client Quit]
<diego71_>
fan53555 was required by firefly rk3288, if I rememeber well
<Kamkaze84>
yeah I heard it mentioned it was needed by the rk3399 aswell, something about cpufreq failing without it.
<diego71_>
Kamkaze84: yes it's needed for cpufreq, at least rk3288
<gab>
yes, I had this issue of rk3339's cpufreq failing without fan53555 (still booting, but keeping clocks very slow)
return0e_ has joined #linux-rockchip
mrfixit2001 has quit [Remote host closed the connection]
mrfixit2001 has joined #linux-rockchip
return0e has quit [Ping timeout: 256 seconds]
kaspter has quit [Quit: kaspter]
hanetzer has quit [Quit: WeeChat 2.1]
hanetzer has joined #linux-rockchip
return0e_ has quit [Remote host closed the connection]
<Kamkaze84>
gab: i _might have_ just managed to patch my DTS for the fan53555 and pwm-regulator issues i just had. i basically just took a couple of values that looked related from the firefly tree, and also compared against the (decompiled) eMMC DTB
<Kamkaze84>
it seems to load both modules now and not hang... although I've only used it for a few minutes
<Kamkaze84>
im not sure yet if cpufreq is functioning, but will check soon
<Kamkaze84>
diego71_: arch doesn't seem to have that binary in a package in it's default repos. but cpupower seems to show available frequencies and related CPUs they can be set on
<Kamkaze84>
I'll run something CPU intensive and see if it ramps up
<vagrantc>
there's also /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
<beeble>
0 are the a53, 4 the a72
<vagrantc>
hah
<beeble>
time_in_state is only available with a extra kernel option
<beeble>
CONFIG_CPU_FREQ_STAT
<Kamkaze84>
its in my kernel apparently, but it looks like it hasn't changed state yet. i haven't run anything crazy yet though, will do soon
<Kamkaze84>
hey the a53 has ramped up
<Kamkaze84>
a72 hasn't though
punit has joined #linux-rockchip
<Kamkaze84>
i'm not real familiar with big.LITTLE, but I modprobe the arm_big_little_dt driver... not sure if it's had any affect... although I guess since cpufreq is aware of the different frequencies maybe it has?
<Kamkaze84>
well, at least the fan53555 and pwm-regulator fix seems to be working. i better put up my dts on github
<gab>
Kamkaze84: fyi, on my rk3399 the cpufreq driver is CONFIG_CPUFREQ_DT, not CONFIG_ARM_BIG_LITTLE_CPUFREQ
<Kamkaze84>
ok, yeah i checked lsmod and it's actually using cpufreq_dt i think
<Kamkaze84>
ah there we go, i used cpufreq-bench and told it to use the a72, and the a72 is ramping up now
<vagrantc>
beeble: fwiw, i got puma-rk3399 enabled in gnu guix ... was easier to get all the arm-trusted-firmware and cortex-m0 stuff in there than in debian
* vagrantc
tried unsuccessfully to use the same ATF/m0 stuff with firefly-rk3399
<vagrantc>
i need to get a freind to help solder a switch onto the firefly-rk3399 to disable the eMMC ... then i would be willing to try installing u-boot to the eMMC again ... although it's distinctly possible the eMMC is fried on this board
<vagrantc>
after so many attempts to short the eMMC to ground...
<Kamkaze84>
the location of the pin to short to gnd for eMMC sucks
<Kamkaze84>
i'm glad i've never tried that so far. i'm sure i'd screw it up. the one time I tried something similar was with a Cisco Meraki AP, and I killed it.
<vagrantc>
another bizarre thing is ... when booting from the microSD ... when i reboot or reset the board ... it requires phyiscally ejecting and inserting the microSD... even after disconnecting from power
* vagrantc
wonders if there is some power bleeding in from the serial console
<vagrantc>
beeble: gotta say, the puma-rk3399 is such a pleasant piece of hardware to work with, by contrast :)
<vagrantc>
just about everything "just works"
<vagrantc>
although i have noticed a bizarre issue where attempting to use ansible on it hard-crashes it. never seen anything like that before
anarsoul|2 has joined #linux-rockchip
<beeble>
vagrantc: nice to hear (the praise) the ansible part not so. must say that i don't use it
<beeble>
but the jenkins slaves i have here run fine and also the kernelci devices do their jobs
LargePrime has joined #linux-rockchip
<vagrantc>
yeah ... i've used ansible with some 30-40 boards so far, and there's something about it that triggers a kernel panic only on the puma-rk3399 ... been meaning to try and dig a little deeper on it, amongst all the other things... :)
<beeble>
i have no ansible knowledge at all. most automation i used in the past was puppet
<beeble>
but if i can help out just give me some pointers
<vagrantc>
i have an idea for a simple test case i'll try out later
matthias_bgg has quit [Quit: Leaving]
Easyfab has joined #linux-rockchip
<vagrantc>
beeble: simple test case didn't trigger the issue ... ugh... when it happens, the orange light on the cpu module flashes ... dunno if that's normal for most kernel panics
<beeble>
we are talking mainline right?
<beeble>
default the led on the module is heartbeat and it also acts as panic led
return0e has quit [Read error: Connection reset by peer]
return0e has joined #linux-rockchip
asciilifeform has joined #linux-rockchip
<asciilifeform>
hello #linux-rockchip .
<asciilifeform>
does anyone here know the state of the art in re: booting mainline uboot on asus c101pa 10" 'chromebook' ?
<asciilifeform>
or , failing that, know where are the spi rom contacts on this machine's mainboard ( example photo on my www, http://www.loper-os.org/?p=2326 )
<asciilifeform>
( there appears to be an (unpopulated) google 'servo' debug connector, but it apparently does not bring out the spi contacts )
<asciilifeform>
any tips/leads appreciated, thank you.
<asciilifeform>
i am open to porting uboot with own hands, but do not have a sufficient supply of the machines to create brick after brick. so looking for where to solder spi burner leads.
<beeble>
is it booting from spi by default?
<asciilifeform>
not sure, possibly it is an internal mmc
<asciilifeform>
shows up as /dev/mmcblk0
<asciilifeform>
it would be just as great for my purposes, to find the method for forcing the rockchip cpu into mask rom mode, and then reflash via usb A-A cable
<asciilifeform>
i recently worked with a roc-rk3328-cc board, on similar chipset, and it had two test pads that can be shorted to trigger this mode.
mrfixit2001 has joined #linux-rockchip
<beeble>
maybe take a look at mmcblk0. hexdump it and look at offset 0x8800
<beeble>
is there a header resembling the string RK33
<beeble>
if so your bootsource is mmc
<asciilifeform>
looks to be null.
<beeble>
ok, then it probably booting from spi (cat /proc/mtd maybe?)
<asciilifeform>
device shows as a 40MHz mmc0 in kernel log, however.
<asciilifeform>
but in /proc/mtd, shows as mtd0: 00800000 00001000 "spi1:0"
<asciilifeform>
so looks like a emmc chip in spi mode.
<beeble>
no, mmcblk0 is the emmc mtd0 is the spi flash
<asciilifeform>
aah hm
<beeble>
hexdump /dev/mtd0, offset 0x1000
<beeble>
see if there is a RK33 header
<asciilifeform>
RK33u
<beeble>
tada
<beeble>
so spi bootloader
<asciilifeform>
right
<beeble>
easy to force it into maskrom
<beeble>
can't say for 100% due the lack of pixles in your picture
<asciilifeform>
any simple way , other than by zeroing the rom ?
<beeble>
but second chip from the left
<beeble>
next to the second nope
<asciilifeform>
the one under the 2nd screwhole from left ?
<beeble>
yes
<beeble>
if you could tell me the marking on that
<asciilifeform>
that was my lead suspect. i assume all i gotta do is to short sda line to ground ?
<beeble>
yes, but as there is no sda take miso, mosi, clk or cs. all of them will work
<beeble>
then it will go into maskrom mode
<beeble>
http://git.denx.de/?p=u-boot.git;a=blob;f=board/theobroma-systems/puma_rk3399/README;h=f67dfb451ffd36745a5209a83459a8337134b75d;hb=HEAD#l80 on how to flash mainline uboot with rkdeveloptool
<asciilifeform>
aa neato ! thx beeble . i'ma try this later, this box is a 1st class pain to open, and designed in such a way that there is no way to get to the contacts without completely removing the mobo. will have to solder leads and try this.
<beeble>
then starts the hard part
<beeble>
because there is no mainline support for the c101pa yet
<asciilifeform>
i suspected this. ( hence why looked for spi )
<beeble>
so not sure if spl supports lpddr right now
<beeble>
the thing is
<beeble>
rkdeveloptool does not support spi flashing
<beeble>
and for loading u-boot into ram we have to implement tpl first
<asciilifeform>
seems to support manual feeding of boot rom image though, and with this i can debrick.
<beeble>
but then you have to find a data line for the emmc too
<beeble>
or better the clock line
<beeble>
so you can short that too
<asciilifeform>
google's rom knows how to boot from external sd; from there, can reflash mmc0
<beeble>
ah ok
<asciilifeform>
... or will rk autoboot from mmc0 even when spi is shorted out, unless mmc0 is nulled ?
<beeble>
yes
micken has quit [Ping timeout: 245 seconds]
<asciilifeform>
so gotta short both, to get into mask mode ?
<beeble>
bootorder is spi -> emmc -> sd
micken has joined #linux-rockchip
<asciilifeform>
it's a bit of a puzzler then why the vendor included the spi rom, if rockchip knows how to boot from mmc
<gab>
cheaper PCB routing ?
<beeble>
less issues if people play around with mmcblk0
<asciilifeform>
i doubt that it'd offset the cost of the extra chip. personally i suspect that it was done specifically for the 'nintendoization' ( the firmware is writeprotected, by default, gotta pull out the battery to bring the WP pin low )
<beeble>
and no problem with mmcblk0bootX
<beeble>
thats always a bit of a pain
<beeble>
no, actually it is really just a cheap safe way to store your bootloader
<beeble>
NOR flash reliability is higher then MLC NAND (even if stored in the SLC partitions)
<asciilifeform>
any theory re: how these get flashed during manufacture ?
<beeble>
boot from sdcard
<beeble>
thats at least how i do it
<asciilifeform>
this happens by default if both roms are full of null ?
<beeble>
yes, spi, emmc, sd card (nand inbetween or before emmc not sure) and if all fails usb mode
<asciilifeform>
mmc rom ( supposing it's the large item on bottom left of cpu ) seems to have only 1 exposed pad
<beeble>
yes thats the emmc
<asciilifeform>
i've never seen an emmc that wasn't a bga ( like this one is ). how do people usually short it ?
<asciilifeform>
( or would simply nulling it from inside a working os booted from sd , suffice )
<beeble>
vias somewhere on the way
<beeble>
there could also be a small resistor value in the clock line
<beeble>
usually you have 22-33ohm there for emc reasons
tllim has joined #linux-rockchip
<asciilifeform>
line terminator aha
<asciilifeform>
and would i have to null whole 16GB, or just 1st N sectors
<beeble>
bootrom looks for the RK33
<asciilifeform>
ah ok
<asciilifeform>
the mmc should already be bypassed, then, even with stock google os: it has no RK33 marker even now
<asciilifeform>
(if spi is shorted)
<beeble>
yes
<beeble>
if you have a sd slot
<asciilifeform>
so theoretically can leave mmc alone
<beeble>
then thats the easiest way to develoip
<asciilifeform>
so looks like a shorting toggle for the spi, should suffice
<asciilifeform>
1 more q -- anybody know what the 4pin empty pad next to the 'servo' pads, is ? uart ?
<asciilifeform>
( and there's a 6-pin testpad-looking thing next to the power usbc connector; any theories ? )
<asciilifeform>
err, not power usbc, but the secondary one next to audio jack
<asciilifeform>
anyway folks, thx for the tips. i will post the magic recipe on my www when it is ripe. normally i can be found at #trilema , where the cp101pa delousing is only the smallest of many interesting open puzzles.
<asciilifeform>
physically the cp101pa is imho a very spiffy box; will make for a great cheap linux workstation when we find how to wash 100% of the nintendo off it.
<beeble>
doesn't look like it's sold in europe
<asciilifeform>
amazon.co.uk seems to have it.
<asciilifeform>
£240 for the 4GB ver.
JohnDoe_71Rus has joined #linux-rockchip
<beeble>
wow, only 5 pounds shipping
<beeble>
should do it as long as they are still in the eu :)
<asciilifeform>
i'm in usa, where they can be seen even in ordinary shops
mrfixit2001 has joined #linux-rockchip
<asciilifeform>
usa amazon does ship into eu, but makes you pay vat.
<beeble>
i can't bypass vat if i buy it private anyway
<asciilifeform>
in re other rockchips, i have a working gentoo for the 3328 : http://www.loper-os.org/?p=2295 , if anybody wants one.
Xal1u5 has joined #linux-rockchip
Easyfab_ has joined #linux-rockchip
anarsoul|3 has joined #linux-rockchip
Easyfab has quit [Read error: Connection reset by peer]
BenG has quit [Read error: Connection reset by peer]
anarsoul|2 has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has joined #linux-rockchip
aalm has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Client Quit]
aalm has joined #linux-rockchip
return0e has quit [Read error: No route to host]
return0e has joined #linux-rockchip
<paulk-gagarine>
asciilifeform, what device are you asking about?
<paulk-gagarine>
sounds like a rockchip chromebook
nashpa has joined #linux-rockchip
<asciilifeform>
paulk-gagarine: asus c101pa ; RK3399 chipset
<paulk-gagarine>
neat
<paulk-gagarine>
that's one I don't have
<paulk-gagarine>
I doubt that they exported UART anywhere else than the servo pads
<asciilifeform>
it's a pretty great box, aside from the vendor firmware. aluminum chassis, ips lcd, etc
<paulk-gagarine>
what's wrong with the firmware?
<paulk-gagarine>
it's coreboot
<asciilifeform>
it's google's nintendoized mutilated coreboot, forces you to go through their song & dance to build kernels, won't load'em from standard partitions (gotta keep a GB of toolchain crapola around, to write kernels)
tllim has quit [Ping timeout: 240 seconds]
<asciilifeform>
won't give uboot console, won't netboot, ugly.
<asciilifeform>
and when in 'dev mode' it prompts you for magic keypress on every boot, and if you don't press in time, reformats the disk. (like all chromebooks.)
mrfixit2001 has quit [Remote host closed the connection]
<paulk-gagarine>
no, it's regular coreboot
<paulk-gagarine>
with the depthcharge payload
<paulk-gagarine>
it's called that way for a reason
<paulk-gagarine>
so yes, you don't get u-boot shell :p
<asciilifeform>
right
<paulk-gagarine>
I don't see how data erase when enabling dev mode is a bad thing
<asciilifeform>
adds up to a mostly unusable, per my lights, box, until i find a way to cleanse it.
<paulk-gagarine>
and the kernel format is fit
<paulk-gagarine>
it's totally standard
<paulk-gagarine>
and allows for verified boot
<asciilifeform>
i want a kernel on normal ext4 partition.
<asciilifeform>
like on normal boxen.
<paulk-gagarine>
zImage doesn't allow these types of use cases
<asciilifeform>
and to hell with 'verified boot', i want 0 google crapola on my boxes.
<paulk-gagarine>
fit image is definitely standard
mrfixit2001 has joined #linux-rockchip
<paulk-gagarine>
you can use u-boot as a payload
<paulk-gagarine>
instead of depthcharge
<paulk-gagarine>
GRUB2 also has a work in progress port for ARM
<asciilifeform>
this is roughly what i'd like to build, yes
<paulk-gagarine>
(maybe v7 only though)
<paulk-gagarine>
asciilifeform, well, coreboot has support for that :)
<asciilifeform>
rockchip is theoretically capable of blobless boot.
<paulk-gagarine>
last time I checked, coreboot master was fully-featured for rk3399
<paulk-gagarine>
not theoretically
<paulk-gagarine>
I do it on kevin
<paulk-gagarine>
Chromebook Plus
<paulk-gagarine>
with upstream coreboot, atf, depthcharge and vboot
<paulk-gagarine>
with generated keys
<asciilifeform>
iirc there's some magic to enable the embedded micro, and the lcd, on this box
<paulk-gagarine>
also the ec firmware
<paulk-gagarine>
it's already all in coreboot
<asciilifeform>
iirc ec fw is nonvolatile
<paulk-gagarine>
I don't remember how it is for bob
<paulk-gagarine>
but on kevin you have another spi flash for it
<paulk-gagarine>
which is routed to servo SPI1
<asciilifeform>
i actually don't mind the vendor's ec fw, their posted source builds and the resulting item, runs
<asciilifeform>
and contains nothing objectionable imho
<paulk-gagarine>
anyway you can also reflash the ec from the device itself
<asciilifeform>
right
<paulk-gagarine>
so if you're looking for help rebuilding this stuff, feel free to ask
<paulk-gagarine>
I have a build system ready for that
<paulk-gagarine>
doesn't have bob support for now, only kevin as far as rk3399 goes
<paulk-gagarine>
and linux-cros only, not mainline linux for now
<paulk-gagarine>
I have yet to make a mainline defconfig and so
LongChair_ has quit [Quit: Connection closed for inactivity]
<asciilifeform>
paulk-gagarine: i have a working userland ( http://www.loper-os.org/?p=2295 ) for the box already. now i only need boot fw and kernel.
<asciilifeform>
building works ok from inside it ( chroot from devmode'd google linux )
<asciilifeform>
i've gotten it to boot properly into it using a kernel lifted from archlinux and signed with dev keys via google's tooling, also; but this gives no networking currently (it seems to want modules, which of course aren't there in my userland, which i originally built together with a monolithic kernel for rk3328)
<asciilifeform>
what i'd like to end up with is a box from which 100% of the googlism is banished.
<asciilifeform>
( i like the rockchip , the 9 hour battery, and the 10 inch ips; i do not want or need google's crapola for anything whatsoever. in particularly the 'verified' song and dance. )
<asciilifeform>
the rk3328 devboard was very easy in this respect -- it has no onboard flash at all, 100% of the firmware lives on sd card that pulls out.
xerpi has joined #linux-rockchip
<paulk-gagarine>
that's very nice for dev boards but it's really not secure for a laptop to have all the software on a sd card
<paulk-gagarine>
in that regard, the spi flash + screw design is nice
<paulk-gagarine>
but I understand you don't care about the security model
vagrantc has joined #linux-rockchip
<asciilifeform>
write-protectable bios is theoretically nice , but this box is quite unfriendly to disassemble. i ripped the touchpad connector right off mine, not long ago, while opening.