Phytec MPC5554 not running out of flash?

[Peter Dufault]

Yes, I know.  My basic debugging method is to develop with SRAM mapped down where flash is.  Then to execute out of flash I copy my RAM into flash with the low-memory flag set to 0xffffffff instead of 0.  On reset the code then goes through the normal MMU setup instead of skipping it.

This has been working for years, it's the latest release that isn't.

To develop I start with a working version in flash that can load a binary off NFS into the upper RAM, clear the low-memory flag, copy a routine to stack that knows how to set up the MMU and reset the CPU to execute out of RAM, and jump to that stack-based routine to restart in RAM.  Everything should be exactly the same except the cleared low memory word, the setting of two of the mapping registers, and the skipping of the MMU setup when that memory word is cleared.

I do think this is more a -devel than a -users posting, I think it's recent breakage.

On Jul 11, 2014, at 11:00 , Thomas Doerfler <Thomas.Doerfler at embedded-brains.de> wrote:

> Peter,
> 
> just a hint: you are aware that the MPC5554 BAM code expects certain
> magics at the start of the flash, otherwise the flash block is
> considered non-bootable.
> 
> wkr,
> 
> Thomas.
> 
> Am 11.07.2014 14:44, schrieb Peter Dufault:
>> I've been developing code just fine running in SRAM with the current head.  I just tried to run out of flash.  My software put the program in flash just fine, but it doesn't run, it winds up in the BAM code trying to boot off the serial port / CAN.
>> 
>> The difference between SRAM and FLASH is only the setup of the MMU, and it's the same code in both cases. For SRAM flash is moved from 0 up to 21400000 and 4MB of SRAM down from 21400000 to 0.  The MMU is setup in the debugger and at startup the MMU setup is skipped if a flag in low memory is clear.  That's the only difference in the behavior (see below), and I've never noted any differences before.
>> 
>> I verified that I have the same MMU setup except for the address translation in both situations.  It was different, someone changed the setup to only set the supervisor mappings and not map certain sections executable but that didn't matter, I've duplicated those settings and it works the same way.
>> 
>> Before I go too far can anyone (Sebastian) think of changes in any other places that might affect this?
>> 
>> static BSP_START_TEXT_SECTION void mpc55xx_start_mmu(void)
>> {
>>  #ifdef MPC55XX_BOOTFLAGS
>>    /* If the low bit of bootflag 0 is clear don't change the MMU.  */
>>    bool do_mmu_config = (mpc55xx_bootflag_0 [0] & 1) != 0;
>>  #else
>>    bool do_mmu_config = true;
>>  #endif
>> 
>>  if (do_mmu_config) {
>>    mpc55xx_start_mmu_apply_config(
>>      &mpc55xx_start_config_mmu [0],
>>      mpc55xx_start_config_mmu_count [0]
>>    );
>>  }
>> }
>> 
>> 
>> Peter
>> -----------------
>> Peter Dufault
>> HD Associates, Inc.      Software and System Engineering
>> 
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>> 
> 
> 
> -- 
> --------------------------------------------
> embedded brains GmbH
> Thomas Doerfler
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: Thomas.Doerfler at embedded-brains.de
> Phone: +49-89-18 94 741-12
> Fax:   +49-89-18 94 741-09
> PGP: Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering