nighty- has quit [Quit: Disappears in a puff of smoke]
kaspter1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 268 seconds]
kaspter1 is now known as kaspter
ujerry_ has quit [Quit: Leaving]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-rockchip
cnxsoft1 is now known as cnxsoft
mateo` has quit [Ping timeout: 260 seconds]
mateo` has joined #linux-rockchip
Kamikaze84 has joined #linux-rockchip
<Kamikaze84>
Hi
nighty- has joined #linux-rockchip
<Kamikaze84>
I have a firefly rk3399 and I'm trying to rebuild an SDCard image similar to the firefly provided one but with my own compiled kernel and my own rootfs
<Kamikaze84>
I'm starting from the existing image and trying to modify it (starting simple, then I'll replace more as I go)
<Kamikaze84>
I've found the offset the kernel is written to and it seems to be a rockchip image format as I can see the header 'KRNL
<Kamikaze84>
' where it starts
<Kamikaze84>
So I flashed over it, and I can see the uboot is recognising the new kernel as it detects the correct size of it, but it hangs on 'Starting kernel...'. I'm thinking I need to flash a new 'resource' partition with new DTB
<Kamikaze84>
Anyone have any links handy on what exactly this resource partition is and how it's formatted (if it's an actual filesystem...) ?
<Kamikaze84>
It _looks_ like it might be a filesystem of some sort, just because I can see reference to a few file names rk-kernel.dtb and logo.bmp
<Kamikaze84>
the image header starts with 'RSCE' if that helps
<Kamikaze84>
and file names entries seem to be prefixed with ENTR
<Kamikaze84>
eh maybe it won't matter... i just found the 'resource_tool' file in the rkbin tools
afaerber has joined #linux-rockchip
<Kamikaze84>
Hmm still hangs on Starting kernel ...
<Kamikaze84>
Looks like it finds the new resource img and loads the new DTB
<Kamikaze84>
maybe that kernel doesn't work for me... i compiled the tar.gz from the linux-rockchip tree in kernel.org cgit tag v4.16
<Kamikaze84>
anyone know what tree should work for me if compiling for a firefly rk3399 and wanting something mainline or close to mainline?
<Ke>
even mainline works occasionally, I hear
<Ke>
at least for chromebook Kevin rk3399
<Kamikaze84>
really? maybe it was the config I used then? I just took the defconfig from the arch/arm64/config/rockchip/defconfig
<gab>
Kamikaze84: if you changed from rockchip to mainline kernel, you need to change the console= parameters
<Ke>
not sure, what's the current state
<gab>
try this 'earlycon=uart8250,mmio32,0xff1a0000 console=uart8250,mmio32,0xff1a0000 earlyprintk'
<gab>
this is what I'm using on a sapphire with 4.16
<Kamikaze84>
ok thanks, that might take me some minutes, got to find where they are in the sdcard image and modify them.
<Kamikaze84>
will try.
<Kamikaze84>
know where they are on the eMMC as it seems to be almost the same layout
<Kamikaze84>
?
<gab>
if the parts are the same as emmc, it should be on partition 4
<gab>
extlinux directory
<Kamikaze84>
cheers
<gab>
also note that with mainline, the mmc devices dont have the same indexes
<gab>
emmc is in mmcblk2 instead of mmcblk0
<gab>
(I don't know about SD because I don't use it)
<Kamikaze84>
ok
<ayufan>
do anyone knows what is the format of uboot.img/trust.img produced by loaderimage and trust_merger?
<Kamikaze84>
oops. killed it. must have flashed to wrong offset. at least it shouldn't take me long to get back to where I was
chewitt has joined #linux-rockchip
<Kamikaze84>
really weird. if I switch the params it seems to kill the boot. i've pulled them down via 'dd' and modifying the hex code. i'm surprised this is causing issues.
<Kamikaze84>
gab: i couldn't get a copy of your params could I ?
<gab>
which params ? cmdline ?
<Kamikaze84>
actually,sorry, you mentioned yours were in a partition with extlinux... it doesn't look like these are.. at least I don't think so
<Kamikaze84>
basically since I don't know what format these are stored in I'm modifying the actual hex data to insert my params/cmdline to append to the kernel boot
<Kamikaze84>
i think these are what gets written when you use upgrade_tool. there's a 'parameters' file in the images it works with
<Kamikaze84>
god damn i think these parameters are checksummed somehow
<Kamikaze84>
i changed one single byte - /dev/mmcblk0p6 to /dev/mmcblk1p6 and it completely forgets how to boot.
<Kamikaze84>
e.g. before i modify them, it finds the kernel, and tries to start it (but hangs) if I modify the params at all, then it fails to even find the kernel
<gab>
hm not a very good idea if these are in uboot env variables... uboot's env is checksumed with crc32
<Kamikaze84>
i'm not sure whether those params are within u-boot, but the rockchip 'upgrade_tool' seems to be able to flash 'em
<Kamikaze84>
the SD card image I've got still falls back to rockusb when things fail (which it did because of my non-checksummed params)
<Kamikaze84>
so using rockusb
<Kamikaze84>
I was able to then use upgrade_tool and flash the parameters the way it expects with the upgrade_tool: DI -p parameter_gpt.txt
<Kamikaze84>
now, it must write a new checksum somewhere that allows it to work
<Kamikaze84>
because I can see it booting up most of the kernel, except I get stuck at : [ 1.915291] pwm-regulator: supplied by regulator-dummy
nashpa has quit [Quit: Going away]
Kamikaze84 has quit [Ping timeout: 260 seconds]
Kamikaze84 has joined #linux-rockchip
kaspter has quit [Read error: Connection reset by peer]
<Kamikaze84>
btw gab thanks for the hints regarding parameters, they definitely got me further now that I can see the output of it trying to boot.
kaspter has joined #linux-rockchip
<Kamikaze84>
i haven't switched u-boot yet because I hadn't had any luck doing that on SDCard so far. so instead I decided to work backwards from their SDCard image
<beeble>
did you disabled your emmc when trying to load u-boot from sd?
<Kamikaze84>
beeble: no not with this config
<Kamikaze84>
beeble: I did sort of try that before. I wiped out u-boot partition only on emmc, but still failed to boot with SDCard images (i tried a few, some compiled entirely myself, some from githubs like xypron)
<Kamikaze84>
not sure if that was enough, but i didn't want to fully wipe eMMC as I was afraid of having to short pins for maskrom if i got to that point.
<beeble>
emmc is prioritized over sd. so if you have a bootloader signature on the emmc it will not try to load any from the sd card
<Kamikaze84>
this doesn't seem to be the case anymore, at least for my board. I read somewhere on the firefly forums that after a certain image ( I think it was around may 2017 ) emmc would recognise and boot from SD. I can confirm that I can boot the firefly SDCard image named: Firefly-rk3399_xubuntu1604_SD_201705151725.img from my board, with an intact emmc
<beeble>
i'm talking about the bootloader
<Kamikaze84>
oh, so the bootloader is always loaded from emmc first, but then might hand off to SD or emmc for the next stage?
<beeble>
if you power up your board the maskrom will search for a signature on SPI NOR -> eMMC/NAND (not sure which one first right now) -> SD Card and if it does not find any it will start the usbloader ("rockusb maskrom mode")
<beeble>
so if you want to load it from the sd card you have to prevent finding it on the eMMC. thats possible by erasing the emmc or by using the "maskrom" pin
<beeble>
that is acutally just messing up the data/clock line of the emmc that the cpu can't read data from it
<Kamikaze84>
i'm still confused by this, sorry excuse my ignorance... so maskrom finds the boot loader sig on eMMC/NAND, and the bootloader runs on there, but the bootloader then can hand off to u-boot+trust on SDCard?
<Kamikaze84>
sorry, I'm just trying to figure out what's happening exactly on my board at the moment with the modified SD image i've got partly booting
<beeble>
there are multiple stages and they are different depending on the rockchip version and the u-boot mainline version
<beeble>
so on your board it will be
<beeble>
maskrom searching for the signature (just a header) in the order described before
<beeble>
miniloader has this signature and it will be found on the emmc
<beeble>
miniloader is loaded into sram and executed. miniloader initializes the dram and loads the atf and the second stage bootloader (u-boot in that case)
<beeble>
in your case they are also on the eMMC because everything is merged into one binary
<beeble>
after that atf is executed and after that it jumps into u-boot
<Kamikaze84>
thanks... however i'm fairly sure the u-boot it's loading is coming from the SD in my case, I think the atf too. I could check this pretty easily.
<beeble>
in your case u-boot will then load the kernel and dtb from the emmc in some partition and some format that i do not know well enough (take a look at the rockchip wiki if it's important)
<beeble>
and then executes the kernel
<beeble>
i'm pretty sure it will not be on the sd-card :)
<Kamikaze84>
if what you're saying is right, then if i wipe the uboot from the sdcard, i'll still be getting to the same point in the boot process.
<Kamikaze84>
I've plugged it back in, and reset again, and (since I just wiped the parameters on the sdcard to force rockusb mode), I'm getting this now:
<Kamikaze84>
Hit any key to stop autoboot: 0 'boot' does not seem to be a partition nor an address Unable to boot:boot try to start recovery 'recovery' (...snip...) try to start rockusb
<Kamikaze84>
I totally hear what you are saying, but for some reason, the firefly provided SDCard image that I mentioned earlier _does seem to boot_ from sdcard.. which is why I've worked backwards from that image, wiping parts of it to get what I want booting.
<beeble>
the important lines would be the u-boot startup
<Kamikaze84>
I just fixed up the parameters again (using upgrade_tool as I mentioned a while back) and it gets to the same point in booting. I can paste the output if you like?
<Kamikaze84>
e.g. the kernel begins to start up and i get output, but it hangs at [ 1.930401] pwm-regulator: supplied by regulator-dummy
<Kamikaze84>
thanks. what board is that for, and what kernel version?
<beeble>
rk3399-puma
<beeble>
could be 4.15
<beeble>
should work on 4.16
tllim has joined #linux-rockchip
<Kamikaze84>
:( still no luck. hangs at same spot.
<Kamikaze84>
btw i tried wiping u-boot with zeroes on sdcard just to be certain that it's using emmc as you suggested it was - and yep, it still boots exactly as it did before i wiped it - just had to check it for my sanity. Thanks for pointing that out.
<Kamikaze84>
alright that's enough for tonight. thanks all !
Kamikaze84 has quit [Quit: wahoo, kernel begins to start! Progress!!]
tl_lim has joined #linux-rockchip
tllim has quit [Ping timeout: 260 seconds]
lurchi__ has quit [Ping timeout: 240 seconds]
kaspter has quit [Read error: Connection reset by peer]
<mmind00>
anarsoul|3: also rk_tools/3328/*_nospl.sh in there
<mmind00>
anarsoul|3: not in uboot
<anarsoul|3>
mmind00: is anyone working on upstreaming rk3328 patches for u-boot?
<mmind00>
not sure ... I don't think it's a priority for rockchip people
<anarsoul|3>
:(
<mmind00>
anarsoul|3: although the only thing missing was the ddr support, and I think I remember there being patches on the mailinglist for that ... but that was some months ago
<anarsoul|3>
mmind00: does ethernet work in u-boot?
<mmind00>
anarsoul|3: yep
<anarsoul|3>
I don't see it in defconfig
<anarsoul|3>
mmind00: OK, thanks
<anarsoul|3>
I guess I can live with year old u-boot if it can boot linux
lurchi__ has joined #linux-rockchip
<mmind00>
anarsoul|3: "someone" forgot to push the rebased hack-branch
<mmind00>
mmind00: which I rectified ... now it's only a 6 month old uboot ... including the ethernet stuff
<mmind00>
anarsoul|3: ^^ ... addressed wrong person above ;-)
<anarsoul|3>
mmind00: what's the max cpu freq for rk3328? 1.296GHz?
<mmind00>
anarsoul|3: not sure if you can find the parts on the mailing list ... but linux hdmi support for rk3328 is also in anarsoul|3: and hdmi for rk3328 in the linux kernel
<anarsoul|3>
mmind00: found it
<mmind00>
anarsoul|3: according to the dtsi it's this 1.296GHz you listed
<anarsoul|3>
4 outstanding patches for hdmi support as far as I can tell
BenG has quit [Read error: Connection reset by peer]
<mmind00>
anarsoul|3: if an emmc is connected to your rock64 you need to use the maskrom switch on the board ... if none is connected you can also write that stuff to a sd card
<anarsoul|3>
and where do I take trust.img from?
return0e has quit []
<mmind00>
anarsoul|3: that mk_nospl script does create it