INTL 3:770/1 3:770/3
REPLYADDR JL@gct.com
REPLYTO 3:770/3.0 UUCP
MSGID: cc6b8583
REPLY: f158f9b4
PID: SoupGate-Win32 v1.05
CHRS: LATIN-1 2
XPost: sci.electronics.design
On Sun, 22 Sep 2024 09:33:48 +0100, The Natural Philosopher
wrote:
>On 22/09/2024 00:11, john larkin wrote:
>> On Sat, 21 Sep 2024 20:46:52 -0000 (UTC), Phil Hobbs
>> wrote:
>>
>>> 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.
>>>>
>>>>
>>>
>>> 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!
The boards in this series are about 17 square inches, usually 6
layers, and we'll have parts on both sides.
The CPU and big flash and small flash would fit inside the footprint
of the Ethernet connector! And cost a lot less!
--- 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
|
