INTL 3:770/1 3:770/3   
   REPLYADDR JL@gct.com   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  5b335c9a   
   REPLY:  48f6f8df   
   PID: SoupGate-Win32 v1.05   
   CHRS: LATIN-1 2   
   XPost: sci.electronics.design   
      
   On Sun, 22 Sep 2024 09:32:10 +0100, The Natural Philosopher   
    wrote:   
      
   >On 21/09/2024 20:56, 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.   
   >>   
   >I think the recommended technique is to disable all those and suspend   
   >any other threads that might be active or write only single threaded code   
      
   I think we'll go bare-metal on both CPUs, no RTOS, but we'll still   
   have interrupts so can't guarantee that all the code we need is in the   
   tiny cache. A separate small eeprom simplifies things.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 10/0 1 90/1 103/705 105/81 106/201 124/5016 129/305 153/757   
   SEEN-BY: 153/7715 218/0 1 601 700 840 870 930 220/70 221/1 6 360 226/17   
   SEEN-BY: 226/30 100 227/114 229/110 111 114 200 206 300 317 400 426   
   SEEN-BY: 229/428 470 550 616 664 700 240/1120 266/512 267/800 282/1038   
   SEEN-BY: 291/111 292/854 301/1 113 812 310/31 320/219 322/757 335/364   
   SEEN-BY: 341/66 342/200 396/45 460/58 633/280 712/848 770/1 3 100   
   SEEN-BY: 770/330 340 772/210 220 230 5020/400 1042 5058/104 5075/35   
   PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426