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.gitso 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 buildIf 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
On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson
<[email protected]> wrote:
On Fri, May 28, 2021 at 2:53 PM Robert Nelson <[email protected]> wrote:
>
> On Fri, May 28, 2021 at 2:45 PM Robert Nelson <[email protected]> wrote:
> >
> > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz <[email protected]> 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..
>
> 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? ;)
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
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/1419458740.838013.1622321132117%40mail.yahoo.com.
