kaspter has quit [Read error: Connection reset by peer]
anarsoul has joined #linux-rockchip
kaspter has joined #linux-rockchip
lurchi_ is now known as lurchi__
tl_lim has quit [Read error: Connection reset by peer]
tl_lim has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
nighty- has joined #linux-rockchip
nighty- has quit [Remote host closed the connection]
nighty- has joined #linux-rockchip
lurchi__ is now known as lurchi_
tl_lim has quit [Read error: Connection reset by peer]
tl_lim has joined #linux-rockchip
VargaD has quit [Ping timeout: 240 seconds]
VargaD has joined #linux-rockchip
anarsoul has quit [Ping timeout: 265 seconds]
tl_lim has quit [Ping timeout: 260 seconds]
tl_lim has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
nighty- has joined #linux-rockchip
lurchi_ is now known as lurchi__
Guest43305 has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 240 seconds]
vstehle has joined #linux-rockchip
anarsoul has joined #linux-rockchip
Guest43305 has quit [Ping timeout: 240 seconds]
hanetzer has quit [Ping timeout: 268 seconds]
hanetzer has joined #linux-rockchip
tl_lim has quit [Read error: Connection reset by peer]
rj1_ has joined #linux-rockchip
hanetzer has quit [Quit: WeeChat 2.1]
hanetzer has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
cyteen has joined #linux-rockchip
BenG83 has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
<Ke>
https://www.chromium.org/chrome-os-devices-and-kernel-versions "On ARM devices we’ve started integrating firmware and kernel patches supplied by ARM. Development is still ongoing so release timelines have not been finalized. ARM devices will receive updated firmware and kernels before they enable virtualization features."
<Ke>
(2018-Feb-22: Updated to describe plans for ARM devices.)
<Ke>
so I guess no hurry to update yet
nighty- has quit [Quit: Disappears in a puff of smoke]
<maz>
I don't see the connection between spectre mitigation and virtualization, but hey, whatever...
<Ke>
doesn't virtualization require some trustzone code that might be vulnerable to spectre, I don't know though what it the virtualization used for
<maz>
spectre v2 mitigation requires secure firmware to be updated with arch_workaround_1 support. that's completely otherogonal to virtualization (and KVM does have support for calling into it, and offers the same service to guests).
<phh>
Ke: maz if you only run managed code, you can protect against spectre in the VM
<phh>
with native code, not so
<maz>
phh: indeed. but I seriously doubt chromebooks only run JIT-ed code...
<Ke>
I thought there is some sort of code in the secure fw to manage the vm page tables
<maz>
Ke: fsck no. that's why you have stage-2 translation.
<Ke>
who is maintaining that, the hot linux?
<phh>
maz: question is about untrusted code, and well, until android apps, I think yes everything was JIT-ed
<phh>
that's no longer true with android apps though
<phh>
(it was better at the time of the NaCl ARC)
<maz>
Ke: who is maintaining what?
<Ke>
the stage-2 translation tables
<Ke>
are those mapped to the host OS
<maz>
in general, the hypervisor does. with KVM, that's the host kernel.
<Ke>
I had the idea that host linux could not do that directly
BenG83 has quit [Remote host closed the connection]
Substring has joined #linux-rockchip
Easyfab has quit [Quit: Leaving]
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined #linux-rockchip
TheKit has quit [Ping timeout: 240 seconds]
BenG83 has joined #linux-rockchip
gnufan has quit [Ping timeout: 260 seconds]
TheKit has joined #linux-rockchip
gnufan has joined #linux-rockchip
gnufan has quit [Ping timeout: 256 seconds]
gnufan has joined #linux-rockchip
Substring has quit [Quit: Leaving]
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined #linux-rockchip
gnufan has quit [Ping timeout: 260 seconds]
<sphalerite>
I've got a C201 which I'm running linux on. With a custom-built kernel (but no patches) everything works fine, but the kernel from my distro (quite a vanilla build) only boots very unreliably — it seems to depend on me plugging in the SD card with the root filesystem on it in at the right time.
<vagrantc>
sounds familiar
<sphalerite>
Any way I can debug this? Supposedly there's a header with a serial interface inside, but the contacts are so tiny that I don't think I can make any use of it
<vagrantc>
well, i haven't bothered with the custom-built kernel ...
gnufan has joined #linux-rockchip
<vagrantc>
you can boot a kernel in a special mode to get a serial console out of one of the USB ports
<vagrantc>
well, a hacked up usb cable
<sphalerite>
oooooh that's good to know. Do you know of a tutorial or something?
<mmind00>
sphalerite: and of course that is in mainline since 2015
vstehle has quit [Ping timeout: 265 seconds]
gnufan has quit [Ping timeout: 260 seconds]
<amstan>
sphalerite: how does your cmd line look? does it have a hardcoded rootfs, perhaps something like "mmcblk0"?
<amstan>
sphalerite: it's a known thing that the order the mmc drives enumerate in is not deterministic, if you boot with the sd card plugged in you could have mmcblk0 as the sd card and mmcblk1 as the emmc
<amstan>
but if you don't, your emmc might enumerate first as mmcblk0
<amstan>
way around that would be to use UUIDs or labels in your cmdline
<amstan>
or.. given that you're on a C201, using depthcharge: root=PARTUUID=/PARTNROFF=1
<amstan>
that makes depthcharge fill in the uuid of the partition following the kernel it just loaded
<vagrantc>
with linux 4.8, i actually managed to get eMMC to work on the c201/veyron-speedy ... but with newer releases it's so bad that it tends to hang the CPU
<vagrantc>
sometimes it allows rootfs on the microSD to work, as long as the eMMC fails only slightly badly
<sphalerite>
amstan: I guessed that might be the issue. I tried using the /dev/disk/by-id path previously but never seemed to work
<amstan>
sphalerite: i believe /dev/disk/by-id paths are "generated" (using symlinks) by udev, which is userspace
<amstan>
but the kernel needs to know the path way before that :)
<sphalerite>
didn't know about the depthcharge thing, that could be helpful! Although currently I'm testing kernels from a USB stick and keeping a reliably-working one on the SD card with the rootfs
<vagrantc>
well, if you're loading an initramfs...
<sphalerite>
yeah I am
<amstan>
if your rootfs is numerically the next partition on your drive, switching to root=PARTUUID=/PARTNROFF=1 is a noop
<vagrantc>
then userspace might work, depending on your initramfs
<sphalerite>
yeah it's nixos's initramfs which does run udev
<amstan>
vagrantc: i don't have much experience to what root= means when you do an initramfs
<sphalerite>
amstan: it's up to the initramfs to handle it in that case
<amstan>
yeah, exactly
<sphalerite>
also, depthcharge seems to prefer booting off an SD card over a USB stick, regardless of the priority values for the kernel partitions? :(
<amstan>
yeah... it probably simplifies the control flow
<amstan>
find a device, ok... there's a partition table, find the partition with the highest priority
<amstan>
otherwise you would need a union of all partition priorities from all drives
<sphalerite>
I suppose. It would make my life a lot easier though :p
<sphalerite>
oh yeah, are there any more sophisticated bootloaders available to use on the c201, maybe through chainloading from depthcharge?
<amstan>
i've heard people in here using kexec
gnufan has joined #linux-rockchip
<amstan>
there's also uboot, simon glass added rk support to it, especially for the 3288
<amstan>
libreboot? if you agree with their added "open sourceness", even though the depthcharge we ship already is all the way open
<sphalerite>
libreboot uses depthcharge as the actual loader too
<sphalerite>
u-boot would be good!
<amstan>
yeah, probably because they haven't bothered to rename it
<amstan>
sphalerite: anyway, i don't know much about uboot or how chainloading works
<vagrantc>
i would also love to see veyron_speedy u-boot support
<vagrantc>
is there any interactive prompt for depthcharge?
<vagrantc>
maybe i should experiment with kexec
<sphalerite>
nope just a few hotkeys
<amstan>
I think something got added recently for the kernelci.org stuff
<vagrantc>
that's what i thought ... which makes it really difficult to debug
<amstan>
but idk if veyron has support for it
gnufan has quit [Ping timeout: 265 seconds]
<amstan>
jwerner, any ideas?
<sphalerite>
I've got kernels kexec'd successfully on here iirc
<amstan>
\o/
<sphalerite>
I just don't know about getting a nice UI for it
<amstan>
sphalerite: anyway, but what's your annoyance with depthcharge? maybe I can help offer a workaround
<vagrantc>
my primary annoyance is you can't do anything other than boot, boot from some other device
<vagrantc>
how do you pass boot arguments?
<amstan>
it's part of the kernel partition itself
<vagrantc>
ah, right
aalm has joined #linux-rockchip
<vagrantc>
so if you typo'ed the boot arguments, you can't fix it without another computer
<sphalerite>
mostly just choosing between two external boot devices (USB stick and SD card) without unplugging them. Editable kernel commandline would be nice too
<amstan>
a thing i do frequently is netboot via depthcharge
<sphalerite>
depthcharge does netboot!?
<amstan>
yes :)
<sphalerite>
where :o
<amstan>
the production version doesn't include that feature for speed reasons
<jwerner>
I don't know what kernelci.org is and I'm not aware of any recent changes to depthcharge of that sort. there is a debug console that can be enabled if you recompile, but it can't really do much (e.g. not boot a kernel)
<sphalerite>
ah ok so I'd need to reflash for that
<vagrantc>
i knew the veyron_speedy and chromebook_jerry were similar, but i didn't realize it was just a few gpio differences ...
<amstan>
but the dev version (which kernelci.org has somehow) (or you can compile yourself) has all of that
<vagrantc>
network boot over ... wifi?
<vagrantc>
usb gadget?
<vagrantc>
serial?
gnufan has joined #linux-rockchip
<amstan>
usb, rk3288 acts like a host
<jwerner>
I don't think there are any differences between Jerry and Speedy that would affect firmware boot at all. A Jerry image should work just fine on it
<amstan>
you need an ethernet dongle
<amstan>
and the caveat is that the ethernet dongle must be one of 3 chips, jwerner can comment on which
<vagrantc>
r8152, perchance?
<jwerner>
on ToT, yes. not on the Veyron branch. but ToT images should run fine on it
<jwerner>
also not all models of it for the time being
<jwerner>
btw if you want to chainload u-boot (and you have a u-boot to chainload), you can do that without reflashing the existing firmware. there is an empty region for developer use on the flash and you can tell depthcharge to chain-load it from the developer screen. google for RW_LEGACY (just ignore the SeaBIOS part, it can load anything you put there, not just SeaBIOS)
<sphalerite>
neat!
alyssa has joined #linux-rockchip
<alyssa>
vagrantc: "with linux 4.8, i actually managed to get eMMC to work on the c201/veyron-speedy ... but with newer releases it's so bad that it tends to hang the CPU"
<alyssa>
and here I was blaming dwc2 for that?
<amstan>
anyway.. anyone interested about netbooting on c201 and has the right dongle?
<sphalerite>
only the former here. Probably.
<sphalerite>
I'm also a bit scaredy about flashing since I've never done a hardware reflash before and I don't have the kit for it and stuff, so I'd rather not need to do it
<amstan>
sphalerite: it's fair
<sphalerite>
there's probably someone at ScotLUG who could help with that though. I should ask.
<alyssa>
amstan: "libreboot? if you agree with their added "open sourceness", even though the depthcharge we ship already is all the way open"
<alyssa>
and we thank you for it \ o /
<alyssa>
libreboot on the C201 == the stock coreboot, with ChromeOS branding removed and that's about it
aleonard has quit [Quit: Leaving]
<amstan>
alyssa: i'm fine with your project itself, but i don't understand the need for it on veyron
<alyssa>
I mean, it's not my project, nor was I involved in the veyron work on it :p
<amstan>
i feel like it causes countless reddit threads of people bricking their device for installing something they don't really need (under the promise of "more free" software)
<alyssa>
oh?
gnufan has quit [Ping timeout: 256 seconds]
<amstan>
it's just a little fustrating, even for installing something else like archlinux-arm, it works like butter, with the stock firmware