5272 vrs 5282 memory protection, was problems writing a driver

[Dietrich]

This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!

---

Feb 1, 2006, 7:33 AM

Post #1 of 8 (38 views)

 [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver

--------------------------------------------------------------------------------
 
>> But I was only trying to make the point, that it is not going to help him
>> accomplish memory protection on a 5272, which is impossible.

> I just had a quick glance at the 5272 UM and it looks like it
> implements a super/user bit in each CSBR register, to restrict
> accesses to being allow only when in the appropriate protection
> mode.
> So it would allow some limited address space protection (certainly
> against perhiperal devices on CS lines). I didn't check any further
> but you may be able to protect internal perhipals too.

Huh, there is, ok, but I don't see any sort of protection capable of locking
down GPIO registers, (this was the original discussion although yes, I did
foolishly started throwing out absolutes).The 5282 provides this capability
with it's SCM module, which the 5272 lacks. Historically there is no sort of
memory protection to these registers in the uClinux port for the 5272.
Whether or not the processor has the capability to implement some sort of
memory protection is more research than I want to do right now, I don't see
anything looking in the features list.

I cc'd the Wildrice list. Maybe somebody over there can shine some light on
this discussion, it's really more their realm.
Would anyone mind giving a brief overview of the memory protection capabilties
of the 5272 vrs the 5282?

thx,
NZG
--------------------------------------------------------------------
Feb 1, 2006, 4:51 PM

Post #2 of 8 (36 views)

 Re: [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver [In reply to]

--------------------------------------------------------------------------------
 
 
NZG wrote:
>>>But I was only trying to make the point, that it is not going to help him
>>>accomplish memory protection on a 5272, which is impossible.
>
>
>>I just had a quick glance at the 5272 UM and it looks like it
>>implements a super/user bit in each CSBR register, to restrict
>>accesses to being allow only when in the appropriate protection
>>mode.
>>So it would allow some limited address space protection (certainly
>>against perhiperal devices on CS lines). I didn't check any further
>>but you may be able to protect internal perhipals too.
>
>
> Huh, there is, ok, but I don't see any sort of protection capable of locking
> down GPIO registers, (this was the original discussion although yes, I did
> foolishly started throwing out absolutes).The 5282 provides this capability
> with it's SCM module, which the 5272 lacks. Historically there is no sort of
> memory protection to these registers in the uClinux port for the 5272.

Yes, as I already told you in this thread. None of the address space
protection mechanisms has ever been used on any ColdFire part running
uClinux. Not just the 5272.

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude 
SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia

--------------------------------------------------------------------
Feb 2, 2006, 6:43 AM

Post #3 of 8 (34 views)
 
 Re: [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver [In reply to] 

--------------------------------------------------------------------------------
 
> Yes, as I already told you in this thread. None of the address space
> protection mechanisms has ever been used on any ColdFire part running
> uClinux. Not just the 5272.
Perhaps not deliberately, but address protection is used on most 5282
platforms.
By default the MCF5282 prevents users from dereferencing internal registers
except from supervisor mode, which the kernel runs in.
This may have not been intentional, but it does result in a protection scheme.

NZG

--------------------------------------------------------------------
Feb 2, 2006, 7:52 PM

Post #4 of 8 (32 views)
 
 Re: [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver [In reply to] 

--------------------------------------------------------------------------------
 
 
NZG wrote:
>>Yes, as I already told you in this thread. None of the address space
>>protection mechanisms has ever been used on any ColdFire part running
>>uClinux. Not just the 5272.
>
> Perhaps not deliberately, but address protection is used on most 5282
> platforms.

This is completely boot loader specific, so generalizing it to
"most" is not really helpful.

uClinux neither setups any address space registers itself, and it
doesn't rely on them being set in any particular way.

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude

SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia

--------------------------------------------------------------------
Feb 3, 2006, 7:29 AM

Post #5 of 8 (29 views)
 
 Re: [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver [In reply to] 

--------------------------------------------------------------------------------
 
On Thursday 02 February 2006 9:52 pm, Greg Ungerer wrote:
> NZG wrote:
> >>Yes, as I already told you in this thread. None of the address space
> >>protection mechanisms has ever been used on any ColdFire part running
> >>uClinux. Not just the 5272.
> >
> > Perhaps not deliberately, but address protection is used on most 5282
> > platforms.
>
> This is completely boot loader specific,
That is true in the sense that since Linux doesn't modify it, it keeps
whatever was passed to it.
But it's not truein the fact that it isn't something that has to set up, it
defaults to it.
It's also not true in the fact that Linux implements a separate kernel/user
space which allows the memory protection scheme to work.
Although, yes, theoretically it's out of Linux's hands, I get customer
support requests and emails saying "I can't access my 5282 registers from
user space but I could from my old 5272, whats wrong?"

> so generalizing it to
> "most" is not really helpful.
I disagree, I don't have any statistical evidence to back me up, but I think
it very likely that this will "mostly" be the case.
Because the only reason you would have user space access is if the bootloader
specifically turned off supervisor protection of registers before passing
control to the OS, which would be a very silly thing for it to do. Register
protection in the 5282 is controlled by a section of registers that do
nothing but provide register protection, so their wouldn't really be a reason
to set them inadvertantly.
I know for a fact that u-boot does not turn them off.
I don't know about Freescales bootloader, but it would be very silly for them
to do that since they designed the hardware and should really know better.
Does the bootloader you use turn it off?
Does anyone on this list know of one that does?

NZG
-------------------------------------------------------------------- 
 
 

Message Edited by Dietrich on 04-01-2006 11:32 AM

Message Edited by Dietrich on 04-04-2006 09:32 PM

[Dietrich]

This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!

---

Feb 3, 2006, 7:01 PM

Post #6 of 8 (26 views)
 
 Re: [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver [In reply to] 

--------------------------------------------------------------------------------
 
NZG wrote:
> On Thursday 02 February 2006 9:52 pm, Greg Ungerer wrote:
>>NZG wrote:
>>>>Yes, as I already told you in this thread. None of the address space
>>>>protection mechanisms has ever been used on any ColdFire part running
>>>>uClinux. Not just the 5272.
>>>
>>>Perhaps not deliberately, but address protection is used on most 5282
>>>platforms.
>>
>>This is completely boot loader specific,
>
> That is true in the sense that since Linux doesn't modify it, it keeps
> whatever was passed to it.
> But it's not truein the fact that it isn't something that has to set up, it
> defaults to it.
> It's also not true in the fact that Linux implements a separate kernel/user
> space which allows the memory protection scheme to work.

Exactly what argument are you making here?

The fact is that uClinux doesn't currently set or use any
protection register on any ColdFire part. No part of this
statement is untrue, or in a grey area, it is a fact.

Therefore whatever the registers are set to before uClinux
starts is what will be in effect when uClinux is running.
So boot loader has set them, or they are power-on default.
This seems quiet strait forward to me, surely this doesn't
confuse you?

> Although, yes, theoretically it's out of Linux's hands, I get customer
> support requests and emails saying "I can't access my 5282 registers from
> user space but I could from my old 5272, whats wrong?"

It is not out of Linux hands. We could set these of we choose too.
I haven't seen or heard from anyone yet who complains that the
current implementation is a real problem for them. Or is that whay
you are saying, this is a problem for you?

>>so generalizing it to
>>"most" is not really helpful.
>
> I disagree, I don't have any statistical evidence to back me up, but I think
> it very likely that this will "mostly" be the case.

I didn't say "most" was wrong, I said it is not helpfull.

If you desire your uClinux system to trap on access to IO memory
regions when running in user privilege mode then you should make
sure the registers are set correctly. It doesn't matter that
most/all/none boot loaders will set this for you. if you want it
your kernel should set it appropriately. (Or if you choose boot
to modify the boot loader then that is your option too).

> Because the only reason you would have user space access is if the bootloader
> specifically turned off supervisor protection of registers before passing
> control to the OS, which would be a very silly thing for it to do. Register
> protection in the 5282 is controlled by a section of registers that do
> nothing but provide register protection, so their wouldn't really be a reason
> to set them inadvertantly.
> I know for a fact that u-boot does not turn them off.
> I don't know about Freescales bootloader, but it would be very silly for them
> to do that since they designed the hardware and should really know better.

I still think you are approaching this wrong. If you want guaranteed
user space access then modify your kernel code and make sure it is
the way you want it. Then deliver that to your customers.

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude

SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia

--------------------------------------------------------------------
Feb 6, 2006, 8:44 AM

Post #7 of 8 (22 views)
 
 Re: [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver [In reply to] 

--------------------------------------------------------------------------------
 
> Exactly what argument are you making here?
That most uCLinux distributions inadvertantly implement memory protection for
the MCF5282 by not modifying it's default register content.

> The fact is that uClinux doesn't currently set or use any
> protection register on any ColdFire part. No part of this
> statement is untrue, or in a grey area, it is a fact.
I agree it does not set any of them. I never argued that it did.

> Therefore whatever the registers are set to before uClinux
> starts is what will be in effect when uClinux is running.
> So boot loader has set them, or they are power-on default.
> This seems quiet strait forward to me, surely this doesn't
> confuse you?
Now lets not get nasty, were just talking.
I am well aware of how it works, but I think you are looking at it wrong.
I'm not trying to point a finger, or say that it's any particular software
projects "responsibilty" to implement this.
I'm just trying to shed some light on how a typical system (that's hardware,
bootloader and OS) does in fact work as it stands.

> > Although, yes, theoretically it's out of Linux's hands, I get customer
> > support requests and emails saying "I can't access my 5282 registers from
> > user space but I could from my old 5272, whats wrong?"
>
> It is not out of Linux hands. We could set these of we choose too.
Could but don't. When I say Linux I mean the OS, not it's developers.
It is currently out of the OS's hands because it does not deal with these
registers in any way.

> I haven't seen or heard from anyone yet who complains that the
> current implementation is a real problem for them. Or is that whay
> you are saying, this is a problem for you?
No, it's not.
I'm quite happy with the way it works, I'm just discussing it.

> >>so generalizing it to
> >>"most" is not really helpful.
> >
> > I disagree, I don't have any statistical evidence to back me up, but I
> > think it very likely that this will "mostly" be the case.
>
> I didn't say "most" was wrong, I said it is not helpfull.
That's true, I approached this wrong.

I should have said it is helpful because originally It was a discussion about
register protection with an OS user, and I was just trying to shed some light
on the real situation.

There were some other responses talking about officially registering the
memory region with the kernel, I pointed out that this was a nice thing to
do, but did not in any way solve the problem.

Then we got into this discussion about whether it was or wasnt' actually
memory protection which has become purely academic.

I'm sure the original poster has long abandoned us this thread.
At this point we are just argueing about who was right, hopefully
constructively.

> If you desire your uClinux system to trap on access to IO memory
> regions when running in user privilege mode then you should make
> sure the registers are set correctly.
I agree.

> It doesn't matter that
> most/all/none boot loaders will set this for you.
Doesn't matter to us specifically, since we have control over it. It is,
however, a handly thing to know when your just answering general questions
about 5282 boards on mailing lists.
Yes, you can just throw up your hands and say
"we don't modify those registers so it's not our problem"
and you would be correct.
But it's not a very nice thing to say, when you do if fact understand the
underlying issue, and could just explain that.

> if you want it
> your kernel should set it appropriately. (Or if you choose boot
> to modify the boot loader then that is your option too)

This is exactly what we do.
We have a port of u-boot we maintain specifically for our board.

> I still think you are approaching this wrong.
And I think you are looking at it wrong.

I agree that software distributions should be put together as you have
stated, with the bootloader in control of the it. Our boards do this, and
have done this for some time.

My arguement was never specifically about our boards, the original question
was not regarding one of our boards.
This has been a purely academic discussion about whether or not uClinux
implements memory protection on a 5282, which followed from a discussion
regarding whether it existed on a 5272.

You say it does not exist on a 5282 distribution because this was not the
intended design and the OS makes no deliberate effort to accomplish it.

I say it does, because whether it was deliberate or not, it exists in "most"
situations. This is because it only would not exist, if the bootloader turned
off memory protection, which is not a sensible thing for any bootloader to
do.

NZG
--------------------------------------------------------------------
Feb 6, 2006, 11:22 PM

Post #8 of 8 (22 views)
 
 Re: [ColdFire] 5272 vrs 5282 memory protection, was problems writing a driver [In reply to] 

--------------------------------------------------------------------------------
 
 

NZG wrote:
>>Exactly what argument are you making here?
> That most uCLinux distributions inadvertantly implement memory protection for
> the MCF5282 by not modifying it's default register content.

I wouldn't use the word "implement". It doesn't. The kernel is
trapping on access events in this case, and you are viewing
that as memory protection, but it is not implemented as such.

>>Therefore whatever the registers are set to before uClinux
>>starts is what will be in effect when uClinux is running.
>>So boot loader has set them, or they are power-on default.
>>This seems quiet strait forward to me, surely this doesn't
>>confuse you?
>
> Now lets not get nasty, were just talking.

I am struggling to understand what point you are making,
not trying to be nasty.

[snip]
>>I still think you are approaching this wrong.
>
> And I think you are looking at it wrong.
>
> I agree that software distributions should be put together as you have
> stated, with the bootloader in control of the it. Our boards do this, and
> have done this for some time.
>
> My arguement was never specifically about our boards, the original question
> was not regarding one of our boards.
> This has been a purely academic discussion about whether or not uClinux
> implements memory protection on a 5282, which followed from a discussion
> regarding whether it existed on a 5272.
>
> You say it does not exist on a 5282 distribution because this was not the
> intended design and the OS makes no deliberate effort to accomplish it.

I don't argue that it doesn't exist, only that the uClinux kernel
doesn't set it up or rely on it.

> I say it does, because whether it was deliberate or not, it exists in "most"
> situations. This is because it only would not exist, if the bootloader turned
> off memory protection, which is not a sensible thing for any bootloader to
> do.

I don't understand this argument either. Why is it not sensible for
the boot loader to disable memory protection?

To my thinking it actually makes good sense. A generic boot loader
should not make any assumptions about what code it is going to load
and run. When Freescale sell a M5xxxEVB board they have no idea
what code will end up running on it. So I would prefer it the boot
loader (dBUG or whatever) doesn't assume anything.

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude
SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia
-------------------------------------------------------------------- 

Message Edited by Dietrich on 04-01-2006 11:31 AM

Message Edited by Dietrich on 04-04-2006 09:28 PM