* samueldr
wonders if there is another setting to add or if this is sufficient
<samueldr>
it must be sufficient
andi- has quit [Ping timeout: 252 seconds]
<gchristensen>
so, what if, if no console is specified, all the /dev/tty*s are used? is that silly?
<samueldr>
maybe
<samueldr>
ttyS doesn't mean a VT console
<samueldr>
or let me rephrase
<samueldr>
not all consoles are tty
<samueldr>
the blutooth chip in one of my computer shows up as ttyUSB
<gchristensen>
ack
<gchristensen>
bad idea, then... pretty nasty idea.
<samueldr>
yeah, you might end up sending garbage through a modem
<gchristensen>
or worse... sensitive info
<samueldr>
[DON'T DO THIS] e.g. if you power down your phone, power it up with the two volume buttons pressed, it might boot in the qualcomm "fun" mode
<samueldr>
which IIRC shows up as a ttyUSB
<gchristensen>
why don't do it? :)
<samueldr>
it looks like the phone is bricked
<samueldr>
and unless you keep pressing power for IIRC longer than the usual reboot time, it'll look dead
<samueldr>
(but show up on usb)
<gchristensen>
oh haha
<gchristensen>
I don't suppose this works on an iphone :)
<samueldr>
probably not, probably not on non-NA-flagship samsungs either
<samueldr>
though maybe they also use that shortcut for their "fun" mode
<gchristensen>
it didn't do it, so not that :)
<gchristensen>
my bet is there isn't really a way to enter it
<samueldr>
guessing their DFU mode is enough
<samueldr>
DFU != recovery
<samueldr>
and fun tidbit, I know for the first ARM-toting iMac, not sure for the others, they can enter DFU mode too
<gchristensen>
there is an ARM iMac? :o
<samueldr>
nah, the silly chip
<gchristensen>
oh, the t2 thing?
<samueldr>
yeah
<samueldr>
I forgot the name
<samueldr>
since those chips, all macs boot the ARM part first and *that* chip starts the intel cpu
<samueldr>
I'm ambivalent on it
<samueldr>
I like the design, but it's got the fatal flaw of all apple ARM devices: completely locked
andi- has joined #nixos-aarch64
* samueldr
sees a repeating pattern in his tech choices
<gchristensen>
as a security device, it does make sense
<samueldr>
I disagree with proof: chrome hardware
<samueldr>
their design allows multiple levels of security without compromising the more secure ones
<samueldr>
I might get some details wrong, but I can try and explain in broad strokes
<gchristensen>
ahh like the let-me-do-it screw
<samueldr>
for one part, yes
<samueldr>
that's the "I reallt want to screw with the device" :)
<gchristensen>
lol
<samueldr>
that defeats all security, and even allows a user which defeated it to put it back
<samueldr>
e.g. once I have my own fancy firmware, I may as well add it back to keep it from being compromised
<gchristensen>
well 🍎 will never let someone take apart their device.
<samueldr>
this is 100% the right way to handle firmwares: do not disallow a user to go back to more security, especially write-security
<samueldr>
most android devices with the scary : YOU UNLOCKED FASTBOOT fail since they're permanently shown as disabled
<gchristensen>
agreed
<samueldr>
(and then you can't really mess with the basic bootloaders)
<samueldr>
chrome devices also have another level of security
<samueldr>
the developer mode
<samueldr>
this assumes the screw was never tampered with
<samueldr>
simply put, in the bootloader, you can trigger a menu which allows you to touch the OS in fun ways, the firmware then wipes the TPM, so anything encrypted is as good as garbage
<samueldr>
so the firmware is still legit 100% safe, but it tells the operating system: yeah, let 'em do what they want
<samueldr>
and is reversible without traces
<samueldr>
(if you modify the system, it won't boot)
<samueldr>
rephrasing: if you modify the system and turn developer mode off
<gchristensen>
that is really, really great
<gchristensen>
I like that a lot
* gchristensen
reads about TPMs
<samueldr>
having to buy a laptop, the choice for me would be between a librem and a chromebook
<samueldr>
I have an intel-based chromebook and the developer community is phenomenal for having ported tianocore on it
<samueldr>
well, I guess it's more of making tianocore work with everything, since tianocore is/was already a supported coreboot payload
<gchristensen>
ah, cool
<samueldr>
with coreboot, the laptop boots in record time... they had to add an artificial 2s delay to allow accessing the tianocore menu :/
<samueldr>
(going from memory, not 100% sure)
<gchristensen>
hah
<gchristensen>
I'd like my next personal laptop to be fere
<gchristensen>
but my immediately next laptop is going to be a work-laptop, XPS.
Piece_Maker has joined #nixos-aarch64
chris|_ has joined #nixos-aarch64
srk has quit [*.net *.split]
chris| has quit [*.net *.split]
Acou_Bass has quit [*.net *.split]
Piece_Maker is now known as Acou_Bass
chris|_ is now known as chris|
sorki has joined #nixos-aarch64
sorki is now known as srk
lopsided98 has quit [Ping timeout: 250 seconds]
lopsided98 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
maskerad has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<makefu>
samueldr: about the serial ... yeah i thought it was configured correctly already, looks like i only configured ttyS0 and tty0 ... i also think this changed at some point in the raspi 1 2 3 thing, however i need to check this with the raspi1 i still have in use
tilpner has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
worldofpeace has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 245 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
Acou_Bass has quit [Quit: byeeeeeeeeeeeeeee]
Acou_Bass has joined #nixos-aarch64
zupo has joined #nixos-aarch64
granra has joined #nixos-aarch64
<granra>
Is it possible to apply an fdt overlay when using extlinux.conf? I only know how to do it with boot.scr.
zupo has quit [Ping timeout: 272 seconds]
<sphalerite>
thefloweringash: btw nixpkgs has terminus_font which contains higher resolutions of terminus, which is a lot prettier than the ttf-console-fonts thing you use IMHO :)
<sphalerite>
(an actual raster font)
zupo has joined #nixos-aarch64
<lopsided98>
granra: No, AFAIK. I have been thinking about writing a patch for it, but haven't done it yet. On my RPis where I need an overlay, I use the Raspberry Pi bootloader without U-Boot, so I can specify the overlay in config.txt
<lopsided98>
Alternatively, you can manually merge the overlay with the device tree using fdtoverlay
<granra>
lopsided98: so merge the overlay and then run extlinux.conf in u-boot?
<lopsided98>
You replace the original dtb with the merged one, but its not that easy to do right now because the NixOS module gets all the dtbs from the kernel derivation
<lopsided98>
You could "wrap" (copy/symlink all the files into the wrapper derivation) the existing kernel derivation and replace the relevant dtb with the merged one. I haven't done this, so I don't have an example of exactly how this would be written.
worldofpeace has quit [Remote host closed the connection]
worldofpeace has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
<granra>
lopsided98: what about the ability to set fdtdir in extlinux.conf?