<samueldr>
on mine it would involve opening its back, and booting it while shorting some test pads
<samueldr>
yours, I think you could use it without
<samueldr>
it looks like you have a 2015 one
<clever>
ive already obtained root (both su or adb su)
<samueldr>
yeah, thus why "it looks like" :)
<clever>
i was able to `adb su` via an `adb restore` exploit
<samueldr>
>> (Only 5th gen) Downgrade to 5.0.1 firmware via adb sideload in Amazon recovery, then proceed to use the left volume button to enter boot-rom.
<clever>
ive never gotten into the bootloader stuff
<samueldr>
yours would be miles more trivial to do than mine :)
<samueldr>
I put mine aside to try, though
<samueldr>
it's relatively low risk
<clever>
the restore exploit, is to restore an app and directory, that contains 100's of files
<samueldr>
AFAIUI the worst (fixable) thing that could happen can be fixed by just doing it again
<clever>
and the permissions on the directory being restored are 777
<samueldr>
then, the actual worst is something like accidentally shorting the wrong thing and releasing some of the magic smoke
<clever>
then you setup a race condition, to replace the final file, with a symlink
<clever>
(from a normal adb shell)
<clever>
then the restore process opens the symlink, and blindly overwrites whatever it pointed to
<clever>
typically, a config file claiming that android is running in a VM
<samueldr>
craige: you're flying out awfully early... well... not that early when I think about it... only feels like it since it's still sunday here :)
<clever>
which disables all security (and hw accel)
<clever>
main thing i worry about, is bricking the fire, either soft or hard, as i replace the os
<samueldr>
hm?
<samueldr>
I gather you're still using it then
<samueldr>
probably not a good thing to toy with in that case
<clever>
not really, its been retired for a few years
<samueldr>
ah
<clever>
but id rather not brick it still
<samueldr>
then it should be relatively safe, in your case, at any point you can put it in "boot rom" mode, where amonet can run any code on it
<clever>
ah
<samueldr>
amonet runs tethered from your computer
<clever>
so the bootloader for recovery usage has been cracked wide open
<samueldr>
not entirely sure of the details, but I think it's that that special mediatek mode has a flaw
<samueldr>
so it's not even using the special mode, but using it to inject a payload
<samueldr>
I had a look at the repo, it's generally straightforward how the big picture looks
* clever
rips the back cover off
<samueldr>
you don't even need to!
<clever>
i see some special contacts for usbboot, reset, and power
<samueldr>
yours has a bootloader that is signed by amazon that will enter in that special mode already
<clever>
oh, and theres rx/tx!
<clever>
ive had the cover off before
<samueldr>
ah
<samueldr>
carry on then :D
<gchristensen>
craige: where do you travel from?
<clever>
many many years ago, i tripped on the stairs, and rammed the corner of the tablet into a tile
<clever>
the screen survived (thanks to having giant edges), but the covered had popped half off
<craige>
.au, gchristensen
<clever>
modern edgeless phones are at risk of damage :P
<samueldr>
I'm thinking about setting up a tac switch through the back of my kindle fire if this is something fiddly I want to be able to re-use to repair bricks
<gchristensen>
good long trip :)
<craige>
"normal" :-)
<gchristensen>
aye
<clever>
samueldr: ive also heard rumors of shorting something in the usb port to trigger usb boot too
<samueldr>
not rumours :D
<clever>
samueldr: and it could be done with a special cable
<craige>
There's a system, you just do it. Should be fresh when I get there gchristensen :-)
<samueldr>
qcom and mtk (most of the time) all have a special way to do it via a cable
<samueldr>
I acquired such a cable
<samueldr>
though some devices can access the mode without a cable, just press the right sequence at boot
<clever>
ah
<clever>
but the amazon bootloader has an unsigned function to enter mtk mode?
<samueldr>
and there, with qcom, during boot, it looks like it's bricked!
<samueldr>
an amazon-signed bootloader has the function accessible through a key combo, which is likely an oversight
<samueldr>
hmmm
* samueldr
is wondering
<samueldr>
would the mtk cable I ordered do the trick with the fire?
<samueldr>
>> (Only 5th gen) Downgrade to 5.0.1 firmware via adb sideload in Amazon recovery, then proceed to use the left volume button to enter boot-rom.
<samueldr>
if you downgrade the bootloader, the tablet won't boot a more recent system
<samueldr>
thus the note
<samueldr>
>> NOTE: Using option two will brick your device until you have successfully finished the process.
<clever>
left volume button?
<samueldr>
here they're using the term "brick" when they should be using the term" unbootable-but-fixable-via-software
<clever>
all of my buttons are on the same side, pow vol- vol+
<samueldr>
heh, I figure the one that is to the left when in a specific orientation
<samueldr>
so... either of those, if it doesn't, the other :D
<samueldr>
though you'll need the 5.0.1 firmware
<clever>
let me boot it up and see...
<clever>
immediately on power-up, the bootloader shows the logo in portrait mode, with the buttons on the top
<clever>
left volume is vol-
<clever>
system version 7.5.1!
<clever>
connectbot says i havent opened a local shell for 4 years
<samueldr>
hah
<clever>
`su` instantly works, i now have a root shell
<samueldr>
hmmm
<samueldr>
I figure you maybe can apply the same bootloader exploits from within the OS, though that's unlikely to be "ready to use"
<clever>
a direct usb link is also way faster then wifi
<clever>
one confusing thing, how is mmcblk0boot0 getting created?
<clever>
what tells the kernel to boot more then a number into the partition field?
<samueldr>
those are hardware partitions on the emmc
<samueldr>
the kernel just shows them
<samueldr>
they are a different area on the emmc
<samueldr>
some devices will have those, while not using them
<samueldr>
my chuwi tablet has those, and they are (apparently) not used, they are not even readable or anything iirc
<samueldr>
oh hey
<samueldr>
I saw mediatek preloader in lususb wizz by with that cable
<clever>
one question, is the cable active or passive?
<samueldr>
passive
<samueldr>
resistors of a specific value IIRC
<clever>
a good way to confirm that, boot the device with the cable, then once its in the right mode, switch to a normal cable
<clever>
does the lsusb output persist?
<samueldr>
aw, wrong boot mode
<samueldr>
so it's an *additional* mode it looks like
<clever>
so, if i'm reading this right, amonet should just unlock fastboot, and leave android in place?
<samueldr>
"just"
<clever>
and then fastboot lets you reflash any partition, without limits?
<samueldr>
yeah
<samueldr>
something along the lines
<clever>
i have put clockworkmod onto a galaxy S3 before in the past
<clever>
biggest nasty surprise, is that the stock bootloader can look similar, and doesnt strongly confirm before unpacking a zip file (and pre-wiping the device)
<clever>
so if you try to re-apply su.zip, and dont notice the bootloader "fixed" itself, it will factory reset itself!
<samueldr>
sucks that bootrom mode is not the same as that preloader mode
<samueldr>
it would have been too easy :)
orivej has quit [Ping timeout: 240 seconds]
<clever>
from what ive seen of android before, there are 2-ish bootloader menus (one is a menu to select things, the other is a boot rom to unbrick or factory flash it)
<clever>
and then there is the recovery image, which is basically just dual-booting between "recovery" and android
<samueldr>
yeah, recovery is a pared down linux os
<samueldr>
not sure about your 2-ish bootloader menus
<clever>
there is an extremely low-level one, that i think might be in a rom on the cpu itself
<samueldr>
though those can differ depending on the OEM and/or SoC
<samueldr>
ah, the qualcomm firehose mode
<clever>
and then there is a slightly higher level one, that is on the mmc, and can actually bring the display online
<samueldr>
and let's not forget most of the "cpus" in use are SoCs
<gchristensen>
yeah
<samueldr>
I don't know if M0 generally are SoCs or just the cpu
<gchristensen>
true
<samueldr>
lately I've been seeing stuff, it looks like memory chips are going to be the waaaaay bigger components in most mid-range systems
<samueldr>
like those new chips for the new surface devices, be it the ryzen or the qualcomm ones
ryantrinkle has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
<t184256>
opened a submission request for Nix-on-Droid to F-Droid, despite it violating the inclusion guidelines; wish me luck
<clever>
t184256++
<{^_^}>
t184256's karma got increased to 1
<samueldr>
inclusion guidelines t184256?
<samueldr>
ah, "some/all guidelines" and not "guidelines about inclusions", is that it?
<samueldr>
anyway t184256++ for fun sillyness
<{^_^}>
t184256's karma got increased to 2
<samueldr>
at the very worst you could figure out a way to host the repo yourself
<t184256>
software should not download binaries and/or include autoupdate mechanisms
<samueldr>
ah, right
<samueldr>
termux though
<t184256>
oh, that's infinitely easier than submission to their repo
<clever>
t184256: thats kind of the entire point of nix
<clever>
t184256: and means fdroid shouldnt be a valid app in fdroid, lol!
<t184256>
termux, anlinux, everybody and their uncle
<t184256>
Oh shit
<samueldr>
there's only termux that I *know* is on f-droid though :)
* samueldr
thinks
<samueldr>
someone without an aarch64 machine could bootstrap themselves with nix on droid for mobile nixos, lol
<samueldr>
that's actually amazingly useful
<t184256>
I doubt that
<samueldr>
well, in theory
<clever>
samueldr: someone in #nixos recently said they where able to cross-compile all of nixos to arm
<samueldr>
how come?
<samueldr>
all of nixos? I doubt it :)
<t184256>
Compiling anything on my tablet is terribly slow
<samueldr>
though enough to have the iso image and/or sd image going, I do think so
<samueldr>
t184256: I was thinking about building with cache.nixos.org backing it
<samueldr>
there's not that much to build for stage-2, most of it is taken wholesale from cache.nixos.org
<t184256>
and until somebody shows me how to cross-compile, I'm stuck with what's already in binary cache
<samueldr>
so it wouldn't be a quick experience, but would still be better than nothing
<samueldr>
I'll have to try it out
<t184256>
Well, building without compiling anything remotely big is feasible
<samueldr>
it is one of my concern, I don't want to distribute images, but without it, it would become cumbersome for most users
<samueldr>
and stupidly enough, stage-2 is trivially easy to build
<samueldr>
it's stage-1 that has the most cost to build, but that can be cross-compiled
<t184256>
But even tiny native libraries/binaries start from 10 minutes. I wonder how much is due to CPU performance and how much is due to proot overhead =/
<samueldr>
oh, it's backed by proot?
<samueldr>
now I see
<t184256>
samueldr: why not distribute images?
<clever>
t184256: ahh, proot based, *looks*
<samueldr>
because it would mean having to build n images, where n is the amount of devices in mobile-nixos
<t184256>
yeah, because otherwise I'll have to recompile everything *just* to change the /nix/store path
<samueldr>
n could be cut back some, but not entirely
<samueldr>
I guess SELinux on Android is what makes it impossible to run using a chroot with root privs?
<samueldr>
(as an additional mode of operation)
<t184256>
n doesn't sound bad if there are only k architectures and most derivations can be reused
<samueldr>
still, I don't want to *have* to :)
<t184256>
Um, if you have root, you can disable SELinux
<samueldr>
the least amount of work I have to do, the better it is :D
<t184256>
but playing by the rules is way more interesting
<t184256>
anything special about this one or it it also proot-based?
<clever>
its also proot based, but has buttons to auto-download a distro
<samueldr>
btw, just making sure, I'm not being dismissive in saying "it's backed by proot?"
<samueldr>
just as you said, playing by the (expected) rules is more interesting :)
<clever>
i'm curious if user namespacing still works
<t184256>
"the least amount of work I have to do, the better it is :D" - said the person behind mobile-nixos? wow
<samueldr>
it's still true!
<samueldr>
I'm a developer because I'm lazy
<t184256>
clever: I wouldn't use 'still' for something that is not wide available yet
<samueldr>
and android is getting in the way of my lazyness
<t184256>
cannot compute
<clever>
t184256: it works on any modern linux kernel, if debian hasnt patched it out
<clever>
t184256: and modern android definitely uses root namespacing, to isolate apps further
<t184256>
Last time I've checked, my shiny new 2016 tablet didn't have it.
<samueldr>
heh, "shiny new 2016"
<samueldr>
likely running a 2014 era kernel :3
<clever>
Linux version 3.0.8-02825-g9e39b8c (ubuntu@ip-10-166-55-151) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Sat Aug 3 23:03:37 PDT 2013
<clever>
from /proc/version
<samueldr>
though I was highly surprised, the new redmi note 8 pro (IIRC) from xiaomi are mtk-based AND have a 4.14 (yes, fourteen) kernel
<clever>
shell@android:/ # cat /proc/modules
<clever>
bcmdhd 437056 0 - Live 0xbf00b000
<clever>
atmel_mxt_ts 25085 0 - Live 0xbf000000
<clever>
surprised to see modules on android
<t184256>
Mine's 3.10
<t184256>
samueldr: we seem to have absolutely polar opinions on what constitutes 'the least amount off work' =)
<t184256>
One of the reasons I admire your work is how outlandishly hardcore your goals are
<samueldr>
haha, though it's surprisingly straightforward up to now
* samueldr
knocks on all wood-like surfaces
<t184256>
it's like pmos is crossing an ocean on a small boat with 20 people, purism is crossing the ocean with a boat, two guys and a bag of money, and you are crossing the boat with a log all alone on a paddleboard with the absolute best high-tech paddle ever invented
<samueldr>
you're missing the big picture, I'm hoping (and trying) to get all of us tied together
<samueldr>
still not sure how to, but I hope to achieve a better dialogue between all projects, you have to add ubports, maemo leste, lune os, and halium, at the very least :)
<samueldr>
there's a biiiiig chunk of commonalities that we need to figure out a way to build upon
<samueldr>
like how I am working on a phone that's not available on other platforms
<samueldr>
I want it to work easily on other platforms too
<samueldr>
and vice versa
<t184256>
that's a separate grandiose goal in itself
<samueldr>
I wouldn't feel that my work in complete without a better dialogue/cooperation within those projects that do share a basic big chunk
<t184256>
you're doing God's job, no doubt, but it sounds insanely big
<samueldr>
and it's likely not going to be "my work" only to achieve this, but I hope, if it isn't already under way implicitly, or explicitly, that things can be nudged towards something good :D
<samueldr>
I don't know if I will have coordinated my thoughts on the matter enough for the talk
<samueldr>
hopefully yes
<samueldr>
but there is an appeal to OEMs I want to do
<samueldr>
to make sure they give the means to run whatever you want
<t184256>
Call me pessimistic, but in my eyes, a goal of a Linux phone, let alone a big Linux phone ecosystem, needs resources thrown at it, and if someone asked me to estimate those efforts, I'd estimate them in Nokias
<samueldr>
it will help success with resources thrown, but I think that is not something that a single company can do, since they provably seemingly can't :D
<samueldr>
nokia with maemo being my "probably seemingly"
<samueldr>
though there it may be that they have been poisoned by elop
<t184256>
Note the 's' in 'Nokias' =)
<samueldr>
I have a belief that it needs to come from "outisde" the companies
<samueldr>
with the end-users in mind
<samueldr>
not the end-product im mind
<t184256>
Companies tend to cling to what they wrote
<samueldr>
exactly, and they want to shrink wrap it for their needs
<samueldr>
see tizen
<samueldr>
while it's much more gnu/linux like, it's still entirely foreign, and unusable
<t184256>
Maemo was marvelous for the first iteration
<samueldr>
that it sure was
<samueldr>
I had the N800 when it was new
<samueldr>
even got a couple friends around me interested in it, not all of them being total geeks
<samueldr>
at that point in time, an "internet tablet" was still an amazing new thing
<t184256>
Yeah. Had a N800 and an N900, they were quite different beasts
<t184256>
My point is, is Maemo sparked a couple of similarly sized efforts that also reused the traditional stack instead of piling up new alien stuff like crazy, that'd be freaking ideal
<t184256>
*if
<samueldr>
couldn't get n900 here, and if I would have, it wouldn't have worked well due to bands issues :(
<t184256>
But, since it didn't happen, the pessimist in me is afraid of the 'Linux desktop'-style scenario
<samueldr>
what I hope makes the difference here is that I want, as a goal, to make ports as cheap as possible
<samueldr>
I'm willing to compromise on the ideal of mainline free libre oss everything
<samueldr>
I rather have an install base of OEM kernels with some blobs to create a mass of users
<t184256>
As in, more DEs than one can even follow, all of them doing something different, all of them unpopular
<samueldr>
and *then* when the mass has enough inertia, working on the ideals
<samueldr>
(thanks, talking about it I think I finally put into words my approach)
<t184256>
Finally, someone who doesn't try to capitalize on 'libre everything' while sacrificing usability
<samueldr>
what good is a libre system that no one will/can use?
<samueldr>
I could have spent a godawful amount of time forward porting my zenfone 2 laser to mainline linux
<samueldr>
and likely lose support for some of the useful features
<t184256>
Gathering investments before going out in a puff of smoke, obvs
<samueldr>
and have no one to help
<samueldr>
meanwhile I have spent the least amount of time I could on the kernel port, it works with a chunk of evidence everything can be made to work well
<samueldr>
and I replicated the approach on 4 different android-based devices with success, in less time than estimated
<samueldr>
the oneplus-oneplus3 port was mind-blowingly trivial and quick
<samueldr>
(due to experience mainly I think)
<t184256>
makes sense, if you want stuff to work. does not, if you're, for example, pmos
<samueldr>
hm?
<samueldr>
I believe they're halfway torn in between, though they do have mostly OEM kernels going on
<adisbladis>
samueldr: Tbh the gemini porting experience was also pretty good
<t184256>
if your primary goal is long-term support, you want stuff mainlined
<adisbladis>
Except the obvious glaring omissions once you got into userspace :3
<samueldr>
adisbladis: glaring omissions? what do you mean?
<samueldr>
if you mean docs and porting guide: definitely!
<samueldr>
this is scheduled as the next big bit of work
<adisbladis>
samueldr: I mean like hybris not working
<samueldr>
ah, then that's something else :D
<adisbladis>
Yeah :D
<samueldr>
you're at the same place than I am
<samueldr>
and also, nice, I have not been able to work with MTK devices, I didn't know if there would be different stuff that wouldn't map
<t184256>
everyone wants different things and everyone does it differently. wish you luck bringing us all together
<adisbladis>
samueldr: Anyway, I'm hopeful to get hybris up and running once I get some more time to invest
<adisbladis>
I _know_ that our hybris stuff is working since it worked on Gemian with nix-built applications
<samueldr>
and one thing is clear: I don't spit on mainline. In fact I desire for mainline, but see that pragmatically we need a critical mass before working on that
<adisbladis>
(I even checked which libs were loaded at runtime to make sure we didn't get gemian impurities)
<adisbladis>
So I'm _very_ hopeful it's just a matter of getting that android container stuff running
<adisbladis>
Also my strace results would imply that it's the missing piece
<samueldr>
yeah, I have a big question mark about those things
<samueldr>
wondering how we'll end up implementing that
<samueldr>
though also have time set aside exactly for that
<adisbladis>
samueldr: Imho we should do the same as Halium