sdcard flash-sd.sh: I expected the default DEVICE Trimagesee to be wally-artya7.dtb and the script to copy the buildroot/output/.//rootfs.cpio to the ext4 filesystem at the end of the sdcard

[PietDelaney]

sdcard flash-sd.sh:

I expected the default DEVICE Trimagesee to be  wally-artya7.dtb and the script to copy the buildroot/output/.//rootfs.cpio to the ext4 filesystem at the end of the sdcard.

[PietDelaney]

OK for me to try making a Pull Request with the fix of this?

-piet

[rosethompson]

The kernel and root file system are packaged together into initramfs and copied into partition 2 of the flash card. Changing this now would disrupt the instructions in our textbook which is on the way to publication. Unless there is a compelling reason to change I'd prefer keep this as is. I don't think this will solve the issue you have having.

[PietDelaney]

I worked on a Tensilica system somewhat similar to Wally. In the old days before the initramfs, all of the drivers needed
to boot the access to the filesystem were statically linked in the kernel. The initramfs was created so that drivers could be
dynamically linked to the kernel during boot. The initram file system only has the required drivers and perhaps a bit more like /dev inodes.

Upon booting the kernel it loads the init program into memory. The init process brings up all of the processes
that run in user space to support the kernel. All of this stuff is in the non-ram root filesystem that goes into the
last partition which is appears to be empty on my builds.

I was surprised how slow WALLY appeared to be booting compared to linux on our Tensilica Xtensa Processor on the
ML605 Xlinx FPGA. My guess is the slow speed of this implementation may make booting to multiuser impractical. If it
was desired the Buildroot filesystem in the .cpio file in the Buildroot output would be unpacked into the now empty last partition.

I don't know why the textbook on Wally would be written to assume the complete filesystem in the init-ram filesystem.
My guess is that it's not practical to run multiuser on the Wally FPGA. Maybe I'm wrong and if debug logging of the number of instructions Reached was disabled maybe the performance would be much better.

You are absolutely right that fixing these things are not blocking me. If I get the FPGA building I'd like to get the Risc-v Debug option working to support JTAG debugging. That would allow folks to debug kind of early booting issues like Im experiencing. I'm installing the Wally tools now on my Ubuntu base workstation. Sure is slow...

[davidharrishmc]

None of us have Linux experience in the commercial space, so we’ve had to figure this out from the literature as we went along. The boot takes about 600M instructions to the command prompt. Roughly 2/3 of them are decompressing the file system. This is a day-long simulation in lockstep with Imperas. On the FPGA, most of the time is spent reading the filesystem from the SD card into RAM over the slow SPI interface. The logging instructions reached has essentially zero contribution to boot time. At this stage, it’s too late to change the approach for this edition of the book, but we’d still love to learn about better practices. The file system doesn’t have much more than the essentials, but I presume you are saying some of it could be moved out of initramfs and the system would be more responsive? If you are booting Linux for business purposes and not just a demo, it would be great to optimize and pull them into the repo after the 1.0 tag. The FPGA boot would be much faster if we had a better SD card reader. Unfortunately there seems to be proprietary issues with SDC so we are stuck with SPI. Rose knows the system much better than me.

…

On Jan 20, 2025, at 6:56 PM, Pete Delaney ***@***.***> wrote: I worked on a Tensilica system somewhat similar to Wally. In the old days before the initramfs, all of the drivers needed to boot the access to the filesystem were statically linked in the kernel. The initramfs was created so that drivers could be dynamically linked to the kernel during boot. The initram file system only has the required drivers and perhaps a bit more like /dev inodes. Upon booting the kernel it loads the init program into memory. The init process brings up all of the processes that run in user space to support the kernel. All of this stuff is in the non-ram root filesystem that goes into the last partition which is appears to be empty on my builds. I was surprised how slow WALLY appeared to be booting compared to linux on our Tensilica Xtensa Processor on the ML605 Xlinx FPGA. My guess is the slow speed of this implementation may make booting to multiuser impractical. If it was desired the Buildroot filesystem in the .cpio file in the Buildroot output would be unpacked into the now empty last partition. I don't know why the textbook on Wally would be written to assume the complete filesystem in the init-ram filesystem. My guess is that it's not practical to run multiuser on the Wally FPGA. Maybe I'm wrong and if debug logging of the number of instructions Reached was disabled maybe the performance would be much better. — Reply to this email directly, view it on GitHub <#1234 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA33OQ6IKXIGICKSIAZL2LWZONAVCNFSM6AAAAABVIRRS72VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBZG4ZDONA>. You are receiving this because you are subscribed to this thread.