RP2040 attached to Cytron "Maker Pi Pico" demo board

[MarkMLl]

This is more a status report than a request for help, since I've spent more time tinkering with this than I can afford.

The SD-Card pinning for this appears to correspond to init code of

// Alternative pinning as per the Cytron Maker Pi Pico schematic from e.g.
// https://www.electrokit.com/uploads/productfile/41018/MAKER-PI-PICO%20v1.2.0%20Schematic.pdf

    gpio_init_mask(0x27 << 10);
    gpio_set_function(10, GPIO_FUNC_SPI); // SCK
    gpio_set_function(11, GPIO_FUNC_SPI); // MOSI
    gpio_set_function(12, GPIO_FUNC_SPI); // MISO
    gpio_set_function(15, GPIO_FUNC_SIO); // CS
  #define SDCARD_CS_GP 15
    gpio_set_dir(SDCARD_CS_GP, true);

I'm able to compile a kernel and upload it using gdb/OpenOCD and a Picoprobe. Using a Saleae-style analyser I'm able to see card initialisation and collection of 16 bytes of CSD from a Sandisk card but reading the first block fails

2835540-2835502 SD card (SPI mode): Commands/replies: CMD9 (SEND_CSD): Ask card to send its card specific data (CSD)
2835540-2835502 SD card (SPI mode): Commands/replies: CMD9 (SEND_CSD): Ask card to send its card specific data (CSD)
2835540-2841574 SD card (SPI mode): Commands/replies: CSD: [254, 64, 14, 0, 50, 91, 89, 0, 0, 118, 178, 127, 128, 10, 64, 64]
2843175-2844900 SD card (SPI mode): Commands/replies: CMD17 (READ_SINGLE_BLOCK): Read a block from address 0x0000
2844938-2844900 SD card (SPI mode): Commands/replies: CMD17 (READ_SINGLE_BLOCK): Read a block from address 0x0000
2844938-2845498 SD card (SPI mode): Commands/replies: Block data: []
2845546-2845802 SD card (SPI mode): Commands/replies: R1: 0x00

Hence

FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2022 Alan Cox <alan@etchedpixels.co.uk>
Devboot
264kB total RAM, 160kB available to processes (15 processes max)
Enabling interrupts ... ok.
NAND flash, 1952kB physical 1277kB logical at 0x13018000: hda: 
SD drive 0: hdb: hdb1 hdb2 
Mounting root fs (root_dev=0, ro): failed

panic: no root

I've tried to use VSCode to wrap the debugger, but so far have not managed to get it to build in debug mode for reasons that elude me.

I'll try to get my head around driving gdb directly, but it's a long time since I've done this sort of thing.

---

A curious detail is that investigating the pinning with an appropriate continuity tester suggests that the SD-Card connector is wired

1 CS    GP14
2 MOSI  GP15
3 Gnd   N/C
4 Vcc   +3.3v
5 Clk   GP10
6 Gnd
7 MISO  GP12
8
9 CD, to Gnd if inserted. No connection to RP2040

However this is illusory and I mention it only to prevent others being misled: I believe that the correct wiring is as discussed above.

[davidgiven]

The fact that it's read the partition table suggests that it has succeeded in reading the boot block. I'm sufficiently out of context to be able to tell at a glance what the SD response means, unfortunately...

Also, isn't root_dev=0 the NAND flash? Is there a filesystem flashed onto the device? I have had a report from someone that the build script is broken and is generating invalid filesystems.

[MarkMLl]

The SD-Card has been prepared from the binaries at http://cowlark.com/2021-03-10-fuzix-pi-pico/index.html, I initially thought that your port hadn't yet been merged into the main Fuzix build. I've checked the first couple of blocks using xxd and they appear OK.

I was building the kernel initially from https://github.com/davidgiven/FUZIX but then moved to the main repo after I realised it had been merged: this didn't change the symptoms. If I forcibly enable debugging I can see that it's trying to use 0xffff for all the drive parameters, i.e. (I think) as shown by the SPI trace attempting to read block zero transfers no data but the code is trying to use the content of uninitialised RAM.

I've been going round in circles with this over the last few days, largely on account of having difficulty getting the wiring sorted out (I still don't really know what was misleading me there) but also because of lack of familiarity with cmake and VSCode. I'm a long way from being a beginner at this sort of thing, but am unfamiliar with these specific tools and am finding the learning curve steep.

I'll order an SD-Card socket so I can duplicate your original wiring but it will take a few days to arrive, and right now I really do have to get on with other things.

[EtchedPixels]

Your SD card appears to be working regardless of what your analyser thinks because it displayed the partition tables correctly and those are on block 0.

You then tried to mount the root file system from the internal nand flash, which apparently doesn't have one installed. Try hdb1or hdb2 if they have the root image on them ?

[MarkMLl]

I need at least a few hours to think about that one.

I can see the CSD being read, but not the block-zero partition table. However I think I understand what you're saying from the kernel boot output. Where is the root device set... I see #define CMDLINE in platform-rpipico/config.h but no indication of how it's patched in.

[davidgiven]

The boot device is in Kernel/platform-rpipico/config.h. Look for BOOTDEVICE. It's a sixteen-bit major/minor device number with the high byte containing the major; look in update-flash.sh for the numbers. For /dev/hdb2 you probably want 18.

[MarkMLl]

18 as in 0x0012 :-) That improves things somewhat:

SD drive 0: hdb: hdb1 hdb2 
Mounting root fs (root_dev=18, ro): OK
Starting /init

panic: no /init

OK, let's try again methodically. I've previously used your prebuilt filesystem at http://cowlark.com/2021-02-16-fuzix-pi-pico/fuzix.tar.xz, but presumably at this point I should be switching to one built with the modified config.h.

make world -j 4
./update-flash.sh
ls -lt | head
-rw------- 1 markMLl markMLl 1304064 Jun  8 18:54 filesystem.img
...
sudo dd if=filesystem.img of=/dev/sdd2 bs=1M

...quoth the panic: no /init

I must admit that I find this very disturbing. There's been enough people over the past year insisting that Fuzix on the RP2040 is the best thing since sliced bits... surely I'm not the only one who's actually tried running it?

[EtchedPixels]

The panic is issued when it tries to start /init off the filesystem, so it got somewhere in that it read the partition table, and it then found a valid file system (mounted OK) but failed to load init for some reason. It's very hard to guess in this case because there are no error messages printed from the lower levels to indicate why, which is weird because I would expect to see SD errors reported.

I don't know if the current git head works with a Pico. My Pico is otherwise engaged, and I don't go over each board and test it except at release candidate/release points.

[MarkMLl]

I'll try to look at head, but I'm a tyro when it comes to Git. I've got a Pico and Picoprobe on my desk, with Saleae-style and traditional logic analysers.

I'd note that I tried to get (the RP2040 variant of) Fuzix building with cmake, and while the build was OK I couldn't get debugging enabled.

This is all part of a larger exercise which I'm doing pro-bono for a journalist friend whose looking at the availability of debugging tools at the low end (i.e. Arduino etc.).

[TurBoss]

hello, I tried setting boot to 18

and got this message

 FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2022 Alan Cox <alan@etchedpixels.co.uk>
Devboot
264kB total RAM, 160kB available to processes (15 processes max)
Enabling interrupts ... ok.
NAND flash, 1952kB physical 1277kB logical at 0x13018000: hda: 
SD drive 0: hdb: hdb1 hdb2 
Mounting root fs (root_dev=18, ro): OK
Starting /init

panic: no /init

thanks

[MarkMLl]

As per my note of a couple of days ago. Sometimes a simple "me too!!!" really is sufficient :-)

Whatever, welcome to the community and let's see if we can lick this between us.

Anybody: what format is that .img file supposed to be? I've prodded it with the Linux file command and it only gets described as "Data"... is there any way it can be mounted on a PC for inspection?

[davidgiven]

Be careful which image you're writing; there are two for the Pico. There's the filesystem.img, which is an ordinary Fuzix file system, and the filesystem.ftl, which wraps it in the Dhara NAND FTL. See the image target in Kernel/platform-rpipico/Makefile. You can use Standalone/ucp to manipulate fileeystem images.

[MarkMLl]

I was using filesystem,img as per your instructions.

Here's the one from your website

~/Downloads/fuzix$ file *
doc:            directory
filesystem.img: data
fuzix.uf2:      data
README.md:      ASCII text

~/Downloads/fuzix$ cksum *
cksum: doc: Is a directory
3138808571 33553920 filesystem.img
1721089714 107520 fuzix.uf2
3643461524 3789 README.md

...and here's the most recent that I built a couple of days ago:

$ file filesystem.img
filesystem.img: data

[MarkMLl]

ucp can see the content of the image file:

$ /usr/local/src/pico/FUZIX/Standalone/ucp *img
Fuzix UCP version 1.4ac. Type ? for help.
..
ucp: ls
drwxr-xr-x  11     1         512 Jun 08  122   17:54  ./             
drwxr-xr-x  11     1         512 Jun 08  122   17:54  ../            
drwxr-xr-x   2    51        4096 Jun 08  122   17:54  bin/           
drwxr-xr-x   2    50        1536 Jun 08  122   17:54  dev/           
drwxr-xr-x   2    49         512 Jun 08  122   17:54  etc/           
drwxrwxrwx   2    48         512 Jun 08  122   17:54  mnt/           
drwx--x---   2    47         512 Jun 08  122   17:54  root/          
drwxrwxrwx   2    46         512 Jun 08  122   17:54  tmp/           
drwxr-xr-x   5    45         512 Jun 08  122   17:54  usr/           
drwxr-xr-x   3    44         512 Jun 08  122   17:54  var/           
-rwxr-xr-x   1     7        8650 Jun 08  122   17:54  init           

So init is there. Haven't gone any more deeply than that yet.

[TurBoss]

Question:

needs the root partition type be in 7e or 83?

Thanks

[MarkMLl]

Currently set to 83, changing to 7e (either for sdd2 only, or for both) results in no obvious change.

[davidgiven]

We know it's found and mounted the partition from the 'Mounting root fs... OK' line, so the partition type isn't relevant. I suspect something's bitrotted and the binary isn't loading any more. Try setting DEBUG at the top of Kernel/syscall_execelf32.c and it'll show more information.

[MarkMLl]

FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2022 Alan Cox <alan@etchedpixels.co.uk>
Devboot
264kB total RAM, 160kB available to processes (15 processes max)
Enabling interrupts ... ok.
NAND flash, 1952kB physical 1277kB logical at 0x13018000: hda: 
SD drive 0: hdb: hdb1 hdb2 
Mounting root fs (root_dev=18, ro): OK
Starting /init
_execve(/init)
failed: no dynamic area

panic: no /init

That's using your prebuilt filesystem.img to eliminate the possibility that I'm building it wrong:

# fdisk -l /dev/sdd
Disk /dev/sdd: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbf167bcc

Device     Boot Start   End Sectors Size Id Type
/dev/sdd1        2048  6143    4096   2M 7e unknown
/dev/sdd2        6144 71679   65536  32M 7e unknown
# dd if=filesystem.img of=/dev/sdd2 bs=1M
31+1 records in
31+1 records out
33553920 bytes (34 MB, 32 MiB) copied, 2.76776 s, 12.1 MB/s
# sync
# cksum filesystem.img
3138808571 33553920 filesystem.img

[MarkMLl]

I've finally worked out how to step through using either gdb or vscode: comment out the set(PICO_COPY_TO_RAM 1) line in CMakeLists.txt (and not replacing it with set(PICO_NO_FLASH 1). Is there any alternative to doing that which I haven't yet discovered?

I'll see if I can nibble away at the problem later, but am obviously not promising any magic results.

[TurBoss]

hello,

i used this instructions to debug the pi with gdb attached

https://circuitsgeek.com/guides-and-how-to/learn-how-to-program-and-debug-raspberry-pi-pico-with-swd/

edit: you can use a seccond pico with picoprobe as debugger

[MarkMLl]

That's basically a copy of the "official" instructions from https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf . I'm using a Picoprobe based on a Waveshare RP2040-Zero, patched to handle the LED properly https://github.com/MarkMLl/picoprobe_led

I have no problems at all with other demo projects, both C and Pascal, using gdb directly or with a GUI wrapper e.g. vscode or Lazarus.

However, if either COPY_TO_RAM or NO_FLASH is active it's not possible to set breakpoints, either using gdb or vscode.

Commenting out COPY_TO_RAM in the Fuzix build fixes it.

[davidgiven]

The reason for both of those is that if you try to write to the NAND flash filesystem, then the ability to run code from flash has to be disabled (for the duration of the write). So, it's easiest to just put the whole Fuzix kernel in RAM; faster, too. As you're using an SD card file system, then this isn't a problem. It'd be safer to disable the flash filesystem completely by commenting out the call to flash_dev_init() in Kernel/platform-rpipico/devices.c if you want to run out of flash, though.

[MarkMLl]

Will commenting flash_dev_init() out change the drive allocation? I'll probably find out shortly...

[davidgiven]

Ah. Mm. Yes, it will (block devices are allocated dynamically). That means you'll want to change the boot drive to /dev/hda2, which is 0x0002 IIRC.

[MarkMLl]

Yes, that looks good. I've forked to https://github.com/MarkMLl/FUZIX and will incorporate the changes I've made so far, which get the pins right for the Cytron board, sort out the drive/filesystem allocation to the position where it tries to load init, and optionally runs from Flash so that gdb and vscode debugging work.

It will need attention from somebody who's further up the cmake learning curve to control the debuggability based on whether Debug or Release mode is specified. An alternative to what I've done would be some way of postprocessing the debug symbols to compensate for the code being moved.

I've taken the liberty of adding a "Built" message to the main startup, immediately after the copyrights etc.

[MarkMLl]

I have NOT forked.

I can no longer build platform-rpipico, either from this repo or Yours (David), getting

...
Compiling TinyUSB with CFG_TUSB_DEBUG=1
Including custom CMake file /usr/local/src/pico/pico-sdk/src/common/pico_base/generate_config_header.cmake
ELF2UF2 will need to be built
-- Configuring done
CMake Error at CMakeLists.txt:21 (add_executable):
  Cannot find source file:

    ../version.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

-- Generating done
-- Build files have been written to: /usr/local/src/pico/FUZIX/Kernel/platform-rpipico/build

At this point I'm giving up, since while I'm interested in Fuzix as an OS project I've got vastly more important things to do than wrestle with Git and Github.

[davidgiven]

I have a PR pending to fix at least some of the Pico bitrot --- see #920. This makes it boot on my vanilla board using an old userland, so I know the kernel now works. There's still something wrong with the binaries themselves which I'll look at tomorrow.

@MarkMLl I haven't seen anything even slightly resembling your issues. How are you building it?

[MarkMLl]

@davidgiven The image was the one from your own download page.

Sorry, I'm out of this: I've got bookkeeping to do and my desktop PC blew up after a power glitch. I might look again in a few weeks or months to see whether things have been properly tested.

[davidgiven]

@MarkMLl Yikes. Let us know when you want to pick it up again.

The init load failure, BTW, happened because somehow the armm0 userland got reconfigured to generate bFLT binaries while the kernel was expecting ELF...

Edit: I beg your pardon, Fuzix executables, not bFLT.

[TurBoss]

got something:

after merge @davidgiven branch into local master, commneted // flash_dev_init();

then set boot to 0x0002 got boot!!!

but some tools give this error:

FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2022 Alan Cox <alan@etchedpixels.co.uk>
Devboot
264kB total RAM, 160kB available to processes (15 processes max)
Enabling interrupts ... ok.
SD drive 0: hda: hda1 hda2 
Mounting root fs (root_dev=2, ro): warning: mounting dirty file system, forcing r/o.
OK
Starting /init
init version 0.9.0ac#1
Cannot open file
Current date is Wed 2022-06-22
Enter new date: 
Current time is  1:42:59
Enter new time: 

 ^ ^
 n n   Fuzix 0.3.1
 >@<
       Welcome to Fuzix
 m m

login: root

Welcome to FUZIX.
# ls
FLAGRANT SYSTEM ERROR! EXCEPTION 3
 r0=2001A60E r1=2001A702  r2=00000001  r3=2001A840
 r4=2001A66C r5=2001A850  r6=20019238  r7=2001A86C
 r8=00000001 r9=200149B4 r10=2001A630 r11=20014FC5
r12=20018861 sp=2001A4A0  lr=20016FCB  pc=2001554A
PROGBASE=200149B4 PROGLOAD=20014FB4 PROGTOP=200249B4
UDATA=200149B4 KSTACK=20014AC4-20014FB4
user mode relative: lr=00002017 pc=00000596 isp=2001A5C8 brk=2001AD44

panic: fatal exception

thanks

[MarkMLl]

I'll try to take another look at some point- weeks rather than days, since apart from anything else I think that getting my alternative SD-Card configuration to suit the Cytron board into the master would be useful.

I just wish that this business hadn't sent me round so many loops blaming VSCode for being unable to set breakpoints etc... really the only thing I was confident in was the Picoprobe I'd wired up myself (and tested with multiple IDEs) and even there I had to modify the firmware to get the LED working (should one really trust a project that can't even flash an LED? :-)

[davidgiven]

> Welcome to FUZIX.
> # ls
> FLAGRANT SYSTEM ERROR! EXCEPTION 3

This one's because the bugfix I made to sh actually broke the other platforms and got backed out: https://github.com/EtchedPixels/FUZIX/commit/7a269851ae0a7c4c9c441492c483250075be9ed5

The bugfix is needed because sh does some really dubious things with managing memory, including assuming that the stack is above the heap (so it can distinguish between heap variables and stack variables). However, the pico port puts the stack below the heap, so we can use brk() to resize the heap. That's important to keep process sizes down, because by default the pico has no swap.

I'm not sure why this broke the other platforms. The only thing I can think of is if sh is something putting objects in global memory, but that should never happen? I'll need to investigate.

[EtchedPixels]

If it is doing that (and I think it maybe) then perhaps the fix is "is_on_stack(addr)" as some kind of mini helper. For Pico you can check top/bottom of stack range for the process and on traditional Unixlike mappings you can just do the usual addr > brk ?

[ngomez64]

Hello, I'm interested in Fuzix OS project. I'm new to cmake process and have ran into the same issue as mentioned in MarkMLl commented [on Jun 14].

... Compiling TinyUSB with CFG_TUSB_DEBUG=1 Including custom CMake file /usr/local/src/pico/pico-sdk/src/common/pico_base/generate_config_header.cmake ELF2UF2 will need to be built -- Configuring done CMake Error at CMakeLists.txt:21 (add_executable): Cannot find source file:

../version.c

Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

Would someone know what step/s I may have missed or where I maybe able to locate the missing source file "version.c" Thanks in adavace!

[davidgiven]

What command are you using to actually build it?

[ngomez64]

I used CMake 3.24.0 GUI version. Based on my reading of the Makelist file I suspect the Version.c is created when the project is properly built. Since I new to Makelist build process I made a "wrong turn" in the build process. I would be very grateful in any direction that could be provided at your convenience. Thanks in advance.

[davidgiven]

I have no idea what that is! But the kernel is supposed to be built with a simple 'make'... Look in the kernel/platform-rpipico/README.md and there should be full instructions there.

[ngomez64]

Update: I started over this time using CLI and I was able to get a bit further. Here is where I am at currently.

C:\SPB_Data\FUZIX-master\Kernel\platform-rpipico>make mkdir -p build (cd build && cmake ..) -- Building for: Visual Studio 16 2019 Using PICO_SDK_PATH from environment ('c:/SPB_DATA/pico-sdk') PICO_SDK_PATH is C:/SPB_Data/pico-sdk Defaulting PICO_PLATFORM to rp2040 since not specified. Defaulting PICO platform compiler to pico_arm_gcc since not specified. -- Defaulting build type to 'Release' since not specified. PICO compiler is pico_arm_gcc -- The C compiler identification is MSVC 19.29.30146.0 -- The CXX compiler identification is MSVC 19.29.30146.0 -- The ASM compiler identification is GNU -- Found assembler: C:/VSARM/armcc/10 2020-q4-major/bin/arm-none-eabi-gcc.exe Build type is Debug Using regular optimized debug build (set PICO_DEOPTIMIZED_DEBUG=1 to de-optimize) Defaulting PICO target board to pico since not specified. Using board configuration from C:/SPB_Data/pico-sdk/src/boards/include/boards/pico.h -- Found Python3: C:/Program Files (x86)/Microsoft Visual Studio/Shared/Python37_64/python.exe (found version "3.7.8") found components: Interpreter TinyUSB available at C:/SPB_Data/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB. Compiling TinyUSB with CFG_TUSB_DEBUG=1 cyw43-driver available at C:/SPB_Data/pico-sdk/lib/cyw43-driver lwIP available at C:/SPB_Data/pico-sdk/lib/lwip -- Configuring done -- Generating done -- Build files have been written to: C:/SPB_Data/FUZIX-master/Kernel/platform-rpipico/build make -C build make[1]: Entering directory /c/SPB_Data/FUZIX-master/Kernel/platform-rpipico/build' make[1]: *** No targets specified and no makefile found. Stop. make[1]: Leaving directory/c/SPB_Data/FUZIX-master/Kernel/platform-rpipico/build' make: *** [build/fuzix.elf] Error 2

C:\SPB_Data\FUZIX-master\Kernel\platform-rpipico

[MarkMLl]

I've been planning to revisit this for a few days but have held off because I am very suspicious of the behaviour of VSCode on my Linux system. For that reason I'm sticking strictly to a command-line build, and not attempting to modify the code to suit my board or to debug it.

Using a freshly-downloaded .zip of the sources, starting in ...FUZIX-master/Kernel/platform-rpipico

$ mkdir build
$ cd $_
$ cmake ..

# All OK to this point.

$ make
Scanning dependencies of target ELF2UF2Build
[  1%] Creating directories for 'ELF2UF2Build'
[  2%] No download step for 'ELF2UF2Build'
[  4%] No patch step for 'ELF2UF2Build'
[  5%] No update step for 'ELF2UF2Build'
[  6%] Performing configure step for 'ELF2UF2Build'
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/src/pico/FUZIX/FUZIX-master/Kernel/platform-rpipico/build/elf2uf2
[  8%] Performing build step for 'ELF2UF2Build'
Scanning dependencies of target elf2uf2
[ 50%] Building CXX object CMakeFiles/elf2uf2.dir/main.cpp.o
[100%] Linking CXX executable elf2uf2
[100%] Built target elf2uf2
...
[ 96%] Building C object CMakeFiles/fuzix.dir/usr/local/src/pico/pico-sdk/lib/tinyusb/src/common/tusb_fifo.c.obj
[ 97%] Building C object CMakeFiles/fuzix.dir/usr/local/src/pico/pico-sdk/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c.obj
[ 98%] Building C object CMakeFiles/fuzix.dir/usr/local/src/pico/pico-sdk/lib/tinyusb/hw/bsp/rp2040/family.c.obj
[100%] Linking CXX executable fuzix.elf
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: CMakeFiles/fuzix.dir/usr/local/src/pico/pico-sdk/src/rp2_common/pico_standard_link/crt0.S.obj: in function `__get_current_exception':
/usr/local/src/pico/pico-sdk/src/rp2_common/pico_standard_link/crt0.S:259: undefined reference to `main'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/fuzix.dir/build.make:928: fuzix.elf] Error 1
make[1]: *** [CMakeFiles/Makefile2:111: CMakeFiles/fuzix.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

# That's a sequence that worked properly when I started looking at it in June(?), so some sort of integration issue has crept in.

$ /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld --version
GNU ld (2.31.1-12+11) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

MarkMLl

[davidgiven]

(Sorry, from phone, so terse...) Don't build it with cmake --- use the Makefile. That'll invoke cmake with the right arguments and also build the other things you need. See the Reader for instructions.

[MarkMLl]

Mea culpa... sorry, that looks better (should have read my notes more carefully). Build completed, will investigate the board-specific mods I did last time.

$ ls -lt | head -6
total 9252
-rw-r--r-- 1 markMLl markMLl 3997696 Aug 11 11:51 filesystem.uf2
-rw-r--r-- 1 markMLl markMLl 1999300 Aug 11 11:51 filesystem.elf
-rw-r--r-- 1 markMLl markMLl 1998848 Aug 11 11:51 filesystem.ftl
-rw------- 1 markMLl markMLl 1304064 Aug 11 11:51 filesystem.img
drwxr-xr-x 6 markMLl markMLl    4096 Aug 11 11:50 build
$ ls -lt build | head -6
total 3292
drwxr-xr-x 5 markMLl markMLl    4096 Aug 11 11:50 CMakeFiles
-rw-r--r-- 1 markMLl markMLl  149504 Aug 11 11:50 fuzix.uf2
-rw-r--r-- 1 markMLl markMLl 1313026 Aug 11 11:50 fuzix.dis
-rwxr-xr-x 1 markMLl markMLl   74708 Aug 11 11:50 fuzix.bin
-rw-r--r-- 1 markMLl markMLl  210207 Aug 11 11:50 fuzix.hex

[davidgiven]

Excellent. Let us know if the images work.

[MarkMLl]

The unmodified sources result in a usable kernel and filesystem image if the .uf2 files are both copied to the RP2040.

I need to look at the mods I did a few weeks ago to allow / to be on the SD-Card, since the Cytron board's pinout is not the same as your (David) example. I'll report back on this.

The Cytron board also has provision for an ESP8266 module: I can confirm that basic operation of this is OK, although inconveniently it appears on UART0. Noting the content of README.NET, I presume that this won't be usable with Fuzix: in practice I'd be satisfied getting something like Kermit or SLIP to work.

[EtchedPixels]

It is in theory possible to program an ESP8266 to act as a "real" wireless offload interface. The Amstrad CPC M4 does it but I've not seen any open source code for that kind of interfacing

[MarkMLl]

I believe that there's a couple of different variants of "standard" ESP8266 firmware, but apart from believing that one uses an AT-based command set and the other is binary I've not researched the difference.

The Regrettable Reality (c) is that the ESP AT command set has enormous "traction" due to the number of people who have used it in Arduino projects. It will be interesting to see whether the RP2040W manages to compete.

[MarkMLl]

Looking good here:

FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2021 Alan Cox <alan@etchedpixels.co.uk>
Built Aug 12 2022 10:44:42. Devboot
264kB total RAM, 160kB available to processes (15 processes max)
Enabling interrupts ... ok.
NAND flash, 1952kB physical 1296kB logical at 0x13018000: hda: 
SD drive 0: hdb: hdb1 hdb2 
�Mounting root fs (root_dev=17, ro): OK
Starting /init
init version 0.9.0ac#1
Cannot open file
Current date is Thu 2022-08-11
Enter new date: 2022-08-12
Invalid date.
Enter new date: 2022-08-12
Current time is 10:51:57
Enter new time: 09:46

 ^ ^
 n n   Fuzix 0.3.1
 >@<
       Welcome to Fuzix
 m m

login: root

Welcome to FUZIX.
# df
Filesystem       Blocks   Used   Free  %Used Mounted on
/dev/hdb1          2515   1910    605    76% /
# fdisk -l
                      START                  END
Device    Boot  Head Sector Cylinder   Head Sector Cylinder  Type  Sector count

      0        0     0             0
      0        0     0             0
      0        0     0             0
      0        0     0             0
                      START                  END
Device    Boot  Head Sector Cylinder   Head Sector Cylinder  Type  Sector count

/dev/hdb1         0      1        1     63     32        2    7e          4096
/dev/hdb2         0      1        3     63     32       34    7e         65536
      0        0     0             0
      0        0     0             0
# 

I've taken the liberty of adding the kernel build date and time to the startup messages, apologies if this is ultra vires.

There's an unexplained "Cannot open file" which I've not yet investigated. (Later: from fsck -a / in /etc/rc)

Entering the date always takes two attempts, suggesting an uninitialised variable somewhere.

That was experimentally using a small filesystem on /dev/hdb1, I've since moved to /dev/hdb2 and wiped /dev/hdb1 as swap. I've not yet worked out how to integrate device selection with cmake, so it's hardcoded.

[MarkMLl]

Apropos Kermit since I mentioned it a day or so ago. In principle, Kermit running as a server should be usable for file transfers since it only uses a single TTY, i.e. it doesn't need both its controlling TTY and an additional serial line.

Looking at http://www.columbia.edu/kermit/archive.html , C-Kermit has a riscix (i.e. Archimedes, BSD-derived) target which might be useful. However in order to keep the code simple I've focussed on version 4E, which was the first interactive one (i.e. could start off like a shell and then be switched to server mode).

Most of the conversion looks like makefile hacking, but there's a preprocessor which needs to be built coded in (resolutely) K&R C which is challenging my ability.

Most of my erstwhile Kermit hacking was in assembler, which says how long ago it was :-)

I've not yet investigated the state of KA9Q from e.g. https://github.com/ka9q/ka9q-nos or https://github.com/ke6jjj/ka9q-unix

[EtchedPixels]

Most versions of kermit will be a disaster on the Fuzix Pi side because it forks into two processes both active. Same problem it always had on minix 68K. Xmodem is much simpler.

For the networking side what you actually want for microcontrollers except for simple stuff is an API akin to the WizNET one where the buffering and socket side activity happens on the ESP8266 and you talk to it with an interface that has proper multi-channel flow control, be that a horror like the GSM mux protocol standard or something semi-sane like drivewire or tnc host mode style interfaces.

[MarkMLl]

I'd forgotten about the unfortunate tendency of unix comms software to fork(), which does sound like a showstopper.

[MarkMLl]

With a couple of extra defines, I'm able to get uckermit from https://github.com/BAN-AI-Communications/uckermit built, running and minimally-tested in server mode on x86_64 without using fork(). I think this is worth pursuing since (a) in server mode it doesn't need an extra comms line and (b) it is capable of transferring binary files (something that XModem over a console link often has problems with).

My tentative makefile for Fuzix on RP2040 Pico is below, but I am having problems with the ckcpro.c unit which needs to be generated as part of the build process using a non-standard program: below assumes that the wart utility is available as a binary, but there are still problems.

ROOT = ../..
include $(ROOT)/Applications/rules.armm0

CSRCS = ckcfn2.c ckcfns.c ckcmai.c ckcpro.c ckucmd.c ckucon.c ckudia.c
CSRCS += ckufio.c ckuker.doc ckuscr.c ckutio.c ckuus2.c ckuus3.c ckuusr.c
HDRS = ckcdeb.h ckchdr.h ckcker.h ckucmd.h ckuusr.h

OBJS = $(CSRCS:.c=.o)

all: fuzix-minimal

ckcpro.c: ckchdr.h ckcpro.w wart
        ./wart ckcpro.w ckcpro.c

ckcpro.o: ckcpro.c ckcker.h ckcdeb.h ckchdr.h

wermit: $(OBJS) $(CRT0)
        $(LINKER) -o wermit.debug $(CRT0) $(OBJS) $(LINKER_OPT)
        $(STRIP) $(STRIP_OPT) -o $@ $@.debug

fuzix-minimal:
        $(MAKE) -f Makefile.armm0 wermit "CFLAGS = -Wall -Os \
                              -g -fno-unwind-tables                       \
                              -fno-asynchronous-unwind-tables -fno-ident  \
                              -flto -fno-exceptions -fdata-sections       \
                              -ffunction-sections -ffast-math             \
                              -fno-math-errno                   \
                              -fmerge-all-constants -funsigned-char       \
                              -fdelete-null-pointer-checks        \
                              -funsafe-math-optimizations        \
                -DSYSVR3 -DUXIII -DBSD42 -DUXIII \
                -DFIONREAD -DDIRENT -DNOCKUSCR -DNOCKUDIA \
                -DNODOHLP -DNODISP -DNOPUSH -DNOSTATS \
                -DNOICP -DMINBUF -DNOATTR -DNOTILDE -DNOCONN \
                -DNOLOGS -DNOSPACE" \
                "LNKFLAGS = -Wl,-O,2 -Wl,-flto -Wl,--gc-sections"

.c.o:
        $(CC) $(CFLAGS) $(COPT) -c -DVT52=0 -DANSI=1 -o $@ $<

clean:
        rm -rf $(OBJS) *.lst *.sym *.map *.noi *.lk *.ihx *.tmp *~ *.o *.rel *.asm
        rm -f wermit *.bin ckcpro.c

This appears to be close to working, except that compilation insists on getting files such as dirent.h and termio.h from /usr/include/newlib rather than FUZIX/Libraries/include.