96Boards Updates Site With EE, HuskyBoard Details

[robclark]

Heh, I kinda saw that coming. Still like to dream about a UEFI-less world...

yeah, I complained about UEFI (and ACPI in particular) initially for the server stuff, after all we already went through the pain to transition to devicetree.. but the reality is there is no way to get to the point where you could boot a kernel that was compiled before hw exists, like you can in the x86 world, without some sort of BIOS. And that is must-have in the grown-up (ie. non crazy mobile crap) world.

[droidhacker]

I want to see benchmar of this vs nvida shield as they both use 4xcore Cortex-A57

Given that nvidia shield has precisely ZERO cooling surface and no possibility of active cooling, and these boards (both of them) have 4 holes around the CPU that are OBVIOUSLY purposed for fastening down your choice of cooler, you'll see about... 1/8th of a second before nvidia starts its thermal throttle and grinds nearly to a halt, and about.... forever, where the A1100 is running full out, I think we can safely predict who will win THAT benchmark.

Of course it is important to recognize that they actually have different *purposes*. So pick the one that makes the most sense for YOUR APPLICATION and quit trying to compare them as if they were the same thing.

[pal666]

obviously you can get a good Intel CPU and board for less

obviously you can't get an arm Intel CPU

[pal666]

the reality is there is no way to get to the point where you could boot a kernel that was compiled before hw exists, like you can in the x86 world, without some sort of BIOS.

device tree in firmware is not enough?

[starshipeleven]

yeah, I complained about UEFI (and ACPI in particular) initially for the server stuff, after all we already went through the pain to transition to devicetree.. but the reality is there is no way to get to the point where you could boot a kernel that was compiled before hw exists, like you can in the x86 world, without some sort of BIOS. And that is must-have in the grown-up (ie. non crazy mobile crap) world.

Uhm... can you please explain what you compile dtb files for? Why you transitioned to devicetree if you don't use dtb files?

With a dtb in firmware (or boot partition or anywhere the bootloader can read it from) the bootloader just loads a blob called "my_kernel", a blob called "this_board.dtb", places them in a standardized place in RAM and then executes the first one.

And the thing boots fine regardless of when the kernel was made.

With dtb file support in kernel and bootloaders, the embedded world entered the "grown-up" world.

FYI, if your bootloader is too old/dumb to use dtb files, add them inside the zimage, the kernel (if it supports the feature) will detect and use the dtb file.


The only reason you cannot use u-boot and similar embedded bootloaders in x86 world is that the board needs special initialization from BIOS/UEFI (or core/libreboot) first, then it can go and look for bootloaders in system drive.

I was hoping that this being an ARM board, it would have not needed UEFI crap as it would not have to be initialized like x86 boards.

[duby229]

obviously you can't get an arm Intel CPU

Certainly that's true for consumer products like cell phones, but Intel does still manufacture arm processors for network controllers and storage controllers. I personally wouldn't be one tiny bit surprised if Intel's current crop of PC chipsets used embedded arm processors for IO acceleration.

[pal666]

Intel does still manufacture arm processors for network controllers and storage controllers. I personally wouldn't be one tiny bit surprised if Intel's current crop of PC chipsets used embedded arm processors for IO acceleration.

those would be relevant in arduino thread

[starshipeleven]

Certainly that's true for consumer products like cell phones, but Intel does still manufacture arm processors for network controllers and storage controllers. I personally wouldn't be one tiny bit surprised if Intel's current crop of PC chipsets used embedded arm processors for IO acceleration.

Can you make an example of arm processors in network controllers?

in SSDs I know they do, and inside chipsets there are ARM processors responsible of all their secure *cough*hardware backdoor*cough* board initialization and remote management crap

I think that storage controllers (in the sense of sata controllers in the chipset or something) aren't using a standard architecture as they are low-level.

[duby229]

Can you make an example of arm processors in network controllers?

in SSDs I know they do, and inside chipsets there are ARM processors responsible of all their secure *cough*hardware backdoor*cough* board initialization and remote management crap

I think that storage controllers (in the sense of sata controllers in the chipset or something) aren't using a standard architecture as they are low-level.

Yeah, Intel has used Xscale pretty much everywhere. Look for their IOP products for storage processors and their IXP products for network processors.

EDIT: They don't advertise arm cores in recent products, but I'm reasonably certain they must have some kind of embedded processor and I'm willing to bet it's still based on xscale.

[robclark]

device tree in firmware is not enough?

no, devicetree is (reasonably) good at describing things that have already been seen, but it's just a static data table, so not so good at dealing with new hw that comes along much later.. you end up needing a layer of firmware below the kernel to deal with that (which is what is done in x86 world)