On 12/9/20 12:41 am, Joel Sherrill wrote: > On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas <karel.gar...@centrum.cz > <mailto:karel.gar...@centrum.cz>> wrote: > > On 9/11/20 3:13 PM, Joel Sherrill wrote: > > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced > > in 1989. The Pentium was 1993. Remember It's All About the Pentium! > > Pentium II was 1997 and first with SMP but maybe not setting the > baseline > > we want. > > What about to support in master what man can currently purchase? If so, > then based on my limited research it looks like the cpu family > (orderable) goes back to 2016/2015 which support architecture of more or > less NetBurst uarch isn set (both intel and amd). > > One exception found is Vertex86 cpus which still sells and boards are > available and which are compatible only with i586/p5 from as you noted > 1993... > > Karel: Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86 > > If I am reading that right, we may be ok dumping i386 and i486 completely > and assuming around a Pentium II as default. Rather than a blanket drop > 32-bit support which kills a LOT of usable functionality, I would rather find > a new floor for the CPU model.
We have been thinking the BSP is working and technically it is not. I think this is the issue we should look at first. Would adding into the BSP a way of detecting and reporting the CPU details be worth doing? We could then match the specifics of the models to the build of RTEMS running and if wrong generate a fatal error. This way a user will know if they have made a mistake selecting a configuration. If there is no configuration they can report the model and we can take a look. I think this would be better than an application "almost" working until a specific case like we have with this thread is hit. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
