possible bug in sxitwi.c for orange pi one (H3)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

possible bug in sxitwi.c for orange pi one (H3)

Stephen Graf
I think I have found the problem with the sxitwi driver.

 

After your note about the uart working and using the same clock as i2c, I
turned my attention back to the sxidriver.

 

I noted that there is no clear indication in the Allwinner documentation on
how to clear the INT_FLAG bit once it is set.  The text on page 445 in the
Allwinner H3 data sheet re the INT_FLAG says that in slave mode the clock is
held low until the INT_FLAG bit is written as '1'. This is what I am seeing
even though the device is in master mode.  The driver currently sets it to
'0' after a status change.

 

I changed the code to set the bit after a status change and the data started
flowing!

 

I think this may have to do it in a number of places.  I would rather the
author of this driver do it properly.  

Reply | Threaded
Open this post in threaded view
|

Re: possible bug in sxitwi.c for orange pi one (H3)

Stephen Graf
I just checked the Allwinner A10 documentation (for which the driver was
written) and this is definitely a reverse of the H3.  H3 says write '1' and
A10 says write '0'.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Stephen Graf
Sent: Sunday, September 24, 2017 11:19 AM
To: 'aa e30' <[hidden email]>; [hidden email]
Subject: possible bug in sxitwi.c for orange pi one (H3)

I think I have found the problem with the sxitwi driver.

 

After your note about the uart working and using the same clock as i2c, I
turned my attention back to the sxidriver.

 

I noted that there is no clear indication in the Allwinner documentation on
how to clear the INT_FLAG bit once it is set.  The text on page 445 in the
Allwinner H3 data sheet re the INT_FLAG says that in slave mode the clock is
held low until the INT_FLAG bit is written as '1'. This is what I am seeing
even though the device is in master mode.  The driver currently sets it to
'0' after a status change.

 

I changed the code to set the bit after a status change and the data started
flowing!

 

I think this may have to do it in a number of places.  I would rather the
author of this driver do it properly.  


Reply | Threaded
Open this post in threaded view
|

Re: possible bug in sxitwi.c for orange pi one (H3)

Artturi Alm
On Sun, Sep 24, 2017 at 11:35:56AM -0700, Stephen Graf wrote:
> I just checked the Allwinner A10 documentation (for which the driver was
> written) and this is definitely a reverse of the H3.  H3 says write '1' and
> A10 says write '0'.
>

Oh, great :) that info will help the dev w/H3-hw, to make the driver bend
for the differences like it should.

btw. i'm almost done shoveling w/luserland iic bus access, i haven't done
much like this, and i got distracted for a while just digging deeper on
both sides of the fence trying to get horrible smarts written for it all-
around, or so i think when looking at it now in retrospect:)
i'll trim it down back to securelevel < 1 config/simple fdt override,
and/or simple 'allowed ranges/devices'-impl., and share here on arm@, as
i believe it'd be futile attempt when the #ifdef notyet is nearly 15years
old by now :)

-Artturi

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Stephen Graf
> Sent: Sunday, September 24, 2017 11:19 AM
> To: 'aa e30' <[hidden email]>; [hidden email]
> Subject: possible bug in sxitwi.c for orange pi one (H3)
>
> I think I have found the problem with the sxitwi driver.
>
>  
>
> After your note about the uart working and using the same clock as i2c, I
> turned my attention back to the sxidriver.
>
>  
>
> I noted that there is no clear indication in the Allwinner documentation on
> how to clear the INT_FLAG bit once it is set.  The text on page 445 in the
> Allwinner H3 data sheet re the INT_FLAG says that in slave mode the clock is
> held low until the INT_FLAG bit is written as '1'. This is what I am seeing
> even though the device is in master mode.  The driver currently sets it to
> '0' after a status change.
>
>  
>
> I changed the code to set the bit after a status change and the data started
> flowing!
>
>  
>
> I think this may have to do it in a number of places.  I would rather the
> author of this driver do it properly.  
>
>

Reply | Threaded
Open this post in threaded view
|

Re: possible bug in sxitwi.c for orange pi one (H3)

Alfred Morgan
In reply to this post by Stephen Graf
Hi Stephen,

Congratulations on finding that driver bug detail. I would like to know
more about how you were able to find such a thing. I am really interested
in being able to get to the level to do what you just did. Would you care
to share your detailed experience on how you were able to find this? Some
questions that I have is how in depth is your knowledge in the hardware,
OS, and C language? and how did you get to that knowledge level? I know you
said you are "not an accomplished c programmer" but you seem to be getting
along really well.

> Reading the H3 datasheet would lead me to believe that the switwi driver
should work.

How did you come up with the idea to focus on the sxitwi driver?

> I modified the dtb and the sxitwi driver to set up H3 compatibility,
rebuilt
the kernel...

How did you know what/how to change in the dtb file? Did you cross-compile
and how did you set that up? I imagine the development cycle is really slow
having to cross-compile, copy files to an sd card, plug sd card into the
pi, boot up, wait, and then... how do you know what is happening? maybe
something in the dtb was wrong? how would you know exactly? and if
something did go wrong then you would probably spend a massive amount of
time hunting down the issue and then not to mention going through the bulky
cycle of coding/compiling/copying/booting. How do you manage?

> I changed the code to set the bit after a status change and the data
started
flowing!

How did you figure a bit needed to be set after a status change when this
fact is buried 445 pages deep in documentation?

Thanks,
--
-alfred
Reply | Threaded
Open this post in threaded view
|

Re: possible bug in sxitwi.c for orange pi one (H3)

Stephen Graf
In reply to this post by Stephen Graf
Artturi did all the coding and I helped with the testing.
I have built a thermostat and weather station on a NTC CHIP device with Linux but I prefer to use openbsd.  For my requirements an orange pi one seemed sufficient and so I started working to get openbsd running even though it is not officially supported.  My temperature, pressure, humidity sensor, BMW280, is on the i2c bus and so I had to get the sxitwi driver working.
Artturi, who ported the sxitwi driver, has been extremely helpful (and patient) in setting up the clock structure and driver and code for the BME280 device. The orange pi one is an Allwinner H3 device and the driver was written for a10 and a20. The specs seemed to indicate that the a20 and h3 were very similar and it was not until the driver did not work that I discovered that there is a one bit difference that created a problem. Artturi has written code to take care of the change.
How I go to where I am is too long a story for an email. Suffice it to say that I wrote my first computer program in 1966 (Fortran) and as an engineer have worked on both hardware and software development from microprocessors to large clusters of UNIX servers.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Alfred Morgan
Sent: Tuesday, September 26, 2017 1:34 PM
To: Stephen Graf <[hidden email]>
Cc: [hidden email]
Subject: Re: possible bug in sxitwi.c for orange pi one (H3)

Hi Stephen,

Congratulations on finding that driver bug detail. I would like to know more about how you were able to find such a thing. I am really interested in being able to get to the level to do what you just did. Would you care to share your detailed experience on how you were able to find this? Some questions that I have is how in depth is your knowledge in the hardware, OS, and C language? and how did you get to that knowledge level? I know you said you are "not an accomplished c programmer" but you seem to be getting along really well.

> Reading the H3 datasheet would lead me to believe that the switwi
> driver
should work.

How did you come up with the idea to focus on the sxitwi driver?

> I modified the dtb and the sxitwi driver to set up H3 compatibility,
rebuilt
the kernel...

How did you know what/how to change in the dtb file? Did you cross-compile and how did you set that up? I imagine the development cycle is really slow having to cross-compile, copy files to an sd card, plug sd card into the pi, boot up, wait, and then... how do you know what is happening? maybe something in the dtb was wrong? how would you know exactly? and if something did go wrong then you would probably spend a massive amount of time hunting down the issue and then not to mention going through the bulky cycle of coding/compiling/copying/booting. How do you manage?

> I changed the code to set the bit after a status change and the data
started
flowing!

How did you figure a bit needed to be set after a status change when this fact is buried 445 pages deep in documentation?

Thanks,
--
-alfred