stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 276 seconds]
kaspter has joined #linux-rockchip
camus has joined #linux-rockchip
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
kaspter has quit [Ping timeout: 245 seconds]
apritzel has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 244 seconds]
kevery1 is now known as kevery
camus has joined #linux-rockchip
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
warpme_ has quit [Quit: Connection closed for inactivity]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
mps has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
mps has quit [Ping timeout: 256 seconds]
mps has joined #linux-rockchip
vstehle has joined #linux-rockchip
tlwoerner has quit [Ping timeout: 265 seconds]
kevery has quit [Ping timeout: 246 seconds]
kevery has joined #linux-rockchip
apritzel has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
apritzel has quit [Ping timeout: 260 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
kaspter has quit [Ping timeout: 260 seconds]
damex has quit [Ping timeout: 265 seconds]
damex has joined #linux-rockchip
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-rockchip
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-rockchip
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
yann has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
warpme_ has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
ldevulder has quit [Ping timeout: 264 seconds]
kevery has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
archetech has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 245 seconds]
ldevulder_ is now known as ldevulder
kevery has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
damex_ has joined #linux-rockchip
stikonas has joined #linux-rockchip
apritzel has joined #linux-rockchip
ldevulder has quit [*.net *.split]
damex has quit [*.net *.split]
vstehle has quit [*.net *.split]
macromorgan has quit [Ping timeout: 260 seconds]
vstehle has joined #linux-rockchip
kaspter has quit [Ping timeout: 245 seconds]
matthias_bgg has quit [Ping timeout: 256 seconds]
<yann>
narmstrong: just noticed armbian has a patch/u-boot/u-boot-rockchip64-mainline/sdmmc-force-fifo-mode-in-spl.patch for 2020.10 - not sure it is related to your problem but may be worth checking
stikonas has quit [Ping timeout: 244 seconds]
matthias_bgg has joined #linux-rockchip
stikonas has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery has joined #linux-rockchip
ldevulder_ is now known as ldevulder
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<narmstrong>
yann: thx for the pointer !
maciejjo has joined #linux-rockchip
adjtm_ has joined #linux-rockchip
adjtm has quit [Read error: Connection reset by peer]
<yann>
rtp: I got the nanopi-m4 to work once this morning, with what should be the u-boot armbian version including all their patches - except when trying again the problem was here.
<yann>
Taking the problem the other way round, I'd like to use the armbian-built uboot on my yocto-generated sd; but then armbian does not setup partitions for idbloader and uboot.itb, so I took their whole start of sd (dd skip=64 count=32704) and transfered that to my SD (dd of=/dev/sda seek=64) and it worked (but here again I did not bother booting twice, and after testing other things and redoing this test the problem is there too...)
<robmur01>
IIRC I had to bodge the eMMC frequency down (50MHz?) in U-Boot to get my NanoPC-T4 to boot reliably, although that was quite a while ago now - no idea if it's been addressed upstream since
tlwoerner has joined #linux-rockchip
<yann>
robmur01: the fun is, the armbian image does boot reliably here
<yann>
robmur01: that's v2.3, it does have this patch. Anyway my cycle does unplug usbc power / remove sd / reflash / insert sd / plug power, so it should not be warm reset, unless the board gets enough power through serial rx/tx or hdmi :\
<robmur01>
yeah, I figured that was old enough that it shouldn't be relevant any more; just double-checking :)
<yann>
I'm also puzzled by my little "dd armbian boot onto yocto sd" experiment apparently nuking the GPT somehow - the host reports this once the overwrite is done, and does not expose a single partition any more: https://pastebin.com/CzXrPSar -- isn't the primary GPT header within the first 64 blocks ?
archetech has quit [Quit: Konversation terminated!]
<yann>
hm, in fact the GPT warning is just the same as after flashing the yocto image, nothing bad on that side. Not sure *why* I had this partition disappearance at one point - just did a new test: flash armbian, flash yocto over it, flash armbian boot over it, check the latter with cmp. No GPT mangling, boot OK. Power cycle, boot KO.
* yann
screams
Jmabsd has joined #linux-rockchip
<Jmabsd>
Hi all - i have a question: from a RK3399 SBC, if you de-solder the eMMC and the WIFI chip, will the SBC boot as usual still?
<Jmabsd>
I presume yes, but can you confirm
swiftgeek has joined #linux-rockchip
<rtp>
yann: this power domain issue is kind of random as you can see
<yann>
rtp: it strikes me that the armbian is not random at all, never saw it failing
<Jmabsd>
adjtm_,afaerber,apritzel,arnd,ashleee,azend,cp-,daniels,hanetzer,indy,hipboi,leming,lerc,maz,midnight,mrueg,rtp,steev: big apologies for disturbing, if you have any thought about this one let me know^
<cp->
?
<Jmabsd>
cp-: from a RK3399 SBC, if you de-solder the eMMC and the WIFI chip, will the SBC boot as usual still?
<hanetzer>
Jmabsd: very poor manners. and wifi, probably, emmc, depends on how the bootpath is set up.
<indy>
hanetzer, Jmabsd it should at least be 'bootable' using usb
<cp->
If Uboot is pointing to the eMMC you would be out of luck
<Jmabsd>
exactly, i want to boot via USB or SD memory card
<Jmabsd>
hmm. uboot is on a.. ROM? hm
<indy>
why desolder emmc?
<hanetzer>
why not just zero out the emmc? then if you want to use it later, you can.
<Jmabsd>
indy: i just don't want it
<Jmabsd>
the FriendlyArm NanoPC T4
<indy>
erase content
<cp->
Jmabsd: it depends , it can be on the eMMC itself
<cp->
but that level is not accessible easily by you
<phh>
indy: I have to admit that last time I searched in the TRM, I couldn't find it
<yann>
rtp, robmur01: (with yocto sd + armbian uboot) looks like I never see the problem when booting with HDMI unplugged (I can un/re/plug at will after boot). Makes me suspicious that in the cases where I was successfully booting, the screen would have been in low-power or similar (each time the board had been unplugged for some time)
<indy>
phh, even trm for rk3399 is public sgrf is poorly documented (not at all :) ) and same for otp
<cp->
The point I am missing is why an SD Card would be safer
<cp->
there is the same problem with an SD card
<cp->
if you go to the level of things
<Jmabsd>
cp-,indy,phh: so what is your final verdict, can I just remove the eMMC chip from the RK3399 SBC? :)
<Jmabsd>
and it'll boot from microSD/USB seamlessly?
<phh>
indy: yeah. I guess publicly-available vendor tools can answer this question, but it might require reverse-engineering...
<cp->
no
<yann>
rtp, robmur01: uh oh, I still sometimes get it after some time it seems, maybe when the screen blanks out
<cp->
if the SoC is not setup for this
<cp->
at the lowest level the SoC will boot from a UART first
<indy>
Jmabsd, if you have there proper u-boot you can simple change order using setenv and saveenv in uboot prompt
<cp->
OTP is really funky on the RK3399 AFAIK
<macromorgan>
BROM determines the boot flow and it's hard coded. As long as the "magic" bits to start the process, i.e. the TPL/SPL is missing from the emmc it should jump to the next device in the list
<indy>
cp-, really? is think trm regarding bootrom and boot process is stating emmc/spi and sd (can't recall in which order)
<cp->
right
<cp->
macromorgan: is correct
<phh>
I didn't thought it would boot on UART actually
<cp->
the problem is what are fused in the SoC
<cp->
if anything
<Jmabsd>
cp-: was the "No" to my questoin?
<Jmabsd>
indy,*: if I remove the eMMC first, is there any risk the RK3399 is bricked?
<indy>
does it have spi flash?
<cp->
it won't be bricked if you can resolder it without destroying :)
<cp->
indy I do not know your board
<cp->
Jmabsd:I meant
<Jmabsd>
indy: see the PCB photo i referenced
<Jmabsd>
cp-: no resoldering!...
<robmur01>
sigh, NanoPC-T4 literally has a button to disable the eMMC during the boot process in case you want the boot ROM to ignore a bootloader there and failover to the SD card :/
<cp->
there you go
<robmur01>
the boot process is pretty well documented in the manual and on the Rockchip wiki
<indy>
Jmabsd, see page 17, boot button ties emmc d0 to gnd, so it will look like emmc is out and will boot from sd card or switch to usb protocol
<Jmabsd>
yey!
<Jmabsd>
indy: which will it try first, SD or USB (now that eMMC failed)
<indy>
sd
<Jmabsd>
cool! and then if it does not find a valid uboot on SD, it tries USB
<Jmabsd>
cool!
<rtp>
yann: the iommu backtrace is when is display is blanked/suspended but the messages about not being able to put the vopl in idle is at boot iirc
<Jmabsd>
indy: ok so simply removing eMMC via heat gun will *not* brick then correct?
<indy>
Jmabsd, but not usb in host mode, but usb otg
<yann>
rtp: on my side they happen together, in both cases
<Jmabsd>
indy: ah an awkward unusual USB mode - i see. so really just, boot off the SD memory card then?
<indy>
Jmabsd, no, but better way to test it is to short emmc using boot buton and put sdcard in
<indy>
no was to previous question, yes to last question :)
<Jmabsd>
indy: wait what is your point about "look like emmc is out" because "d0 to gnd"?
<indy>
it 'shorts' emmc's d0 pin to ground, same like shorting pin on spi flash to get to recovery mode
<yann>
Jmabsd: wouldn't you be better of by just shorting the boot button, then ?
<Jmabsd>
indy: ah. removing the eMMC has a consequence in terms of electricity that causes the RK3399 to boot in "recovery mode" on every boot, and that causes it to boot off SD ?
<Jmabsd>
yann: you mean if the boot button on the SBC is always trigged, it will always boot off SD memory card as primary boot option?
<indy>
you must keep it pressed while powering it up
<robmur01>
yann: I'm back to suspecting some kind of race between vopb going idle and inadvertently pulling the power (and/or clocks?) from vopl...
<robmur01>
Jmabsd: use the button to boot from SD once, dd zeros over the eMMC, job done. Then there's no valid boot signature and it'll automatically try to boot from SD every time
<yann>
robmur01: I mean, if Jmabsd wants to be 100% sure the emmc will never be used (for whatever reason, not my problem), he can just short the button solder pads so it will effectively appear as "always pressed"
<yann>
robmur01: damned, now every boot I'm triggering does work
field^Mop has joined #linux-rockchip
<robmur01>
sure, but all the button does in practice is corrupt transferred data slightly (by forcing bit 0 to 0), which is sufficient to defeat the bootloader signature detection, but isn't exactly "disabling" the eMMC
Jmabsd has quit [Read error: Connection reset by peer]
<robmur01>
race are always conditions fun :P
camus has joined #linux-rockchip
kaspter has quit [Ping timeout: 265 seconds]
camus is now known as kaspter
Jmabsd has joined #linux-rockchip
<Jmabsd>
yann,indy: interesting so your argument is that soldering the "boot" button in place would have the same effect as desoldering the eMMC. well.
<Jmabsd>
at least good to know.
<Jmabsd>
thank you a lot all for your input! i may try to desolder the eMMC a bit later
<Jmabsd>
will let you know the outcome
<Jmabsd>
the WIFI, is it actually connected internally via USB? - if so desoldering it should be no problem too clearly
<indy>
Jmabsd, that boot button is there
<indy>
Jmabsd, accoring schematics
<indy>
Jmabsd, well wifi chips are mostly hooked to sdio ports
<indy>
as using usb3 for usb2 based wifi chips is waste of usb3 port
<yann>
Jmabsd: just disable the wifi/sdio nodes in the dts and the kernel won't even know there's a wifi chip
<indy>
and sdio speed and wifi speed match more
<Jmabsd>
better desolder.
<indy>
Jmabsd, desoldering something on ~ $140 board and $40 board is difference
<indy>
better is to zero emmc
<yann>
Jmabsd: using a bazooka to kill a mosquito is likely to have side effects
<Jmabsd>
lol.
<indy>
even you have uboot on sd using saveenv on rk3399 board needs emmc for storing u-boot environment
<Jmabsd>
let's desolder.
<indy>
Jmabsd, it is your board, i just shorted spi flash on rockpi and using rkdeveloptool loaded zeroed image to spi
<indy>
and same for emmc
<yann>
Jmabsd: just be ready to buy a new board :)
<indy>
yes
<indy>
Jmabsd, you have been warned :)
matthias_bgg has quit [Ping timeout: 260 seconds]
<indy>
if you really need to practice desoldering using heat gun, take some already dead board
<DuClare>
pft desoldering is for kittens. real tigers remove the chip with a sledgehammer
kevery has quit [Ping timeout: 260 seconds]
kevery has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
<Jmabsd>
indy,yann: yeah using a heat gun could potentially mess the board
<Jmabsd>
let's see
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
<yann>
robmur01: at least uboot 2020.10 makes a real difference over 2020.07: it allows me to boot with HDMI not plugged, and plug it afterwards to get a working HDMI
<Jmabsd>
indy,yann,cp-,*: many warm thanks again for your input on this one. Super interesting. thanks again it made a big difference. i emailed with Friendlyarm before and eventually now they tell me they will not sell me a modded board, so asking you helped me understand if modding the board myself is viable at all - and you say it is, as long as I don't accidentally destroy the PCB - so , great. also if you yourself talk to SBC manufacturers,
<Jmabsd>
remember to tell them always that WIFI and flash should always be "killswitch"eable and preferably physically removable, for security.
<cp->
that part I do not understand
<cp->
the whole point of eMMC is to be SMC
<cp->
granted Odroid and some others are making mini PCBs with eMMC
<cp->
and connected with some tiny connectors
<cp->
but really that solution is so flimsy
<cp->
certainly the boards we make (not RK3199 based) do not need this
<cp->
since we can boot them from whatever we want
<cp->
But then again our SoCs are not Chinese SoCs
<yann>
physically removable makes little economic sense, except like Odroid does, for making the basic board cheaper while still allowing emmc. Killswitch OTOH seems to make sense for a SBC
<cp->
I agree about the Kill Switch
<cp->
but being concerned about Virus or some Malware in eMMC is probably not a valid concern
<cp->
if you are worried about this kind of things then you should probably more worry about Malware inside the SoC Boot/Factory MCUs
<cp->
because there are tons of them in the SoC
<cp->
and these are lot sneakier threats than an eMMC controller
<cp->
especially when the SoC is Chinese
<Jmabsd>
cp-: you want eMMC to be pluggable, if anyone wants security
<Jmabsd>
the issue with a computer is you have no idea how many backdoors there are
<cp->
Though probably it could be argued that the same shenanigans could probably happen in US silicon
<cp->
when the target warrants it
<Jmabsd>
yann: the utility is security, not economy
<Jmabsd>
triple price for the SBC is OK
<cp->
Jmabsd: I disagree
<cp->
Jmabsd: your SD card has the same problem,
<Jmabsd>
cp-: tons of sneaky threats yes
<cp->
or your USB key
<Jmabsd>
though eMMC would let a virus install itself permanently
<cp->
That part I do not get
<yann>
Jmabsd: then first use an opensource SoC and verify the transistors map the design
<Jmabsd>
so at least without wifi and flash, the SBC is at least "deterministic"
<Jmabsd>
yann: sure with RISCV that is coming over time
<Jmabsd>
we're not quite there yet
<DuClare>
I wonder how common counterfeit emmc are
<DuClare>
counterfeit sd cards are a real thing :/
<cp->
Jmabsd: I could write a SOC MCU malware watching the SPI bus or I2C or whatever
<cp->
that could upload some code to anything you connect
<cp->
and you would not know it
<Jmabsd>
wait MCU is which part of the SoC
<yann>
Jmabsd: and that would not prevent a rogue vendor chip (or whatever rogue infiltrating an honest vendor, even) to add sneaky stuff inside without you knowing
<Jmabsd>
well at least such malware will disappear with reboot
<cp->
in fact these MCUs inside the SOCs are used to do exactly this kind of things when used in verification
<Jmabsd>
yann: well at least you can remove all flash to reduce the damage a bit
<robmur01>
anything a malicious eMMC could do, a malicious SD card could just as likely do; they're pretty much the same basic thing in different packaging
<cp->
Jmabsd: there are few MCUs inside your RK3199 :)
<Jmabsd>
robmur01: at least you can verify the sd card's content externally
<cp->
RK3399 sorry
<robmur01>
at that point you may as well stick with 8-bit machines you can build out of discrete logic...
<Jmabsd>
cp-: MCUs like what
<cp->
ARM MCus
<robmur01>
Jmabsd: by delidding it and probing the raw NAND?
<cp->
that control the I2C buses etc...
<yann>
Jmabsd: what cp- says, is that there are tons of flash units in the SoC, driving MCU's you don't know about - that is a greater threat that flash and CPUs you know about
<cp->
yep
<yann>
there is at least a documented CortexM in the rk3399, see the docs
<cp->
Jmabsd:your perception of security by removing eMMC is a false one
<robmur01>
an SD card has the same kind of internal controller doing flash translation etc. as an eMMC, IIRC some have even been identified as using ARM9 cores
<cp->
there are more than 1
<Jmabsd>
yann: oh, the RK3399 SoC contains various flash chips?
<Jmabsd>
writeable?
<cp->
yes
<cp->
and yes
<Jmabsd>
oh dear. same with Raspberry Pi?
<Jmabsd>
BCM-something
<cp->
not just RK3399
<cp->
but any ARM SoC
<cp->
yes
<robmur01>
AFAIK the RK3399 SoC itself only contains SRAM and some OTP/efuse stuff
<Jmabsd>
robmur01: right!!!!!!!!!!!!!!!!!!!!!
<Jmabsd>
yann,cp-: I believe robmur01 is right
<Jmabsd>
no flash in the RK3399
<cp->
IMX8 IMX6 Armada 38X etc.. all of them
<Jmabsd>
this is why removing the eMMC is useful
<cp->
robmur01: you are wrong
<cp->
it is just not documented
<cp->
for the mere mortals
<yann>
cp-: we reach a point where pointers to the Real Stuff will be useful ;)
<cp->
real stuff ?
<yann>
some concrete data about those MCU
<yann>
the only thing I can point to is the M0 described in chapter 6 of rk3399 TRM part 1, and it does not describe any kind of associated flash
<cp->
this is an example that I debugged and fixed personally
<cp->
this register is not documented anyway
<cp->
this register is not documented anywhere
<cp->
what happened is that marvell validation engineers had left verification MCU slave hardware on when the stuff went to mass production
<cp->
and after lenghtly and painful debugging and proving to the designers , we finally made them admit that the MCU was still on
<cp->
originally they had documented this as silicon design bug (Won't fix)
<robmur01>
yeah, most SOCs have lots of debug and design-for-test features that are used for validation and production testing and never meant to be touched by customers... but how is that evidence of secret flash memory in RK3399?
<cp->
oh there is no secret flash
<cp->
there is secret flash on the MCU
<cp->
if you want to call it secret
<cp->
it is not secret just not documented for customer use
<yann>
that's a shame they don't document such things, anyway
<cp->
So the reason I am saying that is that the ARM IP which is sold to vendors is the same for everyone
<cp->
and it is a requirement
<cp->
now some vendors will implement this in different ways but overall they all have the MCUs
<robmur01>
can you even fab flash cells on the kind of process used for high-performance SoCs? If they went to the bother of putting some in it seems odd that they wouldn't take advantage of it for the bootloader/firmware/etc.
<cp->
you can
<cp->
at least on Marvell you can
<cp->
that is how they enable and disable features
<cp->
and sell different versions of chips
<cp->
which are really the same chips
<cp->
NXP does that too
<cp->
and so does Broadcom
<cp->
I must admit that I do not have the information for RK3399 though
<cp->
but I'd be surprised if they did not
<yann>
robmur01: with uboot 2020.10 I can boot the nanopi-m4 with HDMI unplugged, then after plugging I just have to "xrandr --output HDMI-1 --auto" and things seems to work
<yann>
that does not explain how armbian does to avoid the problem, though
nomis has joined #linux-rockchip
vagrantc has joined #linux-rockchip
<yann>
rtp, robmur01 : also disabling vopl in the dts appears to help (though I can't say for sure given the reproducibility issues - at least 100% OK (booting direct to Xorg with HDMI plugged), with uboot 2020.10 till now)
matthias_bgg has quit [Ping timeout: 256 seconds]
<robmur01>
well, the issue itself looks like that of trying to probe vopl while it's unexpectedly powered off, so I would indeed expect that to be obviated by disabling ;)
<rtp>
well,disabling vopl is not a good option, at least on my platform, since the display is connected on vopl :)
damex_ has quit [Quit: damex_]
macromorgan has quit [Read error: Connection reset by peer]
maciejjo_ has joined #linux-rockchip
kevery has quit [Ping timeout: 244 seconds]
swiftgeek has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
maciejjo has quit [*.net *.split]
<yann>
rtp: I was under the impression that the 3 video outputs (hdmi, dp, edp) could be driven by both vopb and vopl, is it not the case ? that ought to be the case at least for hdmi and dp, I'm not familiar with edp at all, is that one only possible to drive through vopl ? in that case, maybe disabling vopb instead for such a platform could provide a similar workaround ?
tlwoerner has joined #linux-rockchip
swiftgeek has joined #linux-rockchip
kevery has joined #linux-rockchip
macromorgan has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
tuxd3v has quit [Remote host closed the connection]
tuxd3v has joined #linux-rockchip
<yann>
at least for a platform with a single HDMI output it makes sense to just activate a single VOP
damex has joined #linux-rockchip
damex has quit [Read error: Connection reset by peer]
damex_ has joined #linux-rockchip
damex_ has quit [Read error: Connection reset by peer]
damex has joined #linux-rockchip
damex has quit [Read error: Connection reset by peer]