Author: allison.122

Placeholder for now

by

Obviously I haven’t been updating this in a while, so this is a brief placeholder as of now.

Xilinx Radio Frequency System-on-Chip (RFSoC) carrier board in a custom 16-slot crate based on CompactPCI-Serial, for the PUEO experiment.

High Energy Light Isotope Explorer master trigger, a custom Xilinx Artix-7 design.

 

RAdio DIgitizer and Auxiliary Neutrino Trigger (RADIANT, and yes that took effort), a 24-channel GSa/s digitzer for the Radio Neutrino Observatory using custom ASICs (the LAB4D referenced below), SAMD21 microcontroller, Artix-7, and 2 auxiliary Lattice FPGAs to reduce pin count.

I’m currently involved in hardware/firmware/software design with a few projects:

http://helix.uchicago.edu/ : the High Energy Light Isotope Explorer

https://www.phys.hawaii.edu/~anita/new/index.html  The Antarctic Impulsive Transient Antenna

http://ara.wipac.wisc.edu/home the Askaryan Radio Array

And I’m also working on designs for next-generation neutrino experiments, such as the Radio Neutrino Observatory (RNO) and PUEO, the successor to ANITA.

Recent publications:

Dynamic tunable notch filters for the Antarctic Impulsive Transient Antenna (ANITA) https://arxiv.org/abs/1709.04536

On ANITA’s sensitivity to long-lived, charged massive particles https://arxiv.org/abs/1807.08892

LAB4D: A Low Power, Multi-GSa/s, Transient Digitizer with Sampling Timebase Trimming Capabilities https://arxiv.org/abs/1803.04600

SURF/LAB4D readout weirdness, hopefully fixed

by

I think I’ve figured out the SURF/LAB4D weirdness.

It’s basically related to stopping SRCLK every time. The ‘load’ signal (/S) is derived from a falling edge detector on SS_INCR on the negative edge of SRCLK. On the last clock of each sample, we lower SS_INCR, which puts ‘load’ (/S) high on the first clock of the new sample, so we can just seamlessly stream out the data.

However, on the very last sample, SS_INCR still went low, because, well, it was just like any other sample. Then SS_INCR stopped. So ‘/S’ was left high that entire time, and the first new clock of SRCLK, in the next readout, caught ‘/S’ right away. Since ‘/S’ is derived from a falling edge detector, the extra clock with ‘S’ low didn’t do anything – the data just kept shifting out, and from the readout side, it just looked like everything happened a sample earlier than it really should’ve.

REGCLR wasn’t actually screwing anything up here – at reset, the SS_INCR edge-detection registers are both 0, but they take !SS_INCR as inputs. So the first falling edge SRCLK with SS_INCR low sets the first register to 1. The second register is still 0, so its Qb output is 1, giving a ’11’ input into the AND get, setting S low and /S high.

So the solution is just to not have SS_INCR go low in that last readout, and make sure that when starting a readout, the first SRCLK doesn’t actually do anything, because it takes 1 clock to actually load the shift register, like we expected. We do that by not incrementing the bit counter for the very first clock of a readout. So it looks like this.

lab4d_readout_with_srclk_stopping

SURF Firmware To Do

by

1: RFP testing

2: Fix the damn readout shift register to not be godawful

3: Test how the phase select bits map to the actual SST at the LABs

4: Clean up the readout reset stuff. Pass back actual FIFO state.

 

Chromium on PINE64

by

There’s no Chromium build for arm64, so trying to get Chromium on a PINE64 is a bit of a hassle.

Thankfully, armhf and arm64 binaries can easily coexist. So we go ahead and grab the armhf build from Ubuntu.

So install:

  • apt-get install binutils:armhf
  • Download chromium-browser and chromium-codecs-ffmpeg from Ubuntu
  • Download libgcrypt11 from Ubuntu
  • apt-get install libexif12:armhf libudev1:armhf
  • Install chromium-browser, chromium-codecs-ffmpeg, and libgcrypt11 (using dpkg -i)

Next, launch Chromium with

  • chromium-browser –disable-seccomp-filter-sandbox

I’m not sure why the seccomp filter sandbox blows up Chromium, but at least right now, I’m just leaving that option disabled. Seccomp filtering is a kernel option, so there’s probably something misconfigured in the kernel. Maybe. Dunno. Could be a chromium bug, too, there’s been one before.

The extra packages (exif12, udev1) are just because Chromium’s dependencies aren’t actually perfectly specified yet.

And yes, this really does work, considering this was posted from Chromium.

UBI on SPI flash finally working!

by

Finally have UBI actually working, I think!

Unfortunately it requires a number of changes to U-Boot. So I’m almost certainly going to fork u-boot-xlnx (actually, I already have) and push those changes there. Namely:

  • CONFIG_ENV_IS_IN_UBI doesn’t play well with when the MTD device is SPI flash – because the SPI flash doesn’t initialize itself during board bringup. This was first mentioned here: the obvious place to add the equivalent ‘sf probe’ was by creating an ‘initr_spiflash’ and inserting it into the init_sequence right before initr_env.
  • UBI in u-boot does not play well with 4K eraseblocks. I don’t know why – it just doesn’t work right. I’ve got a feeling is that it runs out of memory and silently Tells No One. This doesn’t matter anyway, since 4K eraseblocks are too small for UBIFS, so we didn’t want to use them in any case. So we need to apply this patch which thankfully applies cleanly against u-boot-xlnx.

It also requires a number of changes to platform-top.h in the U-Boot configuration area.

  • All of the stuff to enable environment in UBI.
  • An mtdids and mtdparts environment variable in CONFIG_EXTRA_ENV_SETTINGS. This means I have to completely undo the existing ones coming from platform-auto.h, but to be honest, that’s probably OK. Those, in general, suck horribly. I’ll probably just replace the whole thing.

So with that, you can actually load U-Boot, and set up the flash however you want it! Once I have things looking sane, I’ll probably set up a ubinized image for a one-time flash onto it, but it’s nice to see that it will eventually be working.

UUB Linux Development, continued

by

OK – so PetaLinux’s setup is starting to be a little clearer to me.

You can’t configure everything via the menu. But that’s fine, because u-boot’s configuration can’t all be set by the menu either. Any u-boot configuration changes (or device tree configuration changes) need to happen in subsystems/linux/configs. Device tree changes can happen in subsystems/linux/configs/devicetree/system-top.dts. U-boot configuration changes can happen in subsystems/linux/configs/u-boot/platform-top.h. Changes in those files will never be overwritten.

For some reason PetaLinux’s “automatic bootargs” doesn’t work right. It doesn’t choose the right UART.

Right now I’m trying to set up:

  • 1 flash partition for FSBL and u-boot. This will never be touched.
  • 1 flash partition for ITBs and U-boot environments, under UBI.
  • 1 flash partition for rootfs UBIs: 1 read-only, with squashfs, and 1 read-write, with UBIFS. Still thinking about this one.

Notes on UUB Linux Development

by

Linux on the UUB is going to be much harder than I thought.

PetaLinux is unfortunately a very, very simple tool – it seems like it’s intended to allow people to get up and running quickly, but not actually be able to configure anything intelligently. For instance, there’s no simple way to configure u-boot. At all. It’s Xilinx’s way, or you get no help at all. So, for instance, each boot you have to sit there for about a minute waiting for a boot attempt on the network to time out. No way to tell it “I don’t want netboot.” Sorry, folks, that’s it.

Running list of things I need to figure out:

  • We really want the rootfs to actually be a filesystem. We can’t afford to have the rootfs be entirely a ramdisk: we’re probably going to need lots of RAM for the actual event buffer. Rough estimates would be something like 144 MB. That’s a third of the RAM on the UUB. If we suck up 128 MB for a RAM disk, that only leaves 112 MB for the actual system to use. That’s really restricted.
  • We do not want to use the standard PetaLinux “flash partition” strategy. It’s really, really bad: it uses raw flash, which means any power failure can trash the entire thing, and uses no wear leveling at all. It’s just a bad idea.
  • The clear winner for flash filesystems is UBIFS, using the UBI (‘Unsorted Block Images’) layer.