LnL has quit [Quit: exit 1]
LnL has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL- has joined #nixos-aarch64
LnL- has joined #nixos-aarch64
LnL has quit [Ping timeout: 272 seconds]
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
tilcreator has joined #nixos-aarch64
LnL- has quit [Ping timeout: 258 seconds]
<tilcreator> Got Mobile NixOS running on the 3G ram version of the PinePhone, will write a pr (or at least publish my changes) after confirming everything is working (accidentally forgot putting a rootfs on my sdcard)
<samueldr> great
cole-h has quit [Quit: Goodbye]
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 272 seconds]
tilpner_ is now known as tilpner
rajivr has joined #nixos-aarch64
zupo has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
pinkieval has quit [Excess Flood]
pinkieval has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-aarch64
lafa has quit [Read error: Connection reset by peer]
lafka has joined #nixos-aarch64
CyberManifest has joined #nixos-aarch64
patagonicus1 has quit [Quit: The Lounge - https://thelounge.chat]
patagonicus1 has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 260 seconds]
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-aarch64
CyberManifest has quit [Quit: Leaving...]
juliosueiras has joined #nixos-aarch64
<juliosueiras> the cable is still taking its sweet time to ship
<juliosueiras> so in the mean time, going to see if I can convert batocera-linux
<juliosueiras> configuration
<juliosueiras> to nixos
juliosueiras has quit [Remote host closed the connection]
juliosueiras has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
prusnak has quit [Ping timeout: 240 seconds]
taktoa[c] has quit [Ping timeout: 244 seconds]
chessai has quit [Ping timeout: 260 seconds]
feepo has quit [Ping timeout: 260 seconds]
c00w has quit [Ping timeout: 260 seconds]
dsal has quit [Ping timeout: 272 seconds]
prusnak has joined #nixos-aarch64
taktoa[c] has joined #nixos-aarch64
chessai has joined #nixos-aarch64
feepo has joined #nixos-aarch64
c00w has joined #nixos-aarch64
dsal has joined #nixos-aarch64
alp has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 256 seconds]
kurolox has joined #nixos-aarch64
<kurolox> Morning! I'm trying to install NixOS on my Odroid C2, but following the instructions in the nixos wiki isn't getting me anywhere (https://nixos.wiki/wiki/NixOS_on_ARM/ODROID-C2)
<kurolox> I don't understand the part about "Note this assumes u-boot is in partition 1 of your board's connected eMMC. If you haven't done that yet, you can build it with nix and then write it this fusing script" part. I don't even have an eMMC chip. Do I need a working NixOS installation in order to install it on my odroid?
kahiru has quit [Ping timeout: 240 seconds]
kahiru has joined #nixos-aarch64
<fps> just asking here because maybe there's more u-controller people here than on the main channel:
<fps> i wonder how i can get the teensyduo installed into the arduino-tool
<fps> i guess i'll have to create a mutable environment. maybe with FSH?
cole-h has quit [Quit: Goodbye]
<kurolox> oh wait, so I need to build uboot manually then proceed with the installation? Wouldn't uboot be overwritten by the provided .iso?
<kurolox> or do I need to follow the instructions, THEN install uboot? The link I've provided isn't clear about this
lafka has quit [Remote host closed the connection]
lafka has joined #nixos-aarch64
lafka has quit [Remote host closed the connection]
lafka has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 244 seconds]
kahiru has quit [Ping timeout: 272 seconds]
bbigras has quit [Quit: killed]
Ericson2314 has quit [Quit: killed]
smrtak[m] has quit [Quit: killed]
JJJollyjim has quit [Quit: killed]
bqy has quit [Quit: killed]
bennofs[m] has quit [Quit: killed]
Danct12[m] has quit [Quit: killed]
hpfr has quit [Quit: killed]
puzzlewolf has quit [Quit: killed]
pinage404[m] has quit [Quit: killed]
Ox4A6F has quit [Quit: killed]
fgaz has quit [Quit: killed]
cornu has quit [Quit: killed]
tnias[m] has quit [Quit: killed]
wrench[m] has quit [Quit: killed]
Smith[m] has quit [Quit: killed]
leonardp has quit [Quit: killed]
alexarice[m] has quit [Quit: killed]
hsngrmpf[m] has quit [Quit: killed]
kyren has quit [Quit: killed]
Dandellion has quit [Quit: killed]
ArtemVorotnikov[ has quit [Quit: killed]
thefloweringash has quit [Quit: killed]
danielrf[m] has quit [Quit: killed]
colemickens has quit [Quit: killed]
noneucat has quit [Quit: killed]
blitzclone[m] has quit [Quit: killed]
Jake[m] has quit [Quit: killed]
Ke has quit [Quit: killed]
tilcreator has quit [Quit: killed]
betrion[m] has quit [Quit: killed]
kurolox has quit [Remote host closed the connection]
kahiru has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
Mic92 has quit [Quit: WeeChat 2.9]
kahiru has quit [Read error: Connection reset by peer]
kahiru has joined #nixos-aarch64
betrion[m] has joined #nixos-aarch64
betrion[m] has quit [Remote host closed the connection]
colemickens has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
hpfr has joined #nixos-aarch64
yangm has joined #nixos-aarch64
fgaz has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
puzzlewolf has joined #nixos-aarch64
Smith[m]1 has joined #nixos-aarch64
betrion[m] has joined #nixos-aarch64
bqy has joined #nixos-aarch64
alexarice[m] has joined #nixos-aarch64
codyopel has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
Jake[m] has joined #nixos-aarch64
cornu has joined #nixos-aarch64
tnias[m] has joined #nixos-aarch64
Ke has joined #nixos-aarch64
blitzclone[m] has joined #nixos-aarch64
tilcreator has joined #nixos-aarch64
pinage404[m] has joined #nixos-aarch64
JJJollyjim has joined #nixos-aarch64
ArtemVorotnikov[ has joined #nixos-aarch64
smrtak[m] has joined #nixos-aarch64
noneucat has joined #nixos-aarch64
danielrf[m] has joined #nixos-aarch64
dtz has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
leonardp has joined #nixos-aarch64
Dandellion has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
hsngrmpf[m] has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
kyren has joined #nixos-aarch64
wrench[m] has joined #nixos-aarch64
goibhniu has joined #nixos-aarch64
evalexpr has joined #nixos-aarch64
lafka has quit [Quit: Leaving]
lafa has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
dtz has quit [Quit: Idle for 30+ days]
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
orivej has quit [Quit: orivej]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
alp has quit [Ping timeout: 272 seconds]
<tilcreator> I was trying to add the prebuild rootfs to my Mobile NixOS build like described here: https://mobile.nixos.org/getting-started.html#_using_a_pre_built_system_img , but the resulting image was still the same. I made shure that `local.nix` was used by puting a syntax error in it. I also tested setting the path to a random non existing file and it didn't fail on that. What is the correct way of adding the prebuild
<tilcreator> rootfs? (I'm building the disk-image for pine64-pinephone-braveheart)
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
juliosueiras has joined #nixos-aarch64
lafa has quit [Read error: Connection reset by peer]
lafa has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 264 seconds]
Thra11 has joined #nixos-aarch64
alp has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 244 seconds]
jumper149 has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 244 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
lopsided98 has joined #nixos-aarch64
kahiru has quit [Ping timeout: 244 seconds]
kahiru has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
kahiru has quit [Ping timeout: 260 seconds]
kahiru has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has quit [Ping timeout: 272 seconds]
Acou_Bass has quit [Ping timeout: 256 seconds]
Acou_Bass has joined #nixos-aarch64
kahiru has quit [Ping timeout: 256 seconds]
kahiru has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
kahiru has quit [Read error: Connection reset by peer]
<Thra11> samueldr: It looks like mobile-nixos's boot.postBootCommands might be missing this (or equivalent) from nixos/modules/installer/cd-dvd/sd-image.nix: `echo ",+," | sfdisk -N2 --no-reread $bootDevice`. So it's resizing the filesystem to fill the partition, but not first resizing the partition to fill the disk/card.
kahiru has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
<samueldr> Thra11: plausible, this targets the android-based devices where we CAN'T touch partition sizes
<samueldr> as in a big red interdiction sign
<samueldr> as in: your device may brick if you resize the partitino
<samueldr> partition*
Darkmatter66 has quit [Ping timeout: 256 seconds]
heywoodlh1 has joined #nixos-aarch64
heywoodlh1 has quit [Client Quit]
kahiru has quit [Read error: Connection reset by peer]
kahiru has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<Thra11> possibly could an optional extra for devices (like the pinephone) which support it then
<tilcreator> That would be nice (had to do that manually)
<samueldr> yes, it's a bug a this point
<samueldr> though I recall it resizing on my device
<Thra11> On mine it resized the fs by a few thousand k
<samueldr> I was stating the fact about android-based device as you need to know that if you don't want to brick devices :)
<samueldr> ah!
<samueldr> this is why, I've generally used the examples/demo system, in which this is enabled
<samueldr> hmmm
<samueldr> that makes no sense
<samueldr> as it's done in the nixos initrd, which we're not using
<samueldr> or maybe it never worked and I'm misremembering
zupo has joined #nixos-aarch64
<tilcreator> I'm generally confused on how to build the nixos-mobile rootfs, my first time really booting and posting nixos-mobile (on a PinePhone) was after writing the partition table myself and writing the boot parition and prebuild system parition manually on a sd card.
<tilcreator> My biggest problem rn is that I still don't know where to put the `configuration.nix` for building my own rootfs. Any help plz? I would love to help better the docs, but sadly I'm currently unable, because I don't know what to do eigher.
<tilcreator> The getting started documentation (https://mobile.nixos.org/getting-started.html) isn't really helping, the "Using a pre-built system.img" wasn't helping me since `system.build.rootfs` had no effect. Also I didn't know where to put the `local.nix`, my only help was the `.gitignore`.
<samueldr> I'll be able to give some guidance in a moment, need to do a couple things first
<tilcreator> no problem
<samueldr> okay, I have a few minutes
<samueldr> I would hazard a guess what the issue is
<samueldr> >> system.build.rootfs = fromPath ./system.img;
<samueldr> this forces a new value on top of an attr in `system.build`
<samueldr> except that `system.build`, which is a NixOS configuration option, is "only" an attrset
<samueldr> changing values this way is fraught with peril as there is no priority, and no validation that you are not overwriting an existing value
<samueldr> at some point in the past I had verified it worked for out uses
<samueldr> but it might be that this was dependent on an "external input" that changed, or even internals that changed for Mobile NixOS
<samueldr> so for the time being it looks like it might be broken :/
<samueldr> tilcreator: you probably should "forget" about it and instead, take your sd card, increase the size of the last partition, and `dd` the rootfs img onto it
<samueldr> anyway in both situations, using a pre-built rootfs wouldn't have allowed you to use your own configuration.nix options on top of it
<samueldr> as the rootfs is prebuilt
<samueldr> now, about configuring your system
<samueldr> this is a question wtih some unknowns
<samueldr> since you're most likely using cross-compilation, pre-configuring a system and nix-building it is most likely not a solution except for the simplest of systems
<tilcreator> I'm listening closely ^^
<samueldr> so the current method I've been using is copyhing the rootfs as I described (or flashing it to userdata for android-based devices)
<samueldr> and from there, do a "normal"~ish nixos configuration
<samueldr> so, just adding a /etc/nixos/configuration.nix file on the running system
<samueldr> and if you want to keep working from the "example demo" system
<samueldr> copy and adapt this whole file next to it and add it to imports: https://github.com/NixOS/mobile-nixos/blob/master/examples/demo/configuration.nix
<Thra11> Tried to do my first nixos-rebuild: "Warning: do not know how to make this configuration bootable; please enable a boot loader" (My configuration.nix has `imports = [(import <mobile-nixos/lib/configuration.nix> { device = "pine64-pinephone-braveheart"; })]; plus some boring userspace stuff)
<samueldr> ignore that warning
<samueldr> nixos does not know how to make it bootable
<samueldr> but the mobile init does :)
<Thra11> Ah ok :)
<samueldr> so basically my WIP "lived-in" mobile nixos system's configuration.nix import a basic configuration that way, then I add a configuration adaptaed from examples/demo, then I add whatever I need
<samueldr> yes, it sucks as a way to get yourself started, but this is also an area where basically no work has happened for making it user-friendly yet
<tilcreator> samueldr: thx, will try that and write a pr for the rootfs part
<samueldr> PR that does what?
<samueldr> (to see if you're launching yourself into something that is way hard)
<tilcreator> Add a note to the get started page about `system.build.rootfs` possibly not working
<samueldr> ah
<tilcreator> samueldr: (I very much appreciate someone stopping me ^^)
<samueldr> I would remove it outright for the time being, it's anyway not something we can rely on
<samueldr> and the real usefulness is limited
<samueldr> I can see it causing more headaches than otherwise, thinking about how you would "configure your own user" and it "wouldn't work"
<samueldr> (I hadn't thought of that!)
<tilcreator> I would replace it with a short note about replacing the very minimalistic rootfs with a prebuild one using fdisk, dd or similar
<tilcreator> Or is that process to differend on other devices than the PinePhone?
<samueldr> different by class of devices
<tilcreator> (If so I would place it in the PinePhone part of docs)
<samueldr> on android-based devices it's already a non-issue "just flash rootfs on userdata"
<tilcreator> What does the rootfs included in the PinePhone image do anyway, I thought at first, that it wasn't posting and / or I forgot to add a rootfs?
<samueldr> it's not the "rootfs included in the pinephone image", but rather the "default unconfigured state of NixOS"
<samueldr> couple that with an oversight with the boot splash
<samueldr> what you were seeing is the boot splash hogging the display
alp has joined #nixos-aarch64
<samueldr> because of that you never saw the getty (text terminal login screen) awaiting for a username/password
<samueldr> ... which there are none configured
<samueldr> aaand... this is not a trivial thing to fix from the default build, since we can't configure default options that could wreak havok on a user's own config!
<samueldr> so no default users
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
<samueldr> it might change at some point, depending on if a safe concept is found for implementing
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
<tilcreator> Ah, now I understand
orivej has quit [Ping timeout: 272 seconds]
<tilcreator> thx!
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
bennofs_ has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
heywoodlh has joined #nixos-aarch64
bennofs has quit [Ping timeout: 260 seconds]
justanotheruser has quit [Ping timeout: 260 seconds]
Acou_Bass has quit [Quit: ZNC 1.7.5 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.5 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.5 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
heywoodlh has quit [Quit: ZNC 1.8.2 - https://znc.in]
heywoodlh has joined #nixos-aarch64
<lovesegfault> samueldr: Any idea how I'd package something like this[1] for NixOS?
orivej has quit [Ping timeout: 264 seconds]
<samueldr> I'm not positive still because I haven't taken the time to do it
<samueldr> first you'll need to know whether you're using the raspberry pi 4's own bootloader firmware thing
<samueldr> or u-boot
<samueldr> you're most likely using the raspberry pi 4's own bootloader since u-boot is not merged yet
<lovesegfault> I'm pretty sure I'm not using u-boot
<samueldr> yeah
<samueldr> so you'll have to deal with the .dtbo file somehow
<lovesegfault> Which changed recently, ugh
<lovesegfault> I did look into the new way to use dtbo's
<lovesegfault> but I'm too unfamiliar with it, led nowhere
<samueldr> you probably want to use the raspberry pi foundation's methods
<lovesegfault> I imagine it'd be similar to what is described in the "With GPU" here
<lovesegfault> but with the new syntax
<samueldr> yeah
<samueldr> hm, I don't see any drivers
<samueldr> so is that only a device tree overlay?
<lovesegfault> AIUI with the new syntax I just don't set `base`
<lovesegfault> Are you talking about that driver I linked above?
<samueldr> possibly, I'll have to rework that section anyway for the new u-boot-based images
<samueldr> I don't see driver code, only an overlay
<samueldr> and a service
<lovesegfault> let me see what the "install.sh" does
<samueldr> yeah, dtc is what is used to compile a device tree
<samueldr> (or an overlay thereof)
<samueldr> so it's only a device tree overlay and a "service" to init it?
<samueldr> this might be the "harder" part
<lovesegfault> Apparently, yeah
<samueldr> overlay... fine, if you handle it through nixos' mechanisms
<lovesegfault> This would come in the form of a NixOS option, I think
<lovesegfault> If I were to upstream it
<samueldr> but I don't know what the other options end up doing
<lovesegfault> something like `hardware.hyperpixel.enable` would set this stuff up
<samueldr> ooh
<samueldr> I see
<samueldr> it's using the funky interface
<samueldr> I thought it was an SPI-driven LCD
<lovesegfault> What's the "funky interface" 🤣
<samueldr> so you just have to have those configs in the config.txt I guess
<lovesegfault> Right, AIUI that's "it"
<samueldr> that's why there's no drivers
<samueldr> only configuration and init
<lovesegfault> Aha
<samueldr> right, so you have that overlay, those config.txt settings, and the service
<lovesegfault> Funky indeed
<lovesegfault> I'm going to see what that service does
<samueldr> AFAIUI those three kind-of separate bits are your challenges
<samueldr> so you package the service, probably trivial
<lovesegfault> jeebus
<samueldr> yeah, sending init commands to the display
<lovesegfault> this code is pretty funny
<samueldr> get the .dtbo going... which is probably a "solved problem"... what's not solved is actually using it
<lovesegfault> "write some bytes somewhere"
<samueldr> and then the config.txt settings
<samueldr> yeah, display panels have some smarts and you're initializing them that way
<lovesegfault> Alright, all I have to do this weekend is that and solder 97 buttons
<lovesegfault> I think it's doable
<lovesegfault> FTR, I'm building this: https://booth.pm/ja/items/1619212
<samueldr> I don't think 97 buttons are part of that driver ;)
<clever> id say the SPI based panels are a waste of cpu resources
<clever> you need to drive them with software on every refresh
<samueldr> sure
<clever> DPI/DSI/VEC/HDMI based outputs are 100% hw accelerated
<samueldr> but they're common
<samueldr> so I was expecting to see one of them
<clever> i think the only reason they are common
<samueldr> lovesegfault: I have some jealousy
<clever> is because DPI takes up too many pins
<clever> and DSI is NDA'd up the wazoo
<clever> VEC is too low of a resolution
<samueldr> lovesegfault: those kits actually look good as portable pi setups, compared to the lazy bad jumbles you usually see
<clever> HDMI, is probably too high speed/spec
<clever> so SPI is the only way to get a decent resolution on few pins
<lovesegfault> samueldr: Yeah, I'm very excited
<samueldr> clever: cheap cheap cheap too I suppose
<lovesegfault> I will finally be able to use IRC from my bed
<clever> samueldr: of note, several game consoles (psp for example) and the official rpi touchscreen, are all DPI based
<clever> DPI seems like a cheap and very common protocol
<lovesegfault> I purchased it with tenso for US delivery and it was not super expensive and I got it relatively quickly
<lovesegfault> and it's super high quality
<clever> but due to the pin count, the official rpi touchscreen has a DSI->DPI adapter chip stuck on it
<lovesegfault> the PCBs are v. nice
<samueldr> clever: I bought a (shipped) raspberry pi 3B case + SPI-based display for 20$CAD
<Thra11> Does mobile-nixos do anything funny with boot.kernelParams, such that adding to it in configuration.nix doesn't work?
<samueldr> clever: I'm not sure how much more a DPI one would be
* clever looks
<samueldr> Thra11: yes
<samueldr> Thra11: no
<samueldr> Thra11: maybe
<samueldr> Thra11: you have to "re-flash" the "boot partition" if you need to change kernel parameters
<samueldr> clever: touch screen (resisitive though)
<clever> samueldr: https://www.adafruit.com/product/2453 $19.95 for a 5" 800x480 display i think
<samueldr> Thra11: that's because it's all built on the assumption that we can't control the hand-off from the bootloader to the kernel per-generations because of Android-Based devices
<samueldr> Thra11: still-to-be-implemented is a kexec-based boot option for generations, which would help for your particular issue
<samueldr> clever: 3" display
<samueldr> clever: or whatever the size of the top of a raspberry pi is :)
<clever> ah
<clever> this adafruit one is much bigger
<clever> let me find that other link...
<samueldr> clever: first hit for what I had https://www.aliexpress.com/item/32906213419.html
<samueldr> might have been cheaper than 20$CAD
<samueldr> not 100% sure it's the _same_ thing, but the same kind
<clever> ahhh, embeded into the case, nice
<samueldr> the case itself is quite nice too, there's a top of the case without the hole for the display
<clever> samueldr: wait a sec, those 4 chips on the board for your aliexpress link....
<clever> are those shift registers?
<clever> samueldr: has it arrived yet?
stiell has quit [Ping timeout: 272 seconds]
stiell has joined #nixos-aarch64
<samueldr> I have one from last year
<clever> samueldr: what are the part numbers on the 5 chips?
<samueldr> identical looking though
<samueldr> clever: small
<samueldr> 74hc40940
<samueldr> 74H4094D*
<samueldr> UGH
<samueldr> 74HC4094D*
<clever> >> 74HCT4094 is an 8-bit serial-in/serial or parallel-out shift register with a storage register and 3-state outputs
<clever> and thats the chip there is 4 of right?
<samueldr> yep
<clever> there is a decent chances thats just DPI again
<clever> and they are using the shift registers to drive it with fewer pins
<samueldr> haha lol
<clever> but that means that the SPI has to run at ~24x the clock
<clever> and it has to be driven by software rather then hw
<clever> does the lcd easily come off the pcb? does the lcd have its own part#?
<samueldr> does not come off
<clever> probably some double-stick tape
<samueldr> haven't looked, but yeah, it's "doesn't" come off
<clever> hmmm, it says 64k colors on http://www.lcdwiki.com/3.5inch_RPi_Display
<clever> so thats 16 bits per pixel
<clever> so its probably rgb565
<clever> which reduces the spi clock to ~16x the normal dpi clock needed
<clever> but with 4 * 8bit shift registers, its still a 32bit sample...
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever> looks like each chip is 3 main components, an 8bit shift register, an 8bit register (can hold the value while you shift), and an 8bit tri-state buffer (can either output nothing or the 2nd stage reg)
<clever> so you can cleanly shift a 32bit sample into the whole array, then latch it, and expose that one sample on all 32 pins
<clever> samueldr: can you see where pin 1 of each of the 4 chips is going?
<clever> ah, it says the driver IC is ILI9486 ...
<clever> 16-bit parallel bus transmission for fast transfer speed
<clever> 320x480 resolution for clear display
<clever> samueldr: ahhhh, its not DPI, its a dedicated LCD driver chip, with its own internal framebuffer ram
<clever> it even supports DSI! lol
<clever> page 41, thats definitely a DPI compatible interface
<clever> samueldr: is ILI9486 the 5th chip on the board, or is that something different? it doesnt look like it has enough pins
<clever> page 16 implies its either chip-on-glass or chip-on-flex, and its directly wired in parallel to all 1440 pins on the bare lcd
<craige> Built an image for Braveheart cleanly last night samueldr - unless I missed it the build docs don't include the need for building against unstable and how to do that if you're tracking stable. Would you like a PR adding those notes? May be applicable to other builds too?
Thra11 has quit [Quit: WeeChat 2.9]
juliosueiras has quit [Ping timeout: 256 seconds]