#apertus IRC Channel Logs

yes, I have something to share today :)

go ahead

i.e. how to properly boot and run an rp2 (rp2040 currently) without flash (and also without crystal) from another rp2

while I think that SWD is probably the best way to go, I wanted to see whether the SPI route is feasible and how much code/work is required to get that working

the flash less device then uses the rom code (bootrom) to load a second stage bootloader via SPI (normally from flash) which normally then continues with faster QSPI (at least six wires) XIP executing code from flash memory in place

so the best approach here is to emulate just enough to get the second stage bootloader running (boot2) and then switch to something custom to load more data into RAM

http://vserver.13thfloor.at/Stuff/PICO/custom_boot2_spi_min.tar.zstd

turns out, this isn't very complicated at all, but has some potential drawbacks compared to the SWD setup

then, to get more data over the connection, we need to program the SSI (the (Q)SPI peripheral) to use a higher clock rate and ideally DSPI (dual spi)

another disadvantage is that all data needs to be 'requested' from the flash-less device, and the other RP2 has to 'respond' to those requests

on the plus side, the boot2 bootup happens in less than 8ms and doesn't require anything special from the flash-less device

that said, I will next look at the SWD alternative and check how much needs to be done to get that working

So I as layman understand whats going on, the issue is that normally each rp2 needs a flash memory chip attached right?

yes, the rp2 is designed to 'boot' from either USB or a 'flash' memory of some kind

and still needs to be programmed somehow, so when changing the code for an rp2

we need to somehow

either via a separate USB or SWD connection

so for simple tasks, like for example watching buttons and dials and controlling LEDs

but whats the problem with just having 2 rp2s and 2 flash chips?

2x usb required?

right, I see

if we decide to go with 3 RP2s because they are cheap

and you need to keep all of them in sync

the size of the flash memory can be decided when choosing a chip so storing the firmware for n rp2s is no issue I assume

which should not be a big problem as the code on those is probably quite small

it require though to compile the MCU code for each rp2 and package everything together into some custom firmware image then for flashing right?

does this affect the hardware debugging capabilties in some way?

i.e. it builds the custom boot2 firmware and incorporates it into the flash image for the master

debugging usually happens over SWD, so that would be separate in the SPI case and would be a header to attach a pico probe

they would just be dual use and you want to disable the SWD upload on the master in the debug case

or have some kind of bootloader?

i see

Sounds good!

and to complicate things, there are 3 different version of that bootcode available

into what?

only if they have a flash memory

(this is what I mentioned as fragile setup above)

I would definitely give them flash - everything else seems a bit like asking for trouble

okay - how about using usb to program the other chips?

and having a programming firmware in which the main chip acts as a host

I mean for development that would probably the easiest option

and bit banging USB from the master?

that is true

and you have to 'write' the file to the disk

yeah that sounds like a bunch of work

well done!

anuejn: any news from your side?

how is the reverse engineering image sensor going?

I switched from USB to SWD pretty fast

I see

as USB always requires pressing keys and/or unplugging stuff and uploading files

(for development that is, via pico probe)

sounds good

please share! :D

someone made a demo of using the rp2035 to output mipi dsi to a raspberry pi and that might be a cheaper option than using an fpga

but its very unclear if it would work and I dont actually think that I would enjoy writing the firmware for that so I kinda shelved the idea for now

I actually spend most of my time writing on my thesis - If anyone feels like commenting on it, you are very welcome

is there a link somewhere?

sure, I guess I can have a look, not sure if I can provide any valuable feedback though like an art professor would ...

nice, was that successful?

so now I am a bit in crisis and re-evaluating my options for getting the data fast enough to a computer

I am unsure if thats possible with nextpnr

maybe Ill try to use my previous board revision with the zynq just for the ADC and the ecp5 for timming generation

ah and if you know any CMOS image sensors with analog outputs that would be highly interesting to me

are there any CMOS (not CCD) sensors with analog signals?

for example almost every canon sensor ever made (up until a few years ago)

I believe they did not have the in house talent / semiconductor processes to make nice ADCs so they always (?) used customized Analog Devices parts for off chip digitization

(c.f. https://magiclantern.fandom.com/wiki/ADTG)

well, there are (some) benefits to an external ADC

and... loads of downsides :D

BAndiT1983: you around?

feel free to dive deeper and continue the discussion though!

on using a raspberry pico without flash: have you looked at the rp2350 instead of the rp2040? rp2350 has a uart boot mode which the older rp2040 doesn't seem to have

felix_: yeah, but currently the rp2350 is not really available as chip ... we are also very interested in the B variants as well as the rp2354 with flash