Deutsch English Français Italiano |
<vcokpc$24ol2$6@dont-email.me> 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: The Natural Philosopher <tnp@invalid.invalid> Newsgroups: sci.electronics.design,comp.sys.raspberry-pi Subject: Re: RP2040 reset idea Date: Sun, 22 Sep 2024 09:33:48 +0100 Organization: A little, after lunch Lines: 169 Message-ID: <vcokpc$24ol2$6@dont-email.me> References: <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> <vcn82a$1net1$1@dont-email.me> <l39uejlvspoestr2od47ob2klth3m1bf9u@4ax.com> <vcnbbs$1nt8a$1@dont-email.me> <bqjuej5vjt4urj5ds16hoi7f2n3elts7q9@4ax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 22 Sep 2024 10:33:49 +0200 (CEST) Injection-Info: dont-email.me; posting-host="b83977870f773d29c3595abc7b614c8d"; logging-data="2253474"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/qnh1UXu7wilA7ao7zsAmeTu/v0g78qa4=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:7IWFbcJwLbBTSSHzmdKLotDiVWs= Content-Language: en-GB In-Reply-To: <bqjuej5vjt4urj5ds16hoi7f2n3elts7q9@4ax.com> Bytes: 8392 On 22/09/2024 00:11, john larkin wrote: > On Sat, 21 Sep 2024 20:46:52 -0000 (UTC), Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> john larkin <JL@gct.com> wrote: >>> On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs >>> <pcdhSpamMeSenseless@electrooptical.net> wrote: >>> >>>> john larkin <JL@gct.com> 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. >>>>> >>>>> >>>>>> >>>>>> 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. And the price of a circuit board! > > 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. > -- “But what a weak barrier is truth when it stands in the way of an hypothesis!” Mary Wollstonecraft