As this will be my first update, I would appreciate a quick confirmation:
yes, that is what it means. there is no update script this time, only a disk image
yes
in general, no, it will not be a total and exact restoration. more specifically:
WIFI configuration in particular will not survive. sorry!
the top level of ~/dust/data contains system-level configuration files that can be carried over:
editor.jsongrid-settings.statesystem.favoritessystem.modssystem.state. (<-this one includes clock settings and device port assignments, etc)in general, script-specific preset data under ~/dust/data/<script>/ should carry over, barring the case of breaking script updates.
many scripts will be fine to copy over. but these days, there are quite a few scripts that install their own dependency packages in the linux system when they are first run. (yuck!) so in general, i can only advise that scripts should be re-installed to a fresh ~/dust, then any favorite .pset or .pmap files you want to save for particular scripts can be copied over.
Thanks for the update. Just a little thing: there is a mismatch between file names of the disk image on github and in the docs, e.g. norns220306-shield-pi3-cs4270.tgz (github) vs. cs4720.tgz (docs).
oh! there shouldn’t be any specific .tgz-tagged references in the docs, just the callouts which encourage using the cs4720cs4270 images for older shields and the cs4721cs4271 (ah! typos discovered!) ones for newer (example), along with the pi3/pi4 consideration. since the norns220306 part of the filename will change with future updates, hardcoding it into the documentation leaves room for error. if you saw any .tgz references, implying an exact filename rather than this general guidance, please let us know where and we will correct it!
yes — standard is for the machined aluminum version of norns.
no worries tho! for pre-2022 shields running on a pi3, choose the cs4270 file for pi3 (the top one) 
the docs linked on that download page does this a bit, but we can also post a lil matrix on that page which gives direct “if you have ___ and ___ use ___”, if that’d help?
table made!
| hardware version | software version to download |
|---|---|
| pre-211028 shield with raspberry pi 3 | norns220306-shield-pi3-cs4270.tgz |
| 211028 revision shield with raspberry pi 3 | norns220306-shield-pi3-cs4271.tgz |
| pre-211028 shield with raspberry pi 4 | norns220306-shield-pi4-cs4270.tgz |
| 211028 revision shield with raspberry pi 4 | norns220306-shield-pi4-cs4271.tgz |
| machined aluminum norns (aka ‘standard’ norns) | norns220306-standard.tgz |
Thanks Dan 
Now i installed the right image. I flash the micro SD card with Etcher, and re-powers Norns Shield but keep getting the “Jack Fail” message.
Edit: apparently it helped to pull out all USB cables and try again. Now Norns boot how normal - but when i attach USB devices i get the “Jack Fail message”
Edit 2: did some more investigations. I am able to attach my Grid (Neo) and Nanokotrol2. But When i attach my UM-One interface, I get the “Jack Fail” message when sleep restarting.
Flashed the new image, everything working so far, but norns shield now takes a lot of time to boot up, anyone else having this same issue?
Jack Fail
I have the same “Jack Fail” issue when Korg nanoKONTROL 2 is plugged into USB at the start of Norns Shield (V210330). Other USB devices seem ok. Also the Korg works fine if I plug it in later. So far no other issues in my tests with different scripts, midi, recording etc.
File Names
The thing with the file names was badly described by me: it’s the numbers that are not the same in the docs and the file name on GitHub: 4720 vs. 4270. You can also see it in the screen shot above. Just a small thing really.
lolol ah geez, thank you so much. dang, shouldn’t do support right after waking up 
correcting now! corrected!
sorry to hear about the trouble – grabbing some gear to test out, hang tight!
Does this relate to shields only or should I do this for my factory Norns?
The benefits are only spelled about above in “computer-nerd” jargon 
As a regular person, what’s my reason to update?
Thanks 
I think the reason for updating a factory Norns is so that you can continue on with further later updates.
@alanza’s got it – there are also a few nice things in the 220306 update, like confirmation when deleting a PSET, more stable TAPE number auto-incrementing (so you don’t overwrite TAPEs with the same index), and a reversal of the param name collision errors which would cause init errors on scripts with overlapping params names (more background for the curious).
but yes, the most important bit to note is that after transferring the files you’d like to keep from norns to another computer, a disk wipe + fresh install with the new software is required for you to keep your norns up to date via the menu moving forward:
please let us know if you run into any other q’s!
seems related?
[ screen is blank after boot with 2+ USB devices · Issue #1488 · monome/norns · GitHub ]
@ngwese those URB errors…
[ed] sorry to be brief, i should mention that i’ve personally had no issues using several simultaenous devices including UM-1 with factory norns/CM3 on this kernel.
I will not be able to investigate more deeply until later this evening but I just preformed the following test:
I then booted the device multiples times:
I would not be too surprised if the new kernel behaves differently from the previous kernel when the device is starved for power. Given that we are also using a different driver to configure the codec I could also imagine that in the presence of under voltage conditions the new driver might not enable the codec.
Long story short I suspect these failures may likely be power related.
UPDATE: I should also add that I’ve observed that the new kernel is more willing to pull the CPU out of performance mode (which we set by default) and force it into on demand mode which drops the CPU clock speed by 50%. Previously this resulted in under voltage warnings and starving USB bus. If the device starts feeling sluggish or boots slowly with lots of USB devices plugged in that could also be an indicator of insufficient power.
The instructions for flashing a shield mention to chose the correct version depending on the codec. How do I find out which one I have? Bought mine from a maker, closed encasing. Is there a menu that shows that?
Thanks!
I’m not sure you can tell which codec you have from inside the software, but you can narrow it down a bit - is the charging port usb-c? That’s a pi 4. micro usb? That’s a pi 3b.
And when did you buy it? Unless it was very recently, you can narrow down the date, too 
Anyway, you won’t hurt anything by trying to flash the wrong firmware, it just might not boot / give you JACK FAIL / etc
i’ve deprecated the
werepository which had some outdated tests but also had some worthy engines. these engines (includingPolySubandPolyPercfromawake) now live in the core norns repository. there are a handful of scripts that usepolysub.luawhich is now located in the core. the fix: changeinclude('we/lib/polysub.lua')torequire('polysub')and all is well.
This includes KarplusRings, and now awake-rings doesn’t load, how it’s the new code supposed to be in this case: engine.name = 'KarplusRings' ??
You will need the cs4270 image - all the hardware that is in people’s hands today uses that codec. Only the 2022 rev shield boards use the cs4271.
There is no way to see which codec the device has from the menu but the codec is reported as part of the sound card description when by running the following in maiden’s repl: os.execute("aplay -l")
The output will look like this:
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpimonome [snd-rpi-monome], device 0: bcm2835-i2s-cs4270-hifi cs4270-hifi-0 [bcm2835-i2s-cs4270-hifi cs4270-hifi-0]
Subdevices: 0/1
Subdevice #0: subdevice #0
true exit 0
The charging port will help to identify the rpi3 vs rpi4 but that is completely independent of the which codec is on the shield. The most likely combinations as of now are rpi3+cs4270 and soon the 2022 rpi4+cs4271.