Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: john larkin <JL@gct.com>
Newsgroups: sci.electronics.design,comp.sys.raspberry-pi
Subject: Re: RP2040 reset idea
Date: Sat, 21 Sep 2024 12:56:53 -0700
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <l39uejlvspoestr2od47ob2klth3m1bf9u@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> <vcn82a$1net1$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 21 Sep 2024 21:56:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5c3e3db7ca5eb671571e8e2afa20111e";
	logging-data="1818266"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18t8sRa46n7Hp6cuIvRf9qG"
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:7o7NSJTxhZnJMGJUAB3WszBzOHM=
Bytes: 6674

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.