[opensuse-arm] Beagle Board Black boot from µSD
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? 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. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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
On Thu, May 31, 2018 at 9:41 AM, Guillaume Gardet <guillaume.gardet@free.fr> 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? -- Roger Oberholtzer -- 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 <guillaume.gardet@free.fr> 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
On Thu, May 31, 2018 at 11:43 AM, Guillaume Gardet <guillaume.gardet@free.fr> 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. -- Roger Oberholtzer -- 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 <guillaume.gardet@free.fr> 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 <afaerber@suse.de> 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.
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 31.05.2018 14:50, Roger Oberholtzer wrote:
On Thu, May 31, 2018 at 1:32 PM, Andreas Färber <afaerber@suse.de> 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.
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.
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.
-- 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 <matwey.kornilov@gmail.com> 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
Am 31.05.2018 um 09:02 schrieb Roger Oberholtzer:
I want to explore the ARM PRU (programmable real-time unit).
Please note that the PRU has nothing to do with arm. It's a TI thing and needs its own toolchain that openSUSE does not provide at this time. Cheers, 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 31.05.2018 10:02, Roger Oberholtzer wrote:
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?
In order to boot from uSD automatically, you have to ensure that there is no bootloader at eMMC memory. This can be done using zeroing begin of eMMC. Pressing the button just changes default probing order.
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.
In theory you also can deploy openSUSE image onto eMMC memory if you manage to boot Linux from somewhere. But as far as I know nobody tried this yet. It would be great if you could manage to bring PRU up. There are still some missing parts.
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (4)
-
Andreas Färber -
Guillaume Gardet -
Matwey V. Kornilov -
Roger Oberholtzer