Re: [beagleboard] USB3 on BBAI

['Roger Quadros' via BeagleBoard]

David,

Does the USB1 automatically switch to host mode when you plug the type-C 
adapter?
Can you please print the kernel log without the adapter connected and then plug 
the
type-C adapter?

Looking at device tree (usb1 dr_mode = "otg") I assumed that the type-C was 
designed for
both device and host cases but it looks like it was never designed to be used 
as a host as
there is no VBUS regulator for the type-C port.

The safest way to provide power to the peripheral is like what Robert suggested
- Use a *powered USB3 hub and connect your camera to that

cheers,
-roger

On 01/09/2020 19:54, David Nolan wrote:

Hi Robert,

For me I've powered the device on P9.5 and P9.1, as you've said, and connected 
a powered USB hub to the Type-C also. In this scenario my camera gets power, 
but is not seen by the BBAI (same for a USB key). When I do a lsusb, it just 
shows the USB hubs (internally) as if nothing is connected. When I connect to 
the USB 2 port everything works as expected.

Has anyone successfully gotten the USB3 to work as a host? If so, how?

Appreciate all the help,

Thanks,
David

On Tue, Sep 1, 2020 at 9:46 AM robert.sty...@gmail.com  
mailto:robert.styles.fors...@gmail.com>> wrote:

 From what I can see on the schematic, there is no way to power a USB 
device plugged into the BBAI USB Type-C socket, there is no path to switch +5V 
power to the Type-C socket VBUS.

You would need some sort of adapter or hub with power to supply your device 
(and the BBAI see below).

The BBAI needs power from either USB Type-C or (+5V) P9.5, P9.6 and (0V) 
P9.1, P9.2.

The USB2 can supply power to a device.

On Tuesday, 1 September 2020 at 17:21:23 UTC+1 David Nolan wrote:

Hi Roger,

I finally got a Type-C to Type-A adapter but when I connected it, I 
still get no power to my camera, or to a USB Thumb Drive. Is there some setting 
I need to change to get this to work perhaps?

Thanks,
David

On Wednesday, August 19, 2020 at 12:35:46 AM UTC-7 Roger Quadros wrote:

David,


On 18/08/2020 21:35, David Nolan wrote:

Hi Roger,

Thanks for your email. Apologies for the delay getting back to you. 
Yes, I'm connecting the camera to the Type-C port. The camera has a Micro B 
connector so what I have right now is a cable with a USB Type-C on one end and 
a Micro-B connector on the other side. Unfortunately my laptop doesn't have a 
USB Type-C connector so I can't check it on my own laptop. The camera supports 
USB 3 according to the manufacturer.


This is not the right way of connecting a device to the Type-C 
port. You will need a Type-C to Type-A adapter to connect non type-C 
peripherals.
The Adapter is important because it will tell the Type-C logic on 
the board to switch to DFP (Downstream facing port mode) and so turn on VBUS.

You should not need to run the script. AFAIK the port is in dual-role mode 
"otg" and should automatically switch to host on connecting the right adapter.
In case you have a type-c thumb drive you should be able to test 
this out.



My Apologies, I was incorrect on P5, it's connected to P9, the cape 
connector on the same side of the board as the Type-C connector.

Your point that the camera should be able to take power from USB 
Type-C connector perhaps could be pointing to an issue. I'm not able to get any 
power out of that port. Is there some setting I have to make, or a jumper or 
something to get that to work? Mine seems to only take power in on the Type-C 
connector.


Right. That's why you need to use the type-C to type-A adapter.
e.g.

https://www.amazon.com/Anker-Adapter-Converts-Technology-Compatible/dp/B01COOQIKU?ref_=fsclp_pl_dp_5

cheers,
-roger



Thanks,
David

On Fri, Aug 14, 2020 at 12:56 AM Roger Quadros  
wrote:

Hi David,

On 13/08/2020 19:21, Dave wrote:
> Hi there,
>
> I'm trying to connect a USB3 camera I have to the BBAI (uname 
-r gives 4.14.108-ti-r131).

How are you connecting the camera to the Type-C port? Does the 
camera support Type-C?
If not what type-C to Type-A adaptor are you using? Does it 
support USB3.0? Did you verify it with your laptop's type-C port for example?

>
> I've run "sudo /opt/scripts/boot/bbai_usb_host.sh" to change 
the USB port from a client into a host. I'm powering my camera from the 5V on the beaglebone 
on P5, pin 8. However the camera is not getting detected when connected. I know the camera 
works as if I connect it to the USB2 port it all works perfectly.

What is P5?

Camera should be able to take power from the USB port. Why the 
custom power 

Re: [beagleboard] USB3 on BBAI

['Roger Quadros' via BeagleBoard]

  
  
David,

On 18/08/2020 21:35, David Nolan wrote:


  
  Hi Roger,


Thanks for your email. Apologies for the delay getting back
  to you. Yes, I'm connecting the camera to the Type-C port. The
  camera has a Micro B connector so what I have right now is a
  cable with a USB Type-C on one end and a Micro-B connector on
  the other side. Unfortunately my laptop doesn't have a USB
  Type-C connector so I can't check it on my own laptop. The
  camera supports USB 3 according to the manufacturer. 

  


This is not the right way of connecting a device to the Type-C port.
You will need a Type-C to Type-A adapter to connect non type-C
peripherals.
The Adapter is important because it will tell the Type-C logic on
the board to switch to DFP (Downstream facing port mode) and so turn
on VBUS.

You should not need to run the script. AFAIK the port is in
dual-role mode "otg" and should automatically switch to host on
connecting the right adapter.
In case you have a type-c thumb drive you should be able to test
this out.

  


My Apologies, I was incorrect on P5, it's connected to P9,
  the cape connector on the same side of the board as the Type-C
  connector. 


Your point that the camera should be able to take power
  from USB Type-C connector perhaps could be pointing to an
  issue. I'm not able to get any power out of that port. Is
  there some setting I have to make, or a jumper or something to
  get that to work? Mine seems to only take power in on the
  Type-C connector.
  


Right. That's why you need to use the type-C to type-A adapter.
e.g.
https://www.amazon.com/Anker-Adapter-Converts-Technology-Compatible/dp/B01COOQIKU?ref_=fsclp_pl_dp_5

cheers,
-roger

  


Thanks,
David
  
  
  
On Fri, Aug 14, 2020 at 12:56
  AM Roger Quadros  wrote:

Hi
  David,
  
  On 13/08/2020 19:21, Dave wrote:
  > Hi there,
  > 
  > I'm trying to connect a USB3 camera I have to the BBAI
  (uname -r gives 4.14.108-ti-r131).
  
  How are you connecting the camera to the Type-C port? Does the
  camera support Type-C?
  If not what type-C to Type-A adaptor are you using? Does it
  support USB3.0? Did you verify it with your laptop's type-C
  port for example?
  
  > 
  > I've run "sudo /opt/scripts/boot/bbai_usb_host.sh" to
  change the USB port from a client into a host. I'm powering my
  camera from the 5V on the beaglebone on P5, pin 8. However the
  camera is not getting detected when connected. I know the
  camera works as if I connect it to the USB2 port it all works
  perfectly.
  
  What is P5?
  
  Camera should be able to take power from the USB port. Why the
  custom power connection?
  
  > 
  > lsusb gives:
  > 
  > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0
  root hub
  > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0
  root hub
  > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0
  root hub
  > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0
  root hub
  > 
  > The relevant messages from dmesg I get are as follows:
  > 
  > [  578.405741] xhci-hcd xhci-hcd.2.auto: remove, state 4
  > [  578.405797] usb usb4: USB disconnect, device number 1
  > [  578.410192] xhci-hcd xhci-hcd.2.auto: USB bus 4
  deregistered
  > [  578.410264] xhci-hcd xhci-hcd.2.auto: remove, state 4
  > [  578.410312] usb usb3: USB disconnect, device number 1
  > [  578.414352] xhci-hcd xhci-hcd.2.auto: USB bus 3
  deregistered
  > [  578.422839] dwc3 4889.usb: changing max_speed on
  rev 5533202a
  > [  579.151738] using random self ethernet address
  > [  579.151765] using random host ethernet address
  > [  579.283590] Mass Storage Function, version: 2009/09/11
  > [  579.283620] LUN: removable file: (no medium)
  > [  579.347612] using random self ethernet address
  > [  579.347640] using random host ethernet address
  > [  579.374212] usb0: HOST MAC 28:ec:9a:eb:df:84
  > [  579.374471] usb0: MAC 28:ec:9a:eb:df:85
  > [  579.388618] usb1: HOST MAC 28:ec:9a:eb:df:86
  > [  579.389016] usb1: MAC 28:ec:9a:eb:df:87
  > [  579.516850] IPv6: ADDRCONF(NETDEV_UP): usb0: link is
  not ready
  > [  579.589767] 

Re: [beagleboard] USB3 on BBAI

['Roger Quadros' via BeagleBoard]

Hi David,

On 13/08/2020 19:21, Dave wrote:

Hi there,

I'm trying to connect a USB3 camera I have to the BBAI (uname -r gives 
4.14.108-ti-r131).


How are you connecting the camera to the Type-C port? Does the camera support 
Type-C?
If not what type-C to Type-A adaptor are you using? Does it support USB3.0? Did 
you verify it with your laptop's type-C port for example?



I've run "sudo /opt/scripts/boot/bbai_usb_host.sh" to change the USB port from 
a client into a host. I'm powering my camera from the 5V on the beaglebone on P5, pin 8. 
However the camera is not getting detected when connected. I know the camera works as if 
I connect it to the USB2 port it all works perfectly.


What is P5?

Camera should be able to take power from the USB port. Why the custom power 
connection?



lsusb gives:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The relevant messages from dmesg I get are as follows:

[  578.405741] xhci-hcd xhci-hcd.2.auto: remove, state 4
[  578.405797] usb usb4: USB disconnect, device number 1
[  578.410192] xhci-hcd xhci-hcd.2.auto: USB bus 4 deregistered
[  578.410264] xhci-hcd xhci-hcd.2.auto: remove, state 4
[  578.410312] usb usb3: USB disconnect, device number 1
[  578.414352] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered
[  578.422839] dwc3 4889.usb: changing max_speed on rev 5533202a
[  579.151738] using random self ethernet address
[  579.151765] using random host ethernet address
[  579.283590] Mass Storage Function, version: 2009/09/11
[  579.283620] LUN: removable file: (no medium)
[  579.347612] using random self ethernet address
[  579.347640] using random host ethernet address
[  579.374212] usb0: HOST MAC 28:ec:9a:eb:df:84
[  579.374471] usb0: MAC 28:ec:9a:eb:df:85
[  579.388618] usb1: HOST MAC 28:ec:9a:eb:df:86
[  579.389016] usb1: MAC 28:ec:9a:eb:df:87
[  579.516850] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[  579.589767] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[  583.176056] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[  583.176124] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus 
number 3
[  583.185551] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 
0x100 quirks 0x02010010
[  583.185633] xhci-hcd xhci-hcd.2.auto: irq 223, io mem 0x4889
[  583.186576] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[  583.186602] usb usb3: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[  583.186624] usb usb3: Product: xHCI Host Controller
[  583.186644] usb usb3: Manufacturer: Linux 4.14.108-ti-r131 xhci-hcd
[  583.186664] usb usb3: SerialNumber: xhci-hcd.2.auto
[  583.190665] hub 3-0:1.0: USB hub found
[  583.190793] hub 3-0:1.0: 1 port detected
[  583.191869] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[  583.191916] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus 
number 4
[  583.191961] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0  SuperSpeed
[  583.194273] usb usb4: We don't know the algorithms for LPM for this host, 
disabling LPM.
[  583.194695] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[  583.194721] usb usb4: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[  583.194743] usb usb4: Product: xHCI Host Controller
[  583.194762] usb usb4: Manufacturer: Linux 4.14.108-ti-r131 xhci-hcd
[  583.194781] usb usb4: SerialNumber: xhci-hcd.2.auto
[  583.199144] hub 4-0:1.0: USB hub found
[  583.201451] hub 4-0:1.0: 1 port detected

I'm thinking that the line "We don't know the algorithms for LPM for this host, 
disabling LPM" may be pointing me to the issue, but I'm not sure what to do about 
it. Has anyone experienced this issue before and if so, how did you get around it? Any 
help you can give would be much appreciated.


No. That line is harmless. It just says that the XHCI driver doesn't undrestand 
the LPM mechanism so LPM will be disabled.
(LPM->Link power management)

The issue is more about signal integrity at 3.0 speeds or power sequencing of 
the camera.

cheers,
-roger



Thanks,
David

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 
beagleboard+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/17b66917-3622-418f-9b98-88daa38b61fbo%40googlegroups.com
 
.


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

['Roger Quadros' via BeagleBoard]

On 13/02/2019 19:13, Robert Nelson wrote:
>> Sorry, I'm still a bit lost here ;).
>> How do I see the PRUSS kernel patches that you have picked up?
> 
> Okay for v4.19.x & v4.20.x, i've picked up RFC 1: (I need to backport
> the am33xx-l4 dts changes to then backport RFC2..)
> 
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.20/patch.sh#L382-L392
> 
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss
> 
> from : https://lkml.org/lkml/2018/11/22/948
> 
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/remoteproc
> 
> from : https://lkml.org/lkml/2018/11/26/319
> 
> and we needed: https://lkml.org/lkml/2018/12/2/361
> 
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss-from-v4.14.x-ti
> 
> For 5.0.x/5.1.x: I've picked up RFC 2 directly from your git tree:
> 
> https://github.com/rogerq/linux/commits/for-v5.1/pruss-2.0
> 
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.0/patches/drivers/ti/rogerq_pruss
> 
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v5.0/patch.sh#L352-L379
> 

Thanks.

>>
 All upstream PRUSS series that I posted will not work without changes in
 the resource tables in pru-software-support packages.

 e.g.
 https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f

 If you can wait for 2 weeks then we could have something in
 TI 2019 that should work smoothly.
>>>
>>> So around the time that your first RFC came out, we actually added
>>> that repo by default under /opt/source/ so users could test out your
>>> patchset on the beagle default images:
>>>
>>> https://github.com/RobertCNelson/omap-image-builder/commit/edd84bc5c2d925d67d00d0c2008f48cdd75e3e99
>>>
>>> So any Stretch/Buster/Bionic image after Nov 24 2018, has your repo
>>> installed by default in the root file system. ;)
>>
>> OK. But I haven't fixed all examples as I wasn't sure if the changes that
>> I'm making will be accepted or not.
> 
> I assumed that repo would be a work in progress, it was more to make
> it easy for pru users to give it a quick test and give some feedback
> 
>> Suman has insisted that he wants to continue using the old resource table 
>> format
>> for TI's 2019 release.
>>
>> What do you think is the best approach to take?
> 
> I think what TI has been doing with pru-remoteproc just isn't
> working... To give you some perspective on what users of this forum
> have dealt with: TI's "changed" the pru-remoteproc interface/etc for
> end users in every TI kernel: From v3.14.x-ti, v4.1.x-ti, v4.4.x-ti,
> v4.9.x-ti, to v4.14.x-ti..  It's really Painful..> 
> Whereas the uio interface is compatible all the way back to our
> ancient 3.8.x based kernel..  and yes the uio driver isn't perfect,
> secure, etc..
> 
> So yeah, we will make what every you guys do in v4.19.x-ti as the
> default for our "v4.19.x-ti" kernel, but just note, there is a big
> user base, that won't care and will just use the uio interface in real
> designs and products.  Unless "SOMETHING" goes mainline, then the user
> base doesn't have to worry about it changing on every release.

Yes, having PRUSS support in mainline is very important for us.

> 
>> I would suggest.
>> -Get PRUSS kernel drivers via ti-linux-4.19.y
> 
> That's the default plan..
> 
>> -Switch pru-software-package to use 
>> git://git.ti.com/pru-software-support-package/pru-software-support-package.git
> 
> That also the default ;)  It's actually packaged into a deb package..
> using git of: df5794ce7611f8587950f491ef9bf11807e1d0cf
> 
> https://github.com/rcn-ee/repos/blob/master/ti-pru-software-support-package/version.sh
> 
> Regards,
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2917467a-8e11-25ff-bf51-d12fae9a70af%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

['Roger Quadros' via BeagleBoard]

Robert,

On 13/02/19 18:04, Robert Nelson wrote:
> Hi Roger,
> 
> On Wed, Feb 13, 2019 at 9:52 AM Roger Quadros  wrote:
>>
>> Robert,
>>
>> On 28/01/19 21:15, Robert Nelson wrote:
>>> On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp  wrote:


 I tried to update our app image from the 4.14 bone kernel to the 4.19 bone 
 kernel and ran into a big problem:  uio_pruss is not configured in as it 
 is with 4.14.  Is this an oversight?  Is there anyone I need to contact to 
 try and convince them to re-enable uio_pruss? I'd like to get 
 CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some 
 same configuration between Pi's and BBB's, but that's really minor.   
 uio_pruss is a must-have.

 The ti kernels also don't have it, but I cannot use the ti kernels due to 
 other timing reasons.  Mostly concerned about the bone kernels right now.
>>>
>>> Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
>>> notice and mention it! ;)
>>>
>>> Roger @ TI with comments from David posted an RFC for ti's remotproc
>>> for mainline..  That's what i have in v4.19.x-bone "today" (and
>>> v4.20.x-bone/v5.0.x-bone)..
>>

Sorry, I'm still a bit lost here ;).
How do I see the PRUSS kernel patches that you have picked up?

>> All upstream PRUSS series that I posted will not work without changes in
>> the resource tables in pru-software-support packages.
>>
>> e.g.
>> https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f
>>
>> If you can wait for 2 weeks then we could have something in
>> TI 2019 that should work smoothly.
> 
> So around the time that your first RFC came out, we actually added
> that repo by default under /opt/source/ so users could test out your
> patchset on the beagle default images:
> 
> https://github.com/RobertCNelson/omap-image-builder/commit/edd84bc5c2d925d67d00d0c2008f48cdd75e3e99
> 
> So any Stretch/Buster/Bionic image after Nov 24 2018, has your repo
> installed by default in the root file system. ;)

OK. But I haven't fixed all examples as I wasn't sure if the changes that
I'm making will be accepted or not.

Suman has insisted that he wants to continue using the old resource table format
for TI's 2019 release.

What do you think is the best approach to take?

I would suggest.
-Get PRUSS kernel drivers via ti-linux-4.19.y
-Switch pru-software-package to use 
git://git.ti.com/pru-software-support-package/pru-software-support-package.git

Do you see any issues with this?

cheers,
-roger
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5C644A41.5010105%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

['Roger Quadros' via BeagleBoard]

Robert,

On 28/01/19 21:15, Robert Nelson wrote:
> On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp  wrote:
>>
>>
>> I tried to update our app image from the 4.14 bone kernel to the 4.19 bone 
>> kernel and ran into a big problem:  uio_pruss is not configured in as it is 
>> with 4.14.  Is this an oversight?  Is there anyone I need to contact to try 
>> and convince them to re-enable uio_pruss? I'd like to get 
>> CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some 
>> same configuration between Pi's and BBB's, but that's really minor.   
>> uio_pruss is a must-have.
>>
>> The ti kernels also don't have it, but I cannot use the ti kernels due to 
>> other timing reasons.  Mostly concerned about the bone kernels right now.
> 
> Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
> notice and mention it! ;)
> 
> Roger @ TI with comments from David posted an RFC for ti's remotproc
> for mainline..  That's what i have in v4.19.x-bone "today" (and
> v4.20.x-bone/v5.0.x-bone)..

All upstream PRUSS series that I posted will not work without changes in
the resource tables in pru-software-support packages.

e.g.
https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f

If you can wait for 2 weeks then we could have something in
TI 2019 that should work smoothly.

cheers,
-roger

> 
> Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all
> uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module
> to v4.17.x) and it should work fine..
> 
> Regards,
> 

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5C643D1B.9090805%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

['Roger Quadros' via BeagleBoard]

On 13/02/19 13:57, Matthijs van Duin wrote:
> Since I just noticed a bunch of people were added to the Cc... Just for 
> context, this is the patch set I made to get uio-pruss for the am335x and 
> dra7/am57xx working again on the 4.19-ti series kernel:
> https://github.com/mvduin/ti-linux-kernel-dev/tree/ti-linux-4.19.y-uio-pruss/patches/drivers/ti/uio_pruss
> 
> Summary of the patches:
> 0001: uio-pruss driver itself

> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>   if (pdata->sram_pool) {
>   gdev->sram_pool = pdata->sram_pool;
> gdev->sram_vaddr =

What is this sram pool? Is it about MSMC/OCMC RAM? Why is this only for DA850?

> 0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also 
> needed for remoteproc-pru)

This part will eventually be not needed as we are moving away from hwmods.
If you see
https://www.spinics.net/lists/devicetree/msg272572.html

I have got rid of pruss_soc_bus entirely. We now use ti-sysc bus driver to
manage the SYSCONFIG register.

> 0003: add support for ti,deassert-hard-reset (needed for uio-pruss on am335x)

This should also be managed by ti-sysc bus driver but using some form of
reset control driver that can toggle the necessary PRM registers RESET bit.
There were some challenges as to how to keep the clockdomain out of auto-idle
before reset can be issued.

> 0004: outline dts declarations for pruss (can be dropped when full 
> declarations are added for remoteproc-pru)
> 0005: dtsi files for enabling uio-pruss (for convenience of #including by 
> those who want it)

The only issue I see here is these 2 properties

compatible = "ti,pruss-v2";
ti,pintc-offset = <0x2>;

It will be nice if we can retain the compatibles that I'm using here 
https://lkml.org/lkml/2019/2/4/679
See PRUSS Node->Required properties->compatible

We use a different compatible for every SoC as there are differences e.g. 
different RAM sizes, number of interrupts, INTC offset, etc.
So if we can teach uio_pruss to decipher the different compatibles and get the 
register offsets/RAM sizes right using some kind
of driver data (of_match_table->data?), then you don't need ti,pintc-offset.

> 0006: enable uio-pruss by default on beagleboard-x15 (feel free to drop, but 
> seemed better than nothing until remoteproc-pru works)
> 
> On Wed, 13 Feb 2019 at 12:44, Matthijs van Duin  > wrote:
> 
> Adding ti,pintc-offset = <0x2>; to  should suffice
> 
> 
> Obviously we could also change the uio-pruss driver to avoid this need for 
> this property entirely. It ought to be implicit from the compatible-string.

Exactly.

cheers,
-roger
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5C64109F.5020600%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

['Roger Quadros' via BeagleBoard]

+David, Tony, Suman.

Robert, Matthijs, Daniel,

On 28/01/19 21:15, Robert Nelson wrote:
> On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp  wrote:
>>
>>
>> I tried to update our app image from the 4.14 bone kernel to the 4.19 bone 
>> kernel and ran into a big problem:  uio_pruss is not configured in as it is 
>> with 4.14.  Is this an oversight?  Is there anyone I need to contact to try 
>> and convince them to re-enable uio_pruss? I'd like to get 
>> CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some 
>> same configuration between Pi's and BBB's, but that's really minor.   
>> uio_pruss is a must-have.
>>
>> The ti kernels also don't have it, but I cannot use the ti kernels due to 
>> other timing reasons.  Mostly concerned about the bone kernels right now.
> 
> Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
> notice and mention it! ;)
> 
> Roger @ TI with comments from David posted an RFC for ti's remotproc
> for mainline..  That's what i have in v4.19.x-bone "today" (and
> v4.20.x-bone/v5.0.x-bone)..

This is the latest series that I posted for pruss remoteproc
https://lkml.org/lkml/2019/2/4/677

I have been mostly focussing on remoteproc framework and PRU ethernet driver 
use case.

I see that uio_pruss is important for the bone community. We will need
to work together to make sure that it continues to operate when the
PRUSS remoteproc stuff gets merged to kernel.org.

I will keep you all in cc when I post v3 of the series so you can
test uio_pruss.c and review the patches.

Meanwhile, I'd like to understand what must be done to ensure uio_pruss.c
is supported. We might need to make some changes to uio_pruss.c
so that it can understand the device tree node (interrupts, memory regions)
and do runtime_pm etc. It will be great if we don't have to make any
device tree changes when switching between pruss_remoteproc and uio_pruss
drivers. Just unbinding the current driver and binding the alternate driver
should work.

> 
> Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all
> uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module
> to v4.17.x) and it should work fine..
> 
> Regards,
> 

cheers,
-roger

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5C63FD64.8030205%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Drones Using BBB

['Roger Quadros' via BeagleBoard]

Hi,

On 07/02/19 23:27, chuck.dobson...@gmail.com wrote:
> Free Batteries 
> https://www.myfpvstore.com/?affiliates=c9f0f895fb98ab9159f51fd0297e236d
> 
> On Monday, August 1, 2016 at 4:49:05 PM UTC-4, lightshadown wrote:
> 
> I been searching on this forum but cant find anything related for Aerial 
> Drones, dont know why, im brand new on Beaglebone and wana know if theres any 
> info about them, using the BBB,
> I already found the PixHawk Fire Cape 
>  but its no longer 
> aviable, also theres the Erle-Brain 2.0 
>  in wich case its a 
> little pricey for me at the momment, as well the 3DR PixHawk 
>  autopilot system (still cant 
> figure it out how that one works).
> Some people already told me of using the Raspberry pi because it has more 
> development on the drone area, but honestly i dont like their computing power 
> and the fact they store the operating system on an Micro-Usb (im a 
> Photographer, already had lost too many photos due to a bad memory card)  So 
> if anyone else had or has worked on this type of system using the BeagleBone 
> Black for Drones, plz give me an advice of where to start, it would be 
> appreciated.
> 
> Ps: I dont own a BeagleBone Black yet, been spending too much cash on 
> other things.

What exactly do you want to do?
Tip: Don't choose a platform first and then look for a solution around that. 
Choose an existing solution/platform that has already addressed your problem.

I'd start out with evaluating Flight controller software and what platforms are 
supported there and then choose the platform.

cheers,
-roger

> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/5f7bbec8-ae54-4cc2-8609-b665ea805986%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5C5D4A23.8010208%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Automatic date and time set from host PC

['Roger Quadros' via BeagleBoard]

Hi Alan,

On 06/11/18 06:47, Alan Thomason wrote:
> Hi Roger..
> 
> Thanks for the quick reply.  I'll give that a try, but I should have 
> mentioned the host PC that the Beaglebone will normally interface with this 
> project will be Windows based.  Unless I am misunderstanding, this solution 
> is for a Linux based PC.

Windows should also have some kind of NTP server implementation that should 
work with Bone running NTP client.

cheers,
-roger
> 
> Best Regards,
> Alan
> 
> On Monday, November 5, 2018 at 8:47:20 AM UTC-5, Alan Thomason wrote:
> 
> Hi There...
> 
> I want to reset the time and date on my BeagleBone black from the host 
> PC, ideally as an automatic task when the system boots up.  I only hook up to 
> the wider internet when I need updates, usually I just hook up to the PC an 
> communicate with PC as 192.168.7.1 and the BBB as 192.168.7.2 (as delivered).
> 
> Does anyone have any suggestions on how to do this?  A shell script would 
> be ideal, via PHP or Javascript are also possible avenues that I could use.
> 
> Thanks so much,
> 
> Alan Thomason
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/a958c39b-a847-4321-ae9f-8e9ef3d10965%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5BE1552B.40706%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Automatic date and time set from host PC

['Roger Quadros' via BeagleBoard]

Hi,

On 05/11/18 15:47, Alan Thomason wrote:

Hi There...

I want to reset the time and date on my BeagleBone black from the host PC, 
ideally as an automatic task when the system boots up.  I only hook up to the 
wider internet when I need updates, usually I just hook up to the PC an 
communicate with PC as 192.168.7.1 and the BBB as 192.168.7.2 (as delivered).

Does anyone have any suggestions on how to do this?  A shell script would be 
ideal, via PHP or Javascript are also possible avenues that I could use.


How about running NTP server on you PC and NTP client on bone?
https://www.thegeekstuff.com/2014/06/linux-ntp-server-client/



Thanks so much,

Alan Thomason
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 
beagleboard+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e658c912-77ce-40e6-8829-a71d0a4e0b6f%40googlegroups.com
 
.
For more options, visit https://groups.google.com/d/optout.


cheers,
-roger

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5BE05050.5060504%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Swapped PHY and cannot connect to ethernet

['Roger Quadros' via BeagleBoard]

Hi Stephen,

DP83867IR is a tricky PHY to use due to its quasi state bootstrap pins. Each 
pin can have 4 states.

You will need to use strong pull up/down on the bootstrap pins to ensure that 
it latches a correct bootstrap at Power on reset.

Can you cross check if the bootstrap configuration is right by dumping the 
bootstrap configuration?

e.g.

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index c1ab976..ccfb0bf 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -218,6 +218,11 @@ static int dp83867_config_init(struct phy_device *phydev)
dp83867 = (struct dp83867_private *)phydev->priv;
}
 
+   val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_STRAP_STS1);
+   dev_info(>mdio.dev, "STRAP_STS1 0x%x\n", val);
+   val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4);
+   dev_info(>mdio.dev, "CFG4 0x%x\n", val);
+
/* RX_DV/RX_CTRL strapped in mode 1 or mode 2 workaround */
if (dp83867->rxctrl_strap_quirk) {
val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 16/10/2018 01:30, stephen.nguye...@gmail.com wrote:
> Hello,
> 
> I wanted to upgrade to gigabit Ethernet and swapped out the Ethernet PHY to 
> Texas Instrument DP83867IR
> The board booted up fine and detects the PHY. But trying to communicate 
> through the Ethernet as simple as pinging has no response.
> 
> I'm not quite sure if it's a software or hardware problem.
> 
> Here's my connection
> EthernetPHY.jpg 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Here are the dmesg logs, ifconfig, and ethtool on eth0
> 
> |
> [   0.00]BootingLinuxon physical CPU 0x0
> [   0.00]Linuxversion 4.14.49-ti-r54 (root@b2-am57xx-beagle-x15-2gb)(gcc 
> version 6.3.020170516(Debian6.3.0-18+deb9u1))#1 SMP PREEMPT Fri Jun 15 
> 22:14:13 UTC 2018
> [   0.00]CPU:ARMv7Processor[413fc082]revision 2(ARMv7),cr=10c5387d
> [   0.00]CPU:PIPT /VIPT nonaliasing data cache,VIPT aliasing instruction 
> cache
> [   0.00]OF:fdt:Machinemodel:TI AM335x BeagleBoneBlack
> [   0.00]Memorypolicy:Datacache writeback
> [   0.00]efi:GettingEFI parameters fromFDT:
> [   0.00]efi:UEFI notfound.
> [   0.00]cma:Reserved48MiBat 0x9c80
> [   0.00]Onnode 0totalpages:130560
> [   0.00]free_area_init_node:node 0,pgdat c15ed380,node_mem_map df961000
> [   0.00]  Normalzone:1148pages used formemmap
> [   0.00]  Normalzone:0pages reserved
> [   0.00]  Normalzone:130560pages,LIFO batch:31
> [   0.00]CPU:AllCPU(s)started inSVC mode.
> [   0.00]AM335X ES2.1(sgx neon)
> [   0.00]random:get_random_bytes called 
> fromstart_kernel+0xac/0x460withcrng_init=0
> [   0.00]percpu:Embedded18pages/cpu @df8ea000s41548 r8192 d23988 u73728
> [   0.00]pcpu-alloc:s41548 r8192 d23988 u73728 alloc=18*4096
> [   0.00]pcpu-alloc:[0]0
> [   0.00]Built1zonelists,mobility grouping on. Totalpages:129412
> [   0.00]Kernelcommand 
> line:console=ttyO0,115200n8bone_capemgr.uboot_capemgr_enabled=1root=/dev/mmcblk0p1
>  ro rootfstype=ext4 rootwait coherent_pool=1Mnet.ifnames=0quiet
> [   0.00]PID hash table entries:2048(order:1,8192bytes)
> [   0.00]Dentrycache hash table entries:65536(order:6,262144bytes)
> [   0.00]Inode-cache hash table entries:32768(order:5,131072bytes)
> [   0.00]Memory:440472K/522240Kavailable (13312Kkernel 
> code,1168Krwdata,4372Krodata,1024Kinit,673Kbss,32616Kreserved,49152Kcma-reserved,0Khighmem)
> [   0.00]Virtualkernel memory layout:
>                    vector  :0x-0x1000  (  4kB)
>                    fixmap  :0xffc0-0xfff0  (3072kB)
>                    vmalloc :0xe000-0xff80  (504MB)
>                    lowmem  :0xc000-0xdfe0  (510MB)
>                    pkmap   :0xbfe0-0xc000  (  2MB)
>                    modules :0xbf00-0xbfe0  ( 14MB)
>                      .text :0xc0008000-0xc0e0  (14304kB)
>                      .init :0xc140-0xc150  (1024kB)
>                      .data :0xc150-0xc16241a8  (1169kB)
>                       .bss :0xc162ec1c-0xc16d709c  (674kB)
> [   0.00]SLUB:HWalign=64,Order=0-3,MinObjects=0,CPUs=1,Nodes=1
> [   0.00]ftrace:allocating 42794entries in126pages
> [   0.00]Preemptiblehierarchical RCU implementation.
> [   0.00]    RCU restricting CPUsfromNR_CPUS=2to nr_cpu_ids=1.
> [   0.00]    TasksRCU enabled.
> [   0.00]RCU:Adjustinggeometry forrcu_fanout_leaf=16,nr_cpu_ids=1
> [   0.00]NR_IRQS:16,nr_irqs:16,preallocated irqs:16
> [   0.00]IRQ:Foundan INTC at 0xfa20(revision 5.0)with128interrupts
> [   0.00]OMAP clockevent source:timer2 at 2400Hz
> [   0.26]sched_clock:32bits at 24MHz,resolution 41ns,wraps every 
> 89478484971ns
> [   
> 

Re: [beagleboard] Connecting NAND using GPMC - Partitions creation

['Roger Quadros' via BeagleBoard]

Hi,

On 12/09/18 17:09, LYB wrote:
> Hi.
> I'm not sure that is the exact place to ask, but...
> I'm trying to connect an external NAND to the GPMC pins. I updated the device 
> tree for that, and the NAND is identified correctly.
> Yet, later during the nand init, the partitions, as defined in the device 
> tree, are not created.
> I used to the same partitions definition on a different AM335x board, which 
> used kernel version 3.x, while BBB uses now 4.14.x, and the NAND support code 
> was changed a lot.
> My device tree looks quite fine, as much as I can tell (see below).
> Again, the nand works, it is being identified, all signals work correctly 
> (had to remove one of the MMC's for that). the issue is linux creating 
> partitions.
> does any one have any clue about it?

Could you please post the full u-boot+kernel bootlog?
see some comments below.

> 
> |
> _pinmux {
> bbcape_nand_flash_pins: bbcape_nand_flash_pins {
> pinctrl-single,pins = <
> 0x00 (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad0.gpmc_ad0 */
> 0x04 (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad1.gpmc_ad1 */
> 0x08 (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad2.gpmc_ad2 */
> 0x0c (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad3.gpmc_ad3 */
> 0x10 (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad4.gpmc_ad4 */
> 0x14 (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad5.gpmc_ad5 */
> 0x18 (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad6.gpmc_ad6 */
> 0x1c (MUX_MODE0 | PIN_INPUT_PULLUP)/* gpmc_ad7.gpmc_ad7 */
> 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/* gpmc_wait0.gpmc_wait0 */
> 0x74 (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* gpmc_wpn.gpmc_wpn */
> 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* gpmc_csn0.gpmc_csn0  */
> 0x90 (MUX_MODE0 | PIN_OUTPUT)/* gpmc_advn_ale.gpmc_advn_ale */
> 0x94 (MUX_MODE0 | PIN_OUTPUT)/* gpmc_oen_ren.gpmc_oen_ren */
> 0x98 (MUX_MODE0 | PIN_OUTPUT)/* gpmc_wen.gpmc_wen */
> 0x9c (MUX_MODE0 | PIN_OUTPUT)/* gpmc_be0n_cle.gpmc_be0n_cle */
>>;
> };
> };
> 
>  {
> status = "okay";
> };
> 
>  {
>   status = "okay";
> ranges = <0 0 0x0100 0x1000>;/* address range = 16MB (minimum GPMC 
> partition) */
>   nand@0,0 {
>     compatible = "ti,omap2-nand";
> reg = <0 0 4>;/* device IO registers */
> pinctrl-names = "default";

On v4.14 and later you can try adding

 interrupt-parent = <>;
 interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
  <1 IRQ_TYPE_NONE>; /* termcount */
 rb-gpios = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
 ti,nand-xfer-type = "prefetch-irq";


cheers,
-roger

> pinctrl-0 = <_nand_flash_pins>;
> ti,nand-ecc-opt = "bch8";
> ti,elm-id = <>;
> /* generic bindings */
> nand-bus-width = <8>;
> /* vendor specific bindings */
> gpmc,device-width = <2>;
> gpmc,sync-clk-ps = <0>;
> gpmc,cs-on-ns = <0>;
> gpmc,cs-rd-off-ns = <80>;
> gpmc,cs-wr-off-ns = <80>;
> gpmc,adv-on-ns = <0>;
> gpmc,adv-rd-off-ns = <80>;
> gpmc,adv-wr-off-ns = <80>;
> gpmc,we-on-ns = <20>;
> gpmc,we-off-ns = <60>;
> gpmc,oe-on-ns = <20>;
> gpmc,oe-off-ns = <60>;
> gpmc,access-ns = <40>;
> gpmc,rd-cycle-ns = <80>;
> gpmc,wr-cycle-ns = <80>;
> gpmc,wait-pin = <0>;
> gpmc,wait-on-read;
> gpmc,wait-on-write;
> gpmc,bus-turnaround-ns = <0>;
> gpmc,cycle2cycle-delay-ns = <0>;
> gpmc,clk-activation-ns = <0>;
> gpmc,wait-monitoring-ns = <0>;
> gpmc,wr-access-ns = <40>;
> gpmc,wr-data-mux-bus-ns = <0>;
> /* MTD partition table */
> /* All SPL-* partitions are sized to minimal length
> * which can be independently programmable. For
> * NAND flash this is equal to size of erase-block */
> #address-cells = <1>;
> #size-cells = <1>;
> partition@0 {
> label = "NAND.SPL";
> reg = <0x 0x0004>;
> };
> partition@1 {
> label = "NAND.SPL.backup1";
> reg = <0x0004 0x0004>;
> };
> partition@2 {
> label = "NAND.SPL.backup2";
> reg = <0x0008 0x0004>;
> };
> partition@3 {
> label = "NAND.SPL.backup3";
> reg = <0x000c 0x0004>;
> };
> partition@4 {
> label = "NAND.u-boot-spl-os";
> reg = <0x0010 0x0008>;
> };
> partition@5 {
> label = "NAND.u-boot";
> reg = <0x0018 0x0010>;
> };
> partition@6 {
> label = "NAND.u-boot-env";
> reg = <0x0028 0x0004>;
> };
> partition@7 {
> label = "NAND.u-boot-env.backup1";
> reg = <0x002c 0x0004>;
> };
> partition@8 {
> label = "NAND.kernel";
> reg = <0x0030 0x0070>;
> };
> partition@9 {
> label = "NAND.file-system";
> reg = <0x00a0 0x1f60>;
> };
> };
> };
> 
> |
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/dc22655c-903a-4334-a9cb-bb9a55f5f43e%40googlegroups.com
>  
> .
> For 

Re: [beagleboard] 4 GByte RAM?

['Roger Quadros' via BeagleBoard]

It probably is 4Gb (Gigabit) which means 512MB.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 17/05/18 13:19, Mike Maikaefer wrote:
> No, when you check out the BOM or the schematic, you will find 4GB DDR3 RAM 
> (which is not the eMMC).
> 
> On Thu, May 17, 2018 at 10:47 AM, Rick Mann  > wrote:
> 
> That's eMMC flash, not RAM. It's accessed like a disk.
> 
> > On May 16, 2018, at 22:44 , mike.maikae...@gmail.com 
>  wrote:
> > 
> > Hi,
> > 
> > according to the schematics there is a RAM-module with 4 GByte 
> available on the BBB (and also on the BBG). Why are there only 512 MBytes 
> available for the CPU - aren't enough address lines used? Or what else is the 
> reason?
> > 
> > Kind regards
> > 
> > Mike
> > 
> > 
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to beagleboard+unsubscr...@googlegroups.com 
> .
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/ebee7080-b740-42a2-a3ae-a23416241487%40googlegroups.com
>  
> .
> > For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the 
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/hM3a_5_dsk8/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/D8F82C5D-6936-400C-93FC-0A83412DCFF0%40latencyzero.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAG%3DKTcn6Bf1GxhKbvoU1vg1er%2BvxK0JoExeOus-21cQQf138vA%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/459f43da-316f-9b98-8cf4-25a4fb2e881c%40ti.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 - running xen hypervisor

['Roger Quadros' via BeagleBoard]

Hi Iain,

There was an attempt [1] to run Xen on DRA7-evm board which uses the same SoC 
family that's on the X15 board.
However it is based on an old u-boot and kernel.

I'd be nice if you could share patches/instructions if you manage to get this 
working on mainline u-boot. :)

[1] - 
https://wiki.xenproject.org/wiki/User:Xen_intruction_setup_for_dra7xx-evm_board

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 01/02/18 17:58, drhunte...@gmail.com wrote:
> Thanks for your comments. I have today tracked the paging problem down to a 
> need to flush the TLBs before enabling the MMU. This was done via the 
> TLBIALLH.
> At the moment I've done in in xen head.s but maybe better to be done as part 
> of u-boot as it seems to be an AM57xx uboot problem rather than a generic xen 
> one.
> Iain
> 
> On Wednesday, 31 January 2018 22:09:04 UTC, Hee-cheol Yang wrote:
> 
> Hello I've tried similar job in exynos and ARM Fastmodel simulator, 
> facing similar issue.
> 
> In my experiences, many issues are related to ARM TZ, not VE. Many 
> firmwares such as BL0 disable MMU functionality for hypervisor in Secure 
> world and jump to Normal world before  they pass the processor's control to 
> bootloader like uboot. 
> So you need to check whether the TZ settings are done correctly.
> 
> Most SOC vendors provide such firmware in binary. For example, You can 
> get Xen for Exynos firmware in Xen wiki. Also, please check this repository :
> 
> https://github.com/hcyang1012/ARM_Hypervisor 
> 
> 
> I'm not sure TI supports such functionality. But it is worth to check it.
> 
> Best regards
> Heecheol Yang
> 
> 삼성 갤럭시 스마트폰에서 보냈습니다.
> 
> 
>  원본 이메일 
> 보낸 사람: drhun...@gmail.com 
> 날짜: 18/2/1 오전 6:44 (GMT+09:00)
> 받은 사람: BeagleBoard 
> 제목: [beagleboard] X15 - running xen hypervisor
> 
> Hi,
> I am trying to get xen hypervisor to run on an X15 but I have a prefetch 
> abort when the first instruction at a virtual address is fetched. The paging 
> tables appear to be being setup correctly.
> 
> I am using u-boot v2017.01 to boot the xen image. u-boot by default is in 
> hypervisor mode with LPAE enabled which is as far as I can see what xen needs.
> 
> So, to my questions.
> - Has anyone tried this before?
> - does anyone know of a reason why after running u-boot the A15 would be 
> in hypervisor mode but have some side effect that means just writing to HTTBR 
> and HSCTLR is not sufficient to get the MMU functioning correctly?
> 
> Thanks, Iain
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/7475a00d-e52e-44e6-b00c-de3ef10cff93%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/32db26c7-4cc7-484d-98a9-3ea7129a33f9%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are 

Re: [beagleboard] Re: X15 Boot via USB

['Roger Quadros' via BeagleBoard]

Hi Angel,

On 18/01/18 06:09, Angel Sosa wrote:
> On Tuesday, January 16, 2018 at 11:51:57 AM UTC-5, marc bellazzini wrote:
>> Hello Angel, 
>> Mine is still collecting dust after my failed attempt at booting off the 
>> eSATA and making the modifications you have also done. Very disappointing 
>> since it was an expensive purchase. I am also awaiting a solution. The 
>> directions on booting from eSATA were not very clear. 
>>
>>
>> Good luck!
>>
>>
>> On Mon, Jan 15, 2018 at 2:07 PM, Angel Sosa  wrote:
>>
>>
>>
>> Hi Everyone,
>>
>>
>>
>>  I am new to the X15. I have an XM since it came out and have done many 
>> projects with it. I have recently purchased and X15. My desire is to 
>> boot from a SATA drive connected to the ESATA port. I have verified when
>>  booted from the MMC card the SATA drive is bootable, can mount and it 
>> works well. I imaged the SATA drive with the X15 image, In my case SDA1 
>>  is the first partition created. I have removed R444 and placed a jumper
>>  I believe what is J3 pins 1-2 and have left the R444 resister solder 
>> points/mounts empty. When I try to boot off of the SATA drive the board 
>> times out and powers down. The instructions are  a little vague on the 
>> on instructions with in the user manual. I had a similar problem when 
>> the partition was enlarged on the MMC card to 32 gigs, the boot process 
>> would timeout. I used the grow_partition.sh script which fixed the time 
>> out issue with the MMC card. If I hold the X15 board orienting J3, J4,J6
>>  at the upper right corner hand corner, And join pins 1-2 -- most left 
>> hole moving right towards the center  pin, there orientation is 
>> horizontal I believe. The board as I mention powers up and then times 
>> out and shuts down. I have tried with the MMC in and out no avail. I 
>> have also purchased two boards at a pretty steep price and would like to
>>  pass them out to family members with the hopes of purchasing additional
>>  boards. But the ESATA/SATA issue is stopping me and I don't want to 
>> return the second board to DIGIKEY. I cant return the first board well 
>> because I modified it by removing the resistor. 
>>
>>
>>
>> Is the image I used on the SATA drive incorrect or need an adjustment? Are 
>> the PIN orientation as I understand it incorrect.
>>
>>
>>
>> Held the X15 so that the ON switch is the upper left and jumpers are upper 
>> right hand corner. 
>>
>>
>>
>> The drive spins up when I power up the board. So I know the ESATA port is 
>> powering up with the board.
>>
>>           1 2 3
>>
>> | Ethernet   |   | XX0 | J3 Short 1 and 2
>>
>> | Connector|   | 000 | J4
>>
>> |             |   | 000 | J6
>>
>>
>>
>> Drive Manufacturer is the SEAGATE IRON WOLF. 
>>
>>
>>
>> Image:
>>
>> bbx15-debian-9.0-lxqt-armhf-2017-07-02-4gb.img.xz,
>>
>> I have also run ( apt-get -y update && and apt-get -y upgrade )
>>
>>
>>
>>
>>
>> Can you please help? Is there an alternate way of booting off of the ESATA 
>> port
>>
>>
>>
>> Thanks in advance 
>>
>>
>>
>> Angel
>>
>>
>>
>>
>>
>> On Thursday, September 28, 2017 at 10:54:51 AM UTC-4, mab.mo...@gmail.com 
>> wrote:
>> Hello,
>>
>> I just purchased an X15 and the EMMC memory is rapidly filling up. 
>>
>> 1. Is there a way to boot from an external USB hard drive?
>> or 
>> 2. Can someone provide more detail directions on switching boot sequence to 
>> boot directly from eSATA?
>> The reference manual is very vague on this. You need to unsolder and 
>> resolder resistors to act as jumpers? There are perforated holes in the 
>> circuit board where the resistors and jumpers are supposed to be. Are the 
>> resistors supplied? Are they on the board? If so where are they? What are 
>> their values in Ohms? How are the perforations on the board numbered 1-3 
>> from left to right or right to left? This needs to be much more detailed. 
>> Why would you design a board that make switching the boot sequence so 
>> difficult? How about just putting in some removable jumpers!
>>
>> Any detailed help and direction would be appreciated. 
>>
>> Thanks
>>
>> MAB
>>
>>
>>
>>
>>
>> -- 
>>
>> For more options, visit http://beagleboard.org/discuss
>>
>> --- 
>>
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>>
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/xPYp2vR6TDk/unsubscribe.
>>
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/6e58bd35-d1d8-4027-a5f8-23bd76edf60e%40googlegroups.com.
>>
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
> 
> Hi Marc,
>  One other detail, The SATA/ESATA is powered with an external power supply. 
>  The ESATA port is not providing power to the drive itself. And in addition 
> since I de-soldered R444 and added the