Review Board 2.0.15


ARM: Add system for ARM/Linux and bootstrapping

Review Request #165 - Created Aug. 13, 2010 and submitted

Information
Ali Saidi
gem5
Reviewers
Default
ARM: Add system for ARM/Linux and bootstrapping

   
Posted (Aug. 13, 2010, 4:37 p.m.)



  
src/arch/arm/faults.cc (Diff revision 1)
 
 
Rather than putting pc in a temp variable for the DPRINTF and having to protect it like this, it would probably be simpler and cleaner to just read it in place in the one place it's passed as an argument.
src/arch/arm/faults.cc (Diff revision 1)
 
 
This line is too long.
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
It looks like each 32 bit field has a defined purpose (tag, flags, etc.) I'd be warmer and fuzzier if this was a structure with named elements instead of a uint32_t array. Perhaps it could be called AtagHeaderStruct or something like that, and they'd inherit from each other to build on a common base structure on up.

Also, if the name AtagHeader, etc., weren't chosen to match names in Linux (I suspect they were, so this doesn't matter) then they could stand to be a little more descriptive. It's not clear at all what that means. I'm guessing address tag header, but I really can't tell. A brief comment explaining what these objects are used for would help.
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
It seems a little weird to put the initializer on a new line but the empty function body at the end of the line. If this is mandated by the style guide then fine, but it seems a little wonky.
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
What does this hardcoded constant mean? Why isn't it read from anything, or at least verified to be the same as that something even if a particular value is expected?

This same comment applies later on as well.
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
Ah, so atag is a bootloader thing. This comment isn't particularly helpful, but I'll leave judgment of its value to you. In any case, explanatory comments like this would be better at the top, where you see them and at least know they're there before being baffled by the rest :-)
src/arch/arm/system.cc (Diff revision 1)
 
 
I like this fix. This is much better.
Posted (Aug. 14, 2010, 3:57 a.m.)



  
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
The max size can be arbitrarily large, so that doesn't work particularly well
  1. I don't necessarily agree, but at least it should be a uint8_t * or void * that gets cast to a structure. Just knowing it's a bunch of uint32_ts (and according to that comment it isn't actually?) and knowing some value is at offset such and such is a little too magical.
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
It's special for each type. It doesn't seem necessary to create a bunch of AtagXXXId that is assigned to each.
  1. The comment below actually already has constants defined just like that, but then they aren't used. If you move that out of the comment and just make it an enum at the top of the file, you haven't net added anything and it'd be a lot clearer.
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
Perhaps one should read the entire file before beginning to comment on it. ;)
  1. But one probably won't and shouldn't have to since it's an easy problem to fix.
Posted (Aug. 17, 2010, 8:11 a.m.)



  
src/arch/arm/faults.cc (Diff revision 1)
 
 
M5_USED_VAR was added instead. Having the PC here is nice for debugging
src/arch/arm/faults.cc (Diff revision 1)
 
 
Even though I didn't change it, it's ifxed
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
No because part of the spec says that every descriptor is in units of  4 byte chunks
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
The style guide is silent on the matter
  1. It is true that the style guide is silent, but I'd have to agree with Gabe.  Either all on one line or on three lines.  I won't fight though.
  2. three lines then.
    
src/arch/arm/linux/atag.hh (Diff revision 1)
 
 
Fine