<robmur01>
looks like one for the PCIe3.0 RCs and the other for the PCIe2.0 ones
<maz>
ah, right. not looking at the right version, i guess.
* robmur01
gets fed up of Github navigation/search and pulls the branch...
<maz>
I expect this machine is made of unobtainium, as usual?
<maz>
I could try and convince $WORK to get a handful if they were available.
<robmur01>
quite a few RK3588 boards on the horizon now, so I suspect silicon might be near the point of mass production
<robmur01>
I suspect I might end up buying one because MMU-600, but I'll refuse to enjoy it
* robmur01
still hasn't finished the DT for the RK3288 box that got him into this whole mess years ago
stikonas has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
<Tenkawa>
I've got the Odroid version of the RK3588 on order once it gets released.., also waiting on a RK3568 based Odroid based board to get here with several drive interface options so its going to be interesting to see how well the kernel and dtb comes out initially
<Tenkawa>
so both are oredered... just waiting for them
matthias_bgg has quit [Ping timeout: 256 seconds]
vagrantc has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
Tenkawa has quit [Quit: Was I really ever here?]
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
<macc24>
is doc/README.rockchip still right about mainline u-boot being unable to boot from emmc on rk3399?
<robmur01>
my RK3399 board running mainline everything off eMMC for the last 4 years or so suggests no
<robmur01>
it probably still has the U-Boot hack to limit the eMMC to a 50MHz mode though, dunno if that ever got fixed properly
<macc24>
robmur01: okay, how did you get it to boot from emmc?
<robmur01>
AFAIR I built a U-Boot image and wrote it to the eMMC :/
<macc24>
ah
<robmur01>
eMMC is basically just another SD card in this context
macromorgan has joined #linux-rockchip
<macc24>
o/ macromorgan
<robmur01>
although I do have a vague memory of having to set the "same-as-spl" boot order property to convince it to behave, even though it seemed like that was supposed to be the default anyway
<robmur01>
yeah, my local tree just has one patch doing that, on top of v2021.10, but according to `sudo strings /dev/mmcblk2` I'm still actually running something based on v2020.01
Tenkawa has joined #linux-rockchip
lurchi_ is now known as lurchi__
<Jmabsd>
robmur01: feel free to write this up somewhere
Tenkawa has quit [Quit: Was I really ever here?]
Tenkawa has joined #linux-rockchip
<Jmabsd>
Oh remind me, which RK3588 SBC:s are in the production pipe: Radxa, Firefly. Who more?
<robmur01>
Huh, write what up where? Does it need recording for posterity that I can't be bothered to update bootloaders once they work?
<Tenkawa>
Jmabsd Rock5
<Jmabsd>
tenkawa: That's by Radxa. More?
<Tenkawa>
Jmabsd: oh yeah duh
<Tenkawa>
I was referencing it "from" the Odroid dealer... that was throwing me off
<Tenkawa>
Jmabsd: QuartzPro64
<Tenkawa>
by Pine
<macc24>
so i kinda have a rk3399
<macc24>
device
<macc24>
that i can't kick out of rockusb mode
<macc24>
it unfortunately has something on its emmc so it isn't maskrom mode and i can't override it
<macc24>
is there any way i can rescue that device without shorting emmc to ground and without uart?
<vagrantc>
soldered emmc?
<macc24>
yes
<vagrantc>
i played that game with a firefly-rk3399 board ... no fun.
<macc24>
i can't short emmc clock to ground because the device has no documentation :|
<robmur01>
yeah, that state can be a bugger to get out of... I think if you have a fully-packed RKFW image, "uf" in rockusb can still overwrite the SPL along with everything else
<macc24>
"fully packed rkfw image" so update.img?
<robmur01>
ISTR rescuing my RK3288 box by doing a recovery boot to re-flash stock Android on several occasions
<Jmabsd>
tenkawa: Oh yes
<robmur01>
if there's enough SPL left and you're particularly lucky, it might still look to load U-Boot main stage off the SD card, but there are several variables at play there
<macc24>
robmur01: there's enough u-boot there to recognize that it's broken and to kick rk3399 into rockusb
<macc24>
and it tries complaining about u-boot being broken but i've got way too slow uart adapter
<vagrantc>
oh, yeah, the default speed for many rk3399 is 1500000... you definitely want a reasonably ok uart...
<robmur01>
the other thing is to look carefully around the vicinity of the eMMC (both sides of the board) for two close-together test pads where one is grounded and the other at around 1.8V
<robmur01>
if they've followed the reference schematic without being too clever, that should be the EMMCCLK escape hatch :)
<macc24>
hmm
jakllsch_ is now known as jakllsch
<robmur01>
(although looking at rk3399_box_ref specifically I see it specifies a few more too - from experience EMMC_D0 should be equally sufficient to break booting; I guess EMMC_CMD might be; EMMC_STRB probably isn't)
<robmur01>
(which reminds me I haven't updated my local git version in ages...)
<macc24>
now why does it complain of missing dtb
<robmur01>
you flashed u-boot.itb, not u-boot.bin, right?
<macc24>
yep
<macc24>
note that i'm trying to port a board
<robmur01>
oh, yeah, I have a half-finished attempt at that lying around too, and getting all the configs and stuff right seems to be a whole extra dose of fiddly
<Tenkawa>
yay.. my RK3568 with NVME interface will be here in a few days
<Tenkawa>
this should be fun
dvergatal has quit [Ping timeout: 256 seconds]
<robmur01>
for certain values of "fun", at least
dvergatal has joined #linux-rockchip
<robmur01>
I believe NVMe really wants working MSIs, which is not proving to be one of the RK35xx chips' strong points