[PATCH 2/5] SPARC: add BSP specific error handler

[Daniel Hellstrom]

On 06/10/2014 09:34 AM, Sebastian Huber wrote:
> On 2014-06-09 11:06, Daniel Hellstrom wrote:
>> On 06/05/2014 04:54 PM, Sebastian Huber wrote:
>>> On 2014-06-04 20:48, Daniel Hellstrom wrote:
>>>>
>>>> On 06/04/2014 11:51 AM, Sebastian Huber wrote:
>>>>> On 2014-06-04 11:23, Daniel Hellstrom wrote:
>>>>>> Instead of calling the system call TA instruction directly it
>>>>>> is better paractise to isolate the trap implementation to the
>>>>>> system call functions.
>>>>>>
>>>>>> The BSP_fatal_return() should always exist, regardless of SPARC
>>>>>> CPU.
>>>>>
>>>>> Why do we need BSP_fatal_return() and bsp_reset()?
>>>>
>>>> The LEON3 doesn't, it does not define bsp_reset. I tried to preserve the
>>>> behaviour of LEON2 and ERC32 BSPs, the bsp_reset is called from the fatal
>>>> handler. On all SPARC BSPs, ending up in BSP_fatal_return is a result of
>>>> bootcard or bsp_start_on_secondary_processor returning which they should never
>>>> do. The two functions also have different error exit codes.
>>>
>>> Ok, so this BSP_fatal_return() is used to mark unreachable code. Maybe we
>>> should just remove these two special cases since its impossible to test this
>>> code or we could also add a general _Unreachable_code() function.
>>
>> I'm fine with removing them. I'm not sure why it was originally this way, there
>> was probably some reason for it in the first place.
>
> Originally the _Thread_Start_multitasking() and thus boot_card() returned to the caller.  I changed _Thread_Start_multitasking() to a no-return function recently since it simplified some things.  I 
> didn't touch the low-level start code of the BSPs to eliminate some bytes of dead code, but it should go away step by step.

Ok, I will remove it then.