<DigitalKiwi>
i have to figure out what pins to connect anyway
<samueldr>
it really depends of the exact model
<samueldr>
and then of what board
<samueldr>
so yeah
<samueldr>
the gist of it is you connct ground to gound, tx to rx, rx to tx, and then NOT connect the 5V cable
<DigitalKiwi>
i have a rpi3b+ or rpi 3b currenly mucking around with the 3b
<DigitalKiwi>
why are there 4 but only use 3
<DigitalKiwi>
for other boards?
<samueldr>
other uses
<samueldr>
I *think* the pi can be powered through it correctly, but I'm not sure
<samueldr>
but... sometimes RX and TX are not trivially labeled on the cable so you may end up connecting TX to TX and RX to RX... not a huge deal it just won't work as expected
<samueldr>
swapping them will fix it
<clever>
something ive been playing with here, and just got working nicely, auto reboot
<samueldr>
john nettleton is a known person in ARM stuff AFAIK
<thefloweringash>
What are the expected changes?
<samueldr>
that's the only thing I know
<samueldr>
but it was known that the early boards were going to be different than the final
<samueldr>
but not how
<samueldr>
so I'm looking forward about *knowing* about the coming revision, if it makes more sense :)
<thefloweringash>
There’s a long list of errata on the SolidRun side, which they really should fix. Haven’t heard anything about the NXP side
<samueldr>
haven't kept up to date really
<samueldr>
still would like an ARM workstation at home
<samueldr>
glad the laptop is more than passable
<thefloweringash>
I hope this doesn’t mean running Linux on the pre production version will become difficult
<samueldr>
well, it shouldn't, you have a static device tree describing the hardware and the kernel will load it to know how it's setup
<samueldr>
right?
<samueldr>
riiiiight?
<samueldr>
(that's sarcasm)
<thefloweringash>
Will arms ever work like this?
<samueldr>
yes
<samueldr>
they already do
<samueldr>
except it's not a device tree
<samueldr>
it's ACPI
<samueldr>
:^)
<samueldr>
those new ARM windows laptops
<samueldr>
but it should be like that
<samueldr>
I despise the decision of abusing the device trees to parameterize the hardware
<samueldr>
like how the kernel has shifted putting quirks into the code into writing them into device trees
<samueldr>
so now you can't just have a "one good description" of the hardware in your firmware
<samueldr>
no, you have to load the device tree that shipped with your kernel!
<samueldr>
imagine if you had to update your laptop's BIOS with each kernel upgrade!
<samueldr>
madness
<thefloweringash>
I’m going to assume this was necessary
<thefloweringash>
How do you know which quirks to apply?
<thefloweringash>
(If not tagged in the device tree)
<samueldr>
they already have to do that for ACPI-based hardware on x86_64
<samueldr>
there's a list of ways to do it "the right way"
<samueldr>
they generally use the strings in the bios that identifies the laptop or hardware
<samueldr>
so here it would be the main "compatible" string
<clever>
of note, the rpi SD controller, has a funky bug when dealing with 16bit writes
<samueldr>
like for the pbp, pine64,pinebook-prorockchip,rk3399
<samueldr>
oh
<clever>
if you write the top and bottom half of a 32bit register, as a pair of 16bit writes, the 2nd write is just discarded, if you do it too quickly
<samueldr>
there's nulls in there
<clever>
the nulls are a list
<clever>
dtc doesnt parse it right when decompiling
<samueldr>
pine64,pinebook-pro rockchip,rk3399
<samueldr>
with pine64,pinebook-pro they have WAAAY more to work with than on many ACPI-based devices!
<clever>
linux needs to specially handle the bug i mentioned, and defer a 16bit write, and batch 2 of them into a 32bit write
<samueldr>
because there's some that just ships "has to be filled by O.E.M" strings
<samueldr>
then they do other heurstics
<thefloweringash>
I'm super on board with the hardware contributing its own description. Having the kernel be a big hardware database is not great, even without the linux specific parameters in the device trees
<samueldr>
the kernel will always need to have a database, but it shouldn't be the one true source of truth
<samueldr>
well, I say database, but it's more about mappings of what hardware is what and how to know it
<thefloweringash>
but does it need to be so exhaustive in terms of having an entry for every model of computer ever
<samueldr>
right, yeah
<samueldr>
it doesn't
<samueldr>
and furthermore, if the kernel needs to add to the device trees, they should be overlays!
<samueldr>
dtbo!
<thefloweringash>
you'd need some interface to augment the hardware description when connecting peripherals to the expansion busses, like spi displays
<samueldr>
and the kernel should have a way to load them in the kernel rather than punt those to the bootloader stages!
<thefloweringash>
yeah, that
<samueldr>
here I was thinking about hacks that are "on the hardware"
<samueldr>
not even the external stuff
<samueldr>
since, you know
<samueldr>
there's already a way to load dtbos at runtime!
<samueldr>
that's a thin wrapper over the *existing* stuff in the kernel
<thefloweringash>
oh, I saw the 96boards articile but didn't notice the configfs interface wasn't in mainline
<samueldr>
hm?
<thefloweringash>
I skimmed a little too hard. I didn't realise you needed an out of tree module
<samueldr>
right
<samueldr>
though it's quite minimal :)
<samueldr>
I believe that one is *another* implementation
<samueldr>
they are linking to another one
<samueldr>
(though 404s)
<samueldr>
>> For example, "Transactional Device Tree & Overlays" describes an interface using ConfigFS, but this has not been merged to the upstream at the time of writing (2016-04-04).
wavirc22 has joined #nixos-aarch64
<samueldr>
I still have a big gap in groking device trees that hampers me when playing with stuff (though it's filling all the time)
<samueldr>
but that dtbocfg stuff seemed to work on mainline with the rpi3
<samueldr>
what didn't work is the display since all the things I was finding were for the foundation's kernel
<samueldr>
ah
<samueldr>
ANOTHER THING
<clever>
have you seen the dtparam commands that the rpi uses some?
<samueldr>
forking off the device trees
<clever>
181 dtparam audio=off
<samueldr>
that's just so rude
<clever>
184 dtoverlay spi-gpio40-45
<clever>
193 dtparam -R spi-gpio40-45
<clever>
194 dtparam audio=on
<samueldr>
now you have created "the mainline" and the "downstream" device trees
<samueldr>
when you write an overlay you have to target one of those
<clever>
i dont know exactly how this works, but this disables the audio port, then re-maps the audio pins to the spi controller
<clever>
then undoes it
orivej has joined #nixos-aarch64
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 268 seconds]
zarel_ has joined #nixos-aarch64
zarel has quit [Ping timeout: 258 seconds]
wavirc22 has quit [Ping timeout: 268 seconds]
cap_sensitive has quit [Ping timeout: 268 seconds]
cap_sensitive has joined #nixos-aarch64
cap_sensitive has quit [Ping timeout: 268 seconds]
<sphalerite>
yeah I need to get it into 8MiB together with coreboot and the kernel, so it's another bit tighter
<samueldr>
I haven't optimized it yet
<sphalerite>
but since it's so hardware-specific I don't mind e.g. creating device nodes with mknod or using devtmpfs instead of udev and stuff like that
<samueldr>
though the init itself is quite minimal, haven't verified with all the features, but at the moment it was a PoC the init + scripts in one static binary were about 900KiB
<sphalerite>
that could still be workable
<samueldr>
it likely would be worthwhile to add support for udev-less functionality
zarel has joined #nixos-aarch64
<samueldr>
or maybe with busybox's?
<samueldr>
ah, that's another bit that can be trimmed off, most of busybox
<samueldr>
when I say "fits in 16MiB with the kernel" it also includes helpful things like adb or rndis+sshd
<samueldr>
right now I'm still using the full blown busybox, rather than a minimal one
<clever>
right now, i have a 14mb zImage, that includes both linux and a very basic initrd
<samueldr>
MB or mb?
<clever>
-rwxr-xr-x 1 clever users 14M Jan 18 14:59 arch/arm/boot/zImage
<samueldr>
just making sure you're not flexing
<samueldr>
ah, and the OEM kernel suuuuuucks... there's almost nothing that can be disabled
<clever>
[LDR:read_file]: zImage: reading 14396664 bytes to 0x2000000 (allocated=0) ...
<clever>
that fat
<samueldr>
disable webcam stuff? there, adb fails
<clever>
samueldr: oh, do you know the trick for tracking down kernel size?
<samueldr>
there maye be multiple
<samueldr>
but there's a neat one on one of those linux wikis
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]