<adj_>
asciilifeform, doesn't the link to google in your own blog post says that "case closed debugging" is currently only supported in Ryu (Code name for the rk3399 based Scarlet tablet)?
<adj_>
maybe I didn't understand it
lkcl has joined #linux-rockchip
<adj_>
is this debugging mode the same as the audio jack one but with the "analog audio" sent through the USB type-C Accessory Mode?
<adj_>
or is this a spacial "Alternate Mode" of the same standard?
<adj_>
special
<asciilifeform>
adj_: possibly i misread, but i understood it to refer to the host end
<adj_>
what do you say that it refers to the host? the Ryu requirement?
<asciilifeform>
and earlier this week a fella here suggested that usbc uart will work with this particular machine, so i went to try.
<asciilifeform>
adj_: aha.
<asciilifeform>
i don't need google's debug soft as such, only raw rockchip uart, supposing it is actually present on that connector.
<adj_>
my understanding is that only works right now to debug Scarlet and it uses the audio signal (as in the audio jack debugging) but through the "Accesory Mode" that sends analog audio
<adj_>
asciilifeform, in my link: "Accessory Mode support by phones/notebooks aren’t mandatory, so consumers will need to read the fine print on their new electronic device to determine if audio over USB Type-C is supported or not."
<adj_>
you could try to get audio with "Accessory Mode" and try to debug like with the more usual "audio jack" debugging
<asciilifeform>
all i had to go on was that one hint; i was not able to find any evidence that the usbc uart mode exists on this box; chances are that it doesnt
<adj_>
probably doesn't
<asciilifeform>
adj_: i strapped the plug for 'accessory mode' but the signal that appears on sbu has no resemblance to uart, and doesn't trigger at all during boot
<asciilifeform>
so currently i suspect this is a dead end
florrational has joined #linux-rockchip
<florrational>
I found some goofiness online where debootstrap is run from Arch itself, allowing a Debian bootstrap that way.
<florrational>
It's silly, but so I am, so I'm trying it. It seems to be working, too! :D
florrational has quit [Quit: leaving]
alyssa-- has joined #linux-rockchip
<alyssa-->
(I'm not qualified ot have more than one IRC window open at a time)
alyssa--- has left #linux-rockchip [#linux-rockchip]
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
anarsoul|2 has quit [Ping timeout: 260 seconds]
grw has joined #linux-rockchip
Easyfab has joined #linux-rockchip
JohnDoe7 has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
lukasz_ has quit [Quit: Leaving]
alyssa--- has joined #linux-rockchip
<alyssa--->
(major ugh) Trying the debian mainline kernel on kevin. Depthcharge boots it (no beep), but the screen turns off immediately so I see no visible output. That said, the flash drive's indicator LED is beeping, so I know it's doing *something*.
<amstan>
asciilifeform: you probably want A9 and B4 connected to VBUS
<amstan>
A5 should be a 22k pullup to vbus
<amstan>
B5 should be a 56k pullup to vbus
<amstan>
the rest looks ok
<amstan>
good luck
xypron has left #linux-rockchip [#linux-rockchip]
lurchi__ is now known as lurchi_
<asciilifeform>
amstan: oh hey
<asciilifeform>
my cable actually works
<amstan>
\o/
<asciilifeform>
i get uarts
<amstan>
you should see 3, one of them goes to rk3399, should be RW
<asciilifeform>
lately puzzling over whether the boot spi can be rewritten via this plug
<amstan>
the other is RO, goes to the EC (pressing keys on the keyboard will print stuff on there)
<amstan>
and there's another that's kinda locked down, that's the cr50 chip that you're actually talking to
<amstan>
it can't, not yet, soonish
<asciilifeform>
i was looking at chromium's flashrom, 'raiden' module
mateo` has quit [Read error: Connection reset by peer]
<amstan>
the cr50 chip doesn't let you do that yet (you wouldn't want anyone randomly going to a laptop and replacing your firmware, would you?)
<asciilifeform>
seems like it accesses the spi bus, but doesn't find the spi rom
<asciilifeform>
amstan: i thought it already has the battery pin writeprotect mechanism
mateo` has joined #linux-rockchip
<amstan>
but soon it'll have the capability to allow you to do that after you do a very lengthy unlock procedure (to simulate someone opening the case)
<asciilifeform>
so the ec's spi pins are not actually connected to the boot rom ? or does the latter have HOLD asserted ? or why can't flashrom see it
<amstan>
idk, but it's not supposed to allow you
<amstan>
not really sure how that's implemented but it might manifest itself in flashrom being confused
<amstan>
on that 3rd console you can play with the "ccd" command
<asciilifeform>
the docs for servo board mention some 'dut-control' magic that has to be carried out to enable the spi flash
<amstan>
you'll notice FlashAP and FlashEC are disabled
<asciilifeform>
any idea how to get rid of the lock ?
<amstan>
you can't, not even i can
<asciilifeform>
pretty useless console then
<amstan>
yep, that particular console is pretty useless
<asciilifeform>
apparently i'ma have to cleanse the ec firmware also ( plus it seems to do some verification of the boot rom, on its own , which from my pov is absolutely showstopper )
<amstan>
it doesn't
<asciilifeform>
then why does it have crypto maths routines ?
<amstan>
ec has no capability to read the AP firmware
<amstan>
it probably uses those crypto things to verify itself (the RW portion)
<amstan>
cr50 doesn't care about kernel vs coreboot
<amstan>
and ec has nothing to do with anything
<asciilifeform>
in ec/extra/usb_spi , stm32spi.py ( apparently, test util ? ) is able to write rubbish to spi bus , producing in ec console e.g. [71209.470072 ERROR: Must specify target]
<amstan>
the only thing which you might be witnessing right now is the lack of uart spew in coreboot, and that's because we want the firmware to execute as fast as possible
<asciilifeform>
amstan: hm. then why can't i see the typical rockchip poweron console spew (e.g. init of DDR ram etc)
alyssa--- has left #linux-rockchip [#linux-rockchip]
<amstan>
but if you compile it yourself you'll see it
<amstan>
define typical
<asciilifeform>
i assumed that it gets spat out prior to ec's init of the usb debug device
<amstan>
ec is not really involved in that, the only involvement the ec might have is near the time the ec reboots (which i doubt happened anywhere, unless you're out of battery)
<asciilifeform>
i have a rk3328 board, it does similar. and seems like all rockchip products default to 1500000 baud on warmup
lukasz_ has quit [Quit: Leaving]
<asciilifeform>
possibly this doesn't actually make a problem for me, i don't actually need the mask rom's spew for anything; but i do need to see output from vendor's demo rk3399 boot loader , once i flash it in. and seems like it ought to work, i ran the c101pa with the spi rom inhibited (using the soldered-in button from sunday) and the ec still works (i.e. usb debug console responds to commands)
<asciilifeform>
so prolly this is not an issue for me
<amstan>
what i expect you see is the reboot spew, then the first line will be [ 0.000000] Booting Linux on physical CPU 0x0
<asciilifeform>
none of my uarts show anything like your log
<amstan>
"you might be witnessing right now is the lack of uart spew in coreboot, and that's because we want the firmware to execute as fast as possible"
<amstan>
uart is disabled on shipping images for speed reasons
<amstan>
without dev mode it's supposed to execute in less than a couple of 00ms
<asciilifeform>
my box is in dev mode though
<amstan>
still disabled because there's common code paths
<asciilifeform>
any straight way to enable it ?
<amstan>
you reflash your own build
<asciilifeform>
ah so the default loader is completely silent, got it
<amstan>
yes
<asciilifeform>
ok makes sense
<asciilifeform>
ok i am satisfied with the uart, for debug of future port of mainline coreboot/u-boot . would still like a way to cleanly debrick spi boot rom. possibly if i write in a modified ec image..?
<amstan>
no! lol, the ec is not involved at all
<asciilifeform>
would quite like to avoid fragile probes, 1.8v spi burner, building a box just for bringing reset line low, etc
<amstan>
for reflashing spi flash i recomend just hooking up wires to the chip like you were originally planning, that should be pretty fullproof
<amstan>
or you could wait a couple of months until we get a secure way for cr50 to allow you to flash your firmware
<asciilifeform>
can't , unfortunately, wait, i'm on a pretty tight schedule
<asciilifeform>
i do have a em100 spi emulator, but , annoyingly, it turns out that it is not the 'pro' version, and google's linux util does not actually support it
<asciilifeform>
and on top of this, even the vendor's mswin proggy for it refuses to switch it to 1.8v
<amstan>
get an rpi, a 1.8V regulator and a buffer with a breakout board
<asciilifeform>
i ordered a 'TIAO' , similar, due in next wk
<asciilifeform>
theoretically should work.
<asciilifeform>
but this is kinda ugly.
<asciilifeform>
rather annoying, ec/debug interface clearly knows how to talk to the onboard spi, but something is inhibiting the rom
<amstan>
yes, security, it's not ready yet
<amstan>
it's one of the first devices with this closed case debugging programming method
<asciilifeform>
currently tempted to permanently tie the chip select down, see if that does it
<amstan>
we're trying to be cautious
<asciilifeform>
( i do have a few spare boards , if it smokes )
<amstan>
nice
<asciilifeform>
amstan: out of curiosity, are you at asus ?
<amstan>
google
<asciilifeform>
aaah should've guessed, lol
<asciilifeform>
does google ever publish schematics ? ( they do seem to have 'servo' published, but for some reason not the 'suzy', and definitely not the machines..? )
<amstan>
I mentioned last week that i'm working on suzyq right now
<asciilifeform>
aah
<asciilifeform>
( i only yesterday found out what the official tty plug, was called in-house )
<amstan>
the machines are a tricky subject, generally everyone involved(soc maker, odm, oem, various component makers such as wifi, audio) would have to agree
<asciilifeform>
yea this is why pretty much no full machine schems on the net
<amstan>
for the stuff around the soc you're likely to find the same topology as the other boards that have the same soc
<asciilifeform>
not sure from whom the vendors really hide, it isn't as if chinese are not already in possession of the schem, given where the boxes are built
<amstan>
but things like the EC and cr50 hookups are all secret for some reason, even though we make them
<asciilifeform>
i didn't even realize, until last night, that ec and cr50 are separate physical devices
<amstan>
pretty much every datasheet we get has "Confidential" on it, so you can go figure how secretive partners tend to get
<amstan>
ec has been a thing that we always had, but recently we added the cr50 (which confusingly also compiles its firmware out of the ec folder)
<asciilifeform>
i still don't fully grasp what the purpose of cr50 is
<asciilifeform>
other than to init the usb debug ttys
<asciilifeform>
i'd still like to find out what it is able to do; it seems suspiciously similar to intel ME for my tastes
<asciilifeform>
seems like it sits on top of the rk3399's jtag lines, and so can theoretically access ram
<amstan>
i mean... it's a separate device, the only connections to the ap is a spi bus (with ap being master)
<amstan>
no, jtag lines are not affected
<amstan>
if you don't want to use it you don't have to
<asciilifeform>
ec src suggests that they go through ec, hm, yea
<asciilifeform>
( there's a routine for preventing jtag access through sd card slot )
<amstan>
the scary part is the ccd abilities, it does have the ability to rewrite firmware
<amstan>
but that's for debugging, as you just discovered
Easyfab has quit [Quit: Leaving]
<asciilifeform>
how would one go about rewriting cr50's firmware ?
<asciilifeform>
or does it have own internal 'tivoizer' trap
<amstan>
it need to be signed, so you can't really
<asciilifeform>
i only found one 'proper' spi flash on the pcb, so i assume cr50 has internal flash
<asciilifeform>
( currently i do not even know where on the pcb is cr50, it gotta be one of the unlabeled packages)
<amstan>
yeah, it's probably a few hundred k, similar to the ec
<amstan>
it might be labeled h1
<asciilifeform>
soo, if i understand correctly, i can't actually do anything with the published cr50 source ? or even to verify that my unit actually runs a bin corresponding to said src ?
<amstan>
unfortunatelly not
<asciilifeform>
sucks
<asciilifeform>
seems like it's exactly intel me
<amstan>
if you're paranoid you can probably cut the ap spi flash and ec spi flash traces around it
<amstan>
then it doesn't really have any more impact on the system
<asciilifeform>
will board start up if i simply lift the cr50 ?
<asciilifeform>
or does it control warmup
<amstan>
probably
<amstan>
no
<amstan>
you might lose the power+refresh key combo
<asciilifeform>
i thought that was ec's doing
<amstan>
no, power+refresh is supposed to reboot the ec if the ec is stuck
<amstan>
so it has to be something external to the ec
<amstan>
we used to have a small cpld that did this, but now it's part of a hardware block inside the cr50
<asciilifeform>
cr50 is in-house product ?
<amstan>
yes
<asciilifeform>
interesting
<amstan>
yeah.. you're going to lose all the keys routed through cr50 (power, refresh column, etc)
<asciilifeform>
not clear to me, then , why bother having two ec's
<asciilifeform>
why not abolish the 'nuvoton' ec
<amstan>
there's an in and an out for cr50, so it can capture the power+refresh and only pass along the events when they're needed
<asciilifeform>
if vendor went through the expense of having inhouse ic made, not clear why to include another micro
<amstan>
because cr50 is supposed to be this secure enviroment, the smaller it is the better
<amstan>
anyway, i g2g
<asciilifeform>
ty for the hints, amstan
<amstan>
np, let me know if you're stuck on anything
<asciilifeform>
lemme know if you find out / feel like spilling the beans re: how to neuter cr50
<asciilifeform>
from my pov, it's nsa rootkit
<amstan>
i suggested that around (like silkscreen marking cut here/depopulate these resistors), but it's too tinfoilhaty to be taken seriously
<asciilifeform>
i'm not averse to cutting traces, supposing the result is still something like a working box
<asciilifeform>
but until schems come out , or i get the pcb xrayed, it is impossible to know what to cut.
<asciilifeform>
i have ready buyers for cleansed c101pa boxen lined up and waiting.
<amstan>
realistically you have to stop somewhere and just trust the hardware that you have
<amstan>
like you have to trust there's the trap disallowing you from getting to the jtag that rockchip conveniently places on the sd cards
<asciilifeform>
my whole project is , to find an arm lappy that's cleanable, and clean it.
<amstan>
or that there's no hardware backdoors in the soc itself
<asciilifeform>
if not c101pa, it'll be another.
<asciilifeform>
the fact that google felt it necessary to weld on an external fritz chip, suggests that rk3399 itself is relatively clean .
<asciilifeform>
actually i ~like~ the jtag
<amstan>
we have a custom board an sd card shape that if you plug into a firefly you'll get jtag
<asciilifeform>
if i were designing the box from scratch, i'd put it on dedicated plug
<asciilifeform>
yea but firefly is not a lappy
<amstan>
you probably wouldn't like that to be possible on a personal computer
<asciilifeform>
indeed i would very much like it.
<amstan>
even if someone else was using that jtag against you?
<asciilifeform>
i regard the concept of physical access 'vulnerability' as nonsensical
<asciilifeform>
if enemy has the machine, he can take it home, use it as boat anchor, etc.
<amstan>
true, i agree with you
<asciilifeform>
blocking off jtag, spi flash, etc. has only the effect to tie my own hands in re my own hardware that i paid for
<asciilifeform>
if in some exotic scenario you have to give the machine to an enemy for five minutes, the correct pill is epoxy, nailpolish seals, etc. , rather than tivoism.
<amstan>
asciilifeform: we have a few more barriers for physical access though
<asciilifeform>
the cr50 is fritz chip plain and simple, i can't picture what legitimate purpose there is in perma-locking the console, cr50 firmware r/w , etc
<amstan>
it boils down to "if you have very little time around someone's chromebook you shouldn't be able to get root on it. if you have time to open it up all bets are off, but until then it should be impossible"