#12183 LOW Not Tri: XO-4 B1 has Data Abort during boot

[Zarro Boogs per Child]

#12183: XO-4 B1 has Data Abort during boot
-----------------------------------+----------------------------------------
 Reporter:  wad                    |                 Owner:  wad        
     Type:  defect                 |                Status:  new        
 Priority:  low                    |             Milestone:  Not Triaged
Component:  hardware               |               Version:  4-B1       
 Keywords:  XO-4, OFW, Data Abort  |           Next_action:  reproduce  
 Verified:  0                      |   Deployment_affected:             
Blockedby:                         |              Blocking:             
-----------------------------------+----------------------------------------
 An XO-4 B1 #SHC238000BF was running a repeated SPI reflash and reboot test
 when it displayed a "Data Abort" on the screen (no serial port was
 connected, and the TS tag was set to show).  The keyboard was inoperative.

 That laptop had been modified to use a +3.3V SPI Flash (volt. translation
 and R295 = 1K).  It does not appear that this is related to this ticket.
 The SPI reflash and reboot test runs the script located at:
 http://dev.laptop.org/~wad/test_spi2.fth

 A serial port was connected, and the ftrace and .registers information
 collected, followed by other information as requested by Mitch (attached).

 MitchBradley: It's in the timer tick handler checking to see if any
 keyboard events need to be processed, and the address within the input
 queue is totally bogus and yet the value in r10, which should be q + head,
 is 5f0c4dd3 and we are already inside the interrupt handler, ruling out
 the likelihood of a register getting corrupted by an interrupt handler

 MitchBradley: the instruction that faulted was "ldrb r10,[r10]"

 MitchBradley: The faulting sequence in Forth is "q  head @  +  c@" with
 the fault itself happening in c at .  Much of the arithmetic happens in r10,
 the top-of-stack register.   The value 'q' is in the memory stack during
 part of the computation, where memory corruption - or more likely cache
 corruption, and it's unlikely to make it all the way out to memory - could
 occur

-- 
Ticket URL: <http://dev.laptop.org/ticket/12183>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system