fix hanging PCI memory writes

BaS_gcc.config

@@ -1,3 +1,4 @@
 // Add predefined macros for your project here. For example:
 // #define THE_ANSWER 42
-#define MACHINE_FIREBEE
+//#define MACHINE_FIREBEE
+#define MACHINE_M5484LITE

BaS_gcc.files

@@ -1,3 +1,4 @@
+.travis.yml
 Makefile
 dma/dma.c
 dma/MCD_dmaApi.c

README.md

@@ -1,3 +1,6 @@
+
+[![Build Status](https://travis-ci.org/firebee-org/BaS_gcc.svg?branch=master)](https://travis-ci.org/firebee-org/BaS_gcc)
+
 # BaS_gcc
 **FireBee gcc-based firmware**
 
@@ -22,21 +25,22 @@ BaS_gcc aims to fully supports native EmuTOS + native FreeMiNT on the FireBee.
 
 - checkout a copy of the BaS_gcc sources to your local machine
 - make sure you have a suitable gcc toolchain available. This could be either an m68k-atari-mint toolchain or an m68k-elf gcc toolchain (see switches in the toplevel Makefile).
-- type "make". The build should finish without errors
-- for the FireBee, you'll find a flashable file (bas.s19) in the firebee directory
-- for the m5484lite board files will reside in the m5475evb directory
+- type "make". The build should finish without errors (just warnings about code not finished yet)
+- for the FireBee, you'll find a flashable file (`bas.s19`) in the `firebee` directory
+- for the m5484LITE evaluation board, files are in the `m5484lite` directory
+- for the m5475evb board files will reside in the `m5475evb` directory
 - for the m54455 FreeScale evaluation board, files (not functional yet) are in the respective directory
 
+- `ram.s19` files are meant for testing. They are suitable for direct download to RAM (instead of flashing them). This saves wear on the flash chips and improves development turnaround
+- `basflash.s19` is a proof of concept result. It goes on the SD card and BaS_gcc will load and execute it on boot. This is meant to provide flash upgrade services in future. For now, it only outputs a diagnostic message to the serial terminal 
+
 ## How to flash:
 
 These files can be flashed with either Didier Méquinon's flasher available from the firebee.org home page or any BDM hardware (urgently recommended as this is the only "parachute" available if something goes wrong during flashing). Personally, I'm using a parallel P&E flash solution that came with my m5484lite board and the BDM tools from here: https://sourceforge.net/projects/bdm/ since they are supported under Linux (my favorite) and also support the TBLCF (another, USB based open source BDM solution). See the firebee.org home page for more information.
 
-**WARNING: with BaS_gcc installed, do not try to flash anything from EmuTOS with Didier's flasher tool if you do not have a BDM pod. This will not work currently and leave you with a bricked Firebee. This is not EmuTOS' fault but a "feature" (rather a missing one) of BaS_gcc that currently does not run from RAM (it could, but this has been disabled for now for the sake of easier debugging). It runs from flash and its (required) interrupt handlers reside there as well. Didier's flasher tool does not disable interrupts while flashing, so you will most likely run into a situation where Didier's flasher tool erased the flash to rewrite it and (innocent) EmuTOS will try to call an interrupt handler that is not there. Unfortunately, there is no way to remedy from this situation other than BDM.**
-
-Note that this does not apply when flashing from FireTOS which is safe (as FireTOS replaces BaS_gcc's interrupt handlers with it's own copy in RAM).
-
-Bottom line: if you want to flash BaS_gcc with Didier's tool, do it from FireTOS ONLY! 
-Unless you have a BDM device (which I'd personally recommend under all circumstances anyway), that is.
+# ALL-CLEAR
+The warning I had here before is superfluous. The problem has been fixed with R_0_9_4.
+That means you can now savely flash BaS_gcc from EmuTOS (and FireTOS, of course, as this was working fine all the time) using `FLASH_CF.PRG`
 
 ## What do I gain using BaS_gcc compared to "original" BaS?
 
@@ -56,5 +60,3 @@ From a pure user's perspective (mainly using FireTOS, probably): very little (yo
   These tools are available for all major platforms (Windows, Linux, Mac OS), and BaS_gcc has been tested to compile fine on all of these, so you are not limited to any specific configurations
 
 - BaS_gcc enables (fast) networking using EmuTOS + FreeMiNT because it provides the ColdFire MDMA (multi channel DMA) and a suitable FEC driver. This way, you have a fully native OpenSource ColdFire environment without any slowdown through m68k emulation. Of course "legacy" (TOS) programs have to be compiled for this environment or can only used with m68k emulation (https://github.com/vinriviere/68kemu , for example), but if you intend to use the FireBee for new development, this is the fastest setup you can get with full access for all sources compilable with open source toolchains. A true OpenSorce environment.
-
-[![Build Status](https://travis-ci.org/firebee-org/BaS_gcc.svg?branch=master)](https://travis-ci.org/firebee-org/BaS_gcc)

flash_scripts/flash_m548x_bas.bdm

@@ -77,16 +77,6 @@ erase 0xE0000000 10
 erase 0xE0000000 11
 erase 0xE0000000 12
 erase 0xE0000000 13
-#erase 0xE0000000 0x2000
-#erase 0xE0000000 0x3000
-#erase 0xE0000000 0x4000
-#erase 0xE0000000 0x5000
-#erase 0xE0000000 0x00006000
-#erase 0xE0000000 0x00007000
-#erase 0xE0000000 0x00008000
-#erase 0xE0000000 0x00009000
-#erase 0xE0000000 0x0000a000
-#erase 0xE0000000 0x0000b000
-#erase-wait 0xe0000000
+
 load -v ../m5484lite/bas.elf
 wait

flash_scripts/flash_m548x_bas.sh

@@ -0,0 +1,7 @@
+#!/bin/bash
+
+pushd ../../BaS_gcc
+make clean all
+popd
+time bdmctrl flash_m548x_bas.bdm /dev/tblcf4
+

flash_scripts/flash_m548x_etos.bdm

@@ -5,9 +5,6 @@
 open $1
 reset
 
-# Turn on RAMBAR0 at address FF10_0000 
-write-ctrl 0x0C04 0xFF100007
-
 # Init CS0 (BootFLASH @ E000_0000 - E07F_FFFF 8Mbytes)
 write 0xFF000500 0xE0000000 4
 write 0xFF000508 0x00001180 4
@@ -34,15 +31,25 @@ write 0xFF000104 0x710D0F00 4 # SDCR (lock SDMR and enable refresh)
 sleep 10
 
 
-# use sram as flashlib scratch area
+# use system sdram as flashlib scratch area
 # flashing EmuTOS with plugin does not work yet (at least not for 64bit hosts)
-#flash-plugin 0xFF101000 0xffff flashintelc3.plugin
+#flash-plugin 0x1000 0xf000 flash29.plugin
 
 # notify flashlib that we have flash at address 0xE0000000, length 0x7FFFFF, plugin is flash29
 flash 0xe0000000
 
-# Erase flash from 0xE0100000 to 0xE01FFFFF (reserved space for EmuTOS on the m5484lite)
+# Erase flash from 0xE0600000 to 0xE06FFFFF (reserved space for EmuTOS)
+#
+# Caution: sector offset numbers need to be the ones from the x16 address range
+# column and they vary in size - needs to be exactly as in the data sheet (p. 9)
+#
+# contrary to documentation, it seems we need to erase-wait after each sector
 
+erase 0xe0000000 16
+erase 0xe0000000 17
+erase 0xe0000000 18
+erase 0xe0000000 19
+erase 0xe0000000 20
 erase 0xe0000000 21
 erase 0xe0000000 22
 erase 0xe0000000 23
@@ -63,4 +70,4 @@ erase 0xe0000000 37
 erase 0xe0000000 38
 erase 0xe0000000 39
 
-load ../../emutos/emutos-m548x-bas.elf
+load -v emutos-m548x-bas.elf

flash_scripts/flash_m548x_etos.sh

@@ -0,0 +1,8 @@
+#!/bin/bash
+
+pushd ../../emutos
+make clean m548x-bas -j
+m68k-elf-objcopy --alt-machine-code 4 -Isrec -Oelf32-m68k emutos-m548x-bas.s19 emutos-m548x-bas.elf
+mv emutos-m548x-bas.elf ../BaS_gcc/flash_scripts/emutos-m548x-bas.elf
+popd
+time bdmctrl flash_m548x_etos.bdm /dev/tblcf4

pci/pci.c

@@ -974,7 +974,7 @@ static void pci_bridge_config(uint16_t bus, uint16_t device, uint16_t function)
 
     pci_write_config_longword(handle, PCIBISTR, MCF_PCI_PCICR1_CACHELINESIZE(8) |
                               MCF_PCI_PCICR1_LATTIMER(0x20));
-    pci_write_config_longword(handle, PCIBAR0, swpl(0x80000000));
+    pci_write_config_longword(handle, PCIBAR0, swpl(0x00000000));
     pci_write_config_longword(handle, PCIBAR1, 0x0);
     pci_write_config_word(handle, PCI_LANESWAP_W(PCICR), swpw(
                               (1 << 1)  /* memory space */

sys/mmu.c

@@ -624,19 +624,19 @@ void mmu_init(void)
     /* map PCI address space */
     /* set SRAM and MBAR access */
     set_acr0(ACR_W(0) |                             /* read and write accesses permitted */
-            // ACR_SP(1) |                             /* supervisor only access permitted */
+            ACR_SP(1) |                             /* match on all accesses */
             ACR_CM(ACR_CM_CACHE_INH_PRECISE) |      /* cache inhibit, precise */
             ACR_AMM(0) |                            /* control region > 16 MB */
-            ACR_S(ACR_S_SUPERVISOR_MODE) |          /* match addresses in supervisor and user mode */
+            ACR_S(ACR_S_ALL) |                      /* match addresses in supervisor and user mode */
             ACR_E(1) |                              /* enable ACR */
 #if defined(MACHINE_FIREBEE)
             ACR_ADMSK(0x7f) |                       /* cover 2GB area from 0x80000000 to 0xffffffff */
-            // ACR_BA(PCI_MEMORY_OFFSET));             /* (equals area from 3 to 4 GB */
-            ACR_BA(0xe0000000));
+            ACR_BA(PCI_MEMORY_OFFSET));             /* (equals area from 3 to 4 GB */
+            // ACR_BA(0xe0000000));
 #elif defined(MACHINE_M5484LITE) || defined(MACHINE_M5475EVB)
             ACR_ADMSK(0x7f) |                       /* cover 2 GB area from 0x80000000 to 0xffffffff */
-            // ACR_BA(PCI_MEMORY_OFFSET));
-            ACR_BA(0xe0000000));
+            ACR_BA(PCI_MEMORY_OFFSET));
+            // ACR_BA(0xe0000000));
 #elif defined(MACHINE_M54455)
             ACR_ADMSK(0x7f) |
             ACR_BA(0x80000000));                    /* FIXME: not determined yet */
@@ -647,7 +647,7 @@ void mmu_init(void)
     /* data access attributes for BaS in flash */
 
     set_acr1(ACR_W(0) |
-            ACR_SP(0) |
+            ACR_SP(3) |
             ACR_CM(0) |
 #if defined(MACHINE_FIREBEE)
             ACR_CM(ACR_CM_CACHEABLE_WT) |