Subj : Re: RP2040 reset idea To : tnp@invalid.invalid From : john larkin Date : Sat Sep 21 2024 12:43:58 XPost: sci.electronics.design On Sat, 21 Sep 2024 19:29:26 +0100, The Natural Philosopher wrote: >On 21/09/2024 16:08, john larkin wrote: >> On Sat, 21 Sep 2024 09:12:06 +0100, The Natural Philosopher >> wrote: >> >>> On 20/09/2024 19:00, john larkin wrote: >>>> On 20 Sep 2024 11:30:13 +0100 (BST), Theo >>>> wrote: >>>> >>>>> In comp.sys.raspberry-pi The Natural Philosopher wrote: >>>>>> On 19/09/2024 23:09, Lasse Langwadt wrote: >>>>>>> On 9/18/24 00:33, john larkin wrote: >>>>>> >>>>>>>> It looks like a USB memory stick. You can delete or add files if you >>>>>>>> want. >>>>>>>> >>>>>>>> It boots CPU 0 (the one we call Alice) from a file with the extension >>>>>>>> .UL2 >>>>>>>> >>>>>>>> Why   .UL2   one wonders. >>>>>>>> >>>>>>>> We'll put a bunch of files into the flash. Code for Bob, the 2nd CPU. >>>>>>>> An FPGA bitstream file. A prototype calibration table. A README file >>>>>>>> to explain everything in plain English. >>>>>>> >>>>>>> sure it's not UF2? >>>>>>> >>>>>>> https://github.com/microsoft/uf2 >>>>>>> >>>>>>> >>>>>> Definitely uf2 here. >>>>>> >>>>>> And no, you cannot 'delete or add files' to it. >>>>>> The action of pretending to download a uf2 file into what appears to be >>>>>> an empty drive, erases everything on it and programs the flash. >>>>>> >>>>>> There are no visible files to delete. >>>>> >>>>> Neat. So basically you throw some files at it, which causes a series of >>>>> block writes. UF2 picks out specially tagged block writes and uses that to >>>>> program the flash. It doesn't actually care what other stuff is written to >>>>> the flash as it ignores all of that, so it doesn't care about all the FAT >>>>> stuff or whatever junk your OS decides to put on there. >>>>> >>>>> Means you can write any kind of files to it and it'll only pay attention to >>>>> the specific tagged blocks. If the OS is happy to cache the medium (as many >>>>> do) you could maybe even reformat it as some other filesystem like NTFS and >>>>> it would still handle writing the UF2 file correctly. >>>>> >>>>> Theo >>>> >>>> My Pi guy says that you can only write one file, and the act of >>>> writing that file wipes anything that was there before. So the flash >>>> probably doesn't have a file structure, and the USB memory-stick write >>>> is, well, a sort of cheap trick. >>>> >>>> That's workable, if inelegant. We can pack everything we need into >>>> that one big file and users can upgrade box code in the field pretty >>>> easily. >>>> >>> >>> It gets nastier if you want to preserve config info across reboots. >>> It is possible to read and write areas of flash from the code, but its >>> no picnic. >>> And it gets wiped when new code is uploaded >>> >>> >>> It is an area I will have to tackle for one project tho. >> >> Yes, writing to flash from the running application is nasty. >> >> We have to calibrate each box. We'll store the prototype calibration >> table inside the big flash image. At factory test, we'll grab that, >> edit it for this particular unit, and save it to a small SPI eeprom >> chip. That costs 24 cents and one chip select pin. >> >> My guy says that there are a few magic integers at the start of the >> UF2 file that identifies it, well, as a UF2 file. That confirms that >> the Pico flash doesn't have a file structure, it just stores one giant >> chunk of stuff starting at the start. >> >> It's Windows who lies about it acting like a USB memory stick that >> stores files. >> >> We did consider saving the real cal table at some fixed physical >> address near the end of the flash , on the theory that nobody will >> ever write a bootable image that big. That might work. >> >That seems to be the case. > >I looked into it enough to see that it would be possible to store NV >data in a high part of the flash. > >I think that the runtime provides access to a memory location that >indicates the end of the uploaded flash image, so in theory flash above >that is free to write, with the proviso it has to be done in large >blocks on specific address boundaries. > >All this is at least Pi Pico specific anyway. We're using the RP2040 chip, so will have a huge flash chip. We will sometimes store an FPGA config file that could be too big for the 2 MByte part on the Pico. > >Will keep me busy through the dark winter days...:-) Storing anything in high flash still has the problem that you can't run flash-cached code while the write is going on, unless you are very careful. --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .