[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ARM Ports BoF: armel in buster



On 08/28/2017 08:46 AM, W. Martin Borgert wrote:
> Quoting uhmgawa <uhmgawa@member.fsf.org>:
>> We probably should be leveraging a cross built embedded class distro which
>> would place us in that mainstream and solve many of our logistical problems.
>
> As long as you have enough flash memory (some hundreds of MiB) and RAM
> (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware
> in my experience. It depends on your applications, of course.

Available flash is from 32~64MB depending on platform.  So manual subset
of the distro id required and where recurring the effort enters the picture.

>
> Could you tell us something about your hardware and application?
>

ARM926EJ-S SoC with the usual assortment of peripherals, SPI flash for
u-boot/kernel/userland 32~64MB in current product, 256~512MB DRAM.
Pretty typical for a legacy arm32 embedded linux platform.

The footprint complication primarily arises from the constraint to use SPI flash
and its associated cost / minimal capacity.

>> But support of that architecture
>> was likely never more than a coincidental goal for non-embedded
>> server/workstation distros.
>
> Debian is supposed to be the "universal operating system". I.e. it is for
> server + workstation + embedded + whatever. This is different from most
> other Linux distributions.

I applaud that goal.  But the approach of using a native arch build vehicle
for the distro also introduces complication for embedded class development.
Not insurmountable but additional compared to the cross-build approach
typical of embedded linux distros.

Note there was no technical motivation moving from a DEB to RPM based
distro.  But rather a special case where leverage of preexisting internal RPM
build infrastructure is possible rather than dealing with that additional infrastructure
and (self-inflicted) legal process associated the Debian option, or moreover the
largely "drop in" use of Yocto/OE.


Reply to: