#cubox irc log of Thu 24 Mar 2016

IRC log of #cubox of Thu 24 Mar 2016. All times are in CET < Back to index

05:52 topi` intel braswell is quite disappointing cpu-wise, the new A72 chips will blow past it

05:53 topi` I wonder how long intel can keep their stranglehold on some key markets, e.g. chromebooks

05:54 topi` the cheapest / more generic has always won in the end - witness the UNIX workstations of 1990s being replaced by generic intel boxes. And now, the same is happening w/ ARM core/arch licensing model

06:51 jnettlet topi`, in general we deal with embedded qualified chips which means that the vendor will be producing them for 7-10 years. Right now there aren't any a72's that fit that bill, except for server only chips.

06:52 jnettlet perhaps with Qualcom moving towards embedded they will produce something worth looking at.

06:53 jnettlet nvidia are on the boat but they are dumping all their chips into the automotive industry, and ati are still chasing after their own tail.

07:01 jnettlet really this is about rounding out SolidRun's offering. We are still working on refreshing our iMX6 lineup, and the Armada is coming along nicely.

13:20 KBme yeah, an aarch64 machine would be nice, but for me power is not really that big of a deal. I do need to have one PC per deployment (use proprietary software only available for pc so it's either that or qemu-amd64 on arm, which I think would hurt badly), and that's what sparked my interest in this braswell machine.

13:34 rabeeh KBme: beyond the notes below; Intel has moved in giant leaps when it comes to lowering power consumption while; so we can defintely use it

13:34 rabeeh if you look at solution deployment and at least prototyping super fast we see lots of companies fail because of the lack of embedded software expertise

13:35 rabeeh with Intel based solutions; you put a USB stick with any Linux / BSD distro and it installs and people can start using it and develop their application quite immediately

13:35 KBme hello rabeeh. I'm not sure I understand what you're saying.

13:35 KBme ah, right

13:36 rabeeh KBme: but if you look at the huge amount of connectivity i.MX6 offers (number of i2c, SPI, Canbus etc...); you can't really find a device that is that capable

13:36 KBme yeah, it is simpler, and software support is usually much better than any embedded device I've seen

13:36 rabeeh and looking at Marvell Armada when it comes to networking and storage; it simply kicks any device around it with that price point

13:37 rabeeh KBme: when we had the Intel SOM up and running; it literally took us 5 hours to install Kodi / Ubuntu 15.04 and Windows 10 for initial evaluation.

13:38 KBme my big gripe with arm machines is the way they shun kernel development, and the way there is not one graphics driver that can keep up with linux kernel development

13:38 rabeeh most of those 5hrs where flashing usb sticks and waiting for the thing to install

13:38 KBme yeah, it would definitely simplify a lot of things. not sure how the price will compare to the hummingboard, though

13:39 rabeeh KBme: there is a price tag when using Intel based processors; but I think we cut a good deal with Intel

13:39 KBme right

13:39 rabeeh the team is working on final pricing; but i think you would be surprised to see those too.

13:40 KBme honestly, I really like the ARM business model and architecture. but I really don't understand how they can suck so much on the software side.

13:40 KBme well, I'll be looking out for the announcment. we might be interested, depending on the price.

13:41 rabeeh KBme: again, it depends what you want to do. if you want a PC like machine (desktop / laptop / POS etc...) - then Intel is the fastest way to that

13:41 rabeeh if you are looking for pure networking and storage (NAS / GW with or without mobility) - then ARM and especially Marvell Armada excells

13:41 KBme also, their graphics cards are supported out of the box on latest vanilla linux, which is a huge effing deal

13:42 KBme rabeeh, do you need anything special to boot linux on that machine, or just a regular amd64 debian'll boot fine?

13:42 rabeeh KBme: again, depends on the application; general X / Wayland - x86 rules

13:43 rabeeh embedded with qt5 etc... - then ARM has major solutions too

13:43 rabeeh yes; it's a PC. but tiny :)

13:43 KBme yeah, see, that.

13:43 KBme that's a big deal

13:44 rabeeh from HW point of view; we have done really amazing things. The size of the SOM is less than Q7 which is the smallest with Intel based.

13:44 rabeeh dual channel DDR (each one 64bit) - again you won't see this with ARM

13:44 KBme true

13:45 rabeeh but if you look at Armada; we were able to do 1.6GB/sec on the storage side with 3xSATA; 2.5Gbps TCP/IP without pain.

13:45 vpeter rabeeh: how many layers pcb som have?

13:45 KBme I bet the introduction of uefi on arm will simplify a lot of the software support needed for all the different socs

13:45 rabeeh vpeter: i can't say - sorry. but not a lot

13:46 rabeeh if you spend 3 months on doing only layout then the number of layers gets really really down; but requires lots of dedication

13:46 vpeter not a lot? 8 at least I would say.

13:46 rabeeh KBme: yeah; that's a major point too. Jon Masters has lots of things to say about that; but it is true.

13:47 KBme not to say that I like uefi, but it beats u-boot or any other boot method the arm guys have managed to bless us with

13:47 rabeeh if you get into the point where you have a UEFI; and the vendor only needs to tweak that and the OS simply installs then it's a major thing for embedded / consumer (and most important servers where RedHat is trying to push ARM to)

13:47 KBme yeah

13:47 rabeeh uefi sucks

13:47 KBme +1

13:47 rabeeh u-boot is easy

13:48 KBme I don't quite agree. it horribly complicates the hardware support process

13:48 KBme I develop linux distributions

13:48 rabeeh the deal is actually bigger; u-boot must come with a custom kernel, and custom device tree; uefi can work with any OS (potentially)

13:48 KBme and supporting just two different arm socs is such a pita I understand many distributions don't even bother

13:48 rabeeh yeah; right. so we do agree

13:48 KBme yep

13:49 rabeeh and trust me that i have came to this conclusion with almost 17 years in the industry, mostly with embedded designs (and mostly ARM).

13:50 KBme yeah, I believe you.

14:10 rabeeh vpeter: withregards the number of layers; it's not really important. what is important is that because of the high integration of the SOM our users can build 2 and 4 layer PCBs :)

14:11 rabeeh with Intel specifically we done even higher integration than previously done; the SOM itself gets up to 21v and then the SOM provides the 5V/3.3v/1.8v to the carrier board making it even simpler to design.

14:13 vpeter rabeeh: I was asking for numbers because SOM is so small and all the pcb place is covered with components. So somewhere must be connections :)

14:13 rabeeh oh; that's easy then

14:13 vpeter And I understand the idea: complex working som + simple carrier board = success

14:13 rabeeh we use micro vias under the pads of the devices

14:14 rabeeh so called HDI design; but we use the simple methods of HDI to keep the cost down.

14:15 rabeeh so you would almost see no route on the outer layers; only micro vias under the pads of the devices and then internally they are routed against internal GND planes.

14:16 vpeter Yes, just googling.

14:17 vpeter And I can't made even classic pcb :)

14:20 rabeeh vpeter: having simple PCBs today is really really easy.

14:20 rabeeh lots of prototyping fabs, lots of intituive tools (eagle for free, tools from digikey etc...)

14:21 rabeeh but the one that is professional and easy to use that i see lots of ours customers use it is altiem; especially for it's brilliant 3D design

14:24 vpeter Sure, but some skills still needed. Bribing a friend for some time now :)

14:25 rabeeh one thing i really really like is that integration with ARM Cortex M0 on the Intel SOM

14:25 rabeeh we haven't played with it a lot; but i think it would be wonderful extension

14:26 rabeeh it's an STM32 based MCU and the thing that i like is that it supports HDMI CEC; the the MCU is connected via USB to the main processor

14:26 rabeeh (for Kodi)

14:27 vpeter That's nice. Also for some realtime apps with RTOS on it.

14:27 vpeter Must show this to my friend.

14:33 rabeeh what's nice is that ST SDK can be installed directly on the machine itself :)

15:02 suihkulokki rabeeh: re uefi/u-boot, I agree UEFI has potential to help supporting from distro side

15:03 suihkulokki rabeeh: there are still some catches, for example updaring EFI variables if UEFI is installed on same (typically emmc) media as rootfs

15:03 suihkulokki rabeeh: and also, with u-boot syslinux style extlinux.conf menus, supporting u-boot based boards is getting easier from distro side

15:04 suihkulokki with u-boot the problem is generally that vendors give a 2013 vintage fork with quirks

15:05 suihkulokki and I'm not entirely convinced that won't happen with UEFI too :P

15:08 KBme yeah, vendors already make quirky UEFI implementations for PCs.

15:08 jnettlet suihkulokki, the problem with u-boot is that the upstream maintainers were the problem. Recently Denx has mostly been removed from the project and the rest of the community is trying to make up for the prior mistakes made.

15:09 jnettlet However the kernel has this same problem right now. Even when they accept some outside ideas there can be pushback for one specific part that basically makes everything accepted useless. Look at the preempt-rt patches

15:09 rabeeh suihkulokki: i'm not sure what the right solution is; but the experience that ARM should be going into is the simplification of things and making standards

15:10 rabeeh for instance; if the device tree was of u-boot (and not the kernel) then you can dream about a single kernel fits all

15:11 rabeeh developers should be forbidden to call their uart /dev/ttymxc where everyone else in the world calls a uart /dev/ttySX

15:11 jnettlet actually they can call it that as long as they add proper aliases

15:13 rabeeh and those are the easy parts; when getting deep into autodetecting features like memory size, number of processors becomes more challenging

15:14 rabeeh jnettlet: but thats the whole point; if any of those developers agrees to the standards then it should be called /dev/ttyS from day one. no aliases, no extra documentation, no waste of time

15:16 jnettlet yes, but ACPI is just as much of a mess. Linux took so long to work on x86 hardware because ACPI dsdt tables would have blocks of functionality locked up in "if "OS = WINDOWS" blocks

15:17 jnettlet it is about consistency and not about the technology. Really I think coreboot has it right. Tiny core that can load up a payload which can be anything.

15:17 rabeeh jnettlet: i'm not saying ACPI IS the way to do it; i'm saying that i see tons of hours and days are being wasted since developers decides to deviate, foolishly without bringing in real value

15:18 jnettlet been happening for 20+ years now. Look at how far behind getting UEFI/ACPI on ARM64 has put those products back.

15:19 jnettlet They went from the future of servers to...oh yeah those too...all because Jon Masters and RedHat wanted to force them all to work like x86 boxes.

15:20 jnettlet The main reason that x86 works "out of the box" is that they use entirely hotpluggable protocols and everything else is handled by an EC. You don't see lots of x86 boxes with loads of developer IO.

15:21 jnettlet if you do it sits on an expansion card that is interfaced over USB or PCI and needs custom drivers

15:31 rabeeh jnettlet: yup; discoverable protocols is the way to do it

15:48 jnettlet as long as they are well documented standards they tend to work, although USB is still a pain on all the major operating systems.

05:52	topi`	intel braswell is quite disappointing cpu-wise, the new A72 chips will blow past it
05:53	topi`	I wonder how long intel can keep their stranglehold on some key markets, e.g. chromebooks
05:54	topi`	the cheapest / more generic has always won in the end - witness the UNIX workstations of 1990s being replaced by generic intel boxes. And now, the same is happening w/ ARM core/arch licensing model
06:51	jnettlet	topi`, in general we deal with embedded qualified chips which means that the vendor will be producing them for 7-10 years. Right now there aren't any a72's that fit that bill, except for server only chips.
06:52	jnettlet	perhaps with Qualcom moving towards embedded they will produce something worth looking at.
06:53	jnettlet	nvidia are on the boat but they are dumping all their chips into the automotive industry, and ati are still chasing after their own tail.
07:01	jnettlet	really this is about rounding out SolidRun's offering. We are still working on refreshing our iMX6 lineup, and the Armada is coming along nicely.
13:20	KBme	yeah, an aarch64 machine would be nice, but for me power is not really that big of a deal. I do need to have one PC per deployment (use proprietary software only available for pc so it's either that or qemu-amd64 on arm, which I think would hurt badly), and that's what sparked my interest in this braswell machine.
13:34	rabeeh	KBme: beyond the notes below; Intel has moved in giant leaps when it comes to lowering power consumption while; so we can defintely use it
13:34	rabeeh	if you look at solution deployment and at least prototyping super fast we see lots of companies fail because of the lack of embedded software expertise
13:35	rabeeh	with Intel based solutions; you put a USB stick with any Linux / BSD distro and it installs and people can start using it and develop their application quite immediately
13:35	KBme	hello rabeeh. I'm not sure I understand what you're saying.
13:35	KBme	ah, right
13:36	rabeeh	KBme: but if you look at the huge amount of connectivity i.MX6 offers (number of i2c, SPI, Canbus etc...); you can't really find a device that is that capable
13:36	KBme	yeah, it is simpler, and software support is usually much better than any embedded device I've seen
13:36	rabeeh	and looking at Marvell Armada when it comes to networking and storage; it simply kicks any device around it with that price point
13:37	rabeeh	KBme: when we had the Intel SOM up and running; it literally took us 5 hours to install Kodi / Ubuntu 15.04 and Windows 10 for initial evaluation.
13:38	KBme	my big gripe with arm machines is the way they shun kernel development, and the way there is not one graphics driver that can keep up with linux kernel development
13:38	rabeeh	most of those 5hrs where flashing usb sticks and waiting for the thing to install
13:38	KBme	yeah, it would definitely simplify a lot of things. not sure how the price will compare to the hummingboard, though
13:39	rabeeh	KBme: there is a price tag when using Intel based processors; but I think we cut a good deal with Intel
13:39	KBme	right
13:39	rabeeh	the team is working on final pricing; but i think you would be surprised to see those too.
13:40	KBme	honestly, I really like the ARM business model and architecture. but I really don't understand how they can suck so much on the software side.
13:40	KBme	well, I'll be looking out for the announcment. we might be interested, depending on the price.
13:41	rabeeh	KBme: again, it depends what you want to do. if you want a PC like machine (desktop / laptop / POS etc...) - then Intel is the fastest way to that
13:41	rabeeh	if you are looking for pure networking and storage (NAS / GW with or without mobility) - then ARM and especially Marvell Armada excells
13:41	KBme	also, their graphics cards are supported out of the box on latest vanilla linux, which is a huge effing deal
13:42	KBme	rabeeh, do you need anything special to boot linux on that machine, or just a regular amd64 debian'll boot fine?
13:42	rabeeh	KBme: again, depends on the application; general X / Wayland - x86 rules
13:43	rabeeh	embedded with qt5 etc... - then ARM has major solutions too
13:43	rabeeh	yes; it's a PC. but tiny :)
13:43	KBme	yeah, see, that.
13:43	KBme	that's a big deal
13:44	rabeeh	from HW point of view; we have done really amazing things. The size of the SOM is less than Q7 which is the smallest with Intel based.
13:44	rabeeh	dual channel DDR (each one 64bit) - again you won't see this with ARM
13:44	KBme	true
13:45	rabeeh	but if you look at Armada; we were able to do 1.6GB/sec on the storage side with 3xSATA; 2.5Gbps TCP/IP without pain.
13:45	vpeter	rabeeh: how many layers pcb som have?
13:45	KBme	I bet the introduction of uefi on arm will simplify a lot of the software support needed for all the different socs
13:45	rabeeh	vpeter: i can't say - sorry. but not a lot
13:46	rabeeh	if you spend 3 months on doing only layout then the number of layers gets really really down; but requires lots of dedication
13:46	vpeter	not a lot? 8 at least I would say.
13:46	rabeeh	KBme: yeah; that's a major point too. Jon Masters has lots of things to say about that; but it is true.
13:47	KBme	not to say that I like uefi, but it beats u-boot or any other boot method the arm guys have managed to bless us with
13:47	rabeeh	if you get into the point where you have a UEFI; and the vendor only needs to tweak that and the OS simply installs then it's a major thing for embedded / consumer (and most important servers where RedHat is trying to push ARM to)
13:47	KBme	yeah
13:47	rabeeh	uefi sucks
13:47	KBme	+1
13:47	rabeeh	u-boot is easy
13:48	KBme	I don't quite agree. it horribly complicates the hardware support process
13:48	KBme	I develop linux distributions
13:48	rabeeh	the deal is actually bigger; u-boot must come with a custom kernel, and custom device tree; uefi can work with any OS (potentially)
13:48	KBme	and supporting just two different arm socs is such a pita I understand many distributions don't even bother
13:48	rabeeh	yeah; right. so we do agree
13:48	KBme	yep
13:49	rabeeh	and trust me that i have came to this conclusion with almost 17 years in the industry, mostly with embedded designs (and mostly ARM).
13:50	KBme	yeah, I believe you.
14:10	rabeeh	vpeter: withregards the number of layers; it's not really important. what is important is that because of the high integration of the SOM our users can build 2 and 4 layer PCBs :)
14:11	rabeeh	with Intel specifically we done even higher integration than previously done; the SOM itself gets up to 21v and then the SOM provides the 5V/3.3v/1.8v to the carrier board making it even simpler to design.
14:13	vpeter	rabeeh: I was asking for numbers because SOM is so small and all the pcb place is covered with components. So somewhere must be connections :)
14:13	rabeeh	oh; that's easy then
14:13	vpeter	And I understand the idea: complex working som + simple carrier board = success
14:13	rabeeh	we use micro vias under the pads of the devices
14:14	rabeeh	so called HDI design; but we use the simple methods of HDI to keep the cost down.
14:15	rabeeh	so you would almost see no route on the outer layers; only micro vias under the pads of the devices and then internally they are routed against internal GND planes.
14:16	vpeter	Yes, just googling.
14:17	vpeter	And I can't made even classic pcb :)
14:20	rabeeh	vpeter: having simple PCBs today is really really easy.
14:20	rabeeh	lots of prototyping fabs, lots of intituive tools (eagle for free, tools from digikey etc...)
14:21	rabeeh	but the one that is professional and easy to use that i see lots of ours customers use it is altiem; especially for it's brilliant 3D design
14:24	vpeter	Sure, but some skills still needed. Bribing a friend for some time now :)
14:25	rabeeh	one thing i really really like is that integration with ARM Cortex M0 on the Intel SOM
14:25	rabeeh	we haven't played with it a lot; but i think it would be wonderful extension
14:26	rabeeh	it's an STM32 based MCU and the thing that i like is that it supports HDMI CEC; the the MCU is connected via USB to the main processor
14:26	rabeeh	(for Kodi)
14:27	vpeter	That's nice. Also for some realtime apps with RTOS on it.
14:27	vpeter	Must show this to my friend.
14:33	rabeeh	what's nice is that ST SDK can be installed directly on the machine itself :)
15:02	suihkulokki	rabeeh: re uefi/u-boot, I agree UEFI has potential to help supporting from distro side
15:03	suihkulokki	rabeeh: there are still some catches, for example updaring EFI variables if UEFI is installed on same (typically emmc) media as rootfs
15:03	suihkulokki	rabeeh: and also, with u-boot syslinux style extlinux.conf menus, supporting u-boot based boards is getting easier from distro side
15:04	suihkulokki	with u-boot the problem is generally that vendors give a 2013 vintage fork with quirks
15:05	suihkulokki	and I'm not entirely convinced that won't happen with UEFI too :P
15:08	KBme	yeah, vendors already make quirky UEFI implementations for PCs.
15:08	jnettlet	suihkulokki, the problem with u-boot is that the upstream maintainers were the problem. Recently Denx has mostly been removed from the project and the rest of the community is trying to make up for the prior mistakes made.
15:09	jnettlet	However the kernel has this same problem right now. Even when they accept some outside ideas there can be pushback for one specific part that basically makes everything accepted useless. Look at the preempt-rt patches
15:09	rabeeh	suihkulokki: i'm not sure what the right solution is; but the experience that ARM should be going into is the simplification of things and making standards
15:10	rabeeh	for instance; if the device tree was of u-boot (and not the kernel) then you can dream about a single kernel fits all
15:11	rabeeh	developers should be forbidden to call their uart /dev/ttymxc where everyone else in the world calls a uart /dev/ttySX
15:11	jnettlet	actually they can call it that as long as they add proper aliases
15:13	rabeeh	and those are the easy parts; when getting deep into autodetecting features like memory size, number of processors becomes more challenging
15:14	rabeeh	jnettlet: but thats the whole point; if any of those developers agrees to the standards then it should be called /dev/ttyS from day one. no aliases, no extra documentation, no waste of time
15:16	jnettlet	yes, but ACPI is just as much of a mess. Linux took so long to work on x86 hardware because ACPI dsdt tables would have blocks of functionality locked up in "if "OS = WINDOWS" blocks
15:17	jnettlet	it is about consistency and not about the technology. Really I think coreboot has it right. Tiny core that can load up a payload which can be anything.
15:17	rabeeh	jnettlet: i'm not saying ACPI IS the way to do it; i'm saying that i see tons of hours and days are being wasted since developers decides to deviate, foolishly without bringing in real value
15:18	jnettlet	been happening for 20+ years now. Look at how far behind getting UEFI/ACPI on ARM64 has put those products back.
15:19	jnettlet	They went from the future of servers to...oh yeah those too...all because Jon Masters and RedHat wanted to force them all to work like x86 boxes.
15:20	jnettlet	The main reason that x86 works "out of the box" is that they use entirely hotpluggable protocols and everything else is handled by an EC. You don't see lots of x86 boxes with loads of developer IO.
15:21	jnettlet	if you do it sits on an expansion card that is interfaced over USB or PCI and needs custom drivers
15:31	rabeeh	jnettlet: yup; discoverable protocols is the way to do it
15:48	jnettlet	as long as they are well documented standards they tend to work, although USB is still a pain on all the major operating systems.