<samueldr>
(in case you want to get started before I'm available)
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<betaboon>
good morning
<clever>
morning
<betaboon>
samueldr: I'm using that commit on top of mobile-nixos master. building against nixos-unstable. doesnt work for me. not sure if it is due to wrongly configured aarch64 remote builder or due to wrong nixpkgs commit
<clever>
samueldr: i just realized, my custom bootcode.bin could add gpt support to the pi
grw has quit [*.net *.split]
samueldr has quit [*.net *.split]
Aleksejs has quit [*.net *.split]
grw has joined #nixos-aarch64
Aleksejs has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
<clever>
samueldr: reading the rpi docs more, it claims the spi interface can be clocked at up to 125mhz (and faster, if you overclock the gpu), but they only rate the IO pads to support up to 30.5khz (not sure where exactly that limit comes from)
<betaboon>
clever: where does it say the io pads support only up to 30.5 ? oO
<clever>
The practical SPI clock will be lower as the I/O pads can not transmit or receive
<clever>
signals at such high speed. The lowest SPI clock frequency with a 250 MHz system clock is
<clever>
30.5 KHz.
<clever>
from page 2`1
<clever>
21*
<betaboon>
yeah. as i read that sentence that just means: the lowest possible spi clock frequency (as in the highest possible speed_field) at a system clock of 250Mhz is 30.5Khz.
<clever>
oh wait
<clever>
yeah, i misread that
<clever>
so, the spi block can be anywhere between 30.5khz and 125mhz
<betaboon>
yeah sounds like it
<clever>
but, it can only be an spi master
<clever>
so it cant emulate an SD card
<betaboon>
do you wanna replace the spi-chip with a sd-card-reader ? XD
<clever>
i'm currently on page 51, reading all the gory details of the dma engine
<clever>
betaboon: we where previously discussing having something emulate an sd card, so another device would think the pi itself is an sd card
<betaboon>
ah ok. for what purpose ?
<clever>
so you can swap out the image without having to re-flash the card
<clever>
betaboon: also, have a look at page 5 of the pdf, that explains why the docs often give conflicting addresses for IO devices in ram
<clever>
so, you can tell it to copy 10 rows of pixel data, that are 5 bytes long each, and to add +16 to the source addr after each row, but +32 to the dest addr, after each row
<clever>
betaboon: i think the flashair only goes from card->cloud, and only supports fat32
<betaboon>
ah ic XD
<clever>
those types of devices tend to cheat, and read their own internal fat32, and upload it without the camera being aware
<clever>
and the "internet passthru" allows cameras that are aware of the extra features, to use it as a wifi card
<clever>
the stride stuff in the dma engine, allows many things
<clever>
the intended use, is to update a sub-section of an image
<clever>
for example, my main monitor is 1280x1024
<clever>
if i want to draw a 800x600 image to the screen, i would copy 800 pixel long segments, but increment the destination by 1280
<clever>
so it wraps around, and hits the same column, on the next row
<clever>
but, you can abuse it, and set a stride of 0, to make it write to the same addr infinitely
<clever>
which could be a fifo on a uart
<clever>
you can also tie the dma engine to the fifo full/emtpy signaling, so it will properly wait for the fifo to drain
<clever>
and it can dynamically adjust its priority on the AXI bus, to ensure the fifo never runs dry (or overflows)
<clever>
it also supports creating a linked list of operations for the dma engine to perform, so your instructions can be artibtraily complex
<clever>
and there are 16 channels, that can all be doing dma in parallel
<clever>
ahhh, the axi stuff will stall reads automatically, but the apb<>axi bridge cant, so you only need the special dreq channels when dealing with apb
<clever>
(i still have no idea WHAT apb actually is though, lol)
<clever>
i'm thinking of something that acts as a full memory card, but you can just point it to a .img on disk
<betaboon>
that would be neat after all
<clever>
aha, the dma engine even has a /dev/null destination, which the hardware specially handles, allowing it to read faster
<clever>
and the intended usage, is to read something via the L2 cache, to pre-load data into the cache
orivej has quit [Ping timeout: 240 seconds]
<betaboon>
clever: so you want to use something like this: https://www.sparkfun.com/products/9419 but instead of putting a sdcard in, emulate all the spi directly with a rpi, right ?
<clever>
betaboon: it doesnt have to be an rpi, but everything else is correct
<betaboon>
well yeah, something that can speak spi XD
<clever>
it could just be a micro-controller that can support up to 100mhz spi slave, plus usb2.0 slave
<clever>
it would need a limited understanding of the SD protocol, along with the ability to stall reads
<clever>
then it can relay everything out the usb, and reply when it gets a block from the host disk
<clever>
of note, both the rpi (and i think the avr) require that the spi clock be under half the system clock
<clever>
for the rpi, half of 250mhz is 125mhz
<clever>
but for the avr, half of 20mhz is only 10mhz
<clever>
and even if it could deal with the spi at 100mhz, it would be receiving 12,500,000 bytes per second, .... which would only leave you with 1 clock cycle to read the spi bus, and deal with it (if you want to keep the fifo in check)
zupo has joined #nixos-aarch64
<betaboon>
that somehow sounds like fpga-land ?
<clever>
that was also one idea we bounced around
<clever>
but a larger fifo, with the ability to just tell the host, "i got the command, please wait" would also work
<clever>
page 66 of the pdf starts talking about the SD controller within the rpi
<clever>
and mentions that it has its own clock, coming from the main clocking module
<clever>
betaboon: this is what ive been working on lately
<clever>
if you run nix-build -A firmware, you will get a result/bootcode.bin
<clever>
that is then capable of booting linux on an rpi
<clever>
and the source is all in plain view!
<betaboon>
nice
<clever>
the only part not open at that point, is the boot rom (a mask rom) which is etched into the cpu at the factory
<clever>
its primary job is to load bootcode.bin and execute it
<betaboon>
bbl
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
clever has quit [Ping timeout: 240 seconds]
clever has joined #nixos-aarch64
lopsided98 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 250 seconds]
lopsided98 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 276 seconds]
Thra11 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 245 seconds]
Thra11 has joined #nixos-aarch64
bdju has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bdju has joined #nixos-aarch64
<betaboon>
samueldr could you hit me it when you're around ? :)
zupo has joined #nixos-aarch64
* samueldr
strikes betaboon
* betaboon
is now awake xD
<clever>
samueldr: how big did you say a u-boot blob was?
<betaboon>
better than coffee
<samueldr>
clever: ~6xxKiB for sunxi with defconfig
<clever>
samueldr: what about without an SPL?
<samueldr>
oh
<samueldr>
unknown
<clever>
the rpi open firmware, takes an arm chainloader
<clever>
which it will just shove at physical address 0, and set the arm loose
<clever>
if i just replace that whole thing, with a u-boot
<clever>
and its already fully in ram, then you dont need an spl
<clever>
the current arm chainloader will read: cmdline.txt, rpi.dtb, zImage, from the SD card, and then execute zImage
* samueldr
is building u-boot for rpi3
<samueldr>
that image I figure will not need an SPL
<betaboon>
samueldr no that i have been granted access to the aarch64 community builder i tried to build `android-device` of examples/demo on mobile-nixos master + your linked commit (lightdm) applied on top against nixos-unstable. but it fails with `attribute 'targetPlatform' missing, at ... meson/default.nix:98:17`. any advice ?
<samueldr>
betaboon: is the nix output first tracing that it's cross-compiling? (we are)
<samueldr>
if so, then I guess we need to do something about that detection
<betaboon>
samueldr: yes it is
<samueldr>
right, so adding the aarch64 machine does nothing in this case, since mobile-nixos forcibly (and erroneously here) assumes cross-compilation
<samueldr>
personally, I just checkout the project on the builder directly, but that's because my internet upload speed is potato
<samueldr>
localSystem can/should always be set anyway
<betaboon>
i see. havent looked into cross-building alot yet.
<samueldr>
it's getting better, but still an uphill battle
<betaboon>
now its building. on the community builder :)
<betaboon>
thanks a lot
<samueldr>
betaboon: I think it was you who got a OP3 for this, right?
<betaboon>
samueldr: yep
<samueldr>
btw, both OP3 and OP3T were verified to boot the same kernel, and it was documented in other projects already as sharing the same builds
<betaboon>
i have one as my daily driver. and got a used one off of ebay for 35€ oO
<samueldr>
good pricing there :)
<betaboon>
yeah. was a no brainer XD
<samueldr>
I got one as a target for porting since it was revealed to be the most likely device to be unused in a drawer among european folks
<betaboon>
(it has a non oem screen tho. but it works :) )
<samueldr>
so, a likely device that a couple contributors would go on "oh, I have this"
<samueldr>
and frankly, it looks like a good device
<samueldr>
no experience with it outside of booting it to unlock the bootloader though
<betaboon>
it's a decent device. 6GB of ram and a snapdragon 820 (quadcore 2x2.15Ghz + 2x1.6Ghz) and usb-c
<samueldr>
yeah
<samueldr>
821 for the 3T
<samueldr>
but for all intents and purposes, a drop-in replacement here
<betaboon>
i was toying with the idea of having a nixos-environment on it, then connect it via usb-c to my office-monitor and connect bluetooth keyboard+mouse to it and have a full portable workstation XD
<samueldr>
does it have eDP out?
<samueldr>
finding information on the matter is EXTREMELY HARD on the internet
<samueldr>
from a quick search, no
<samueldr>
what I mean by "on the matter" is a list of devices supporting it
<samueldr>
when you search device-by-device generally you get a confidence level
<samueldr>
here it looks like 80% chances it cannot
<samueldr>
be wary, there are some usb dongles that purport to do that, and they do seem to work, even through micro-USB
<samueldr>
but in reality it's a custom chip that installs a package on the device to do screen mirroring through ADB
<betaboon>
yeah quick search makes me believe its not possible with this device
<betaboon>
meh. well i still have another usecase xD
<samueldr>
I got a razer phone 2 (cheap) this week _because_ it supports eDP out
<samueldr>
and verified it
<samueldr>
it does
<samueldr>
US/Canada razer.com shop has it at 299$USD 399$CAD
<samueldr>
though not sure yet it's a good mobile-nixos device, but it's at least a plausible one, since it has easy^W trivial bootloader unlock, and has sources
<samueldr>
but right now I'm having troubles getting it to build the kernel
<betaboon>
samueldr: https://webcache.googleusercontent.com/search?q=cache:uKhQrugW-BoJ:https://www.wikiwand.com/en/List_of_devices_with_video_output_over_USB-C+&cd=23&hl=en&ct=clnk&gl=de this has a list of devices supporting video-output via usb-c (way down there is smartphones)
<samueldr>
yeah, old deleted wikipedia page
<samueldr>
but it's not like a list of all devices