Suggestion to community

The other versions of the BPI boards are different and really not version sisters but different items.

The software from BPI seems to be aimed at one size fits for all. This is truly not a good thing.

As we see the development of the UBUNTU kernel has continued to change version numbers rapidly. The Debian kernel not so much.

I am suggesting that the software images be unmerged so that the kernel 4 development can leap ahead and allow the kernel 3.4 development to remain as long as it is still maintained by debian.

I spent some time removing the M1-m2-m2p software from the mate BPI-m3 image and it is actually working nicely now.

Can you please show us changes to the kernel for the M3 ?

Bananas use neither Ubuntu nor Debian kernels. They have to use either vendor kernels (3.4.39 for M3 forever, @sinovoip ignores that responsible vendors patch the kernel up to latest 3.4 LTS version: 3.4.113) or mainline kernel (nothing ready yet for M3 since developers don’t like this board due to the many design flaws).

Sure PM me I can show what needs to be done that I have discovered so far. Mostly cleanup and the multi boot has created a strange file system. I mistakenly responded to the notification with an email.

Yes you are correct from the boot screen it looks like a graft from android OS but the package managers are Apt Dpkg the sources list Debian and Ubuntu. If you look around the web sinovoip is producing a bunch of different android tablets with later versions of etc Android os. I would almost bet that one of our chinese friends could tell us where to find an android build pack for one of those devices.

Sure I know there is a big fight going on \ I do not care / I am doing some development on this board because it is performing well for my needs. SUNXI a rival of SINOVOIP has published a lot of critique of this board but at the same time has not offered a board with the same thread count and affinity capability that this processor has.

Like any board I work on I do the thermal management first. I have designed and machined a 20W aluminum heat sink for BPI-M3 with a 40mm fan on top.

And as far as the version number war I thought Windows 2000 won that or was it macos10 anyway there both at 10 and Debian is releasing 9 soon. The only thing a kernel needs to do is support the hardware it’s running on and provide the same handles and pointers. The Debian developers which I am one are even arguing with the number scheme. I read an article from Torvalds about 2.6 being the last number he needed or something like that.

I am not looking to argue anything it is not the same product as the sunXi boards.

The version of the kernel can be altered at any time.

If the code changes between 3.4 and what ever the latest number is effect code that is pertinent to this processor and board than implement the code changes and escalate the number yourself.

I see 5 separate products represented in the software images provided I think that this one board should be split out.

Multilingual is the same kind of thing I read and write 4 languages speak 3 but I use english my second language only on my software because most of C++ code is written in english. I use locale purge and delete any non-english files on my devices to clear out some of the recent bloat. It’s the same thing The trouble with the BPI-M3 bluetooth for instance is a combination of crazy file system and overly cautious security in the python apps.

Even if BPI proper does not follow my suggestion I still will be producing images for the BPI-M3 only not the multi boot stuff.

One issue that I have narrowed down is the Mathlibs were not included with the primitives on the core kernel. This causes the 64bit long to truncate incorrectly producing buffer under runs.

The other issue I found is the frame buffer structure of the current kernel is set to stream to cpu rather than block chunk. This causes the GPU to not function as designed This causes the video not to scale properly. I will be recompiling the 3.4 kernel with the mathlibs for ARM7L rather than the primitives from the ARM android set. The GPU function is a POWERV so there should be a dedicated Frame Buffer before the XSGX and after XSGX, The mali is a stream processor not the same.

My thought on the kernel is to mirror the changes in a large patch file and avoid including the drivers and other hardware devices NOT present on the M3. The use of shared separate modules instead of compiling them into the kernel will aid greatly on the port. Kmod support post linux 2.6 is very reliable and allows a quick boot time for other applications.

Thanks But I do understand that your basic hatred that you project is not due to the number scheme of a software package. It has much greater issues that I do not care about.

Do you understand the difference between ‘sunxi’ (that’s a ‘family of ARM SoCs from Allwinner Technology’, the open source linux-sunxi community (you are referring to as ‘SUNXI a rival of SINOVOIP’ for whatever reasons) and random hardware manufacturers like Sinovoip?

Linux-sunxi community is not ‘a rival’ to Sinovoip or any other SBC manufacturer, it’s just volunteers making those Allwinner boards useable through their work on software (upstream mainline kernel and related projects, it’s all available in linux-sunxi wiki and not really hard to understand).

Well, you seem to be new here, you are still somewhat naive and optimistic but time will cure this for sure. :slight_smile:

1 Like

Charles it i obvious that you have tremendous animosity and in almost every post that I have seen of yours specifically I have seen only hate in general and criticism of sinovoip. You are not posting on the SUNXI website forum when you post here. The group or what ever is not really my concern nor is one PI hobbies board over another.

If you had a bad experience with a product fine return the product. Camping out looking for anything to start a fight with someone is a kind of strange behavior usually seen in people who have low self esteem and other issues.

While looking for the specifics to my needs I found a processor that is different and yes it is different. This difference happens to fit nicely with what I am doing. One example of this difference is holding up the adoption of the code provided to sort out the new kernel. https://groups.google.com/forum/#!topic/linux.kernel/Nrn5GNnaH0w

You see there is a reluctance to implement a simple added file specific to only the A83T to adapt to the change in the way that the MMC is clocked separate from the other designs as a half clock. Instead of having a divider like the other chipsets. The SUNXI people are not in favor of adding a separate file to allow mainlining. This is the behind the scenes animosity and difficulty this chip has from people not unlike yourself.

This again reinforces my statement that maybe a separate development fork is needed for the A83T and definitely separate boot images as I suggested.

And where is your contribution I would like to see the beneficial aspect of your being before I complete condemn you. I was unable to find any here on this forum only you complaining and trolling.

Charles, do not waste your valuable time to convince him. It is not about living or die - so let him walk his path. When he comes back desperately, he will understand. He is not the first we see like that and I promise you, he will not be the last :sob: