PRU Assumptions - True or False

[Bruce Chidester]

I am using BBB Revision C

Please help me get clarity on my assumptions that I believe I have learned so far and tell me where I am incorrect:

1. There are 2 architectures to interact with the PRU's. They are UIO and RemoteProc. And they can easily be selected in the /boot/uEnv.txt file. You cannot run both at the same time.

2. When using RemoteProc you can send a remote message to the PRU and this solution does not work with UIO.

3. When using UIO the PRU can send an Interrupt to the host code but RemoteProc cannot.

4. When using UIO, you cannot send an interrupt to the PRU, you need to create some other solution maybe through shared memory.

5. When working with UIO, clpru generated binaries are no good and this forces you to write the PRU code in assembly and to use pasm.

It's really not knowing which architecture some articles are talking about, or not knowing the limits of the architecture that makes the PRU stuff so frustrating.

I thank you in advance.

[Dennis Lee Bieber]

On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester

<brucechidester-Re5...@public.gmane.org> wrote:

>I am using BBB Revision C
>
>Please help me get clarity on my assumptions that I believe I have learned
>so far and tell me where I am incorrect:

Can't confirm for everything, but...
>
>1. There are 2 architectures to interact with the PRU's. They are *UIO* and
>*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt file.

>You cannot run both at the same time.

TRUE -- but maybe not "easily"; there are some dependencies upon the
kernel version loaded.

TI has deprecated UIO and considers RemoteProc to be the route for
future usage (it is not tied to just the PRUs, it should work with the DSP
chips on the BB AI, et al.).

>
>2. When using RemoteProc you can *send* a remote message to the PRU and
>this solution *does not work* with UIO.

RPMsg supports sending message in both directions
https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
"""
There are two vrings provided per PRU core, one vring is used for messages
passed to the ARM and the other vring is used for messages received from
the ARM. System level mailboxes are used to notify cores (ARM or PRU) when
new messages are waiting in the shared buffers.
"""

>
>3. When using UIO the PRU can *send* an Interrupt to the host code but
>RemoteProc *cannot*.
>
>4. When using UIO, you *cannot* send an interrupt to the PRU, you need to

>create some other solution maybe through shared memory.
>

As the PRUs do not have what I would call true interrupts (they have a
set of "interrupt bits" but do NOT interrupt the processor, the bits have
to be polled, and appropriate handlers called) any talk of interrupts is
vague.

However, for RPMsg, the "mailbox" provides, I believe, some form of
blocked wait or maybe use of a select() call to test for mailbox data. I
don't really know what a "Kick" entails in:
"""
ARM Host Steps
Step 1a: Allocate a new buffer -or-
Step 1b: Get a Used buffer from the slave Vring
Step 2: Copy data to be transferred into the buffer from Step 1
Step 3: Add the newly filled buffer to the Available list in the
slave Vring
Step 4: Kick the slave Vring by writing its index (1) into a
message in Mailbox 2
PRU Steps
Step 5: A Kick is discovered in Mailbox 2 with the index of the
Kicked Vring (1). This indicates to the PRU that data is available for
receive
Step 6: Get the Available buffer from the slave Vring
Step 7: Copy data to be received out of the buffer from Step 2
Step 8: Add the now empty buffer to the Used list in the slave
Vring
Step 9: Kick the slave Vring by writing its index (1) into a
message in Mailbox 3
"""
Step five appears to be a polling loop on the mailbox.




--
Dennis L Bieber

[Bruce Chidester]

Dennis,

Thanks for your response. 

When developing with the UIO architecture, they use the term "interrupt", so I assume they meant it somehow, but not willing to die on that hill. I could not get any form of "what they called interrupt" to work the remote proc architecture. I tried, and tried, and tried. If that solution exists I would greatly appreciate it.

The bi-directional note is correct about messaging, I was trying to emphasize that UIO cannot do messaging.

Your willingness to get in the mud with my issues is appreciated.

[Robert Heller]

At Fri, 28 May 2021 12:59:20 -0400 beagl...@googlegroups.com wrote:

>
> On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Bruce Chidester
> <brucechidester-Re5...@public.gmane.org> wrote:
>
> >I am using BBB Revision C
> >
> >Please help me get clarity on my assumptions that I believe I have learned
> >so far and tell me where I am incorrect:
>
> Can't confirm for everything, but...
> >
> >1. There are 2 architectures to interact with the PRU's. They are *UIO* and
> >*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt file.
> >You cannot run both at the same time.
>
> TRUE -- but maybe not "easily"; there are some dependencies upon the
> kernel version loaded.

YES. 5.x kernels only support UIO. You need a 4.x TI kernel for RemoteProc.

>
> TI has deprecated UIO and considers RemoteProc to be the route for
> future usage (it is not tied to just the PRUs, it should work with the DSP
> chips on the BB AI, et al.).

I think the mainline kernels don't have the RemoteProc kernel code. At least
by default.

Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Bruce Chidester]

I'm confused because I thought the plan was Remote Proc going forward. Do you seem to say it is UIO going forward?

[Robert Nelson]

On Fri, May 28, 2021 at 12:21 PM Bruce Chidester
<brucech...@gmail.com> wrote:
>
> I'm confused because I thought the plan was Remote Proc going forward. Do you seem to say it is UIO going forward?

Mainline has been 'slowly' getting RemoteProc work done by TI..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Robert Heller]

At Fri, 28 May 2021 10:21:11 -0700 (PDT) beagl...@googlegroups.com wrote:

>
> I'm confused because I thought the plan was Remote Proc going forward. Do
> you seem to say it is UIO going forward?

Only that the *stock* mainline kernels don't have Remote Proc support. I
guess TI has not gotten around to porting things yet or the kernel builder
devs have not built the 5.x kernels with Remote Proc:

from /boot/config-4.19.94-ti-r42:
#
# Rpmsg drivers
#
CONFIG_RPMSG=y
# CONFIG_RPMSG_CHAR is not set
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
CONFIG_RPMSG_VIRTIO=m
CONFIG_RPMSG_RPC=m
CONFIG_RPMSG_PRU=m

#
# Rpmsg virtual device drivers
#
CONFIG_RPMSG_KDRV=y
CONFIG_RPMSG_KDRV_DISPLAY=y
CONFIG_RPMSG_KDRV_ETH_SWITCH=m


from /boot/config-5.4.102-bone45:
#
# Rpmsg drivers
#
CONFIG_RPMSG=m
CONFIG_RPMSG_CHAR=m
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
CONFIG_RPMSG_VIRTIO=m
# end of Rpmsg drivers

> > Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364
> > <(978)%20633-5364>

[Robert Nelson]

On Fri, May 28, 2021 at 12:36 PM Robert Nelson <robert...@gmail.com> wrote:
>
> On Fri, May 28, 2021 at 12:21 PM Bruce Chidester
> <brucech...@gmail.com> wrote:
> >
> > I'm confused because I thought the plan was Remote Proc going forward. Do you seem to say it is UIO going forward?
>
> Mainline has been 'slowly' getting RemoteProc work done by TI..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/remoteproc/pru_rproc.c

[Bruce Chidester]

Does the 5.x kernel support an interrupt from the PRU while also supporting the bi-directional messaging through rproc?

[Robert Nelson]

On Fri, May 28, 2021 at 12:47 PM Bruce Chidester
<brucech...@gmail.com> wrote:
>
> Does the 5.x kernel support an interrupt from the PRU while also supporting the bi-directional messaging through rproc?

sorry, i completely missed these commits, so i have not personally
tested it... It got merged in v5.11.x and has been tweaked since..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml?h=v5.13-rc3

it "should" be an extension of the pru code found in
v4.14.x-ti/v4.19.x-ti/v5.4.x-ti..

[Robert Nelson]

I see lots of interrupt hints here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c

[Robert Nelson]

irq driver for pru:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-pruss-intc.c

[Mark Lazarewicz]

Dumb question by a Debian Newb

I am following this now Debian: Getting Started with the BeagleBone Black

Debian: Getting Started with the BeagleBone Black This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability Boards: BeagleBone Black at Digi-K...

To test this PRU stuff should I use Mainline or TI BSP? whats the difference?

As we speak Im cloning the TI BSP version and looks like somehow I am on 4.14 Branch . I had bad internet last night and I lost the building during resolve after downloading the entire kernel of mainline . Today Im trying TI BSP

cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src

--
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+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjHr%3D2Mx%2BKLa9enn2pd9rfid0SQ6kVw7ZNh8RPgJpZiFA%40mail.gmail.com.

[Robert Nelson]

On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard <beagl...@googlegroups.com> wrote:

Dumb question by a Debian Newb

I am following this now Debian: Getting Started with the BeagleBone Black

Debian: Getting Started with the BeagleBone Black This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability Boards: BeagleBone Black at Digi-K...

To test this PRU stuff should I use Mainline or TI BSP? whats the difference?

As we speak Im cloning the TI BSP version and looks like somehow I am on 4.14 Branch . I had bad internet last night and I lost the building during resolve after downloading the entire kernel of mainline . Today Im trying TI BSP

cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src

Use the "am33x-v5.13" branch of: https://github.com/RobertCNelson/bb-kernel

There are "pre-builds" under apt...

But, I think we need to update the device tree..

Regards,

[Robert Nelson]

Thinking:

https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/7a960d2e3e04a5418772cddd51493ad8578eccf6

Regards, 

[Robert Nelson]

And the interrupt controller..

https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/68aea0792284d7b3c58741c62738287762a5cc0c

Regards, 

[Mark Lazarewicz]

Thanks Robert

I love these instructions very well done

my goal is to be able to build something stable from scratch not drop binaries maybe modify kernel add drivers be self sufficient at building everything and manually updating SD card as opposed to using an upgrade/update on the BB black.

Not worried about having the most current linux wont ask any questions or need support just trying to learn building everything myself for scratch. I have NO capes no changes to .dts Im interested in the workings of this resource file and maybe getting the big shared RAM

Thanks wish I had found this link before did not know it existed

So I guess my question is which version will work as is for testing some PRU MSG examples as is?

Mark

--

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/CAOCHtYjoJEDJgvnwdcz%2B-3ktqFCTmyebB3qF41g2mMSGij1hiA%40mail.gmail.com

.

[Robert Nelson]

On Fri, May 28, 2021 at 2:19 PM 'Mark Lazarewicz' via BeagleBoard <beagl...@googlegroups.com> wrote:

Thanks Robert

I love these instructions very well done

my goal is to be able to build something stable from scratch not drop binaries maybe modify kernel add drivers be self sufficient at building everything and manually updating SD card as opposed to using an upgrade/update on the BB black.

Glad you like it, it's' my old eewiki page just updated and updated as users need help. ;)

Not worried about having the most current linux wont ask any questions or need support just trying to learn building everything myself for scratch. I have NO capes no changes to .dts Im interested in the workings of this resource file and maybe getting the big shared RAM

Thanks wish I had found this link before did not know it existed

So I guess my question is which version will work as is for testing some PRU MSG examples as is?

"as-is"... Either the 4.14.x-ti or 4.19.x-ti with Mark's pru cookbook:

https://markayoder.github.io/PRUCookbook/

v5.13.x: closer... just another bug:

ebian@beaglebone:~$ uname -r
5.13.0-rc3-bone2.1
debian@beaglebone:~$ dmesg | grep pru
[    2.040720] pruss 4a300000.pruss: (null) is missing its 'cfg' node

Regards,

[Mark Lazarewicz]

Thanks!! 

Think of it as I'm validating the instructions I think having these is something good. Unfortunately my VM blew up just now.

I KNOW your adamant about not supporting VM.

So I'll build a dedicated Debian 8 dev box.

Any hints tips lessons learned what you use be appreciated.

Have a great long weekend.

Regards

Sent from Yahoo Mail on Android

--

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/CAOCHtYgW8-jB9B6byJEeB_KFCX6O-s2ObWc-aAzT%2B-hm3PH3Tg%40mail.gmail.com

.

[Robert Nelson]

On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz <laza...@yahoo.com> wrote:
>
> Thanks!!
>
> Think of it as I'm validating the instructions I think having these is something good. Unfortunately my VM blew up just now.
>
> I KNOW your adamant about not supporting VM.
>
> So I'll build a dedicated Debian 8 dev box.
>
> Any hints tips lessons learned what you use be appreciated.
>
> Have a great long weekend.

VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
failure point..

[Robert Nelson]

I think mainline might work:

debian@beaglebone:~$ uname -r
5.13.0-rc3-bone2.2

debian@beaglebone:~$ dmesg | grep pru

[ 2.044506] remoteproc remoteproc1: 4a334000.pru is available
[ 2.045701] remoteproc remoteproc2: 4a338000.pru is available
debian@beaglebone:~$ ls /dev/remoteproc/pruss-core*
/dev/remoteproc/pruss-core0:
coredump device firmware name power recovery state subsystem uevent

/dev/remoteproc/pruss-core1:
coredump device firmware name power recovery state subsystem uevent

@Mark Yoder can you test? ;)

[Robert Nelson]

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state
[ 243.355728] remoteproc remoteproc1: powering up 4a334000.pru
[ 243.366533] remoteproc remoteproc1: Booting fw image
am335x-pru0-fw, size 32456
[ 243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state
[ 296.981371] remoteproc remoteproc1: stopped remote processor 4a334000.pru

[Dennis Lee Bieber]

On Fri, 28 May 2021 10:11:46 -0700 (PDT), in

gmane.comp.hardware.beagleboard.user Bruce Chidester
<brucechidester-Re5...@public.gmane.org> wrote:

>Dennis,
>
>Thanks for your response.
>
>When developing with the UIO architecture, they use the term "interrupt",
>so I assume they meant it somehow, but not willing to die on that hill. I
>could not get any form of "what they called interrupt" to work the remote
>proc architecture. I tried, and tried, and tried. If that solution exists I
>would greatly appreciate it.

I'd need to study much more to find out how a PRU passes an interrupt
to the ARM core, but a comment in
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiW0qzomO3wAhUSV80KHdPiBj8QFnoECAgQAA&url=https%3A%2F%2Fwww.ti.com%2Flit%2Fpdf%2Fsprace9&usg=AOvVaw1D0FgDrMcykHqZsXm5UPdq
(getting started guide from TI: SPRACE9A)
"""
The PRU_ICSSG adds a Task Manager, which can preempt currently running
code. The Task Manager allows firmware to meet timing requirements for high
priority tasks by interrupting lower priority tasks.
"""
reinforces that the non-enhanced PRUs on the BBB (PRU_ICSS vs PRU_ICSSG) do
not have preemptive interrupts.

That document also implies that interrupts are viable, but have to be
defined in the resource tables of the firmware
"""
User applications can require communication between the PRUs and the Arm
core. Linux provides a method for this communication called RemoteProc
Messaging (RPMsg). RPMsg fits into the RemoteProc framework. TI provides a
RPMsg library and getting started examples to demonstrate how to use RPMsg.
These examples showcase the PRU firmware using its resource table to
request specific interrupt mappings and shared memory to implement the
communication channel.
"""

Strangely, section 3.6.2.2 of
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Overview.html
describes TI's PRU as Ethernet port mode, supposedly using RProc/RPMsg. But
when you get to the Linux side (section 3.6.4.1) they are suddenly back to
using UIO.

https://elinux.org/PRUSSv2_Interrupt_Controller (linking to
https://elinux.org/PRUSSv2_Interrupts ) indicates that PRU interrupt #60 is
the one that "sets" when a message has been left in the PRU0 mailbox.

SPRUHF8A (am335x Pru Reference) has
"""
6.1 Introduction
The PRU-ICSS interrupt controller (INTC) is an interface between interrupts
coming from different parts of the system (referred to as system events)
and the PRU-ICSS interrupt interface.

The PRU-ICSS INTC has the following features:
• Capturing up to 64 System Events
• Supports up to 10 interrupt channels.
• Generation of 10 Host Interrupts
– 2 Host Interrupts for the PRUs.
– 8 Host Interrupts exported from the PRU-ICSS for signaling the
ARM interrupt controllers.
• Each system event can be enabled and disabled.
• Each host event can be enabled and disabled.
• Hardware prioritization of events.
"""
• Host Interrupt 0 is connected to bit 30 in register 31 of PRU0 and
PRU1.
• Host Interrupt 1 is connected to bit 31 in register 31 for PRU0 and
PRU1.
• Host Interrupts 2 through 9 exported from PRU-ICSS for signaling ARM
interrupt controllers or other machines like EDMA.
"""

Unfortunately, I've never found any documents for either RPMsg or UIO
APIs... Or, at least, not something I'd consider API documentation (I was
spoiled decades ago by the documentation for VAX/VMS, which filled two
shelves of a bookcase with 3" 3-ring binders).


--
Dennis L Bieber

[Dennis Lee Bieber]

On Fri, 28 May 2021 13:15:20 -0400 (EDT), in
gmane.comp.hardware.beagleboard.user Robert Heller

<heller-2/ccJrXdU8tWk0Htik3J/w...@public.gmane.org> wrote:


>
>YES. 5.x kernels only support UIO. You need a 4.x TI kernel for RemoteProc.
>

Ouch -- a reversion...

>
>I think the mainline kernels don't have the RemoteProc kernel code. At least
>by default.
>

Going to impact the day when Beagle images get Debian 11 I suspect --
since I think Debian 11 is a 5.x kernel.


--
Dennis L Bieber

[Mark Lazarewicz]

Hello 

I've failed to build following those instructions twice in Mainline  and twice using the TI BSP.version. the 2nd attempt of TI BSP is hung as we speak after resolving dependencies for several hours. Each attempt takes hours and the build_kernel script doesnt care you already cloned 2G of code it clones torvald.git

so I retried 4 times by running build_kernel.sh twice in both directories

The Mainline had some git branch errors today

I paid to upgrade my internet for this testing and was ready to buy a 64 bit box but am scared these instructions need a refresh and I will waste $$

what would be lovely is a 2 line like is in the instruction pasted below with something that will work for sure.

the two directories I created are both on wrong branches and  dont complete a buil d

Be nice not keep downloading the 2G kernel source I know there is  a rebuild.sh but I am assuming that is used after a successful build

If these instruction need I tweek I can understand I can test them. If it old and not supported a heads up would be appreciated. So I need something like this below with everything needed to build a kernel including the previous two steps as my two directories are on the wrong branches

Thanks

For TI v5.4.x: Real-Time

#~/ti-linux-kernel-dev/
git checkout origin/ti-linux-rt-5.4.y -b tmp

Build:



Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s


Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s

Build:

#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.sh

[Mark Lazarewicz]

I decided to make another attempt a clean dir on Mainline 5.4 I was blocked. No password . That was not there before 

I guess I will take a break

Linux Kernel

This script will build the kernel, modules, device tree binaries and copy them to the deploy directory.

Mainline

Debian: Getting Started with the BeagleBone Black This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability Boards: BeagleBone Black at Digi-K...

Download:

#~/
git clone https://github.com/RobertCNelson/bb-kernel
cd bb-kernel/

--
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/1419458740.838013.1622321132117%40mail.yahoo.com.

[Robert Nelson]

> Be nice not keep downloading the 2G kernel source I know there is a rebuild.sh but I am assuming that is used after a successful build
> If these instruction need I tweek I can understand I can test them. If it old and not supported a heads up would be appreciated. So I need something like this below with everything needed to build a kernel including the previous two steps as my two directories are on the wrong branches

There is a variable in system.sh to set this up, most users use it
once and done..

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-5.4.y/system.sh.sample

```
###OPTIONAL: LINUX_GIT: specify location of locally cloned git tree.
#
#LINUX_GIT=/home/user/linux-stable/
```

Anywhere in your root file system, clone Torvald's tree:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

and set LINUX_GIT variable to it's location:

For example in home:

cd /home/<my-user>/repos/
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Then set in system.sh
LINUX_GIT=/home/<my-user-name>/repos/linux/

[amf]

Hi lazarman,

on ubuntu 20.04, this builds ok

git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
cd ti-linux-kernel-dev
git checkout remotes/origin/ti-linux-rt-5.4.y -b ti-linux-rt-5.4.y
./build_kernel.sh

I've used VirtualBox before with Ubuntu 16/18/20 without any issues, what VM are you using?

Several years ago a company that I worked for used some other VM, it was a pain in the azz to get to work, if i hear the name again i'll know if that was the one.

I haven't used Debian for a desktop, so I can't help you with that.

[Mark Lazarewicz]

Hello AMF 

I have 5 year old quad core win 8.1 64 bit 8 G ram laptop running Ubuntu 16.04 VM  I used it to build SDK kernel no problems 

and 

a new Debian 10 VM with a 64 bit GCC on same machine.

 The Debian VM is flaky last attempt  I just got memory calloc error on building 5.5 TI BSP from the instructions on Digikey.

I have a 10 year old win 7 quad core desktop I think it has 8 gig ram I never used I was contemplating either a dual boot or nuke win 7 a native Linux build box. Problem is it's probably 32 bit.

Which compiler are you using? 32 bit or 64 bit and a link to it would be great

 and 

Is this 5.x or 5.x 

I have several BBW, an am335x SK and two BBB for hardware. I'm also a JTAG user so I'd prefer nothing in EMC I don't know if that's possible?

I also probably need SD preparation instructions to go with kernel.

You know something like Robert has and the SDK has that even a college student can follow

Thanks alot!!

Mark

Sent from Yahoo Mail on Android

--

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/6dcb2683-2d69-45fa-a4a8-62bb6c6e3ed0n%40googlegroups.com

.