ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log | Community GH | Rockchip GH | ML
vagrantc has quit [Ping timeout: 245 seconds]
Kamikaze84 has joined #linux-rockchip
<Kamikaze84> Hi again. I've been working on getting my 2GB Firefly-RK3399 booting with a mainline kernel via SDCard. I've managed to get the kernel going by not loading the FAN53555 module (or any CONFIG_REGULATOR_* modules) as one of my hangs seemed to be related to this.
<Kamikaze84> I also had to include 'clk_ignore_unused' as a kernel parameter for some reason, as I noticed another hang happened in a function call that disabled unused clocks.
<Kamikaze84> This now gets me to the point of finding the rootfs, however for some reason my kernel fails to detect my SD or my eMMC.
<Kamikaze84> I have a few things to try for the eMMC (as I'm not sure if the kernel I last used had MTD_PARTS_CMDLINE in built or not), but I'm not sure why the SD is not detected. Any hints?
<Kamikaze84> I feel like something might be wrong with my DTB, just because I also noticed a few errors when trying to retrieve values from the DTB.
<Kamikaze84> e.g. this: "Looking up vmmc-supply property in node /dwmmc@fe320000 failed" perhaps it's normal though.
<Kamikaze84> hmm maybe not. also i just realised i pulled that message from the wrong bootup log. don't have my FF on me today and I can't find my pastebin that I made yesterday... so ignore that message.
anarsoul|2 has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-rockchip
<Kamikaze84> Do you need to update u-boot to a later version to have it work with a later mainline kernel? Is there an effect on the kernel if booting from an older u-boot?
lurchi_ is now known as lurchi__
ujerry_ has joined #linux-rockchip
ujerry_ has quit [Quit: Leaving]
ujerry_ has joined #linux-rockchip
busterbcook has quit [*.net *.split]
fireglow has quit [*.net *.split]
aalm has quit [Ping timeout: 256 seconds]
aalm has joined #linux-rockchip
akaizen has joined #linux-rockchip
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 is now known as cnxsoft
return0e has quit [Read error: Connection reset by peer]
lurchi_ has joined #linux-rockchip
return0e has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 248 seconds]
ujerry_ has quit [Read error: Connection timed out]
vstehle has joined #linux-rockchip
ujerry_ has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 244 seconds]
hanetzer has quit [Ping timeout: 260 seconds]
hanetzer has joined #linux-rockchip
Kamikaze84 has quit [Quit: Page closed]
gnufan1 has quit [Quit: Leaving.]
Omegamoon has joined #linux-rockchip
kaspter has joined #linux-rockchip
lukasz__ has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
akaizen has quit [Quit: Textual IRC Client:]
micken has quit [Ping timeout: 256 seconds]
micken has joined #linux-rockchip
BenG83 has quit [Ping timeout: 260 seconds]
fireglow has joined #linux-rockchip
busterbcook has joined #linux-rockchip
fireglow has quit [Max SendQ exceeded]
fireglow has joined #linux-rockchip
akaizen has joined #linux-rockchip
akaizen has quit [Ping timeout: 276 seconds]
matthias_bgg has joined #linux-rockchip
cyteen has joined #linux-rockchip
LargePrime has quit [Ping timeout: 240 seconds]
cyteen has quit [Read error: Connection reset by peer]
cyteen has joined #linux-rockchip
akaizen has joined #linux-rockchip
wens has quit [Ping timeout: 245 seconds]
wens has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
wens has quit [Ping timeout: 244 seconds]
wens has joined #linux-rockchip
cyteen has quit [Read error: Connection reset by peer]
Kamkaze84 has joined #linux-rockchip
<Kamkaze84> Hi, I was here earlier. I'll be afk at times, but I've got a pastebin (here: ) of a mainline kernel booting from sdcard on my Firefly RK3399. I cannot get it to see any partitions on my sdcard or eMMC when it goes to find the rootfs. I
<Kamkaze84> I'm wondering what particular kernel config needs to be set to enable the sdcard in mainline?
zzarr_ has joined #linux-rockchip
zzarr_ has quit [Client Quit]
<diego71_> Kamkaze84: I wonder if it is a problem of DT (device tree)
Omegamoon has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 244 seconds]
<Kamkaze84> deigo71_: I thought that too at one point, hrmm... i'll mess with the resource img
<Kamkaze84> diego71_: thanks
kaspter has joined #linux-rockchip
<Kamkaze84> diego71_: wow yeah thanks that was it.. I must have forgot to reflash the resource last time I re-did the sdcard image... it must have had an old dtb there that it picked up.
Omegamoon has joined #linux-rockchip
mrfixit2001 has joined #linux-rockchip
mrfixit2001 has quit [Client Quit]
tllim has joined #linux-rockchip
tllim has quit [Remote host closed the connection]
mrfixit2001 has joined #linux-rockchip
lurchi_ is now known as lurchi__
<Kamkaze84> finally got a login in arch linux.. woohoo. thanks all. I seem to be getting the bugs that vagrantc reported with the fan53555 module, but I also have one with the pwm-regulator module too. I've had to blacklist them both and use clk_ignore_unused as a kernel param too
LargePrime has joined #linux-rockchip
LargePrime has quit [Client Quit]
<diego71_> fan53555 was required by firefly rk3288, if I rememeber well
<Kamkaze84> yeah I heard it mentioned it was needed by the rk3399 aswell, something about cpufreq failing without it.
<diego71_> Kamkaze84: yes it's needed for cpufreq, at least rk3288
<gab> yes, I had this issue of rk3339's cpufreq failing without fan53555 (still booting, but keeping clocks very slow)
return0e_ has joined #linux-rockchip
mrfixit2001 has quit [Remote host closed the connection]
mrfixit2001 has joined #linux-rockchip
return0e has quit [Ping timeout: 256 seconds]
kaspter has quit [Quit: kaspter]
hanetzer has quit [Quit: WeeChat 2.1]
hanetzer has joined #linux-rockchip
return0e_ has quit [Remote host closed the connection]
return0e has joined #linux-rockchip
mrfixit2001 has quit [Quit: Mutter:]
vagrantc has joined #linux-rockchip
<Kamkaze84> gab: i _might have_ just managed to patch my DTS for the fan53555 and pwm-regulator issues i just had. i basically just took a couple of values that looked related from the firefly tree, and also compared against the (decompiled) eMMC DTB
<Kamkaze84> it seems to load both modules now and not hang... although I've only used it for a few minutes
<Kamkaze84> im not sure yet if cpufreq is functioning, but will check soon
<vagrantc> Kamkaze84: nice!
<diego71_> Kamkaze84: cpufreq-info should tell you if is working (
mrfixit2001 has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
<Kamkaze84> diego71_: arch doesn't seem to have that binary in a package in it's default repos. but cpupower seems to show available frequencies and related CPUs they can be set on
<Kamkaze84> I'll run something CPU intensive and see if it ramps up
<beeble> /sys/devices/system/cpu/cpufreq/policy[0,4]/
<vagrantc> there's also /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
<beeble> 0 are the a53, 4 the a72
<vagrantc> hah
<beeble> time_in_state is only available with a extra kernel option
<Kamkaze84> its in my kernel apparently, but it looks like it hasn't changed state yet. i haven't run anything crazy yet though, will do soon
<Kamkaze84> hey the a53 has ramped up
<Kamkaze84> a72 hasn't though
punit has joined #linux-rockchip
<Kamkaze84> i'm not real familiar with big.LITTLE, but I modprobe the arm_big_little_dt driver... not sure if it's had any affect... although I guess since cpufreq is aware of the different frequencies maybe it has?
<Kamkaze84> well, at least the fan53555 and pwm-regulator fix seems to be working. i better put up my dts on github
<gab> Kamkaze84: fyi, on my rk3399 the cpufreq driver is CONFIG_CPUFREQ_DT, not CONFIG_ARM_BIG_LITTLE_CPUFREQ
<vagrantc> anyone have any luck with using the instructions at:
<vagrantc> on firefly-rk3399
<Kamkaze84> ok, yeah i checked lsmod and it's actually using cpufreq_dt i think
<Kamkaze84> ah there we go, i used cpufreq-bench and told it to use the a72, and the a72 is ramping up now
<vagrantc> beeble: fwiw, i got puma-rk3399 enabled in gnu guix ... was easier to get all the arm-trusted-firmware and cortex-m0 stuff in there than in debian
* vagrantc tried unsuccessfully to use the same ATF/m0 stuff with firefly-rk3399
<vagrantc> i need to get a freind to help solder a switch onto the firefly-rk3399 to disable the eMMC ... then i would be willing to try installing u-boot to the eMMC again ... although it's distinctly possible the eMMC is fried on this board
<vagrantc> after so many attempts to short the eMMC to ground...
<Kamkaze84> the location of the pin to short to gnd for eMMC sucks
<Kamkaze84> i'm glad i've never tried that so far. i'm sure i'd screw it up. the one time I tried something similar was with a Cisco Meraki AP, and I killed it.
<vagrantc> another bizarre thing is ... when booting from the microSD ... when i reboot or reset the board ... it requires phyiscally ejecting and inserting the microSD... even after disconnecting from power
* vagrantc wonders if there is some power bleeding in from the serial console
<vagrantc> beeble: gotta say, the puma-rk3399 is such a pleasant piece of hardware to work with, by contrast :)
<vagrantc> just about everything "just works"
<vagrantc> although i have noticed a bizarre issue where attempting to use ansible on it hard-crashes it. never seen anything like that before
anarsoul|2 has joined #linux-rockchip
<beeble> vagrantc: nice to hear (the praise) the ansible part not so. must say that i don't use it
<beeble> but the jenkins slaves i have here run fine and also the kernelci devices do their jobs
LargePrime has joined #linux-rockchip
<vagrantc> yeah ... i've used ansible with some 30-40 boards so far, and there's something about it that triggers a kernel panic only on the puma-rk3399 ... been meaning to try and dig a little deeper on it, amongst all the other things... :)
mrfixit2001 has quit [Quit: Mutter:]
<beeble> i have no ansible knowledge at all. most automation i used in the past was puppet
<beeble> but if i can help out just give me some pointers
<vagrantc> i have an idea for a simple test case i'll try out later
matthias_bgg has quit [Quit: Leaving]
Easyfab has joined #linux-rockchip
<vagrantc> beeble: simple test case didn't trigger the issue ... ugh... when it happens, the orange light on the cpu module flashes ... dunno if that's normal for most kernel panics
<beeble> we are talking mainline right?
<beeble> default the led on the module is heartbeat and it also acts as panic led
<beeble> the blinkpattern is different
nOOb__ has joined #linux-rockchip
<vagrantc> pretty much mainline... just debian's linux packages
<vagrantc> beeble: that paste above is the kernel panic, if that might give any idea
<beeble> can i get a vmlinux from that kernel?
<beeble> is that available in the debian debug packages?
<vagrantc> not sure
<beeble> maybe i don't need it. let me see if the call trace tells me anything
<vagrantc> unfortunately, i've gotta head out soon
<beeble> no problem. not sure if i can figure it out myself anyway
<beeble> don't forget hardware guy speaking :)
<vagrantc> it takes all kinds :)
* vagrantc waves
vagrantc has quit [Quit: leaving]
<Kamkaze84> OK, so I've put up my patched rk3399-firefly.dts and some instructions for making a Firefly RK3399 sdcard image that is bootable from the existing firefly eMMC. The instructions are really just for me, but maybe they will be useful for someone else. Here it all is:
<Kamkaze84> i'm off too now. seeya !
Kamkaze84 has quit [Quit: mission accomplished?]
Omegamoon has left #linux-rockchip [#linux-rockchip]
mrfixit2001 has joined #linux-rockchip
mrfixit2001 has quit [Quit: Mutter:]
maz has quit [Quit: Leaving]
LongChair_ has joined #linux-rockchip
return0e has quit [Ping timeout: 244 seconds]
return0e has joined #linux-rockchip
return0e has quit [Read error: Connection reset by peer]
return0e has joined #linux-rockchip
asciilifeform has joined #linux-rockchip
<asciilifeform> hello #linux-rockchip .
<asciilifeform> does anyone here know the state of the art in re: booting mainline uboot on asus c101pa 10" 'chromebook' ?
<asciilifeform> or , failing that, know where are the spi rom contacts on this machine's mainboard ( example photo on my www, )
<asciilifeform> ( there appears to be an (unpopulated) google 'servo' debug connector, but it apparently does not bring out the spi contacts )
<asciilifeform> any tips/leads appreciated, thank you.
<asciilifeform> i am open to porting uboot with own hands, but do not have a sufficient supply of the machines to create brick after brick. so looking for where to solder spi burner leads.
<beeble> is it booting from spi by default?
<asciilifeform> not sure, possibly it is an internal mmc
<asciilifeform> shows up as /dev/mmcblk0
<asciilifeform> it would be just as great for my purposes, to find the method for forcing the rockchip cpu into mask rom mode, and then reflash via usb A-A cable
<asciilifeform> i recently worked with a roc-rk3328-cc board, on similar chipset, and it had two test pads that can be shorted to trigger this mode.
mrfixit2001 has joined #linux-rockchip
<beeble> maybe take a look at mmcblk0. hexdump it and look at offset 0x8800
<beeble> is there a header resembling the string RK33
<beeble> if so your bootsource is mmc
<asciilifeform> looks to be null.
<beeble> ok, then it probably booting from spi (cat /proc/mtd maybe?)
<asciilifeform> device shows as a 40MHz mmc0 in kernel log, however.
<asciilifeform> but in /proc/mtd, shows as mtd0: 00800000 00001000 "spi1:0"
<asciilifeform> manufacturer spec lists '16 GB SSD - (eMMC)' .
<asciilifeform> so looks like a emmc chip in spi mode.
<beeble> no, mmcblk0 is the emmc mtd0 is the spi flash
<asciilifeform> aah hm
<beeble> hexdump /dev/mtd0, offset 0x1000
<beeble> see if there is a RK33 header
<asciilifeform> RK33u
<beeble> tada
<beeble> so spi bootloader
<asciilifeform> right
<beeble> easy to force it into maskrom
<beeble> can't say for 100% due the lack of pixles in your picture
<asciilifeform> any simple way , other than by zeroing the rom ?
<beeble> but second chip from the left
<beeble> next to the second nope
<asciilifeform> the one under the 2nd screwhole from left ?
<beeble> yes
<beeble> if you could tell me the marking on that
<asciilifeform> that was my lead suspect. i assume all i gotta do is to short sda line to ground ?
<beeble> yes, but as there is no sda take miso, mosi, clk or cs. all of them will work
<beeble> then it will go into maskrom mode
<beeble>;a=blob;f=board/theobroma-systems/puma_rk3399/README;h=f67dfb451ffd36745a5209a83459a8337134b75d;hb=HEAD#l80 on how to flash mainline uboot with rkdeveloptool
<asciilifeform> aa neato ! thx beeble . i'ma try this later, this box is a 1st class pain to open, and designed in such a way that there is no way to get to the contacts without completely removing the mobo. will have to solder leads and try this.
<beeble> then starts the hard part
<beeble> because there is no mainline support for the c101pa yet
<asciilifeform> i suspected this. ( hence why looked for spi )
<beeble> so not sure if spl supports lpddr right now
<beeble> the thing is
<beeble> rkdeveloptool does not support spi flashing
<beeble> and for loading u-boot into ram we have to implement tpl first
<asciilifeform> seems to support manual feeding of boot rom image though, and with this i can debrick.
<asciilifeform> (with old image)
mrfixit2001 has quit [Quit: Mutter:]
<beeble> but then you have to find a data line for the emmc too
<beeble> or better the clock line
<beeble> so you can short that too
<asciilifeform> google's rom knows how to boot from external sd; from there, can reflash mmc0
<beeble> ah ok
<asciilifeform> ... or will rk autoboot from mmc0 even when spi is shorted out, unless mmc0 is nulled ?
<beeble> yes
micken has quit [Ping timeout: 245 seconds]
<asciilifeform> so gotta short both, to get into mask mode ?
<beeble> bootorder is spi -> emmc -> sd
micken has joined #linux-rockchip
<asciilifeform> it's a bit of a puzzler then why the vendor included the spi rom, if rockchip knows how to boot from mmc
<gab> cheaper PCB routing ?
<beeble> less issues if people play around with mmcblk0
<asciilifeform> i doubt that it'd offset the cost of the extra chip. personally i suspect that it was done specifically for the 'nintendoization' ( the firmware is writeprotected, by default, gotta pull out the battery to bring the WP pin low )
<beeble> and no problem with mmcblk0bootX
<beeble> thats always a bit of a pain
<beeble> no, actually it is really just a cheap safe way to store your bootloader
<beeble> NOR flash reliability is higher then MLC NAND (even if stored in the SLC partitions)
<asciilifeform> any theory re: how these get flashed during manufacture ?
<beeble> boot from sdcard
<beeble> thats at least how i do it
<asciilifeform> this happens by default if both roms are full of null ?
<beeble> yes, spi, emmc, sd card (nand inbetween or before emmc not sure) and if all fails usb mode
<asciilifeform> mmc rom ( supposing it's the large item on bottom left of cpu ) seems to have only 1 exposed pad
<beeble> yes thats the emmc
<asciilifeform> i've never seen an emmc that wasn't a bga ( like this one is ). how do people usually short it ?
<asciilifeform> ( or would simply nulling it from inside a working os booted from sd , suffice )
<beeble> vias somewhere on the way
<beeble> there could also be a small resistor value in the clock line
<beeble> usually you have 22-33ohm there for emc reasons
tllim has joined #linux-rockchip
<asciilifeform> line terminator aha
<asciilifeform> and would i have to null whole 16GB, or just 1st N sectors
<beeble> bootrom looks for the RK33
<asciilifeform> ah ok
<asciilifeform> the mmc should already be bypassed, then, even with stock google os: it has no RK33 marker even now
<asciilifeform> (if spi is shorted)
<beeble> yes
<beeble> if you have a sd slot
<asciilifeform> so theoretically can leave mmc alone
<beeble> then thats the easiest way to develoip
<asciilifeform> so looks like a shorting toggle for the spi, should suffice
<asciilifeform> 1 more q -- anybody know what the 4pin empty pad next to the 'servo' pads, is ? uart ?
<asciilifeform> ( and there's a 6-pin testpad-looking thing next to the power usbc connector; any theories ? )
<asciilifeform> err, not power usbc, but the secondary one next to audio jack
<asciilifeform> anyway folks, thx for the tips. i will post the magic recipe on my www when it is ripe. normally i can be found at #trilema , where the cp101pa delousing is only the smallest of many interesting open puzzles.
<asciilifeform> physically the cp101pa is imho a very spiffy box; will make for a great cheap linux workstation when we find how to wash 100% of the nintendo off it.
<beeble> doesn't look like it's sold in europe
<asciilifeform> seems to have it.
<asciilifeform> £240 for the 4GB ver.
JohnDoe_71Rus has joined #linux-rockchip
<beeble> wow, only 5 pounds shipping
<beeble> should do it as long as they are still in the eu :)
<asciilifeform> i'm in usa, where they can be seen even in ordinary shops
mrfixit2001 has joined #linux-rockchip
<asciilifeform> usa amazon does ship into eu, but makes you pay vat.
<beeble> i can't bypass vat if i buy it private anyway
<asciilifeform> in re other rockchips, i have a working gentoo for the 3328 : , if anybody wants one.
Xal1u5 has joined #linux-rockchip
Easyfab_ has joined #linux-rockchip
anarsoul|3 has joined #linux-rockchip
Easyfab has quit [Read error: Connection reset by peer]
BenG has quit [Read error: Connection reset by peer]
anarsoul|2 has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has joined #linux-rockchip
aalm has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Client Quit]
aalm has joined #linux-rockchip
return0e has quit [Read error: No route to host]
return0e has joined #linux-rockchip
<paulk-gagarine> asciilifeform, what device are you asking about?
<paulk-gagarine> sounds like a rockchip chromebook
nashpa has joined #linux-rockchip
<asciilifeform> paulk-gagarine: asus c101pa ; RK3399 chipset
<paulk-gagarine> neat
<paulk-gagarine> that's one I don't have
<paulk-gagarine> I doubt that they exported UART anywhere else than the servo pads
<asciilifeform> it's a pretty great box, aside from the vendor firmware. aluminum chassis, ips lcd, etc
<paulk-gagarine> what's wrong with the firmware?
<paulk-gagarine> it's coreboot
<asciilifeform> it's google's nintendoized mutilated coreboot, forces you to go through their song & dance to build kernels, won't load'em from standard partitions (gotta keep a GB of toolchain crapola around, to write kernels)
tllim has quit [Ping timeout: 240 seconds]
<asciilifeform> won't give uboot console, won't netboot, ugly.
<asciilifeform> and when in 'dev mode' it prompts you for magic keypress on every boot, and if you don't press in time, reformats the disk. (like all chromebooks.)
mrfixit2001 has quit [Remote host closed the connection]
<paulk-gagarine> no, it's regular coreboot
<paulk-gagarine> with the depthcharge payload
<paulk-gagarine> it's called that way for a reason
<paulk-gagarine> so yes, you don't get u-boot shell :p
<asciilifeform> right
<paulk-gagarine> I don't see how data erase when enabling dev mode is a bad thing
<asciilifeform> adds up to a mostly unusable, per my lights, box, until i find a way to cleanse it.
<paulk-gagarine> and the kernel format is fit
<paulk-gagarine> it's totally standard
<paulk-gagarine> and allows for verified boot
<asciilifeform> i want a kernel on normal ext4 partition.
<asciilifeform> like on normal boxen.
<paulk-gagarine> zImage doesn't allow these types of use cases
<asciilifeform> and to hell with 'verified boot', i want 0 google crapola on my boxes.
<paulk-gagarine> fit image is definitely standard
mrfixit2001 has joined #linux-rockchip
<paulk-gagarine> you can use u-boot as a payload
<paulk-gagarine> instead of depthcharge
<paulk-gagarine> GRUB2 also has a work in progress port for ARM
<asciilifeform> this is roughly what i'd like to build, yes
<paulk-gagarine> (maybe v7 only though)
<paulk-gagarine> asciilifeform, well, coreboot has support for that :)
<asciilifeform> rockchip is theoretically capable of blobless boot.
<paulk-gagarine> last time I checked, coreboot master was fully-featured for rk3399
<paulk-gagarine> not theoretically
<paulk-gagarine> I do it on kevin
<paulk-gagarine> Chromebook Plus
<paulk-gagarine> with upstream coreboot, atf, depthcharge and vboot
<paulk-gagarine> with generated keys
<asciilifeform> iirc there's some magic to enable the embedded micro, and the lcd, on this box
<paulk-gagarine> also the ec firmware
<paulk-gagarine> it's already all in coreboot
<asciilifeform> iirc ec fw is nonvolatile
<paulk-gagarine> I don't remember how it is for bob
<paulk-gagarine> but on kevin you have another spi flash for it
<paulk-gagarine> which is routed to servo SPI1
<asciilifeform> i actually don't mind the vendor's ec fw, their posted source builds and the resulting item, runs
<asciilifeform> and contains nothing objectionable imho
<paulk-gagarine> anyway you can also reflash the ec from the device itself
<asciilifeform> right
<paulk-gagarine> so if you're looking for help rebuilding this stuff, feel free to ask
<paulk-gagarine> I have a build system ready for that
<paulk-gagarine> doesn't have bob support for now, only kevin as far as rk3399 goes
<paulk-gagarine> and linux-cros only, not mainline linux for now
<paulk-gagarine> I have yet to make a mainline defconfig and so
LongChair_ has quit [Quit: Connection closed for inactivity]
<asciilifeform> paulk-gagarine: i have a working userland ( ) for the box already. now i only need boot fw and kernel.
<asciilifeform> building works ok from inside it ( chroot from devmode'd google linux )
<asciilifeform> i've gotten it to boot properly into it using a kernel lifted from archlinux and signed with dev keys via google's tooling, also; but this gives no networking currently (it seems to want modules, which of course aren't there in my userland, which i originally built together with a monolithic kernel for rk3328)
<asciilifeform> what i'd like to end up with is a box from which 100% of the googlism is banished.
<asciilifeform> ( i like the rockchip , the 9 hour battery, and the 10 inch ips; i do not want or need google's crapola for anything whatsoever. in particularly the 'verified' song and dance. )
<asciilifeform> the rk3328 devboard was very easy in this respect -- it has no onboard flash at all, 100% of the firmware lives on sd card that pulls out.
xerpi has joined #linux-rockchip
<paulk-gagarine> that's very nice for dev boards but it's really not secure for a laptop to have all the software on a sd card
<paulk-gagarine> in that regard, the spi flash + screw design is nice
<paulk-gagarine> but I understand you don't care about the security model
vagrantc has joined #linux-rockchip
<asciilifeform> write-protectable bios is theoretically nice , but this box is quite unfriendly to disassemble. i ripped the touchpad connector right off mine, not long ago, while opening.
<asciilifeform> ( now i have mouseless box.. )
Easyfab_ has quit [Quit: Leaving]
return0e has quit [Ping timeout: 260 seconds]
xerpi has quit [Quit: Leaving]
lukasz__ has quit [Quit: Leaving]
mrfixit2001 has quit [Quit: Mutter:]
return0e has joined #linux-rockchip
return0e has quit [Read error: Connection reset by peer]
perr has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
perr has quit [Remote host closed the connection]
perr has joined #linux-rockchip
perr has joined #linux-rockchip
perr has quit [Changing host]
vstehle has quit [Ping timeout: 260 seconds]
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 245 seconds]