INTL 3:770/1 3:770/3   
   REPLYADDR JL@gct.com   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  7baa214b   
   REPLY:  656db345   
   PID: SoupGate-Win32 v1.05   
   CHRS: LATIN-1 2   
   XPost: sci.electronics.design   
      
   On Sat, 21 Sep 2024 20:46:52 -0000 (UTC), Phil Hobbs   
    wrote:   
      
   >john larkin  wrote:   
   >> On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs   
   >>  wrote:   
   >>   
   >>> john larkin  wrote:   
   >>>> 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.   
   >>>>   
   >>>>   
   >>>   
   >>> It?s good to have a warm relationship with your linker mapfile. ;)   
   >>>   
   >>> Cheers   
   >>>   
   >>> Phil Hobbs   
   >>   
   >> Interrupts might get nasty, demanding swaps into the flash cache when   
   >> the flash is busy writing.   
   >>   
   >>   
   >   
   >That’s where the mapfile comes in. Assuming that you can update one flash   
   >page while updating another, that is.   
   >   
   >Cheers   
   >   
   >Phil Hobbs   
      
   The RP2040 usually executes code out of a small 16 Kbyte sram that   
   caches code from the flash, so users don't have obvious control over   
   which flash pages are being read. To write to flash, one has to do   
   things to ensure that nothing needs to read the flash chip for the   
   duration of the write.   
      
   That's a big hassle to save 24 cents of SPI flash chip off to the   
   side.   
      
   I guess the flash cache approach might trash IRQ latency. The flash is   
   4-lane SPI.  I think we can tell the compiler to put the ISRs and some   
   bits of time-critical code into the bigger (256 Kbytes) SRAM.   
      
   Our biggish sine lookup table could be plopped into SRAM too, to   
   reduce thrashing.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 19/38 90/1 105/81 106/201 129/305 153/757 7715 218/700 840   
   SEEN-BY: 220/70 226/17 30 100 227/114 229/110 111 114 200 206 300   
   SEEN-BY: 229/317 400 426 428 470 550 616 664 700 266/512 267/800 282/1038   
   SEEN-BY: 291/111 292/854 310/31 320/219 322/757 342/200 396/45 460/58   
   SEEN-BY: 633/280 281 412 418 420 509 2744 712/848 770/1 3 100 330   
   SEEN-BY: 770/340 772/210 220 230 5020/400 5075/35   
   PATH: 770/3 1 633/280 229/426