Kernel boot comman line

Oh, one other question: I’m beginning to get the idea that UBoot is installed in the MBR, much like grub (and lilo) on x86 (conventional PC) boot disks. Presumably there is something which installs UBoot, presumably with its boot environment. (UBoot-install?).

Fundamental mistake. https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

Forget about what you know about Linux on PC. Userland is the same, everything else is not. Especially when you are trying to use 5-10 years old software that never actually worked well and certainly nobody supports anymore (Debian Jessie, kernel 3.10.y).

Images are manually tested - they 100% boot, but sadly support for M64 is not good quality which is why Armbian label images as “Not officially supported / Community support only / EOS / WIP …”. That tells you what to expect without the need to loose time.

What is actually wrong with M64 on modern kernel? Which is the only one where its sane to invest time to. Most of the functions works fine, but boards shuts off, under moderate load. I suspect some regulator not being fed with correct values but to get with this down to the bottom … its a painstakingly debug/compare/looking schematics that can easily cost days/weeks.

What the hell is wrong with dd???

Please don’t tell me not to use a perfectly good CLI program, without a realy good reason. Etcher is like 90MB! And I expect it won’t run on my (older) Linux laptop. Over in BeagleBoard land it also talks about using Etcher, but when I asked about it there, they said that Etcher is just a fancy GUI toy for newbies and that dd works just fine.

Ok, I downloaded usbimager and used that instead of dd. Same results. Boot fails, looping:

 U-Boot SPL 2020.04-armbian (Jun 14 2020 - 23:09:55 +0200)                     
DRAM: 2048 MiB                                                                
Trying to boot from MMC1                                                      
NOTICE:  BL31: v2.3(debug):635912f-dirty                                      
NOTICE:  BL31: Built : 23:09:46, Jun 14 2020                                  
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)                      
NOTICE:  BL31: Found U-Boot DTB at 0x4095f08, model: BananaPi-M64             
INFO:    ARM GICv2 driver initialized                                         
INFO:    Configuring SPC Controller                                           
INFO:    PMIC: Probing AXP803 on RSB                                          
INFO:    PMIC: Enabling DRIVEVBUS                                             
INFO:    PMIC: dcdc1 voltage: 3.300V                                          
INFO:    PMIC: dcdc5 voltage: 1.500V                                          
INFO:    PMIC: dcdc6 voltage: 1.100V                                          
INFO:    PMIC: dldo1 voltage: 3.300V                                          
INFO:    PMIC: dldo2 voltage: 3.300V                                          
INFO:    PMIC: Enabling DC SW                                                 
INFO:    BL31: Platform setu�

OK, so Armbian is a bust. I am back to Ubuntu…

It lack most critical function which is must have when writing to stupid flash media … you can use DD but you need to read and compare to what you write - i use simple script for that. Those fancy (i don’t recommend Ethcer since its bulky and comes with spyware) utils do that by default …

… this way you eliminate problems and save time. Don’t compare this hw with Beagleboard or Rpi. Both are old and much better supported.

Armbian / mainstream is your only chance and right way to proceed to get this board working. There is no Ubuntu. Its just “Ubuntu”, “Debian”, “Arch” … made by hw folks here.

The Ubuntu image boots up and actually works (except for the overscan), the Armbian does not boot up…

Agree. But I can assure you there are no overscan problems and all modern kernel features works. In case something doesn’t work … try to find such "small " fix anywhere at the people who sold you hardware https://github.com/armbian/build/pull/1887

But how do I get Armbian to boot? What do I need to do? Do I have the wrong image? What is the correct stable image?

Few days, perhaps weeks focusing to this hardware and I might be able to answer on those questions … anything else is just speculating and assuming.

Your boot looks the same as mine https://pastebin.com/HdEf9Apb while mine boots to Linux. But, as I said, something regarding powering is not set right - perhaps that is the reason yours doesn’t pass SPL. Mine shuts off after some load, but not always … Such behaviours is worse to fix.

New / other board revisions might have troubles booting modern u-boot/kernel combo, while they boot old legacy (nobody supports) fine …

When dealing with modern kernel support: https://groups.google.com/forum/#!forum/linux-sunxi and armbian forums is your knowledge base.

So the problem might be power related? I am powering with a micro-USB type power suppy (OTG). It says it is rated at 2A, but maybe not? I have a power supply (also rated 2A) for my Beagles with a DC barrel plug, but the plug is the wrong size for the M64. I found an adapter plug on Mouser – I plan on placing a Mouser order soon.

OK, using a slightly beefier power supply and running the power in via the GPIO header I got Armbian to boot.

It is however still “overscaning”. This is with Armbian_20.05.4_Bananapim64_focal_current_5.4.45_desktop.img.xz

So there is still a problem…

OMG :tired_face: https://forum.armbian.com/topic/4767-powering-through-micro-usb/ Do you have a slight idea how much time was wasted because of a wrong assumption that powering via mUSB is possible? Armbian folks thought about denying any help to boards using such powering … In a modern u-boot, most likely this - not booting when using mUSB - is a feature, not a bug. Fixing HW design mistake.

OK, but here someone might be listening to your problems.

Before asking for help, try switching to nightly (armbian-config -> system) and once again to DEV 5.7.y kernel … which is bleeding edge. Problem might be already solved … if not https://groups.google.com/forum/#!forum/linux-sunxi

if with 5.7 you have no luck, maybe you can try hdmi-patches i added for r2…some of them changing hdmi/drm-core and maybe help

  • 96d3667b04d4054d7dd5e29596bc8b72eb2dc387 drm/mediatek: config component output by device node port
  • 154cee0f6c4b4126a05ee9066eab307d74cf5329 drm/mediatek: fix boot up for 720 and 480 but 1080
  • 7d5c582dcf7419cda4454a9bf14cfde0ac932bab drm: Add get_possible_crtc API for dpi, dsi
  • 4a6be3d03115034997125527e08f80dc4f2ac0f7 drm/mediatek: dpi/dsi: change the getting possible_crtc way

last 2 need to be applied together to have an effect, but

OK, this is going to have to wait – I only have a dialup connection right now. I expect to get a fiber connection in a week or so. The power supply I am using now is not really portable so I can’t take everything someplace with faster internet…