Hi, Le 31/05/2018 à 09:02, Roger Oberholtzer a écrit :

The openSUSE info for the Beagle Board Black (https://en.opensuse.org/HCL:BeagleBone_Black) says:

To boot from µSD card, you must press boot select switch button (near µSD slot) on power-on. Otherwise, you will boot from internal eMMC.

Is this still the case? I am guessing that this is a board-related thing. Is there no way to get the board to boot from the µSD card automatically?

This is how the board is designed. To boot on µSD, you can install u-boot on eMMC with a script which boot with µSD card files. Or you can hack the board to always boot from µSD card.

I do not have a card yet. I want to explore the ARM PRU (programmable real-time unit). But booting from the µSD will be a requirement if we chose to use this card.

Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 31/05/2018 à 10:32, Roger Oberholtzer a écrit :

On Thu, May 31, 2018 at 9:41 AM, Guillaume Gardet wrote:

...

Hi,

Le 31/05/2018 à 09:02, Roger Oberholtzer a écrit :

...

The openSUSE info for the Beagle Board Black (https://en.opensuse.org/HCL:BeagleBone_Black) says:

To boot from µSD card, you must press boot select switch button (near µSD slot) on power-on. Otherwise, you will boot from internal eMMC.

Is this still the case? I am guessing that this is a board-related thing. Is there no way to get the board to boot from the µSD card automatically?

This is how the board is designed. To boot on µSD, you can install u-boot on eMMC with a script which boot with µSD card files. Or you can hack the board to always boot from µSD card. Interesting. I only know about u-boot from seeing it referenced when I was playing with a Raspberry PI card.

Any chance u-boot could get the image over the network instead of the µSD card? https://en.wikipedia.org/wiki/Das_U-Boot claims it can. But it does that work?

Yes, you can boot using PXE: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.pxe;h=98862cdfdef480a85... Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 31/05/2018 à 12:42, Roger Oberholtzer a écrit :

On Thu, May 31, 2018 at 11:43 AM, Guillaume Gardet wrote:

...

Le 31/05/2018 à 10:32, Roger Oberholtzer a écrit :

...

Any chance u-boot could get the image over the network instead of the µSD card? https://en.wikipedia.org/wiki/Das_U-Boot claims it can. But it does that work?

Yes, you can boot using PXE: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.pxe;h=98862cdfdef480a85... Time to get a board and see what it can do. It is the ARM's PRU that makes this board interesting.

I think Andres (in Cc) played with PRU already. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 31.05.2018 um 13:20 schrieb Guillaume Gardet:

Le 31/05/2018 à 12:42, Roger Oberholtzer a écrit :

...

Time to get a board and see what it can do. It is the ARM's PRU that makes this board interesting.

I think Andre[a]s (in Cc) played with PRU already.

I had prepared a cross-compiler toolchain, but it was not yet upstream at the time and I haven't updated the packages for some years - SRs welcome. https://build.opensuse.org/project/show/home:a_faerber:pru Matwey and Alex will know more, but at the time there was only a uio driver. The remoteproc driver was still missing upstream, and I still don't see any with pru in the name: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/dri... Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Thu, May 31, 2018 at 1:32 PM, Andreas Färber wrote:

...

I think Andre[a]s (in Cc) played with PRU already.

I had prepared a cross-compiler toolchain, but it was not yet upstream at the time and I haven't updated the packages for some years - SRs welcome.

https://build.opensuse.org/project/show/home:a_faerber:pru

I see that.

Matwey and Alex will know more, but at the time there was only a uio driver. The remoteproc driver was still missing upstream, and I still don't see any with pru in the name:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/dri...

I need to see how one should really use the PRU. I kind of assumed that one generated code somewhere (using some tool chain - TI's?) that one then loaded into the PRU. How you talk to or control it is unclear. I want it to do some fast processing of a couple I/O lines, and occasionally send out some information. Perhaps just even an interrupt that a Linux all or driver could sense and act on. We tried having a Raspberry PI 3 monitor these lines (which trigger an interrupt), but even in C in a dedicated kernel driver (no context switching), it could not keep up. We are hoping that the PRU may do better. No idea. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Thu, May 31, 2018 at 1:54 PM, Matwey V. Kornilov wrote:

Basically you have to compile your binary code using TI toolchain or GCC toolchain. And follow TI docs to interact with hardware.

Then there is your user-space application which loads this binary to the hardware and exchange the data with your firmware.

The application has to use appropriate host kernel interface to upload binary. The interface implementation for BBB is currently missing part in upstream linux kernel.

Sounds good. It is exactly what I expect. The fun will be to make all the parts work. But it's what we do... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org