FUZIX
FUZIX copied to clipboard
EtchedPixels
RP2040 attached to Cytron "Maker Pi Pico" demo board
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 <[email protected]>
Copyright (c) 2014-2022 Alan Cox <[email protected]>
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.
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.
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.
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 ?
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.
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.
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?
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.
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.).
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 <[email protected]>
Copyright (c) 2014-2022 Alan Cox <[email protected]>
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
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?
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.
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
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.
Currently set to 83, changing to 7e (either for sdd2 only, or for both) results in no obvious change.
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.
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 <[email protected]>
Copyright (c) 2014-2022 Alan Cox <[email protected]>
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
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.
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
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.
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.
Will commenting flash_dev_init() out change the drive allocation? I'll probably find out shortly...
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.
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.
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.
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?
@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.
@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.
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 <[email protected]>
Copyright (c) 2014-2022 Alan Cox <[email protected]>
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
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? :-)