| Deutsch English Français Italiano |
|
<10m0fj99htak0q8j8i9mf00perdmmt7g2j@4ax.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: john larkin <JL@gct.com> Newsgroups: comp.sys.raspberry-pi,sci.electronics.design Subject: Re: RP2040 reset idea Date: Sun, 22 Sep 2024 10:51:35 -0700 Organization: A noiseless patient Spider Lines: 150 Message-ID: <10m0fj99htak0q8j8i9mf00perdmmt7g2j@4ax.com> References: <vcbkcl$3evhe$7@dont-email.me> <eaajej9hlmkdb4dbbdafiff63o549dlgas@4ax.com> <vccaag$3je29$4@dont-email.me> <pf0kejtj8b8riu7aa73ma5700o4bj0mr3e@4ax.com> <vci7f7$o1le$1@dont-email.me> <vcjb88$10tfo$5@dont-email.me> <b+f*To1Uz@news.chiark.greenend.org.uk> <jidrej5t93mud6asmgvis4rcetolmqa6ta@4ax.com> <vclv4m$1he37$2@dont-email.me> <6bntejlmcn474a4upiog3rc8seqcqi6e7p@4ax.com> <vcn3a6$1mla1$3@dont-email.me> <057uejd09fhuk7ktcqljburd969bv3vfdc@4ax.com> <vcokjs$24ol2$4@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 22 Sep 2024 19:51:38 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0e575bd28907a0d4d7c2e2db73b8b931"; logging-data="2423079"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KcBCqBJvucKNYF70/0PNI" User-Agent: ForteAgent/8.00.32.1272 Cancel-Lock: sha1:Ly05mTLrjJ1P/66g8Cg6fAA/T8o= Bytes: 7247 On Sun, 22 Sep 2024 09:30:52 +0100, The Natural Philosopher <tnp@invalid.invalid> wrote: >On 21/09/2024 20:43, john larkin wrote: >> On Sat, 21 Sep 2024 19:29:26 +0100, The Natural Philosopher >> <tnp@invalid.invalid> wrote: >> >>> On 21/09/2024 16:08, john larkin wrote: >>>> On Sat, 21 Sep 2024 09:12:06 +0100, The Natural Philosopher >>>> <tnp@invalid.invalid> wrote: >>>> >>>>> On 20/09/2024 19:00, john larkin wrote: >>>>>> On 20 Sep 2024 11:30:13 +0100 (BST), Theo >>>>>> <theom+news@chiark.greenend.org.uk> wrote: >>>>>> >>>>>>> In comp.sys.raspberry-pi The Natural Philosopher <tnp@invalid.invalid> 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. >> > >Oh. so you are rolling your own boards? I'm a circuit designer! I design boards. I was going to plop a Pico on my boards, as a component, but it's big and has the small flash and the USB connector is awkward, so we'll solder the CPU and flash and such to our board. > >Nice. I wish I were younger sometimes... Can't disagree about that. > >Too big for 2MYBTE flash? Wow. We will use an FPGA on some products, and store the big uncompressed configuration bitfile on the same flash. > >> >>> >>> 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. >> >Yes, but in my case that is OK. Its configuration data set up on a 'once >only' type basis during installation. And then very occasionally thereafter. > >WORM - write once, read many. > >And a single threaded code model. No worse than doing a floppy disk >write in the foreground (remember those days)...