Deutsch   English   Français   Italiano  
<vcokjs$24ol2$4@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: comp.sys.raspberry-pi,sci.electronics.design
Subject: Re: RP2040 reset idea
Date: Sun, 22 Sep 2024 09:30:52 +0100
Organization: A little, after lunch
Lines: 137
Message-ID: <vcokjs$24ol2$4@dont-email.me>
References: <biphejl03r86ebf5dkpcav9ud7u8vcjclj@4ax.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 22 Sep 2024 10:30:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b83977870f773d29c3595abc7b614c8d";
	logging-data="2253474"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/g2IyTWsl0OhS0YsVg0Q1igdj+BmtmTPA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:3SYXIHlW3XUsbioagRzG2TeXNXU=
Content-Language: en-GB
In-Reply-To: <057uejd09fhuk7ktcqljburd969bv3vfdc@4ax.com>
Bytes: 6874

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?

Nice. I wish I were younger sometimes...

Too big for 2MYBTE flash?  Wow.

> 
>>
>> 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)...



-- 
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell