Author Topic: [Solved] Help me choosing an ARM that runs Linux  (Read 780 times)

0 Members and 1 Guest are viewing this topic.

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
[Solved] Help me choosing an ARM that runs Linux
« on: February 11, 2017, 11:05:42 AM »
I chose to put this question here because it is just choosing a chip. I will post in project or MCU section later should I encounter any issues.

Over the years I have developed an audio DAC technology consists an ADSP-BF706 as interpolation engine, iCE40HX8K as SDM/DEM engine and a thermostat 4-bit DAC is used for final DAC conversion.
What I want to do is to make this a portable music player, not just a sound card. I plan to use an ARM processor to run Linux, which handles GUI, USB, decoder and DSP algorithm.
The ARM directly talks to FPGA using a parallel bus, thus eliminating the need of a dedicated DSP chip.

Here is a list of what the processor needs in order to make this happen:
1. 500MHz+ with NEON, power <0.5w at half speed, power <0.8w at full speed.
2. Can be routed with 5mil/5mil traces and 10mil/18mil vias.
3. Supports DDR3L-800 x16. Supports eMMC at 40MB/s+ speed.
4. At least one USB2.0 device interface.
5. MIPI or 16-bit RGB controller, 320*480 or higher.
6. A parallel port that supports 8-bit*100MHz with frame sync, slave mode preferred.
7. Supports suspend to RAM and soft power off.
8. Runs Linux with Mono/Winforms or Mono/Gtk#.

So far I've been looking at iMX6UL/ULL and AM3352. The former doesn't have slave mode parallel interface, and the latter consumes too much power.
Do you have any good suggestions on which ARM processor to use? Or can you suggest me another that suits my needs?

Final decision:
i.MX6ULL, with 528MHz Cortex-A7 w/NEON, LCD controller and EIM external bus interface.
Already ordered the official dev kit for this chip, seems promising to me.
« Last Edit: February 14, 2017, 04:51:19 AM by blueskull »
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline RJDog

  • Contributor
  • Posts: 18
  • Country: ca
Re: Help me choosing an ARM that runs Linux
« Reply #1 on: February 12, 2017, 12:35:48 PM »
I've been playing around a lot lately with Orange Pi and Orange Pi Zero in particular and I've been really digging it.  It is an Allwinner H3/H2+ SoC, with ARM Cortex A7.  Very speedy.  Runs Armbian Linux well.  It is a small(ish) pitch BGA (FBGA347, 0.65mm pitch) though, so not sure if that suits your needs (I am not nearly brave enough to try soldering this myself).

This doesn't solve your requirement about supporting a USB device interface, but I'm using an Atmel Attiny 441 with VUSB library for that very purpose in a project myself, and linking the two via UART.

My two cents.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #2 on: February 12, 2017, 02:18:38 PM »
I've been playing around a lot lately with Orange Pi and Orange Pi Zero in particular and I've been really digging it.  It is an Allwinner H3/H2+ SoC, with ARM Cortex A7.  Very speedy.  Runs Armbian Linux well.  It is a small(ish) pitch BGA (FBGA347, 0.65mm pitch) though, so not sure if that suits your needs (I am not nearly brave enough to try soldering this myself).

This doesn't solve your requirement about supporting a USB device interface, but I'm using an Atmel Attiny 441 with VUSB library for that very purpose in a project myself, and linking the two via UART.

My two cents.

The AllWinner one is a very powerful chip, and I think it does have one USB OTG, which can be configured as device.
However, it doesn't have any parallel buses besides memory interface, and I don't think its NAND interface can be easily configured to a general purpose parallel bus.
The power consumption is also an issue. From linux-sunxi, it seems like it's hot enough to need a heat sink.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline RJDog

  • Contributor
  • Posts: 18
  • Country: ca
Re: Help me choosing an ARM that runs Linux
« Reply #3 on: February 12, 2017, 03:18:04 PM »
The AllWinner one is a very powerful chip, and I think it does have one USB OTG, which can be configured as device.
However, it doesn't have any parallel buses besides memory interface, and I don't think its NAND interface can be easily configured to a general purpose parallel bus.
The power consumption is also an issue. From linux-sunxi, it seems like it's hot enough to need a heat sink.
The GPIO could theoretically be configured as a parallel interface... but the software interface would probably require some serious work... I'll summarize by saying "fair enough".
I have two of the four cores disabled... and gpu disabled, cpu clock speed limited, and a bunch of other stuff to get the power draw under 400mA, so I am getting away without a heat sink, but I know many who use heat sinks.  Probably recommended to use a heatsink if you go full bore on the CPU.

So long story short, maybe not exactly what you're looking for, but I've been working with it a lot lately so I am in a "this is awesome and can obviously be used in every situation" kind of mentality.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #4 on: February 12, 2017, 03:32:42 PM »
The GPIO could theoretically be configured as a parallel interface... but the software interface would probably require some serious work... I'll summarize by saying "fair enough".

Don't think it can spit 100MB/s. I need a 8-bit bus running at 98MHz or 16-bit bus running at 49MHz.
In my DAC architecture, audio input (44.1ksps to 192ksps) is first successively oversampled to 12.288Msps, then sent to FPGA, which does sigma delta modulation and dynamic element matching.
The link between ARM and FPGA must be able to handle 12.288Msps*32bit*2channel=98.304MB/s.

That being said, I would be glad if you can share some of your Linux experience. I need some hep in bringing my yocto system up and running.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline kc8apf

  • Regular Contributor
  • *
  • Posts: 99
  • Country: us
Re: Help me choosing an ARM that runs Linux
« Reply #5 on: February 12, 2017, 03:52:29 PM »
Parallel bus is a bit unusual on ARM parts these days. Maybe a Xilinx Zynx?

Re: Linux and yocto; feel free to ask questions. I work on OpenBMC which is Yocto-based and am setting up a common Yocto distribution for internal projects at work.

Sent from my Nexus 5X using Tapatalk

 

Online julian1

  • Regular Contributor
  • *
  • Posts: 189
  • Country: au
  • http://blog.julian1.io
Re: Help me choosing an ARM that runs Linux
« Reply #6 on: February 12, 2017, 04:06:11 PM »
I don't have any experience in this area, but was recently looking at the Octavo OSD335x, and trying to figure out how difficult it would be target for embedded linux.

http://octavosystems.com/octavo_products/osd335x/. It's an ARM Cortex-A8 which I believe implements ARM v7.

It's a BGA - but large pitch - 1.27mm . And it integrates the complicated DDR3 SDRAM.

Would it be possible to use GPIO to handle the parallel port for the fpga? Would perhaps require writing a kernel level device-driver?

I found it interesting because the Beaglebone is open-source, and is therefore a good source for a reference design. Also it would be possible to prototype with the Beaglebone, before doing a dedicated standalone pcb.

datasheet http://octavosystems.com/octavosystems.com/wp-content/uploads/2015/09/OSD335x-Datasheet.pdf

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #7 on: February 12, 2017, 04:12:05 PM »
I don't have any experience in this area, but was recently looking at the Octavo OSD335x, and trying to figure out how difficult it would be target for embedded linux.

Octavo is based on AM3358, which is the big brother of my contender, AM3352. AM3358=faster AM3352+GPU.
I'm reasonable experienced with AM3358 as I've been working with BeagleBone Black for a while (though I don't know exactly how Linux is set up -- I use a pre-made distribution, Debian), and it has a parallel bus that exactly fits my need, plus it is fast enough.
However, I see two problems with it, one being it supports only SD2.0/eMMC4.2, which imposes a speed penalty when booting. I want my gadget to boot up quickly. The i.MX supports HS200/SD3.0.
Also, another problem I can see is that AM335x is consuming too much power. From TI's documentation, when running with DDR3, the idle power is more than 500mW, let along full load power.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #8 on: February 12, 2017, 04:25:53 PM »
Parallel bus is a bit unusual on ARM parts these days. Maybe a Xilinx Zynx?

Frankly, as a one-off hobbyist build, I don't care about cost. However, my OCD just won't allow my to solve a problem that belongs to a $19 chip set with a $58 chip.
An i.MX6ULL costs ~9 bucks at 1pcs, and an iCE40HX8K FPGA costs ~10 bucks at 1pcs. The cheapest Zync that Digikey has stock is ~58 bucks a pop.

Re: Linux and yocto; feel free to ask questions. I work on OpenBMC which is Yocto-based and am setting up a common Yocto distribution for internal projects at work.

Huge thanks. Please bear with me as I'm a complete newbie in using yocto. Just few hours ago I went into an issue: boost library won't compile when bitbaking.
It says "Error: expected comma after name {a 200-byte long identifier} in .size directive". The error was thrown by assembler, which seems weird to me. The only reason I can think of is compiler generates too long an identifier name, that the assembler can not handle it, or maybe my compiler's version doesn't match assembler's version?
I was building on Ubuntu 14.04.5 with updated packages, all following instruction exactly from NXP's BSP user's guide.
I was able to compile core-image-mininal and core-image-base, but when compiling a slightly larger image, boost failed. I believe gettext also failed, but I didn't log the error.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline kc8apf

  • Regular Contributor
  • *
  • Posts: 99
  • Country: us
Re: Help me choosing an ARM that runs Linux
« Reply #9 on: February 12, 2017, 04:29:20 PM »
Yocto is almost hermetic so Ubuntu version shouldn't matter much. I'll need to see the full build log, what version of Yocto you started with, and what BSP you are using. Boost shouldn't cause a problem like that.

Sent from my Nexus 5X using Tapatalk

 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #10 on: February 12, 2017, 04:41:20 PM »
Yocto is almost hermetic so Ubuntu version shouldn't matter much. I'll need to see the full build log, what version of Yocto you started with, and what BSP you are using. Boost shouldn't cause a problem like that.

I tried U16.10, but a package (lzop) is not happy with GCC6.
I managed to find a patch from Debian repo to fix lzop issue, but line offset of both file are different in yocto and Debian, so I can't patch the diff file.
That source file has 12k lines! Which makes manually searching and patching a hard way. So, I chose to use U14.04, which is suggested in BSP.

I didn't manage to find a full build log, but I copied console buffer to a file, and that contains all crap that bitbake/jam spitted out. The text file is in unix line ending.
The BSP I'm using is git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-4.1-krogoth.
Detailed information can be found here: http://www.nxp.com/products/automotive-products/microcontrollers-and-processors/arm-mcus-and-mpus/i.mx-application-processors/i.mx-6-processors/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core:i.MX6ULL?tab=Documentation_Tab
I attached the PDF in that protected link, anyway it's not confidential. It requires a log-in, but it's free access. I followed this PDF exactly.

I only tried yocto Krogoth since brevious version doesn't support my board. The CPU on that particular board is a new chip, just released in late 2016.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline kc8apf

  • Regular Contributor
  • *
  • Posts: 99
  • Country: us
Re: Help me choosing an ARM that runs Linux
« Reply #11 on: February 12, 2017, 04:45:46 PM »
I'll look at the logs in the morning. Having problems with a different Ubuntu version doesn't make any sense. Yocto defaults are to build its own cross compiler used for building target packages. The host compiler is only used to build a handful of packages that are expected to run on the host. Freescale's BSP might be doing odd things though.

Sent from my Nexus 5X using Tapatalk

 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #12 on: February 12, 2017, 04:54:29 PM »
I'll look at the logs in the morning.

Thanks. Have a nice dream.

Having problems with a different Ubuntu version doesn't make any sense. Yocto defaults are to build its own cross compiler used for building target packages. The host compiler is only used to build a handful of packages that are expected to run on the host. Freescale's BSP might be doing odd things though.

It failed when compiling host package (I guess it's needed for generating zImage?). I thought to install alternate gcc4.8 and g++4.8, but if I can't take advantage of newer compiler, then why use U16.10? So I chose to use U14.04, at least it is verified to work. Anyway they are just VMs and I can just delete one and create a new one.
SIGSEGV is inevitable if you try to talk more than you know.
 

Online julian1

  • Regular Contributor
  • *
  • Posts: 189
  • Country: au
  • http://blog.julian1.io
Re: Help me choosing an ARM that runs Linux
« Reply #13 on: February 12, 2017, 05:45:53 PM »
Quote
Also, another problem I can see is that AM335x is consuming too much power. From TI's documentation, when running with DDR3, the idle power is more than 500mW, let along full load power.

Would down-clocking help power-consumption - or does you DSP need full power (offload to the gpu)? This article suggests its possible to run at 300MHz. http://derekmolloy.ie/changing-the-beaglebone-cpu-frequency/

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #14 on: February 12, 2017, 05:54:27 PM »
Quote
Also, another problem I can see is that AM335x is consuming too much power. From TI's documentation, when running with DDR3, the idle power is more than 500mW, let along full load power.

Would down-clocking help power-consumption - or does you DSP need full power (offload to the gpu)? This article suggests its possible to run at 300MHz. http://derekmolloy.ie/changing-the-beaglebone-cpu-frequency/

I think the software will put it in lowest possible frequency (275/300MHz) when idle. Even so, during idle, it consumes ~500mW of power, and ~800mW when running Dhrystone benchmark.
GPU is not an option. I want to build a portable music player, not a pocket PC. I don't want to install OpenCL, LLVM, mesa and a bunch of other libraries. I don't even want to install X11 -- I think for me, FrameBuffer works well.
My goal is to create a portable player that boots in seconds, preferably less than 3 seconds. This is doable only if both uboot, kernel, initeamfs and rootfs are extremely simplified and stripped.

Talking about performance, I think even when UI is not running, just music is playing, I need at least 250MHz. So even if I can get it to work at lower clock rate, it won't be possible.
Keep in mind that this thing runs a sophisticated 10-band equalizer, an audio decoder and a 12.288Msps sample rate converter. My estimation is it will need 180MHz along just for the sample rate converter, and that's based on the assumption that NEON is used. If only ARM instructions are used, it will need 360MHz along.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: [Solved] Help me choosing an ARM that runs Linux
« Reply #15 on: February 14, 2017, 04:55:37 AM »
Thanks everyone who has replied. Final decision has been made. i.MX6ULL is the winner.
I've purchased a dev kit for it, and I've been playing with yocto on it for a few hours. Everything seem to work correctly, though some tweaking needs to be done.
I will post further in MCU subforum for questions regarding Kernel driver and yocto customization.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline bson

  • Supporter
  • ****
  • Posts: 603
  • Country: us
Re: Help me choosing an ARM that runs Linux
« Reply #16 on: February 14, 2017, 06:38:25 AM »
Would it be possible to use GPIO to handle the parallel port for the fpga? Would perhaps require writing a kernel level device-driver?
I haven't worked with the higher end A series parts, but for the NXP Cortex M and ARM7T parts I've worked with, it could be set up using a DMA channel writing to a GPIO register, clocked by a timer channel which both goes to an external pin (for data clock) and triggers DMA transfers.

The A parts get more complicated and will absolutely require a driver - this isn't terribly hard, especially if the external peripheral can handle data gaps while 1) interrupts might pend for a while, 2) move on to the next buffer in the chain, 3) you reload and restart the DMA channel.  If not, then you need to utilize auto reloading functionality or use two channels chained with one always ready to start when the previous runs down.  You also need to be careful with data cache management to make sure the DMA controller sees what the CPU sees, which may or may not be an issue depending on what else is in the pipeline prior to spitting the data stream out.
<This space intentionally left blank>
 
The following users thanked this post: julian1

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #17 on: February 14, 2017, 07:27:20 AM »
Would it be possible to use GPIO to handle the parallel port for the fpga? Would perhaps require writing a kernel level device-driver?
I haven't worked with the higher end A series parts, but for the NXP Cortex M and ARM7T parts I've worked with, it could be set up using a DMA channel writing to a GPIO register, clocked by a timer channel which both goes to an external pin (for data clock) and triggers DMA transfers.

The A parts get more complicated and will absolutely require a driver - this isn't terribly hard, especially if the external peripheral can handle data gaps while 1) interrupts might pend for a while, 2) move on to the next buffer in the chain, 3) you reload and restart the DMA channel.  If not, then you need to utilize auto reloading functionality or use two channels chained with one always ready to start when the previous runs down.  You also need to be careful with data cache management to make sure the DMA controller sees what the CPU sees, which may or may not be an issue depending on what else is in the pipeline prior to spitting the data stream out.

After calculated MIPS requirement and CPU capability, I decided to move sigma delta modulator to ARM from FPGA, so only modulated (low-bits, same sample rate) signal has to be transferred to FPGA. In my implementation, 4 bits of data per sample per channel at 12.288Msps is transferred to FPGA, which corresponds to 98.304Mbps, so it can be handled easily by QSPI. The need of a parallel bus is eliminated now.

There will be some overheads for sync signals (to sync data scrambling engine used in dynamic element matching) and DAC configuration bits (scrambling pattern, digital volume control, power management control, etc.) These extra bits will be transferred to FPGA as well using the same QSPI bus. I will let the QSPI bus to operate at 100MHz (corresponds to 400Mbps) in burst mode, triggered by FPGA's interrupt signal every 0.1ms. The external trigger model also makes ALSA driver easier to write as I don't have to deal with pcm_timers and kernel jiffy.

By doing so, the ARM has to handle roughly 2x calculation, which demands ~400MHz dedicated to audio processing. We still have plenty left for GUI, though I probably have to drop support for audio visualization, which is anyway superfluous. Power consumption is also within limit since according to i.MX6ULL power test report, at full SIMD load (SW video decoding), the system consumes 400mW, of which 150mW is for RAM, 250mW is for CPU. My algorithm can reside in 128kB of L2 cache, so memory access will be minimum. I estimate the total digital (ARM, RAM, FPGA, eMMC) power consumption will be less than 400mW when screen is off.
SIGSEGV is inevitable if you try to talk more than you know.
 

Online julian1

  • Regular Contributor
  • *
  • Posts: 189
  • Country: au
  • http://blog.julian1.io
Re: Help me choosing an ARM that runs Linux
« Reply #18 on: February 14, 2017, 12:05:32 PM »
Would it be possible to use GPIO to handle the parallel port for the fpga? Would perhaps require writing a kernel level device-driver?
I haven't worked with the higher end A series parts, but for the NXP Cortex M and ARM7T parts I've worked with, it could be set up using a DMA channel writing to a GPIO register, clocked by a timer channel which both goes to an external pin (for data clock) and triggers DMA transfers.

The A parts get more complicated and will absolutely require a driver - this isn't terribly hard, especially if the external peripheral can handle data gaps while 1) interrupts might pend for a while, 2) move on to the next buffer in the chain, 3) you reload and restart the DMA channel.  If not, then you need to utilize auto reloading functionality or use two channels chained with one always ready to start when the previous runs down.  You also need to be careful with data cache management to make sure the DMA controller sees what the CPU sees, which may or may not be an issue depending on what else is in the pipeline prior to spitting the data stream out.

I was thinking unrelated interrupts would be a problem after I posted. Also context switching.

Apparently the TI parts have a dedicated processor available for implementing IO, which has full control over ddr memory, and presumably would keep running during interrupts.

Quote
A programmable real-time unit (PRU) is a fast (200-MHz, 32-bit) processor with single-cycle I/O access to a number of the pins and full access to the internal memory and peripherals on the AM3358 processor

http://beagleboard.org/pru

This guy got 25MHz using one of the PRUs with GPIO and says it should be possible to go faster,

http://hackaday.com/2013/12/07/speeding-up-beaglebone-black-gpio-a-thousand-times/#comment-1125631
« Last Edit: February 14, 2017, 12:07:11 PM by julian1 »
 

Offline kc8apf

  • Regular Contributor
  • *
  • Posts: 99
  • Country: us
Re: Help me choosing an ARM that runs Linux
« Reply #19 on: February 18, 2017, 03:50:12 AM »
Yocto is almost hermetic so Ubuntu version shouldn't matter much. I'll need to see the full build log, what version of Yocto you started with, and what BSP you are using. Boost shouldn't cause a problem like that.

I tried U16.10, but a package (lzop) is not happy with GCC6.
I managed to find a patch from Debian repo to fix lzop issue, but line offset of both file are different in yocto and Debian, so I can't patch the diff file.
That source file has 12k lines! Which makes manually searching and patching a hard way. So, I chose to use U14.04, which is suggested in BSP.

I didn't manage to find a full build log, but I copied console buffer to a file, and that contains all crap that bitbake/jam spitted out. The text file is in unix line ending.
The BSP I'm using is git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-4.1-krogoth.
Detailed information can be found here: http://www.nxp.com/products/automotive-products/microcontrollers-and-processors/arm-mcus-and-mpus/i.mx-application-processors/i.mx-6-processors/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core:i.MX6ULL?tab=Documentation_Tab
I attached the PDF in that protected link, anyway it's not confidential. It requires a log-in, but it's free access. I followed this PDF exactly.

I only tried yocto Krogoth since brevious version doesn't support my board. The CPU on that particular board is a new chip, just released in late 2016.

I haven't forgotten about this.  I got a VM setup with those instructions.  Freescale has taken a unique approach to releasing tested builds.  What did you do to trigger the Boost compile error?
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: Help me choosing an ARM that runs Linux
« Reply #20 on: February 18, 2017, 04:40:41 AM »
I haven't forgotten about this.  I got a VM setup with those instructions.  Freescale has taken a unique approach to releasing tested builds.  What did you do to trigger the Boost compile error?

I can get sato and all other core-images to build, but I cannot build fsl-image-*. I know -qt5 is not supported on my iMX6ULL device, but -gui should be able to work since anyway sato depends on x11.
But the reality is, it doesn't compile. I got stuck at somewhere like ~2800 jobs done, where boost compiling error was thrown.
I guess somewhere in fsl-image layer, boost is incorporated. I will try again with boost dependency removed. Anyway my application doesn't need boost.
I will only need a forked BSP (with my own kernel configuration and driver package, specifically PMIC driver, ALSA driver and LCD driver), and dependencies that mono (provided by open-embedded) will need (x11, pango, etc.).
On top of that, the only thing I need is my custom app, which I can create a layer for it.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline kc8apf

  • Regular Contributor
  • *
  • Posts: 99
  • Country: us
Re: [Solved] Help me choosing an ARM that runs Linux
« Reply #21 on: February 18, 2017, 04:59:21 AM »
OK.  I've setup a build directory with:
Code: [Select]
MACHINE=imx6ull14x14evk source fsl-setup-release.sh -e x11
Now I'm starting a build of fsl-image-gui.  I'll let you know what happens.
 

Offline kc8apf

  • Regular Contributor
  • *
  • Posts: 99
  • Country: us
Re: [Solved] Help me choosing an ARM that runs Linux
« Reply #22 on: February 21, 2017, 03:43:09 AM »
The build finished fine including building Boost.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: [Solved] Help me choosing an ARM that runs Linux
« Reply #23 on: February 21, 2017, 04:45:01 AM »
The build finished fine including building Boost.

Let me try your build command. I used this instead:
MACHINE=imx6ull14x14evk DISTRO=fsl-imx-x11 source fsl-setup-release.sh -b build

I didn't use -e option.


Update: didn't work. This time it stuck on more libraries. I removed the entire yocto folder and recreated one strictly following instruction.
I guess last time what I did wrong is that I shared the same build folder for x11 and fb backends.
« Last Edit: February 21, 2017, 05:14:48 AM by blueskull »
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 5581
  • Country: cn
  • Final year EE PhD
Re: [Solved] Help me choosing an ARM that runs Linux
« Reply #24 on: February 21, 2017, 07:08:00 AM »
The build finished fine including building Boost.

ERROR: Function failed: do_compile (log file is located at /home/bo/fsl/build-x11/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/boost/1.60.0-r0/temp/log.do_compile.22774)
SIGSEGV is inevitable if you try to talk more than you know.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf