Avoiding general compiling issues

[paulwratt]

In the README.md for pTOS, can you explicitly state the GCC & BinTools versions you are using and on what platform (and its version), and whether or not you have a "m68k-atari-mint" cross-toos install (and is it in your path.

Can you also state explicitly what hardware you are testing on (incl. QEMU version)

Using Jessie-Stable-Old distros, I can get pTOS to build without error for both armv6 and armv7, have not tried armv8 (aarch64 or aarch32) yet, with "arm-non-eabi-4.8" (a known good version for compiling for arm targets incl. RPi) as long as I "fix" the __attribute__ ((aligned (4*1024)) in line 94 and 95 of pTOS/bios/raspi_memory.c to something more respectable (ie <16), I chose 8.

However I can not get pTOS to boot on either RPi B (armv6) or RPi 2B+ (armv7). If these are CPU cache related alignments, the 8 is enough for one instruction, but not enough to move it to a page boundry (4*1024). This may be the cause of "cant boot".

Alternatively, the initial compilation Error warning I get (1st line) before make drops in to the target, is not finding "m68k-atari-mint-gcc" which is used to pre-build tools and the resource file that gets included in the target build.

Without early boot console output, I can not see why pTOS is not booting, and the FAT16 write code is not usable yet to enable a dump or trace file.

The simplest immediate solution is to test (at least) the armv7 binary last considered stable by your development environment. If I can not get that to boot I know there is a code issue, not a compiler or configuration issue. So making your binaries available would increase initial build fault finding.

a emudeskt.inf and the RPi boot files would also help speed things up, as would a pre-built sdcard image (1 FAT16 partition). I have tested with a hand built FAT16 boot partition and a pre-build FAT16 boot partition (Linux Wheezy, that I know works), both have failed.

If you were to add 3 sections to the README.md, one for known OS success (or failures), one for GCC version successes (or failures), and one for known target success (or untested - RPi 0, RPi 0w, etc) that would be useful (especially in years to come). Or a new pTOS-BUILD.md file if that makes more sense.

Because I can not use QEMU (I am not on a PC/x86), and I dont have a USB serial (UART) cable, to simplify debugging, I have to go back to basics of bare-metal building ans develop an early console output.

Technically that would eventually be more useful if the ROM image being built was one with EmuCON built in to it and modified for pTOS debugging.

[kelihlodversson]

Hi Paul,

As this is actually a collection of issues, some of which have already been reported (eg. the alignment of the page table variables) I'm going to close this one.

Could you please add the remaining ones as separate issues for easier tracking?

Thanks, keli

[kelihlodversson]

Btw change 98158f8170168f26854de6dac1abc158bfbaa5eb removed the large alignment constraints on the variables in raspi_memory.c, so that might resolve your issues getting to a bootable state on RPI2. (Simply changing the alignment directives is pretty much guaranteed to fail as the MMU tables have strict alignment requirements.)

[paulwratt]

I just updated all commits from 6 hrs ago, and I see there are a LOT of changes, incl. the ref you made, so I will see how things go. Thnx for breaking out source into a arch/machine folder structure, this will make porting a lot cleaner. FYI I did still see some coldfire files in there original places.