ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log | Community GH | Rockchip GH | ML
<asciilifeform> i'm not aware that anybody's got one of these, though.
<amstan> uboot or? the c101?
<asciilifeform> a 100% working 100% degooglized , console-enabled etc bootloader for c101pa
<asciilifeform> it was my intention to slowly, painfully make one, starting with stock rk3399 bootloader
<amstan> generally it's not needed, you can take the code that the current firmware was compiled from and just remove the things you don't like
<amstan> it shouldn't have any blobs, no secrets there
<amstan> while it won't be as flexible as uboot, it should let you do everything (including netboot)
<asciilifeform> i've not been able to find the 'bob' (this box's vendor name, seems) branch
<asciilifeform> it isn't on google's chromium repo
<asciilifeform> (every other known chromebook, seems to be)
<amstan> what were you looking for? I'm sure it's there, just hard to know you got it
<asciilifeform> well ideally i'd like the full source that produced that 8MB rom in that spi.
<asciilifeform> then could happily cut out the objectionables. ( will still need a means of recovering 100% hosed box, however )
<amstan> it doesn't have a bob folder, wtf
<asciilifeform> correct
<asciilifeform> no bob.
<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
<vagrantc> that's an awesome security feature
<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.
<amstan> that CL says it's changing bob, but note how it changes the gru file
<amstan> and there's an ifdef picking between them
<amstan> i'm willing to bet the gru folder services gru, bob, kevin and scarlet
nighty- has joined #linux-rockchip
lurchi__ is now known as lurchi_
<adj__> asciilifeform, amstan: is "Bob" "gru_gru"?
<adj__> samsung chromebook plus is gru_kevin
<amstan> no, gru was the reference design we made when we first brought up rk3399, it's not sold, it was just a prototype
<amstan> think of the name "gru" the same as veyron
<amstan> gru_bob is bob
<adj__> amstan, which devices is then "gru_gru"?
<adj__> I think that I have seen that code in some code
<adj__> that code name
<amstan> gru_gru is the prototype
<amstan> in an ugly white plastic case
<amstan> only about 50 or so exist
<adj__> ah, ok
<adj__> I thought that gru was in fact a prototype devices, and gru_kevin and gru_gru two different devices
<adj__> thanks for the clarification
<amstan> gru_gru is analogous to veyron_pinky
<adj__> ok
<amstan> where the first gru is the family name, pinky is the actual physical prototype device
<adj__> where is then the source code for bob and the kernel dts?
<amstan> (excuse the random hash though)
<adj__> it seems that bob is not in mmind's tree
<amstan> it didn't get upstreamed yet
<amstan> someone on the ml was offering to do it about 2 months ago
<amstan> don't forget about scarlet, that's released now too
<adj__> amstan, is that the rk3399 tablet?
<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
jwerner has quit [Ping timeout: 256 seconds]
<amstan> you want setup_board, workon (the various pieces of firmware, there's at least 5 spots now with coreboot, atf, depthcharge)
<asciilifeform> in re 'gru-bob' dts : i see at least 4 variants (diff board revs? how to find which board a given unit has ?)
<amstan> you probably have the last one
<amstan> depthcharge i think generates a compatible string and puts the board_id in there
jwerner has joined #linux-rockchip
kaspter has joined #linux-rockchip
lurchi_ is now known as lurchi__
<asciilifeform> the linked doc doesn't seem to mention depthcharge ( only builds chromeos ? )
<amstan> build_packages will do everything, but that's overkill (500 ish packages, you only neeed about 5 final ones (plus about 30 dependencies))
<amstan> emerge-bob chromeos-ec depthcharge coreboot libpayload chromeos-bootimage
<amstan> then check /build/bob/firmware/*
<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> this pic makes it look pretty accessible:
<asciilifeform> the balls on right side, rather hard to get to without nudging the resistors and possible other items
<amstan> i mean.. if you can't do that, what chances do you have to override the en pins from some tiny bga packages?
<asciilifeform> no chance unless convenient test pads, lol
<amstan> idk if there are pads for what you're looking for
cnxsoft has joined #linux-rockchip
<asciilifeform> i don't have an ir reflower, only hot air pump, so lifting the rom is likely to cost me several boards before i get a clean result
<asciilifeform> btw my photo is mislabeled, i think the voltage of the rom is 1.8
<amstan> it is, yes
<asciilifeform> i also do not know if there is any obstacle to insystem-reflashing via probe (e.g., does the machine drive #hold ? )
<amstan> in theory you're supposed to to have the rk3399 on, then assert warm reset
<amstan> then the spi pins are hiz
<asciilifeform> where does warmreset live ?
<amstan> but in practice nobody does that, you can keep everything off, only power the spi flash 1.8V rail and you might have some luck
<amstan> servo connector has it
<asciilifeform> nowhere else ?
<amstan> ec can do it too
<amstan> but to get to the ec console you need servo as well
<asciilifeform> you wouldnt perhaps know where there's a test pad for it...?
<amstan> no
<amstan> though i see a lot of test pads around the servo connector
<asciilifeform> aha
<amstan> maybe you see a TP connected to the right pin
<asciilifeform> so which pin ?
<amstan> it's on the servo wiki page
<amstan> with schematics, pinouts and everything
* asciilifeform goes to look.
<asciilifeform> active low reset?
* amstan is amused at the quantity of articles for this:
<amstan> yep
<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]
mrueg has quit [Quit: - Chat comfortably. Anywhere.]
mrueg has joined #linux-rockchip
jkarlson has joined #linux-rockchip
jkarlson has joined #linux-rockchip
phh|new has joined #linux-rockchip
phh has quit [*.net *.split]
Ke has quit [*.net *.split]
jkarlson is now known as Ke
micken has quit [Ping timeout: 248 seconds]
micken has joined #linux-rockchip
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
<adj_> kevin is mainline already
<asciilifeform> err
<adj_> 404 Not Found
<asciilifeform> sorry
gnufan has quit [Ping timeout: 265 seconds]
gnufan has joined #linux-rockchip
JohnDoe3 has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
<paulk-gagarine> okay so
<paulk-gagarine> asciilifeform, gru is the base board/family
<paulk-gagarine> bob is the device codename
<paulk-gagarine> asciilifeform, what are you trying to rebuild? I'll give you the sources / refs
<paulk-gagarine> asciilifeform, also you probably don't want to push your whole rom, it contains the VPD with your free google cloud storage token :p
<asciilifeform> lol
<asciilifeform> i'd like whole rom.
<asciilifeform> and i don't use the storage service and don't intend to start.
<paulk-gagarine> hehe
<paulk-gagarine> asciilifeform, well I have a build system that automates that:;a=summary
<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
<beeble> that's always the case
nighty- has quit [Ping timeout: 240 seconds]
<asciilifeform> i'm looking at , and don't see where the 'TEE' (arm 'trust' crapola, required on arm8) init code is
<beeble> you don't need tee
<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 ( ) 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' )
anarsoul|3 has joined #linux-rockchip
lukasz_ has joined #linux-rockchip
JohnDoe3 has quit [Quit: KVIrc 5.0.0 Aria]
Omegamoon has left #linux-rockchip [#linux-rockchip]
lurchi_ has quit [Remote host closed the connection]
vagrantc has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi_ is now known as lurchi__
Largeprime has quit [Ping timeout: 255 seconds]
BenG83 has joined #linux-rockchip
Largeprime has joined #linux-rockchip
xerpi has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
xerpi has quit [Quit: Leaving]
lukasz_ has quit [Quit: Leaving]
gnufan has quit [Ping timeout: 260 seconds]
gnufan has joined #linux-rockchip
return0e has quit [Remote host closed the connection]
return0e has joined #linux-rockchip
Kamikaze84 has joined #linux-rockchip
lurchi__ has quit [Remote host closed the connection]
return0e_ has joined #linux-rockchip
vstehle has quit [Ping timeout: 248 seconds]
return0e has quit [Ping timeout: 256 seconds]
lurchi__ has joined #linux-rockchip
lurchi__ has quit [Remote host closed the connection]