Armbian running on Pine64 (and other A64/H5 devices)

[hojnikb]

GBit issue on what board?

Pine64? It's a hardware issue and the best way to fix this is replacing the board.

PC2? I don't remember any issues there, but as soon as we get test images we need to collect enough statistics data to adjust TX/RX delays to improve GBit performance.

 

We need to get DRM display driver and Mali kernel driver first (at least for using mali with X desktop).

 

I'm guessing this has to be provided by xunlong/allwinner ? 

[zador.blood.stained]

https://github.com/OrangePiLibra/OrangePi_H5SDK/issues/4#issuecomment-261462313

 

Using a patch to force 100 MBit/sec since TX/RX delay currently can't be adjusted the 'usual way' IMO isn't a solution to be honest (of course it would be one for Pine64's Android offers since Android users seem to be happy to better use stable Fast Ethernet than broken GBit Ethernet -- but TL Lim and Pine people are simply too ignorant to even think about improvements at all)

Well, it's not an issue yet. We need to get more info from linux-sunxi folks on u-boot compatibility and legacy kernel requirements (do we need ATF? can we use mainline u-boot for legacy kernel? etc), after that we need to look at legacy (or mainline) u-boot to see where and how delays can be adjusted.

[zador.blood.stained]

I'm guessing this has to be provided by xunlong/allwinner ? 

Depends on what kernel version are we talking about. I don't see anybody in the community who is interested in cleaning the legacy kernel (as @longsleep did it for Pine64), and I don't see many people interested in Mali on mainline (though DRM driver for DE2.0 is WIP)

[jernej]

can we use mainline u-boot for legacy kernel?

 

On IRC was mentioned several times that they are not compatible.

[zador.blood.stained]

On IRC was mentioned several times that they are not compatible.

Don't remember reading this about H5 specifically, but if this is true, then we need to start looking at legacy u-boot sources.

[jernej]

Allwinner has same boot principle for 64 bit SoCs, so I think doesn't really matter if this is A64 or H5. But you can ask on IRC any time.

[EverythingGreen]

Depends on what kernel version are we talking about. I don't see anybody in the community who is interested in cleaning the legacy kernel (as @longsleep did it for Pine64), and I don't see many people interested in Mali on mainline (though DRM driver for DE2.0 is WIP)

For the price works better then 5 voodoo cards in sli and the PowerrVR Pi board(roseapple pi) has artifacts.

[jernej]

BSP U-Boot must be build as 32 bit binary. I like that SPI flash even more now. I will try to build SPI compatible U-Boot, but some quick & easy solution must be determined for initial flashing. Any idea? I hope it is posible via FEL.

[zador.blood.stained]

BSP U-Boot must be build as 32 bit binary. I like that SPI flash even more now. I will try to build SPI compatible U-Boot, but some quick & easy solution must be determined for initial flashing. Any idea? I hope it is posible via FEL.

By "initial" you mean prior to booting any OS image? AFAIK it is implemented via FEL, but this implementation must be platform specific. You should probably ask @ssvb about this since he is the one who is working on it:

https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip

https://irclog.whitequark.org/linux-sunxi/2016-11-11#18145760

[jernej]

Nice, I hope H5 SPI support lands soon, but for dev purposes it seems that it can be easily patched.

[Christos]

IMHO that SPI memory, is a total distraction.. nobody should do anything with it..

 

P.S.

But thats just my opinion

[jernej]

And why do you think so? For example, OpenELEC build system never forsaw using more than one compiler for target board. This saves me many hours. Put U-Boot there and I don't have to include it on any image.

 

It acts as a BIOS. Board specific U-Boot with board specific settings can be stored there, so you can have universal images. Just like on a PC.

[Christos]

You will eventually include U-Boot because you want to have as many boards as possible (we are talking about Armbian here..)

SPI memories are more or less a thing of the low-spec embedded SBCs eg STM32Fx or Atmel or Microchip, there it definitively makes sense to have such a chip.

Here U-Boot with the diversity of things around needs to be a part of the released firmware all the time.

 

And after all, the guy there decided to put some cheap stuf, no-cost, just to make a bit of a difference.

 

Yet as I said, this is just my opinion, obviously anyone can do whatever he/she likes.

 

 

P.S.

I see SPI memories more like as ID or data storage eg MAC or dig.certificate store.

[jernej]

If I catched spirit of linux-sunxi devs correctly, SPI flash is something desirable. I'm really interested what Armbian devs think about that. @igor, @tkaiser, @zador?

 

I don't understand what do you mean by "You will include U-Boot because you want to have as many boards as possible"? Include U-Boot on SD card because you want to have supported as many board as possible?

 

To address your slowness concern - chip on my board is MX25L1606E, which can be clocked up to 80 MHz (might be changed in the future). This means that in theory it can be read with the speed of about 10 MB/s. More than enough for boot operation, which in general, doesn't need any writting.

[Christos]

.. Include U-Boot on SD card because you want to have supported as many board as possible?

 

 

Exactly.

[zador.blood.stained]

If I catched spirit of linux-sunxi devs correctly, SPI flash is something desirable. I'm really interested what Armbian devs think about that. @igor, @tkaiser, @zador?

I didn't think much about this yet, but I don't think SPI flash changes too much for Armbian project or for average Armbian user.

U-boot will mostly be used from SD and eMMC. SPI flash can be used in 2 new scenarios ("new" as in "now you don't need SD card for this"):

• Root on USB connected device (for boards without eMMC)
• TFTP boot and root on NFS

There are still some considerations:

• Boot priority - SPI flash boot priority is lower than SD/eMMC, but higher than FEL mode. So if you have u-boot in SPI and a board without FEL button, entering FEL mode will require either patching u-boot or using special SD card image
• No write protection. Since there is no hardware WP support, I guess on arm64 based boards protection can be implemented in ATF
• Limited u-boot support. AFAIK still no ATF support, no FIT support and no sunxi SPI driver in u-boot itself.
• Dealing with environment. Writing u-boot to SPI flash is not enough, you need to write configuration for it telling u-boot what to do after it was loaded.

[zador.blood.stained]

Also I compared u-boot source from H5 SDK to existing one for Pine64 and I can say there are changes even in sun50iw1 part, and there are enough changes in general so I don't want to waste time with it. I would guess it is possible to import sun50iw2 related parts on top of Pine64 u-boot and poke it until it works, but it will take too much effort and time, I would better wait for basic mainline support.

[tkaiser]

If I catched spirit of linux-sunxi devs correctly, SPI flash is something desirable. I'm really interested what Armbian devs think about that. @igor, @tkaiser, @zador?

 

Fully agree. By the end of 2017 we should simply stop supporting new sunxi hardware that lacks SPI flash and fade out support for devices from those vendors being too ignorant.

 

It will take some time but as soon as board vendors (collaborating with linux-sunxi community) start to ship their devices with pre-populated SPI NOR flash this will be the best user experience improvement EVER. Just do a quick check of the SD card and inform user that he should return to the mall and buy a better card since the one he's using is insanely slow crap. Do some fancy cpuburn stuff to prevent any 'insufficient power supply' issues by simply deadlocking the board until the user gets the idea to replace the crappy phone charger lying around with a proper PSU. Implement netbooting by default, provide device agnostic Armbian images from then on...

 

Seriously: hardware vendors using Allwinner SoCs who save the 4 Cent to solder 16 Mb flash to their boards should be avoided beginning with January the 1st 2017. Boards with eMMC being the exception since there identical stuff could be stored on eMMC boot partition(s). Lets make this the test case for board support or not!

[zador.blood.stained]

@tkaiser

IMO this will never happen, at least will Allwinner based boards, and especially with newer SoCs. Vendors need to sell boards first in order to allow the community to start mainlining work, otherwise they can either spend money and time on mainlining (= more expensive boards and delayed release time, look at C.H.I.P. as an example. End result is not guaranteed and mainlining is relatively slow process as you can see with C.H.I.P. or linux-sunxi community in general) or using BSP provided stuff (u-boot with blobs and glued script.bin/DTB that supports loading only Android kernels from Android partition layout? And good lick booting into FEL while this is pre-flashed in SPI? No, thanks, first thing any sane user would do is erase this crap and forget it ever was there)

[tkaiser]

And good lick booting into FEL while this is pre-flashed in SPI?

 

You already mentioned 'board without FEL button' -- lets make this the 2nd requirement. IMO it doesn't matter that much what the board vendor thinks when releasing new hardware. But if he does not invest the 4 Cent for 16 Mb SPI NOR flash and the 1 Cent for the FEL button then we skip this hardware design.

 

It's a classic chicken-egg problem that can only be solved by convincing hardware vendors to put both components on their boards. If starting to communicate with linux-sunxi community is part of the process... even better (though I have to admit that I really like Xunlong's communication 'style': Me and maybe others suggested implementing PoE, all answers were either non-existent or negative and then Xunlong simply delivers months later -- great. Same with SPI flash now or with OPi Plus 2E back then)

 

First and most important step is that hardware vendors start to invest the additional 5 Cent to put both SPI NOR flash and a FEL button on their boards. Then it's up to us (mostly linux-sunxi community) to demonstrate what could live inside the flash and how this could improve user experience. And then we'll see.

 

C'mon, it's just 5 Cents for them and if we can help vendors making this decision we should do. Really, simply let us stop supporting sunxi hardware that lacks this starting with 2017. Either eMMC or SPI NOR flash as a prerequisit isn't that much of a requirement?

[zador.blood.stained]

I agree about FEL button requirement (especially for boards with eMMC and SPI flash). But also I want to note that we can't represent this as an opinion of linux-sunxi community in general. And as for Armbian project - expanding list of supported boards without expanding the team would become harder regardless of board vendors decisions on extra chips and buttons.

[tkaiser]

But also I want to note that we can't represent this as an opinion of linux-sunxi community in general.

 

It isn't necessary that there exists some consensus regarding stuff like this especially given that 'linux-sunxi' community isn't an 'entity'. IMO it's just expressing the need for these two 'features' worth 5 Cent per board for new hardware designs and being consequent with regard to supporting boards or not.

• No FEL button but eMMC? Sorry, no Armbian support.
• No eMMC and also no SPI NOR flash? The same

People will buy the hardware anyway and might even be happy with vendor software offers since they don't care about certain issues or are clueless. Who cares?

 

And it's not about supporting more boards but dropping support for boards from vendors that remain ignorant. Lets focus on hardware that is fun to play with and that's worth to get support. We waste so much time on support issues that could be simply avoided if hardware vendors would start to cooperate (really, all those 'SD card imaging gone wrong' stuff won't be an issue any more)

[zador.blood.stained]

I still can't see a use case for SPI flash for an average user. Prebuilt images will still contain u-boot, boards will still boot from SD initially. I have to remind you that u-boot needs boot script and environment file, and it should be easily accessible by user.

[tkaiser]

I still can't see a use case for SPI flash for an average user.

 

Regarding situation today I agree. Am talking about 2017 and huge improvements of the stuff living inside this SPI NOR flash.

 

A bootloader that is able to implement PXE will already ease deployment of sunxi devices a lot in certain environments. If board vendors start to cooperate (requires getting in touch) then why shouldn't be a bootloader also be able to detect/search for a Linux/Android image that meets certain requirements and boot it from wherever it is accessible?

 

Android for Allwinner devices doesn't have to rely on shitty partition schemes as implemented now and stuff like that. Jon Smirl and Kamil TrzciÅ„ski did a big step forward here and maybe even hardware vendors will get the idea that they don't have to rely on this braindead stuff from Allwinner if it's about Android. No one, really no one needs this '15 partitions for no reason Allwinner BSP stuff'. We just have to teach hardware vendors to stay away from this crap.

 

It's a community thing. It's huge but worth the efforts. But the first step is rather simple: Spend those 5 Cent per board and solder the stuff that's needed to your devices

[martinayotte]

@TKaiser, 5 cents is pretty low estimate, I would rather say 20 cents, even 30 cents if we wish 128Mbits

 

BTW, today, I've worked on get U-Boot-SPL-SPI running on my Zero-M2+ ...

I've finally got it working few minutes ago, it was able to boot from USB dongle without SDCard via this U-Boot-SPL-SPI.

Next steps is to get it able to boot from network ...

 

For H5, I presume there still a lot of work to get it work, André told me that it still WIP.

[pfeerick]

Looks like we already know @tkaisers new year resolution (since 1 January 2017 seems to be a key date! ) :

 

To force all SBC vendors to:

• include a FEL button to program the eMMC (if present on board);
• include onboard SPI NOR flash to make the end user / boot experience more robust; and
• stop using shitty zillion partition android images

Did I miss any? My only concern would be the liklihood of failure... as they're all good goals in my opinion

 

I find it really funny the argument... er, discussion... around the SPI NOR flash... essentially saying we need to re-invent the wheel, and adopt a *similar* solution as to what the intel x86 uses with a BIOS... :-O 

[nz1]

My 2cents

If we can use hdmi, keyboard and mouse with a nor flash uboot and it comes pre loaded with the board then I suspect it could reduce the frustration levels for new users when it does not boot and all they are left with are some flashing lights.

I know someone who bought a raspberry pi and never even used it, probably because it would take too long to flash it.

I bought my first board last year and spent large amounts of time trying to get it to boot. I bought a serial/usb cable, installed a diver on my mac, decided to install a gui program that came with the driver, finally got some data on the gui, but the backspace key wouldn't work so I couldn't edit anything. Also overscan problems, trying to fiddle with the monitor to make it go away.

I gave up for many months, then I installed armbian and the monitor displayed beautifully. However still lots of problems using dd to burn images, until I started to use etcher and discovered to my amazement that etcher was catching errors during the write process(before the verify) that dd would blissfully ignore.

The moral of the story for me was to stay as far away from sdcards as possible.

Also I have read with interest that usb with uasp is quite fast. I looked up Aliexpress and you can buy a 16gb ssd for about 15$. So I am wondering if its possible to use a orange pi pc2 with uboot on the nor flash and os on attached ssd. The ssd is much more reliable than sdcards or even emmc, I could modify fstab to have immediate writes and not have to worry about storage failing. The reliability stats for the ssd on aliexpress is pretty impressive.

[Christos]

In an environment where you till strive to get something working having a multitude of pieces to fit together as it is now, you want to add another level of complexity.

In my view Armbian has delivered a phenomenal result since it handles everything succesfully, it contains all the necessary parts in one go and it simply works as the average user wants.

Dont be fooled by those few crying voices that dont know what a SD is or how to boot, for one of those noobs, there are hundrends if not thousands that are happy today and they simply do not bother to post since everything is just fine.

Usually you are distracted from the crying babies..

 

Also, if you want to play a role and push the vendors, it seems to me that you might dont know exactly the business world. Do it, try it, but usually the market is driven by the needs of the many and business people know that.

 

If you do want to promote a technical solution, IMHO, get modern, leave out buttons and SPI, these were things of last decade, get ahead and promote eMMC, fast large non-volatile memory, we are at 2016 and still talking about 128Mbits of SPI memory? cmon guys..

 

 

My 2c

[nz1]

@Christos

I can remember asking my users what they thought of my software and I was always interested in what they said, even if it was negative, because it would give me clues on how I could improve my code.

I would never call my users babies or otherwise insult them as the whole point of writing software is to make someone's else's life a bit easier.

[Christos]

@nz1

Never intended to insult, it is just a metaphor to get the idea of how easy it is to be distracted from the very few that make a lot of noise and forget the many thousands that are happy and quiet..