<CCFL_Man>
zmatt: no poll. i just wanted to see if something was wrong
<CCFL_Man>
i'm rewriting the image to my sd card
<CCFL_Man>
should an 8GB linux image be a fat file system or some ext file system?
<zmatt>
ext4
<zmatt>
single partition
<zmatt>
that's the case for all images
<CCFL_Man>
ahh, ok. it won't be readable on my mac then
<zmatt>
extremely ancient images have a fat boot partition in addition to the rootfs partition, but it hasn't been like that for many many years
<zmatt>
correct
<CCFL_Man>
ahh, wow
<CCFL_Man>
i think Pi images are still FAT
<zmatt>
I don't really know anything about the rpi boot process... other than that the boot cpu is actually the videocore ("gpu") rather than the ARM processor
<CCFL_Man>
wow, thanks for letting me know. i did not know that either
<zmatt>
heh, yeah the rpi is not an ARM-based SoC, it's a VideoCore SoC with an auxiliary ARM subsystem
<CCFL_Man>
i wanted to do soundcard development on the BBB. a fellow from TI wrote a driver for an audio A/D converter. i want to lay out a board and see if i could get the driver working in alsa
<CCFL_Man>
oh wow
<CCFL_Man>
i may have copied the image to the sd incorrectly. i use /dev/disk2s1 instead of /dev/rdisk2
<zmatt>
that won't work
<zmatt>
you should consider using Etcher
<CCFL_Man>
yeah. i'm trying it the right way now
<CCFL_Man>
ok
<zmatt>
(etcher.io)
<CCFL_Man>
oh, even /dev/rdisk2 ?
<zmatt>
?
<CCFL_Man>
the latest etcher won't run on osx 10.10
<zmatt>
oh, annooying
<CCFL_Man>
i think i should use /dev/rdisk2 as the device
<CCFL_Man>
s1 is wrong
<zmatt>
yes, write to the entire disk, not to a partition
<CCFL_Man>
ok
<CCFL_Man>
brew has balenaetcher but macports doesn't
<CCFL_Man>
macports seems to break on older versions
<zmatt>
apparently Electron dropped support for 10.10
<zmatt>
sounds fancy... can't you just use jumper wires for prototyping?
<CCFL_Man>
i can do that, yeah, but i'm not sure how that'll work for higher sample rates
<CCFL_Man>
like 384k
<zmatt>
why on earth would you want to use that samplerate... are you doing stuff with ultrasonic?
<zmatt>
like, for audio for humans there's not really any reason to use anything higher than 48 kHz
<CCFL_Man>
up to 100 kHz. it'll be used to capture radio signals
<zmatt>
ah
<CCFL_Man>
it'll basically be a SDR for the very low frequency band
<CCFL_Man>
and the TI engineer wrote the driver using the BBB
<zmatt>
I can imagine the BBB being convenient for prototyping
<zmatt>
the default kernel is currently still 4.19 but there are packages for 5.x kernels (I noticed mention that that's what the driver targets)
<CCFL_Man>
yeah, i'll need to use the 5.x kernel
<zmatt>
in fact, this driver seems to be part of the 5.10-ti kernels, so you won't even need to compile it yourself
<CCFL_Man>
but the hope is that i can get a working alsa driver. the board will just have screw terminals for connections to the radio receivers
<CCFL_Man>
oh, really?
<zmatt>
hmm, but not sure if it's enabled in the kernel config
<CCFL_Man>
hmm.. that's true
<zmatt>
(though if needed it's really easy to use rcn's build scripts to make kernel packages with tweaked config)
<zmatt>
yeah it's not enabled in the config
<zmatt>
CCFL_Man: in case it's of interest, I do have this document regarding the audio interfaces on the BBB (from a hw point of view; not all configurations described are supported by drivers): https://pastebin.com/raw/37Vr51Wr
<zmatt>
(specifically, having the receive section asynchronous from the transmit section is not supported, so the rx hclk/clk/fs signals should be ignored)
dlan has quit [Ping timeout: 268 seconds]
<zmatt>
and I have this rather sparse outline for how to declare a soundcard in DT: https://pastebin.com/VmHHXagD ... I thought I had a more detailed example somewhere but if so I'm not sure where