<arianvp>
gchristensen: when you start up the rescue mode you hit C-B during boot screen
<arianvp>
then it drops you in an ipxe prompt
<arianvp>
you type > dhcp to get an IP, and then > chain <your_url>
<arianvp>
:)
<sphalerite_>
samueldr: what are your plans as far as getting a coreboot build with an alternative payload goes? I can't seem to get images with initrds working with depthcharge, and it's becoming more and more of a pain
<sphalerite_>
just wondering whether to pursue building it myself as well
<gchristensen>
arianvp: huh, I was never able to get to the console in time for me to be able to interfere with iPXE
alunduil_ has quit [Remote host closed the connection]
efraim has quit [Remote host closed the connection]
efraim has joined #nixos-aarch64
<samueldr>
sphalerite_: don't know yet, don't rely on me for coreboot/libreboot, in that regard I'm a bumbling idiot that hopes to build something...
<samueldr>
... but I'm not even sure what payloads are available for ARM!
<samueldr>
both libreboot and coreboot's documentation is... incomplete and/or so old it doesn't apply, it seems :(
<samueldr>
they both lack in different ways though
<samueldr>
and libreboot's most current snapshot won't build, but that's because the build system is being changed, and the documentation is severly lacking in how to build for a specific platofrm
vcunat has joined #nixos-aarch64
<samueldr>
later today I'll know if coreboot tries to be buildable
<samueldr>
if it does, my hopes is that 1) coreboot+depthcharge works (just works) 2) an alternative payload for ARM works properly
<samueldr>
in those alternative payloads, there is grub and u-boot, if grub doesn't work, I hope u-boot is still maintained; it may make nixos bootable on arm-coreboot boot the same way it does on other arm systems
<samueldr>
finally checked the status, looked into building coreboot's own gcc, and it seemingly built successfully overnight
<sphalerite_>
samueldr: FWIW coreboot+depthcharge and libreboot+depthcharge work fine for me, except when it comes to initrds
<samueldr>
yeah, that's why I'd like something else than depthcharge :)
<samueldr>
more nixos-y boot
<sphalerite_>
and that building images is a bit of a pain because you need to first wrap it in the u-boot header thingy and then sign that along with a command-line
<samueldr>
though, if it comes to it, it may force me to look into making nixos compatible with linuxboot/petitboot or other kexec "tertiar bootloaders" that exists
<samueldr>
tertiary*
<sphalerite_>
yeah I was hoping to get a kexec-based boot working
<samueldr>
adding compat. will probably be helpful in the situations where no upstream bootloader can't be built, and the classic nixos way to boot is still wanted
<sphalerite_>
only problem is that that requires an initrd >.>
<samueldr>
:)
<samueldr>
haven't looked into depthcharge, but in a normal kernel, can't an initrd *or an equivalent to it* be built in the kernel?
<samueldr>
(going from fuzzy memory)
<sphalerite_>
oooh, didn't think of that
<samueldr>
pretty sure that nixos' initrd may be too big
<sphalerite_>
I was just building it into the uboot image
<sphalerite_>
OH. I just saw… that my kernel config has initrd compression disabled
<sphalerite_>
and my initrd... is compressed
<sphalerite_>
>_>
<sphalerite_>
wait no
<samueldr>
that's counterproductive
<sphalerite_>
weird. the relevant options are displayed as =n in menuconfig's search, but marked with a * in the actual menu
<samueldr>
another option forces them on? (dunno much about the menu and config system of the kernel)
<sphalerite_>
well, you've given me another idea with the embedding thing so I'll try that out :)
<sphalerite_>
ok I understand what was going on with the options now. The options that were set to "no" were which compression to use by default, not which compression to support
<sphalerite_>
so it does in fact support all the types
<sphalerite_>
about to reboot to test the kernel with embedded initrd! The excitement is real :o
<samueldr>
:)
<samueldr>
I'm also looking at stuff for coreboot, another option may be to add petitboot as a payload
<samueldr>
though, it will need to fit in less than 4MB
<samueldr>
wow neat, coreboot lets me choose tianocore, but tianocore in the menus only allows IA32 and x84_64 builds
<samueldr>
ah, found how to get depthcharge in menuconfig; "build for chromeos" needs to be enabled
* samueldr
is suuuuure going to need to learn how to flash using the SOIC clip
<sphalerite_>
meh
* sphalerite_
could really use a serial line for debugging right now
<samueldr>
afaict they aren't available on consumer chromedevices :(
<samueldr>
I thought the servo headers wasn't available in most devices
<samueldr>
(though it's unpopulated)
<sphalerite_>
well I've found it in mine :)
<sphalerite_>
I'm getting a kernel panic with the initrd because init failed, but can't actually see how it failed because the stack trace pushes it off the screen :(
<samueldr>
got a high speed camera?
<samueldr>
dunno if the 120fps capture mode of modern high end smartphones can help in those conditions
<clever>
there is a kernel option to insert a delay between each printk
<sphalerite_>
that doesn't seem helpful, since the console is initialised by the time the error occurs
<samueldr>
hmmmmm, upstream coreboot with their own toolchain with default options won't build, as they are passing "-m32" to the arm cross-compiler
* samueldr
needs to read some more
<sphalerite_>
just the delaying doesn't seem to work
<sphalerite_>
hm, kexec doesn't seem to work either. No idea *how* it's failing though since I just get a black screen and a flashing USB light, and don't have a serial console :(
<samueldr>
fuzzy memory: isn't there a ram area that can be used by the kernel to keep failures for the next boot? maybe it needs specific hardware, but IIRC android does that
<sphalerite_>
samueldr: yeah that works with kexec
<clever>
sphalerite_: with some of my GPU's, the graphics state gets messed up upon kexec, and only ethernet works from that point onward
<sphalerite_>
hm, systemctl emergency doesn't seem to work right on the chromebook
<sphalerite_>
so many mysteries
<sphalerite_>
yay I got a kexec working
<samueldr>
don't leave us hanging, anything specific you did?
<sphalerite_>
make sure X doesn't start, systemctl switch-root to a tmpfs with bash as the init first
<sphalerite_>
still WIP
<clever>
oh, that switch-root sounds handy
<sphalerite_>
yeah I mentioned it during our chat yesterday
<sphalerite_>
hm. Is there something I could do while kexecing to get out the information I need (what's going wrong with init)?
<clever>
sphalerite_: i think a serial port is abotu the only thing that works there
<sphalerite_>
clever: what does the SEL stuff you mentioned earlier mean from a practical perspective? Will that make it easier for me to get to the serial port?
<clever>
if the right SEL line is activated, the serial port will be routed over the usb connector
<clever>
so you just cut up a micro-usb cable, and you have access to the serial port
<clever>
i think OMAP_UART_SW has to be pulled low, but i'll need to check datasheets
<clever>
sphalerite_: do you see the `DP3T switch` on the top-right of slide 18?
<sphalerite_>
it doesn't have a micro-usb port. Would one of the regular USB ports be the thing to use then?
<arianvp>
then you'll see the iPXE screen, and you can hit CTRL-B for iPXE repl
<sphalerite_>
oh… maybe I'm running a kernel without user namespacing >_>
<samueldr>
got back to coreboot building, I'm happy, chromeos bundles the config file in the built image, which includes the git commit ID used and the full .config :D
<sphalerite_>
samueldr: that is indeed helpful!
<samueldr>
I can compare to see how likely I am to brick if I flash my just build rom
<sphalerite_>
… nope, that's not the reason
<sphalerite_>
but unshare -U fails too
<sphalerite_>
oh. It's because of how I "booted" the system
<sphalerite_>
huh. I thought the stuff that happens in the initrd was roughly "mount root filesystem on /mnt or something, chroot into /mnt, exec next init"
<sphalerite_>
but now I can't create user namespaces because I'm in a chroot.
<sphalerite_>
so is the actual process mounting the filesystem directly on /?
<clever>
sphalerite_: it uses switch_root or pivot_root, rather then chroot
<clever>
which will swap the 2 mount points, and change the / for all processes
<sphalerite_>
with this setup I could also boot off the eMMC. Not without another storage device attached, but it's still better than nothing!
<samueldr>
hmmmm, I think I need to figure out where is the SPI flash before attempting to flash my rom...
<samueldr>
hmmm, bad news, the SPI flash is probably under a shielding cage
<clever>
samueldr: there may be a header that connects to it
<clever>
samueldr: and the cpu may have alternative ways of booting that can grant access
<clever>
samueldr: in the case of the raspberry pi, it can boot entirely over USB, and you can jam in a slim OS that is capable of reflashing the chips
<samueldr>
oh sure, but now finding the documentation may be harder :)
<clever>
what is the CPU?
<samueldr>
it's the veyron platform, veyron mickey, which is the chromebit CS10, CPU is RK3288
<samueldr>
almost the same thing than what sphalerite_'s chromebook is
<clever>
does the usb behave differently when you take it out?
<samueldr>
clever: it is! it's the write protect screw
<clever>
ah
<samueldr>
no, but it makes it possible to disable the write protect in flashrom
<clever>
what are the numbers on that last chip?
<clever>
its a bit hard to read
<samueldr>
that's unreadable by sight, that picture is 100× better than anything I could do
<samueldr>
the last few pics are alternate angles
<samueldr>
to make the light reflect differently, with locked focus on my phone
<clever>
part of the trick is to rotate it as you look at each digit
<clever>
and also to get the chip a little wet
<samueldr>
it looks like either RE1725 or HE1725 for the first line, which might as well be 25th week of 2017
<clever>
date codes arent of much use, we want a part#
<samueldr>
yeah
<samueldr>
though, its proximity to both the power jack and the split pad makes it a 50% chance of being the spi chip
<clever>
it kind of has too many pins to be spi flash, thats my feeling
<samueldr>
that's what I thought, but especially that it may be something power related, it's right next to the power jack
<clever>
i'm thinking power regulator
<samueldr>
oh, I think flashrom on chromeos can identify the exact chip maker and model, so it'll be easy to confirm once I connect that fiddly pigtail
<samueldr>
finally got it seated
<samueldr>
ah! probably is that chip
<samueldr>
flashrom identifies it as GD25Q32
<samueldr>
google image search shows me chips with the same scribbly G
<samueldr>
the four bits each side that looked like solder are the connectors, probably
<samueldr>
not THAT impossible to work with, but hmmm, SOIC clip won't help
<clever>
page 50 has another diagram
<clever>
with complete measurements
<clever>
and i just remembered
<clever>
the raspberry pi A, just directly connects the host mode usb port, to the cpu
<clever>
and with the right cable, you could OTG it, but the ID pin telling the cpu that an OTG cable is plugged in, isnt wired up
<samueldr>
oh, looks like u-boot has *some* veyron support
<samueldr>
but no speedy
elcid has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<samueldr>
sphalerite_: just so you know, since I don't have a way to unbrick cleanly, I'll be looking (later) at making it boot a petitboot or petitboot inspired setup...
<samueldr>
... furthermore, this'll make it more universal for chromedevice users that don't or can't flash