<vagrantc>
depthcharge on the veyron-speedy was unable to load a kernel+initrd > 16MB, if i recall correctly ... or maybe it was > 32MB ... in any case ... that was a limitation that made me want u-boot
<amstan>
that's not right, might have been overlooked, or, it might use gru
<asciilifeform>
nor does this seem to be the whole shebang, iirc the thing has a uboot layer on top of 'depthcharge'
<amstan>
vagrantc: we don't use initrds, i guess that's why we haven't noticed such a bug
<asciilifeform>
or at any rate something that executes prior to depthcharge
<vagrantc>
amstan: indeed
<amstan>
asciilifeform: one thing you can try, and this will get you as close as possible to a bob binary
<vagrantc>
though i'm admittedly more familiar with u-boot anyways
<amstan>
asciilifeform: and this is also how i would build the firmware for one of these devices
<amstan>
it's kinda annoying, but it guarantees all pieces are there (including the compiler version)
<amstan>
at the repo init step, you probably want to mention a specific branch, for bob you need firmware-gru-8785.B
<asciilifeform>
the vendor seems to love monkeying with pinouts; 'close' likely won't cut it
<amstan>
then there's an emerge command with about 5 packages you can do and you'll get pretty much the same binary that's on that device (minus signing keys, but i doubt you care)
<asciilifeform>
i intend to cut out all of the tivoization crapola.
<amstan>
sigh.. i doubt tivos ever had developer mode/write protect allowing you to install whatever you wanted on your device
<amstan>
you're after the last 1% here, replacing the bootloader
<asciilifeform>
by all accounts tivo was ~easier~ to fully wash in practice than this box
<amstan>
because tivos did not care about security
* vagrantc
really likes the write protect screw on the veyron-speedy
<amstan>
vagrantc: write protect screws were awesome and simple, i wish we kept them
<asciilifeform>
amstan: i did find the bob dts previously; but this is definitely not 100% of what's needed to get the rom built
lurchi_ is now known as lurchi__
<asciilifeform>
it is only needed for kernel , afaik
<amstan>
asciilifeform: i mean.. you can use the dts to tell pin differences between the hardware
<asciilifeform>
right. it doen't reveal whatever magic that bootloader does on top of the rk3399's vendor example
<asciilifeform>
to get e.g. lcd going
<amstan>
vagrantc: but now we can in theory do more without them (like fully debug a device without opening it up)
<asciilifeform>
c101pa doesn't have the screw, i actually spent days looking for it in vain, until someone revealed to me that the same boobytrap is defused by pulling the battery, on this box
<amstan>
sorry about that, it should be documented better
* vagrantc
envisions tiny poisoned darts shooting out of a device
<amstan>
vagrantc: yeah, right?
<asciilifeform>
lol
<asciilifeform>
ideally i'd like something that builds with ordinary linux toolchain, like classical coreboot, rather than having to spend a month setting up google's horror show
<asciilifeform>
but i'll take what can be had. tho the 'bob' dir is conspicuously missing from all of the repos.
<asciilifeform>
if amstan or somebody else, has it, or knows where it lives -- would muchly appreciate. ditto the schematics. many thanks, folx. i'ma brb.
<asciilifeform>
so.. is the rom from-the-ground build process actually documented somewhere ? i dug through the links, all i see so far is fragments of src
<amstan>
I think this is doable with a public chroot, i might be wrong though
<amstan>
you might want to try the mini overlay too, no need to download sources for things you won't need
<asciilifeform>
where do i get a copy of the tree that actually has build/board/bob ?
<amstan>
scroll up, none of them will
<amstan>
gru is the folder you're looking for
<asciilifeform>
aa ok
VargaD_ has joined #linux-rockchip
Pix` has joined #linux-rockchip
VargaD has quit [Ping timeout: 250 seconds]
VargaD_ is now known as VargaD
Pix` is now known as Pix
Pix has quit [Ping timeout: 250 seconds]
<asciilifeform>
re: sd card : still seems to me that the easiest ( least solder ) pill would be to find all of the discrete regulators and perma-connect their enable pins , so as to boot forever from sd; then i can finally bolt the box closed again
<amstan>
they might be very tiny bga devices
<asciilifeform>
they seem to all have test pads exposed tho.
<asciilifeform>
lotsa test pads in this board.
lurchi__ is now known as lurchi_
<asciilifeform>
i even have a microsd breakout board, can power it externally; still gotta enable the sd_io buffer however
<amstan>
there's no buffer
<amstan>
all the pins should go directly to the soc
<amstan>
so powering externally will work
<asciilifeform>
what's sd-io-power-en then
<amstan>
there's 2 voltage rails on the sd cards
<asciilifeform>
1.8 and 3.3, right
<amstan>
one of them switches between 0 and 3.3V
<amstan>
the other one (IO) can be 0, 1.8V or 3.3V
<amstan>
this gru schematic i have in front of me says 3.0, so bob is probably the same
<amstan>
you have to be careful to not externally power the io to 3.0V when the soc sets the muxes to 1.8V, because now you'll backpower the 1.8V internal bus to 3.0V
<asciilifeform>
yea magic smoke
<amstan>
i wouldn't do this if i were you, it's much simpler to just stick with the spi flash
<asciilifeform>
pretty weird package of spi rom tho, no convenient place to solder probes
<amstan>
we've heard of school kids doing this too btw
<asciilifeform>
with every other cbook it is trivial, with crocodile clip around spi rom
<asciilifeform>
this one's the headache.
<amstan>
the thing about warm reset is nothing new though
perr has joined #linux-rockchip
lurchi_ is now known as lurchi__
vagrantc has quit [Quit: leaving]
nots has quit [Quit: Page closed]
perr has quit [Remote host closed the connection]
perr has joined #linux-rockchip
<beeble>
asciilifeform: have not read the complete backlog. but the spi content will not work on the sd card. there is a difference in the format and the first stage loader has to prepared differently
<asciilifeform>
beeble: specifically, how ?
<asciilifeform>
( is this documented somewhere? datasheet doesn't mention any difference )
perr has quit [Remote host closed the connection]
<beeble>
asciilifeform: u-boot mkimage does implement it
<beeble>
but no idea about coreboot. never used it
<beeble>
iirc it is mainly alignment stuff. compare the rksd with the rkspi targets
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 248 seconds]
vstehle has joined #linux-rockchip
LongChair_ has joined #linux-rockchip
perr has joined #linux-rockchip
perr has quit [Changing host]
perr has joined #linux-rockchip
Omegamoon has joined #linux-rockchip
lukasz_ has joined #linux-rockchip
return0e has quit [Remote host closed the connection]
ayaka has quit [Ping timeout: 256 seconds]
ayaka has joined #linux-rockchip
return0e has joined #linux-rockchip
LongChair_ has quit [Quit: Connection closed for inactivity]
Kamikaze84 has quit [Quit: Page closed]
matthias_bgg has joined #linux-rockchip
Largeprime has quit [Ping timeout: 260 seconds]
Largeprime has joined #linux-rockchip
lukasz_ has quit [Quit: Leaving]
adj_ has joined #linux-rockchip
adj__ has quit [Read error: Connection reset by peer]
nighty- has quit [Quit: Disappears in a puff of smoke]
ujerry has quit [Quit: Connection closed for inactivity]
Kamikaze84 has joined #linux-rockchip
lukasz_ has joined #linux-rockchip
lukasz__ has joined #linux-rockchip
lukasz_ has quit [Read error: Connection reset by peer]
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
nighty- has joined #linux-rockchip
phh|new is now known as phh
adj_ has quit [Quit: Leaving]
cnxsoft has quit [Quit: cnxsoft]
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
Kamikaze84 has quit [Ping timeout: 260 seconds]
perr has quit [Quit: Leaving]
adj_ has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
<asciilifeform>
looked through the strings in my c101pa's rom image; found 'Google_Bob.8785.206.0' , which does not correspond to anything i was able to find in the sources linked yesterday
<asciilifeform>
and 'gru' appears to be the 12 inch asus box, rather than the c101pa
<asciilifeform>
( it ~does~ appear to use the gru ddr ram initializer, though )
<adj_>
amstan said yesterday that 'gru' is the reference design, 'gru_gru' the prototype of the reference design
<asciilifeform>
right
<adj_>
gru_kevin is samsung chromebook plus, gru_bob is c101pa
<asciilifeform>
i've been looking for a set of sources that would correspond exactly to my unit, complete with version strings; so far no luck
<adj_>
asciilifeform, I'm sure if I will choose c101pa or cb plus
<asciilifeform>
paulk-gagarine: the item i want to build, is simply the minimal coreboot needed to init the rk3399 and load a stock uboot (which can then load ordinary linux kernels from ordinary partitions)
<paulk-gagarine>
asciilifeform, get upstream coreboot
<paulk-gagarine>
if you don't want vboot/depthcharge there isn't much more you need
<paulk-gagarine>
(actually even depthcharge and vboot are already integrated in upstream coreboot)
<asciilifeform>
rk3399 needs some kind of init magic for the ram; then the c101pa board in turn needs own magic (some of it, documented in the dtd link last night by amstan ) to turn on lcd etc
<asciilifeform>
i looked for these in mainline coreboot, did not find any mention
<beeble>
there is no magic for the ram. ram init is available in coreboot and u-boot (on u-boot lpddr is missing iirc)
<paulk-gagarine>
asciilifeform, yeah it's all in coreboot
<paulk-gagarine>
you don't need to do anything else than build it
<paulk-gagarine>
it was in upstream coreboot before the device was even released
<asciilifeform>
somehow i had the notion that the init is specific to the max frequency of the ddr chips used on a given rk board
<asciilifeform>
in my cbook rom it is in the very 1st page of the rom, even prior to the boot sig
<asciilifeform>
hm according to rockchip arm8 won't run without at least a stub tee
<beeble>
you need atf thats available at github
<beeble>
upstream fully open source
<asciilifeform>
neato.
<asciilifeform>
i'll try it as soon as i get the debrick probes soldered in. ( will still need, on top of this, to build the item that inits lcd on this particular board )
<asciilifeform>
beeble: the factory rom, interestingly, doesn't have atf. what it has is a 1kb block (presumably stub) containing string 'TEE'. i'd actually rather have ~this~, than the half-MB turd from arm; if i can find the src for the stub.
<asciilifeform>
(possibly i missed something, all i got is the quite fragmentary vendor docs + naked eye hexdump browse of rom)
<beeble>
as long as you call everything crap and turd you don't know or understand i'm really not that interested in helping you anymore
<asciilifeform>
beeble: it's your call.
<asciilifeform>
point being, i do not want a ~more~ complex rom than the vendor's original.
matthias_bgg has quit [Ping timeout: 265 seconds]
<asciilifeform>
( and it so happens that i understand the 'trustzone' item quite well; and specifically would like a box where it is deactivated, or if impossible to fully deactivate -- neutered. if i wanted an always-on hardware rootkit, i'd buy an intel board... )
<Ke>
why is not kernel a problem then, it runs at a privilege level where your userland can't touch it
<asciilifeform>
arm7 booted up just fine without this item; but for some reason on arm8 , it is mandatory ('for your own good', presumably)
<Ke>
trustzone is just one more level
<asciilifeform>
Ke: resembles intel's ME.
<Ke>
but you can control what's running there
<Ke>
it's a huge difference
<asciilifeform>
right, so i'd like to find the minimal that satisfies the thing and gets it to boot ( if it is impossible to shut the thing off entirely )
<gab>
nah, trustzone is not like intel ME
<gab>
for starters it runs on the same CPU and arch as your main OS
<asciilifeform>
gab: from my reading of the vendor docs, i got the impression that it has own core ?
<gab>
if you want something like intel ME, look at the extra embedded cortex-M cores that are used for power management (like in amlogic's SOC, running with binary blob)
<Ke>
do you guys really think it's relevant, whether the core is the same or different
<asciilifeform>
Ke: i -- don't
<gab>
nope, trustzone is just a privileged mode of your normal cortex core
<gab>
and that means it usually runs only when the main OS requests it to (through the SMC instruction)
<Ke>
gab: but if your bootloader is locked, it could be used among other things to do bad things just like ME
<gab>
(unless it's designed to have its own scheduler and threads running with its own timer interrupt)
<Ke>
anyway it's not the case with many rockchip devices anyway
<asciilifeform>
gabs (again i could be mistaken, not having a year to dedicate to studying the thing) it is able to service interrupts
<asciilifeform>
* gab:
<gab>
yes it is
<asciilifeform>
so, in principle, it can run without os explicitly requesting it.
<gab>
I was talking from an architectural point of view
<gab>
intel ME is more akin to a PMIC than what trustzone actually is
<gab>
afaik you don't have that on rockchip btw
<asciilifeform>
that's the reason i went into rockchip to begin with.
<gab>
(or it's an external pmic, so that's way less intrusive)
<asciilifeform>
seems to have a minimum of mystery blob, vs other arm64 products.
<asciilifeform>
if another vendor makes a box with even less -- i will buy those.
<gab>
rockchip is probably the lesser one
<asciilifeform>
that's my impression so far.
<gab>
not sure about allwinner, but it has blobs too
<gab>
amlogic is the worst in my opinion
lukasz__ has quit [Quit: Leaving]
<gab>
(especially with that frequency-cheating bl30 thing)
<asciilifeform>
a while back, i was able to get rk3328 ( http://www.loper-os.org/?p=2295 ) to boot, needed 2 vendor blobs: one being the 'RK32' ram init from rockchip; other being the 'atf' (from arm)
<gab>
atf is open suorce
<gab>
source*
<gab>
ram init is tiny
<asciilifeform>
right
<gab>
(not even sure if you still need the ram init blob with mainline uboot)
<asciilifeform>
my long-term goal is to have a box where the user can not only read , but have a reasonable shot at understanding , 100% of the loaded code.
<asciilifeform>
gab: last i tried, rk3328 was not yet merged into mainline.
<asciilifeform>
re: atf: apparently i was wrong earlier, bl31 is in fact present in the vendor's rom.
kaspter has quit [Read error: Connection reset by peer]
<Ke>
marvell armada 8040 again runs with opensource atf, but you lose some powermanagement functionality
kaspter has joined #linux-rockchip
<Ke>
however it's obsolete ATF branch that lags with spectre updates and whatnot
<asciilifeform>
Ke: rockchip is said to run properly with open src atf , but i have not yet tried
<Ke>
yup. it should
<Ke>
even debian has bootloaders packaged
<asciilifeform>
arm7 (at least the ones i worked with, from e.g. marvell co.) were nice, booted up 100% blobless
<gab>
arm7 doesn't need ATF because most platform init stuff used to be vendor-specific
<gab>
ARM tried to unify it with armv8
<gab>
(but as usual vendors do as they please...)
<asciilifeform>
fwiw my arm7 ('pogoplug') ran from a 100%-built-from-src-bloblessly firmware.
<asciilifeform>
can't comment re: other vendors.
<gab>
even then, you also need to consider that most vendors have an in-chip bootrom that you usually can't access or modify
<asciilifeform>
the maskrom ? sure
<asciilifeform>
microcode, also
<gab>
the bootrom is not microcode
<asciilifeform>
well yes, separate items
<asciilifeform>
( older folks sometimes call a maskrom boot code 'vertical microcode' )