Build failure on Raspberry Pi4 64-bit

[skullandbones]

I like to challenge myself by not using a PC anymore and to see what does not work using a Raspberry Pi4 as my main desktop.

I would like to see whether I can fix it so that building on a 64-bit Pi is possible. After all, it is running Linux so it should be doable in principle.

I am running 64-bit Raspberry Pi OS Buster on a 8GB Pi4.

I am trying to build master branch: HEAD commit = 3a7421de "Update pull_request_template.md" (v3.2.1 baseline)

The build fails because the build is trying to run x86 tools on an Aarch64 computer which obviously does not work.

The build output of the failure is:

Copying hdiag.rom to ../../Binary
+ rm -f /tmp/casefn.cache
+ ../../Tools/unix/casefn.sh hdiag.rom
+ cp ./hdiag.rom ../../Binary
+ [  ]
make[2]: Leaving directory '/home/pi/projects/romwbw/Source/HDIAG'
+ make --directory Prop
make[2]: Entering directory '/home/pi/projects/romwbw/Source/Prop'
+ make --directory Spin
make[3]: Entering directory '/home/pi/projects/romwbw/Source/Prop/Spin'
../../../Tools/Linux//bstc -e -l PropIO.spin
+ ../../../Tools/Linux//bstc -e -l PropIO.spin
/bin/sh: 1: ../../../Tools/Linux//bstc: Exec format error
make[3]: *** [../../../Tools/Makefile.inc:120: PropIO.eeprom] Error 2
make[3]: Leaving directory '/home/pi/projects/romwbw/Source/Prop/Spin'
make[2]: *** [../../Tools/Makefile.inc:136: all] Error 2
make[2]: Leaving directory '/home/pi/projects/romwbw/Source/Prop'
make[1]: *** [../Tools/Makefile.inc:136: all] Error 2
make[1]: Leaving directory '/home/pi/projects/romwbw/Source'
make: *** [Makefile:3: all] Error 2

Looking in romwbw/Tools/Linux

-rwxr-xr-x  1 pi pi  14248 Sep 14 21:30 bin2asm
-rw-r--r--  1 pi pi    384 Sep 14 21:30 bios.bin
-rwxr-xr-x  1 pi pi 143652 May 25  2021 bstc
-rwxr-xr-x  1 pi pi 103676 May 25  2021 bstl
-rwxr-xr-x  1 pi pi 105304 Sep 14 21:30 cpmchattr
-rwxr-xr-x  1 pi pi 105096 Sep 14 21:30 cpmchmod
-rwxr-xr-x  1 pi pi 113320 Sep 14 21:30 cpmcp
-rwxr-xr-x  1 pi pi 118776 Sep 14 21:30 cpmls
-rwxr-xr-x  1 pi pi 104920 Sep 14 21:30 cpmrm
-rwxr-xr-x  1 pi pi 124768 Sep 14 21:30 fsck.cpm
-rwxr-xr-x  1 pi pi 133664 Sep 14 21:30 fsed.cpm
-rwxr-xr-x  1 pi pi 101704 Sep 14 21:31 lzsa
-rwxr-xr-x  1 pi pi 111048 Sep 14 21:30 mkfs.cpm
-rwxr-xr-x  1 pi pi 338472 May 25  2021 openspin
-rwxr-xr-x  1 pi pi 308848 Sep 14 21:30 uz80as
-rwxr-xr-x  1 pi pi 203256 Sep 14 21:30 zxcc

It is noted all the tools are Aarch64 ELF files except for bstc, bstl, openspin which are 80386 ELF files.

Looking in the romwbw/Tools/unix/bst/Makefile

#
# build the propeller tools for linux and Darwin
#
UNAME := $(shell uname)
ifeq ($(UNAME), Linux)
    SUFFIX=linux
endif
ifeq ($(UNAME), Darwin)
    SUFFIX=osx
endif

DEST = ../../$(UNAME)

all: $(DEST)
    -for i in *.$(SUFFIX) ; do \
        chmod +x $$i ; \
        cp -p $$i $(DEST)/$$(basename $$i .$(SUFFIX)) ; \
    done

$(DEST):
    mkdir $(DEST)

clean:

It can be seen that the Makefile is deficient in only testing for "Linux". In addition uname -m needs to be used to determine whether the machine is x86-64 or Aarch64. This would allow an Aarch64 ELF binary of the 3 tools to be copied or a helpful error message written.

Is the source code for the bstc, bstl, openspin tools available so that I can build these programs for the Raspberry Pi4 (Aarch64) ? (I have not yet tried to google for the source code)

If I am successful, then I could try to create a PR with a fix.

What do you think ?

Thanks, Dean

[wwarthen]

Thanks for reporting this @skullandbones. I do intend for RomWBW to be buildable on Raspberry Pi (32 or 64 bit). I thought I tried it many months ago and it worked. It looks like my Pi 4 is running Bullseye (64 bit) , so maybe that explains it. When I run uname it returns "Linux". What exactly is your Pi 4 returning when you run uname?

Thanks,

Wayne

[wwarthen]

I see what you mean about the architecture. This may be an issue for building Propeller firmware. I am confused because I could swear it was previously possible to build on Raspberry Pi. I don't know if the needed variants of the Propeller tools exist.

[wwarthen]

So, the core problem is that the Spin tools are included in binary form. To build the Propeller firmware, you currently need either bstc or openspin. I don't think bstc is actively supported. The may be a binary distribution of openspin for Raspberry Pi.

The Makefile in Tools/unix/bst just copies the correct binary version of the tool for the current system to a target execution directory. In Tools/Makefile.inc you will see the logic that determines if bstc or openspin will be used. That logic would need to be improved to handle alternate architectures.

Does this give you enough to go on for now?

Thanks,

Wayne

[skullandbones]

@wwarthen I have created an initial fix branch at: https://github.com/skullandbones/RomWBW/tree/Issue-358_fix_RPI4_build

This branch allows me to build RomWBW on my RPi4. The build bypasses using the propeller tools and does not attempt to build the propeller files on an Aarch64 Linux host.

The solution is incomplete because I need to add handling for 32-bit x86 and 32-bit ARM. I have a 32-bit Raspberry Pi1 so I could try building on 32-bit ARM.

I would like to know which board and configuration uses the propeller images ? Obviously this board and configuration will not build on a RPi4 unless the propeller tools are available for Aarch64. In any case, I need to see how the build fails in that scenario and perhaps write a useful message indicating the build limitation.

BTW: I have a Z180 based SC126 board and now I am building a Z80 based RC2014 system. I have some spare 512K EEPROMs so in principle I could do some testing of the built RomWBW images for those 2 systems.

I am interested in having a native Z80 build environment running on these 2 systems on CPM but I don't seem to have found a text editor that supports tabs as used in Z80 assembly listings. I have tried TE.com and messed about with it but it's tabs handling is incomplete. Are you aware of any other CPM editors that support tabs ?

Anyway, my branch is just a first attempt. Do you have any comments such as styling ?

Thanks,

Dean

[wwarthen]

Thank you @skullandbones. At first glance, your changes seem fine and certainly fit within RomWBW conventions. Do you want to generate a pull request against RomWBW? If so, please make sure the pull request is against the dev branch. If not, I can just copy your changes over and credit you for the work.

To answer your question, the Propeller firmware files are used on the PropIO and ParPortProp boards. There is actually also an RCBus Propeller board as well. Building of the Propeller firmware files is not dependent on the hardware platform you are building a ROM for. They are always built, just like the CP/M OS, support applications, etc. As a result, there is no straightforward way to generate a warning. They just won't be there for an RPi build. I don't think that is a big issue for now, but I have another comment about this below.

Regarding a native Z80 build environment, my favorite text editor is ZDE which is included in the RomWBW distribution. Have you tried that?

Finally, let me comment on a long-term approach to the Propeller firmware. It appears that the BST tools (bstc is one) have not been supported in a long time and RomWBW should probably move away from them. I took a quick look at OpenSpin and it looks like the source will build on pretty much any Linux (or MacOS) platform. My thought is to include the OpenSpin source in a RomWBW subdirectory and simply build the tool as part of the overall build process. This should then work on any platform RomWBW builds on. This is exactly what is already done with zxcc and cpmtools. This requires a significant overhaul and I think I should handle this one myself. It will probably take me a while to get to this, so your solution would be quite nice for the time being.

Thanks,

Wayne

[lynchaj]

Hi I just want to say I really like the idea of self-hosting RomWBW. I currently use a Linux notebook to build RomWBW after downloading it from the GitHub. It would be worth designing a board incorporating an RPi solely for the purpose of building RomWBW if it eliminated or even just reduced dependency on an external PC or laptop. I am following this topic with great interest.

Kudos! Thanks, Andrew Lynch

[skullandbones]

@wwarthen I have created a v2 branch off dev at: https://github.com/skullandbones/RomWBW/tree/Issue-358_fix_RPI4_build_v2

Using dummy scripts to represent the binary Propeller build tools maybe a redundant step. The important part is not to attempt to build Propeller files when the tools are not available and this is done in Source/Makefile. I modified the logic.

I note that the openspin binary is a 64-bit x86 ELF and this will not run on a 32-bit x86 Linux OS. Therefore, I added logic to accommodate that scenario by only allowing x86-64 Linux OSes to build propeller.

I have tried to build RomWBW on my Raspberry Pi1 (32-bit arm6l) with an ancient Raspian OS. The build gets past the Propeller check in my commit but fails later due to missing Tools/Linux/bin2asm so might be another issue.

My build of RCZ180 with the "ext" config completes on my RPi4 64-bit. I have not checked the images.

I think more testing is needed and to decide whether to drop the dummy scripts concept. Copying x86 tools onto ARM based OSes is OK until something tries to execute the tools! If we avoid executing the tools then it will fine. Also note there are many ARM CPU variants so that complicates things.

I have another question, your bootloader supports "user application". If I understand correctly, this would allow me to create add a baremetal Z80 executable that could run in 64K RAM space without paging, right ? However, I am unable to find details on how to do that, I am probably looking in the wrong place.

Thanks, Dean

[wwarthen]

Hi @skullandbones,

@wwarthen I have created a v2 branch off dev at: https://github.com/skullandbones/RomWBW/tree/Issue-358_fix_RPI4_build_v2

Using dummy scripts to represent the binary Propeller build tools maybe a redundant step. The important part is not to attempt to build Propeller files when the tools are not available and this is done in Source/Makefile. I modified the logic.

Sounds good.

I note that the openspin binary is a 64-bit x86 ELF and this will not run on a 32-bit x86 Linux OS. Therefore, I added logic to accommodate that scenario by only allowing x86-64 Linux OSes to build propeller.

OpenSpin is currently only used for MacOS builds. For all Linux builds, bstc.linux is used. bstc.linux is 32-bit ELF and "probably" runs on 32-bit Linux. I don't think you need to preclude that.

I have tried to build RomWBW on my Raspberry Pi1 (32-bit arm6l) with an ancient Raspian OS. The build gets past the Propeller check in my commit but fails later due to missing Tools/Linux/bin2asm so might be another issue.

Odd. bin2asm is built on-the-fly as part of the RomWBW build. I guess it is not building on your old Pi1. I would have thought that would work. Regardless, I wouldn't worry about that right now. Better to get your other fixes checked in. Maybe come back to the bin2asm issue later.

My build of RCZ180 with the "ext" config completes on my RPi4 64-bit. I have not checked the images.

It if completes OK, it is probably fine.

I think more testing is needed and to decide whether to drop the dummy scripts concept. Copying x86 tools onto ARM based OSes is OK until something tries to execute the tools! If we avoid executing the tools then it will fine. Also note there are many ARM CPU variants so that complicates things.

OK, let me know when you are done testing. I have no real preference on whether to keep the dummy scripts concept, up to you. As you say, don't really matter either way if not executed. I'm not exactly sure what you mean about "Copying x86 tools onto ARM based OSes". I agree with the statement though. I use an automated build testing mechanism to ensure that the primary build environments (Ubuntu Linux, MaxOS, and Windows) work and result in identical binary outputs. This normal testing will catch any issues with the primary build environments. I will be running these tests when you are ready to provide final code.

I have another question, your bootloader supports "user application". If I understand correctly, this would allow me to create add a baremetal Z80 executable that could run in 64K RAM space without paging, right ? However, I am unable to find details on how to do that, I am probably looking in the wrong place.

The User Application is exactly that -- a way to include your own personal Z80 executable. It is free to use RomWBW API calls, but no CP/M calls (it executes without any OS loaded). If you look in Source/HBIOS, you will find a file called "usrrom.asm". This is the placeholder for the User Application. Just modify it as you like, build a new ROM, and choose User Application. Your code will be run.

Thanks,

Wayne

[wwarthen]

Hi @lynchaj.

Hi I just want to say I really like the idea of self-hosting RomWBW. I currently use a Linux notebook to build RomWBW after downloading it from the GitHub. It would be worth designing a board incorporating an RPi solely for the purpose of building RomWBW if it eliminated or even just reduced dependency on an external PC or laptop. I am following this topic with great interest.

This is a very good point Andrew. Building on RPi is not a problem. The current issue here is very solvable. A Z80 hosted RPi compute module is an interesting idea. The compute modules are inexpensive and should be sufficient for a build. It might also make it easier to move the build to the Z80 system and thereby faster development cycles.

For clarity, self-hosting on Z80 itself would be a very difficult task. I think it might be possible, but is more work than I would want to take on.

Thanks,

Wayne

[lynchaj]

Hi Wayne Yes, I am suggesting a board with some form of RPi on it solely for the purpose of self-hosting RomWBW and creating ROM images.  Then use Flash utility to update the ROM.   I imagine the RPi would have its keyboard and video connection and could communicate with the host Z80 via I2C or SPI or some other mechanism.  Not trying to convert the RomWBW to self-host on a Z80 CPU because that most likely would not be practical due to tools, speed, memory, and other issues Thanks!  Andrew Lynch PS, my mental picture is a duodyne board with buffers, SPI logic, an RPi-type device in the middle of the board.  VGA and keyboard connectors (USB?) along top of board.  Basically, the DualESP32 board with an RPi instead of an ESP32.

On Wednesday, September 20, 2023 at 03:09:50 PM EDT, Wayne Warthen ***@***.***> wrote:  

Hi @lynchaj.

Hi I just want to say I really like the idea of self-hosting RomWBW. I currently use a Linux notebook to build RomWBW after downloading it from the GitHub. It would be worth designing a board incorporating an RPi solely for the purpose of building RomWBW if it eliminated or even just reduced dependency on an external PC or laptop. I am following this topic with great interest.

This is a very good point Andrew. Building on RPi is not a problem. The current issue here is very solvable. A Z80 hosted RPi compute module is an interesting idea. The compute modules are inexpensive and should be sufficient for a build. It might also make it easier to move the build to the Z80 system and thereby faster development cycles.

For clarity, self-hosting on Z80 itself would be a very difficult task. I think it might be possible, but is more work than I would want to take on.

Thanks,

Wayne

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[skullandbones]

@wwarthen I have created a v3 branch: https://github.com/skullandbones/RomWBW/tree/Issue-358_fix_RPI4_build_v3

I have simplified the commit by only inhibiting the building of Propeller in Source/Makefile. I discarded the rest of the v2 changes .

I successfully built various ROM images on my RPi4 running 64-bit RaspberryPiOS buster and my Mageia (Red Hat based) 64-bit Linux PC. Note that Mageia did not have an rpm for srecord so I had to locate the source code and I built srecord-1.64 (1.65 was unbuildable due to requiring a newer build environment).

I note that my PC built the following Propeller files in the Binary directory: ParPortProp.eeprom PropIO2.eeprom PropIO.eeprom

These 3 eeprom files were not found on my RPi4. This suggests that my commit is working as expected.

I did manage to do a build on my RPi1 using a different SD card containing 32-bit RaspberryPiOS buster. The build took roughly 3 hours.

I am not sure how to create a PR in your repository. Do you have to give me some permissions or something ?

Anyway, please take a look at my v3 commit as I have finished my testing. Note that I have added my best guesses for the x86 Linux PC uname -m strings so I might of added too many or not enough!

What is the best way for me to contact you with queries on RomWBW ? I want to try to setup a native C compiler and Z80 assembler toolchain on a CP/M drive, perhaps you already have an image file for that ? I did manually setup a toolchain on my SC126 using ZSM and MESCC but it has some limitations on supported C features.

Thanks, Dean

[lynchaj]

HiWhat is the smallest and cheapest RPi that could reasonably run the RomWBW make process?   Raspberry Pi Zero W?  Raspberry Pi Pico?  Something else? Thanks, Andrew Lynch

On Thursday, September 21, 2023 at 04:19:58 PM EDT, Dean Jenkins ***@***.***> wrote:  

@wwarthen I have created a v3 branch: https://github.com/skullandbones/RomWBW/tree/Issue-358_fix_RPI4_build_v3

I have simplified the commit by only inhibiting the building of Propeller in Source/Makefile. I discarded the rest of the v2 changes .

I successfully built various ROM images on my RPi4 running 64-bit RaspberryPiOS buster and my Mageia (Red Hat based) 64-bit Linux PC. Note that Mageia did not have an rpm for srecord so I had to locate the source code and I built srecord-1.64 (1.65 was unbuildable due to requiring a newer build environment).

I note that my PC built the following Propeller files in the Binary directory: ParPortProp.eeprom PropIO2.eeprom PropIO.eeprom

These 3 eeprom files were not found on my RPi4. This suggests that my commit is working as expected.

I did manage to do a build on my RPi1 using a different SD card containing 32-bit RaspberryPiOS buster. The build took roughly 3 hours.

I am not sure how to create a PR in your repository. Do you have to give me some permissions or something ?

Anyway, please take a look at my v3 commit as I have finished my testing. Note that I have added my best guesses for the x86 Linux PC uname -m strings so I might of added too many or not enough!

What is the best way for me to contact you with queries on RomWBW ? I want to try to setup a native C compiler and Z80 assembler toolchain on a CP/M drive, perhaps you already have an image file for that ? I did manually setup a toolchain on my SC126 using ZSM and MESCC but it has some limitations on supported C features.

Thanks, Dean

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[skullandbones]

@lynchaj

HiWhat is the smallest and cheapest RPi that could reasonably run the RomWBW make process?
Raspberry Pi Zero W? Raspberry Pi Pico? Something else? Thanks, Andrew Lynch

My suggestion is a Raspberry Pi Zero 2 see below.

I am new to learning about RomWBW and CP/M.

My RomWBW builds on a 8GB Raspberry PI 4 running 64-bit Raspberry Pi OS buster and takes about 14 minutes from a clean start. I was running a desktop with many browser windows open.

I tried building RomWBW using a Raspberry Pi 1 running 32-bit Raspberry Pi OS buster and I estimate this took approximately 3 hours (a very inaccurate measurement).

The RomWBW build process seems to be serialised so no parallel make processes are possible. This means that having a multi-core board won't help build times except for allowing other things to run in parallel with the build.

I suspect the building is constrained by the access time to and from the SD card.

I guess that build times can be improved by not running a desktop environment and using a RAM based file system such as tmpfs (Linux).

To answer your question, you need to find the fastest ARM board that runs a Debian based Linux such as Raspberry Pi OS. 64-bit Linux OS (needs a 64-bit CPU) is faster than 32-bit (can run on a 64-bit CPU). Use a fast SD card and/or use a RAM based filesystem for building.

My quick googling suggests that the Raspberry Pi Zero 2 is the quickest at a low cost and small footprint. It seems to be a quad-core ARM and 64-bit. Note that I am unfamiliar with Raspberry Pi Zeros.

You cannot use a microcontroller based board such as a Raspberry Pi Pico as it does not run Linux.

I hope that helps ?

Dean

[wrljet]

I have built gcc from source on the original Raspberry Pi Zero. It took 5 days of continuous grinding.

[wwarthen]

Hi @skullandbones,

@wwarthen I have created a v3 branch: https://github.com/skullandbones/RomWBW/tree/Issue-358_fix_RPI4_build_v3

I have simplified the commit by only inhibiting the building of Propeller in Source/Makefile. I discarded the rest of the v2 changes .

Sounds good.

I successfully built various ROM images on my RPi4 running 64-bit RaspberryPiOS buster and my Mageia (Red Hat based) 64-bit Linux PC. Note that Mageia did not have an rpm for srecord so I had to locate the source code and I built srecord-1.64 (1.65 was unbuildable due to requiring a newer build environment).

Also good. I am VERY surprised that Red Hat did not have an rpm for srecord.

I note that my PC built the following Propeller files in the Binary directory: ParPortProp.eeprom PropIO2.eeprom PropIO.eeprom

These 3 eeprom files were not found on my RPi4. This suggests that my commit is working as expected.

Yes.

I did manage to do a build on my RPi1 using a different SD card containing 32-bit RaspberryPiOS buster. The build took roughly 3 hours.

Yikes, that is a long time. Three hours does not seem practical.

I am not sure how to create a PR in your repository. Do you have to give me some permissions or something ?

There are no permissions required. However, your fork seems to be disconnected from RomWBW. In this case, I don't know a way to do a pull request. You would need to create a new fork, recreate your changes there, and then do a pull request.

Again, I am very happy to grab your changes and merge them myself. I don't do this unless the contributor wants me to because some people prefer to have their work formally acknowledged in the GitHub history. If I do the work, I will credit you in the comments, but GitHub will show me as the author.

Anyway, please take a look at my v3 commit as I have finished my testing. Note that I have added my best guesses for the x86 Linux PC uname -m strings so I might of added too many or not enough!

This looks good and appears to all be inside a single file, so very simple. I'm happy to move this into RomWBW, but want your permission to do that.

What is the best way for me to contact you with queries on RomWBW ? I want to try to setup a native C compiler and Z80 assembler toolchain on a CP/M drive, perhaps you already have an image file for that ? I did manually setup a toolchain on my SC126 using ZSM and MESCC but it has some limitations on supported C features.

Feel free to email me at wwarthen@gmail.com. Have you seen the extra disk images created by RomWBW? Specifically, there is one for HiTech-C. It probably has most of what you need.

Thanks,

Wayne

[wwarthen]

I have built gcc from source on the original Raspberry Pi Zero. It took 5 days of continuous grinding.

That is definitely not practical! I'm amazed you let it run that long!

-Wayne

[wrljet]

And that was after all the false starts that failed midway through.

[wrljet]

FWIW, The Raspberry Pi Zero 2 uses the same CPU guts as the Pi 3B.

[lynchaj]

Hi DeanYes, very helpful.  Thank you! There is a huge difference between a 14 minute build time and one that takes 3 hours.  I suspect the latter is impractical for most people and excellent feedback before beginning on a duodyne RPi board project. I see the Raspberry Pi Zero 2W costs about $45 on AliExpress.  Also, the unit price has gone up significantly over the past couple of years. Much appreciated!  Thanks!  Andrew Lynch

On Friday, September 22, 2023 at 01:04:07 PM EDT, Dean Jenkins ***@***.***> wrote:  

@lynchaj

HiWhat is the smallest and cheapest RPi that could reasonably run the RomWBW make process? Raspberry Pi Zero W? Raspberry Pi Pico? Something else? Thanks, Andrew Lynch

My suggestion is a Raspberry Pi Zero 2 see below.

I am new to learning about RomWBW and CP/M.

My RomWBW builds on a 8GB Raspberry PI 4 running 64-bit Raspberry Pi OS buster and takes about 14 minutes from a clean start. I was running a desktop with many browser windows open.

I tried building RomWBW using a Raspberry Pi 1 running 32-bit Raspberry Pi OS buster and I estimate this took approximately 3 hours (a very inaccurate measurement).

The RomWBW build process seems to be serialised so no parallel make processes are possible. This means that having a multi-core board won't help build times except for allowing other things to run in parallel with the build.

I suspect the building is constrained by the access time to and from the SD card.

I guess that build times can be improved by not running a desktop environment and using a RAM based file system such as tmpfs (Linux).

To answer your question, you need to find the fastest ARM board that runs a Debian based Linux such as Raspberry Pi OS. 64-bit Linux OS (needs a 64-bit CPU) is faster than 32-bit (can run on a 64-bit CPU). Use a fast SD card and/or use a RAM based filesystem for building.

My quick googling suggests that the Raspberry Pi Zero 2 is the quickest at a low cost and small footprint. It seems to be a quad-core ARM and 64-bit. Note that I am unfamiliar with Raspberry Pi Zeros.

You cannot use a microcontroller based board such as a Raspberry Pi Pico as it does not run Linux.

I hope that helps ?

Dean

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[wrljet]

Hi DeanYes, very helpful. Thank you! There is a huge difference between a 14 minute build time and one that takes 3 hours. I suspect the latter is impractical for most people and excellent feedback before beginning on a duodyne RPi board project. I see the Raspberry Pi Zero 2W costs about $45 on AliExpress. Also, the unit price has gone up significantly over the past couple of years. Much appreciated! Thanks! Andrew Lynch

That's scalping price! List price on a Pi Zero 2W is $15.

The Pis with older CPU than the 4B (i.e. the Pi 3 and Pi Zeros) are made with a larger process size which the fabs don't find as profitable, and are still affected by supply chain issues.

You can use this website to see who has what Pis in stock. Rpi Locator

There are basically no Pi Zero 2W available from genuine Raspberry Pi Resellers in USA at the moment. (and haven't been for a long time)

Bill

[wwarthen]

What is the smallest and cheapest RPi that could reasonably run the RomWBW make process?   Raspberry Pi Zero W?  Raspberry Pi Pico?  Something else?

I think @skullandbones has answered the question better than I could. Performance is a bit disappointing based on his input. I am having trouble comparing the Pi Zero 2 to the other Pi options, so hard to tell what it's performance would actually be.

I had in mind the use of an RPi compute module. I think those are available essentially as equivalents to the normal RPi. For example, there is an RPi Computer Module 4 that appears to be equivalent to the normal RPi 4.

I will be trying some RomWBW builds when Dean's work is checked in.

Thanks,

Wayne

[wwarthen]

FWIW, The Raspberry Pi Zero 2 uses the same CPU guts as the Pi 3B.

Good to know. I have a 3B, so that would allow for some timing runs that should be equivalent to the Pi Zero 2.

Thanks,

Wayne

[skullandbones]

@wwarthen please go ahead and take my v3 commit. I guess you can locally clone my branch and then cherry-pick my commit onto your local PR branch. I don't mind if you are the author although cherry-picking should preserve the authorship. I don't want my E-mail address exposed in my commit so I added a dummy E-mail address. So it might be better if you are the author with your E-mail address!

Thanks,

Dean

[wrljet]

FWIW, The Raspberry Pi Zero 2 uses the same CPU guts as the Pi 3B.

Good to know. I have a 3B, so that would allow for some timing runs that should be equivalent to the Pi Zero 2.

Thanks,

Wayne

The Pi 3B has 1GB RAM. The Zero 2W has only 512KB, which negates some of the CPU boost depending on your OS and workload.

A Pi 3B+ is somewhat faster than the 3B. A Pi 4B is a better Arm code and is about 3x faster than a 3B, give or take.

IMHO and with all due respect, I see little value to building RomWBW on a small Pi, other than for the hack value.

I would guess people actually trying to use a Pi as a desktop computer are now using Pi 4B. Lesser models are doing embedded work. Especially the Zero series, as that is what they were designed for. For example my Pi 3B is driving a 3D printer.

Bill

[lynchaj]

HiMaybe some of the knockoff products would be sufficient for a RomWBW build such as Orange Pi Zero2W? https://www.aliexpress.us/item/3256805830040386.html

half the price of a genuine RPi Zero 2W on AliExpress with more capability Thanks, Andrew Lynch

On Friday, September 22, 2023 at 02:09:34 PM EDT, Bill Lewis ***@***.***> wrote:  

FWIW, The Raspberry Pi Zero 2 uses the same CPU guts as the Pi 3B.

Good to know. I have a 3B, so that would allow for some timing runs that should be equivalent to the Pi Zero 2.

Thanks,

Wayne

The Pi 3B has 1GB RAM. The Zero 2W has only 512KB, which negates some of the CPU boost depending on your OS and workload.

A Pi 3B+ is somewhat faster than the 3B. A Pi 4B is a better Arm code and is about 3x faster than a 3B, give or take.

IMHO and with all due respect, I see little value to building RomWBW on a small Pi, other than for the hack value.

I would guess people actually trying to use a Pi as a desktop computer are now using Pi 4B. Lesser models are doing embedded work. Especially the Zero series, as that is what they were designed for. For example my Pi 3B is driving a 3D printer.

Bill

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[wwarthen]

@wwarthen please go ahead and take my v3 commit. I guess you can locally clone my branch and then cherry-pick my commit onto your local PR branch. I don't mind if you are the author although cherry-picking should preserve the authorship. I don't want my E-mail address exposed in my commit so I added a dummy E-mail address. So it might be better if you are the author with your E-mail address!

Will do Dean. Thanks for your work on this. In addition to credit in the comments, I will link to this issue. I will be doing a check-in later today, so I will include your work.

Thanks,

Wayne

[wrljet]

Andrew,

HiMaybe some of the knockoff products would be sufficient for a RomWBW build such as Orange Pi Zero2W? https://www.aliexpress.us/item/3256805830040386.html half the price of a genuine RPi Zero 2W on AliExpress with more capability Thanks, Andrew Lynch

Just so happens I have one of those Orange Pi Zero 2W boards in my hands! Arrived yesterday. I bought the 1.5GB model, which I already regret not going larger.

There is basically no documentation on it whatsoever yet, that I can find, other than basic specs and the GPIO header pinout. But I've got it running. Started with their own Orange OS, which is based on Arch. They do seem to have upped their game on the software side since my last experiences with Orange Pi boards some years ago.

(I bought it for my work on the Hercules emulator project)

Bill

[wwarthen]

@wwarthen please go ahead and take my v3 commit. I guess you can locally clone my branch and then cherry-pick my commit onto your local PR branch. I don't mind if you are the author although cherry-picking should preserve the authorship. I don't want my E-mail address exposed in my commit so I added a dummy E-mail address. So it might be better if you are the author with your E-mail address!

I have published RomWBW Development Snapshot v3.3.0-dev.56 at the RomWBW Releases Page. This release includes the changes from @skullandbones and I have confirmed that I can build on my Raspberry Pi 4 now.

Thank you Dean. If there are no further issues related to Raspberry Pi builds, I will close this issue tomorrow.

FYI, here are some build performance times for a complete distribution build:

GitHub Hosted Linux: 4m 7s Local System: 7m 33s (although this is WSL). RPi 4 (1GB RAM): 9m 55s

The RPi 4 is reasonable. Normal builds will be faster because the release build creates all of the many distribution ROMs. Very clear that the RPi bottleneck is it's eMMC storage. Without doing a lot of testing, I tend to agree with Bill that anything less that the RPi 4 is going to be pretty painful.

I wonder if the RPi Compute Modules would work? I think there is an RPi 4 equivalent. I'm having trouble figuring out how to actually buy them though.

Thanks,

Wayne

[wrljet]

I wonder if the RPi Compute Modules would work? I think there is an RPi 4 equivalent. I'm having trouble figuring out how to actually buy them though.

Thanks,

Wayne

Yes, there are myriad RPi 4 Compute Modules. At least in the catalog. But what's the point?

[wwarthen]

I wonder if the RPi Compute Modules would work? I think there is an RPi 4 equivalent. I'm having trouble figuring out how to actually buy them though. Thanks, Wayne

Yes, there are myriad RPi 4 Compute Modules. At least in the catalog. But what's the point?

Well, I think Andrew was looking for a way to host the build process on a target system (Z80). Sort of a way to achieve a self-hosted build. However, your question is valid since it would cost at least double for the parent board, components, and compute module vs. a stand-alone RPi doing the same thing. I guess Andrew can speak to the use case.

Thanks,

Wayne

[wrljet]

I wonder if the RPi Compute Modules would work? I think there is an RPi 4 equivalent. I'm having trouble figuring out how to actually buy them though. Thanks, Wayne

Yes, there are myriad RPi 4 Compute Modules. At least in the catalog. But what's the point?

Well, I think Andrew was looking for a way to host the build process on a target system (Z80). Sort of a way to achieve a self-hosted build. However, your question is valid since it would cost at least double for the parent board, components, and compute module vs. a stand-alone RPi doing the same thing. I guess Andrew can speak to the use case.

Thanks,

Wayne

The same can be said for any Pi solution in general. You can buy/scrounge a used x86 PC, perhaps a thin client, that comes in a nice case, includes the power supply, any required cooling, has normal standard connectors (that don't come out 3 different sides of the case), etc. for cheaper than you can fully set up a Pi. And it's loads faster.

[skullandbones]

@wwarthen I have worked out what I did wrong when creating a copy of your RomWBW repository. I imported your repository using github instead of using the fork feature of github. I deleted my copy of RomWBW and forked it using github to create a fresh copy. That should allow me to create PRs in future.

I saw that my change went into the dev branch.

Thanks, Dean

[lynchaj]

Hi Yes, the use case is the simple one that Dean mentioned at the beginning of the thread.  To reduce dependence on external PCs to operate and maintain the homebrew/retrocomputer.  Dean had a brilliant insight and it immediately registered in my head as a great idea. We can add video display that use VGA monitors and keyboard & mouse controllers, but you still need that external laptop or PC to perform the RomWBW build process.  That's one or more piece(s) of stuff on my workbench taking up space and more things that have to be moved to demonstrate the system.  As systems get more complicated, it becomes increasingly difficult to move them requiring extensive disassembly and reassembly, testing, often repairing, at the destination.  Eventually, it is just not practical to move them at all. My hope with the SelfHost board is to make duodyne more self-contained so everything can be moved simply without a bunch of reassembly and test at the destination.  The SelfHost board will plug into the backplane and perform ROM upgrades as needed without lugging a laptop or PC around.  If it works, the system will be movable in only two pieces: the backplane with board assembly and the power supply.  Use VGA monitor and USB keyboard which are usually available at the location. It turns out making the host board is pretty simple assuming a RPi or Orange Pi Zero 2W.  They have the same or similar 40 pin GPIO connector and use tiny USB-C connectors for keyboard/mouse and micro-HDMI for monitor.  I considered the RPi compute module but they are 4-5 times more expensive and use what looks like some exotic high-density connectors, at least compared to a 2x20 2.54mm pin header and pin socket combination. The SelfHost board is worth the gamble at less than $100 total for the Orange Pi Zero 2W plus PCB and parts.  If it works, it is a huge simplification of the homebrew computer and will make it much more portable and easier to use.  If not, well, at least it was fun putting it together.  The Orange Pi Zero 2W is a 1.5GHz quad core ARM plus 4GB of RAM.  It uses microSD so that's probably slow but now I am using a Linux notebook with a 1.66GHz Intel Atom CPU (at least 13 years old) with only 1 GB of RAM.  The Orange PI should be at least comparable to what I am currently using, I'd think. I guess we'll see if it works or not.  Maybe it's a dud or maybe it's great.  Hard to tell without trying it to find out. Thanks, Andrew Lynch

On Saturday, September 23, 2023 at 11:57:02 AM EDT, Bill Lewis ***@***.***> wrote:  

I wonder if the RPi Compute Modules would work? I think there is an RPi 4 equivalent. I'm having trouble figuring out how to actually buy them though. Thanks, Wayne

Yes, there are myriad RPi 4 Compute Modules. At least in the catalog. But what's the point?

Well, I think Andrew was looking for a way to host the build process on a target system (Z80). Sort of a way to achieve a self-hosted build. However, your question is valid since it would cost at least double for the parent board, components, and compute module vs. a stand-alone RPi doing the same thing. I guess Andrew can speak to the use case.

Thanks,

Wayne

The same can be said for any Pi solution in general. You can buy/scrounge a used x86 PC, perhaps a thin client, that comes in a nice case, includes the power supply, any required cooling, has normal standard connectors (that don't come out 3 different sides of the case), etc. for cheaper than you can fully set up a Pi. And it's loads faster.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[wwarthen]

@wwarthen I have worked out what I did wrong when creating a copy of your RomWBW repository. I imported your repository using github instead of using the fork feature of github. I deleted my copy of RomWBW and forked it using github to create a fresh copy. That should allow me to create PRs in future.

Yes, that explains it.

I saw that my change went into the dev branch.

Yes, and thanks again. Will be closing this issue now.

Thanks,

Wayne