Re: [hatari-devel] ENABLE_SMALL_MEM problem |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] ENABLE_SMALL_MEM problem
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Wed, 27 Dec 2017 08:34:18 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1514360061; bh=/VPyVrxbSjnTCKahavT5PQLl2i/VOXw6AkHq7G8haLc=; h=Date:From:To:Subject:From; b=EBAClOUIHEcqQaR25gvF8Z8EkEbw5LMrQthXE3+mduuQrNDEXXWB8H7sf8rOtmKqp Je6yhYf4us849qbhXSkzY18sbbZleNtJVJoz0v7tpNQgDJz+PrwVZWL+zoN2HfuqAW T+v7Kp4YUCrCeq7GeZrIF2gf0vjHoJHtiYyE7Y1xs2o4co7vt9au0opLdKKUoFf62E Cutxec0a2C2qX/Mk/Bn1CbrepM1RKf1FcYuxlcwrx/No22tca/wUf1r4pWu78YFXCE Kbj3QBHOQn5YrIQU0rFqPV38uzm8XGV1h46A5dTV/G1fnlEyQsfTfkFUCCeT6R27zo 24iGuUnHV9IFg==
Hi,
Am Tue, 26 Dec 2017 23:34:12 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> On 23/12/2017 09:16, Thomas Huth wrote:
> >
> > I recently tried to compile Hatari with ENABLE_SMALL_MEM again, but
> > it is currently broken: Main_Init() calls STMemory_Init() which
> > again calls STMemory_Reset() and that accesses IoMem[], causing a
> > segmentation fault. IoMem[] is not available in ENABLE_SMALL_MODE
> > until memory_init() has been called during TOS_LoadImage(), which
> > happens later in Main_Init() (when it calls Reset_Cold()).
> >
> > So we either have got to change the order here a little bit, or
> > maybe remove the call to STMemory_Reset() from STMemory_Init() ?
> > The latter should likely be OK since STMemory_Reset() is called
> > again from Reset_ST()? Nicolas, do you have an idea what's the
> > right fix here?
>
> Hi
> looking at this, there might be several ways to fix it, but none
> really satify me at the moment with current code :(
>
> For example, in main.c we could add a call to memory_init() before
> calling STMemory_Init() (with default to tos address at $fc0000,
> until real tos is loaded later). Would it work for you ?
>
> The problem is that we have several "layers" of init functions, some
> of them calling each other with nearly circular dependancies
> sometimes.
>
> For example in this case, I think memory_init should not be called
> from TOS_LoadImage(). TOS_LoadImage() should be a higher level
> function that can patch tos, show warnings depending on some TOS/HW
> combinations, but it should not call memory_init (or just a subset to
> change TOS address between FC0000 and E00000).
>
> I already tried to create some _Init and _Reset funtion for each HW
> component (which is why I'd rather keep the call to STMemory_Reset),
> but it's not complete yet.
>
> In main.c we should reach something like this :
> - set default params
> - load config
> - init "low level" HW
> - call all _Init functions (eg init should alloc whatever memory
> is necessary for the component)
> - call all _Reset functions (this should set each component in
> the state described in its HW documentation, setting the correct
> default value for each registers and so on)
I agree with you. But then the _Init functions should not call the
_Reset functions directly - that should be part of Reset_ST later.
So to fix the current ENABLE_SMALL_MEM problem, I think it's the
easiest and best solution to remove the call to STMemory_Reset() from
the STMemory_Init() function. Then, after the release, we can consider
whether we also want to rework memory_init() or not, OK?
Thomas