Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Feb 2008 23:58:22 +0100
From:      Rafal Jaworowski <raj@semihalf.com>
To:        Marcel Moolenaar <xcllnt@mac.com>
Cc:        Marcel Moolenaar <marcel@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 135517 for review
Message-ID:  <47B76A8E.5060607@semihalf.com>
In-Reply-To: <504560A3-EABB-4896-8B3E-C7FC89F31EFB@mac.com>
References:  <200802162141.m1GLfgkj048217@repoman.freebsd.org> <47B75EB3.2020001@semihalf.com> <504560A3-EABB-4896-8B3E-C7FC89F31EFB@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote:
>>> Change 135517 by marcel@marcel_jnpr on 2008/02/16 21:41:02
>>>
>>>     Save U-Boot's registers at startup and restore them when
>>>     performing a syscall. This way we don't have to compile
>>>     code specially to avoid using those registers. Otherwise
>>>     we have to encode knowledge of those registers in at least
>>>     4 makefiles and introduce a build knob to enable it all.
>>>     This does not allow us to build everything with a single
>>>     build world.
>>>
>>
>> Hi Marcel,
>>
>> I'm not quite sure this is sufficient... I already had a similar
>> save/restore
>> in place, but there is some general problem with U-Boot that leads to
>> hangs
>> (experienced):
> 
> Interesting, I didn't see any such problems with 1.3.2-rc1.
> 

Chances are it might not surface, depending on the regs usage pattern,
compiler etc., for example a -O0 build would usually hide this issue, but in
principle those regs are not exception/interrupt safe.

>> - U-Boot does not handle interrupts so there's no context save/restore of
>> exceptions, other than very few cases
>>
>> - there's one paricular asynchronous way for U-Boot code to regain
>> control
>> without those dedicated r14/29 regs saved: decrementer, which can hit
>> anytime
>> while in the app code, and which usually leads to hangs/corruption as
>> U-Boot
>> code use them blindly
> 
> It's really best if U-Boot deals with that.
> 

Yes, but it doesn't right now, so IMO the right way to go is first fixing
u-boot and only after that eliminating the -ffixed safety measures and I think
we should revert those last changes until u-boot exceptions handle the
dedicated regs properly.

Rafal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B76A8E.5060607>