Kernel boot comman line

No idea. Never booted this.

On r2/r64 there is a uEnv.txt booted. Maybe on m64 there is already one in root of boot-partition or in bananapi/bpi-*/linux/

OK, I connecte a serial cable to the serial console header:

Hit any key to stop autoboot:  2  1  0 

** Bad device mmc 2 **

reading bananapi/bpi-m64/linux4.4/720p/bpiEnv.txt

** Unable to read file bananapi/bpi-m64/linux4.4/720p/bpiEnv.txt **

reading bananapi/bpi-m64/linux4.4/bpiEnv.txt

** Unable to read file bananapi/bpi-m64/linux4.4/bpiEnv.txt **

reading bpiEnv.txt

** Unable to read file bpiEnv.txt **

reading bananapi/bpi-m64/linux4.4/720p/uEnv.txt

1891 bytes read in 7 ms (263.7 KiB/s)

Loaded environment from uEnv.txt

Running uenvcmd ...

Banana Pi bpi-m64 chip: r18 Service: linux4.4 bpiuser: 720p

reading bananapi/bpi-m64/linux4.4/uImage

7660991 bytes read in 322 ms (22.7 MiB/s)

reading bananapi/bpi-m64/linux4.4/uInitrd

5166907 bytes read in 220 ms (22.4 MiB/s)

It looks like it looks for bpiEnv.txt in several places and then uEnv.txt in several places. What is happening (for me) is it seems to want a 720p display, but for my monitor (a 24" LCD TV) 720p does not work right (some of the display is off-screen at the top and left). 1080p should work better. I think I need to create a 1080p directory and probably also need a 1080p .dtb file to go with it an somehow get uBoot to look there instead of the 720p directory. Where can I get the device tree source files? Are they on github somewhere? If so, where?

I would prefer this file in bpi-boot partition…you should do a printenv in uboot-console to look where the best place is to modify it. Make sure you see full content (wide console windows so output gets not truncated). On r2/r64 there is a abootargs for modifying cmdline passed to linux kernel…you can append with

abootargs=$abootargs yourcontent

OK, after a bit of poking around in the uboot-console, I changed bpiuser to 1080p and also created a 1080p directory with a modified uEnv.txt file, changing screen mode to 10, which should make it 1080p60, but doesn’t seem to. It still seems to be 720p. The problem is that both the kernel (console) and X11 behave as if the screen is a bit larger than it actually is, about 24 pixels on all four sides are “off screen”. How do I fix that? (No the monitor has no resolution adjustment feature – eg no “width or height” adjustment.)

That sounds like you changed only virtual resolution,but hardware is still in 720p mode.

As far as i understand you, your changed environment is passed to linux? You see values in dmesg you’ve set in your new uenv.txt?

For graphics…how did you set resolution? On r2 i can do this like this:

video=1280x1024-32

OK, I added a video= option to the uEnv.txt file. No effect (yes, the option shows up in /proc/cmdline, but has no effect on the screen).

I tried a different monitor and the problem is consistent. The video screen is roughly 50 pixels wider and taller than the actual screen (roughly 25 pixels on all four sides are “off screen”). (25 pixels ~= height of a mate-panel). This is both under X11 and in console mode, right from kernel startup. I wonder if this is a problem with the HDMI driver code? I am beginning to think that the 720p vs 1080p business is a red herring…

Here are two images that illustrate the problem I am having. The zip file available here: https://www.deepsoft.com/m64video-problems/ contains two images, one is a screenshot of the root window showing what X11 thinks it is displaying, and the other is a photograph of my monitor showing what is actually shown on the screen. How do I fix this? I’m guessing maybe a device tree hack? Some exotic kernel parameter? What?

This is adjustable by using the monitor control set. Disable overscan.

Two problems with that:

There is no Overscan setting for either monitor (and this happens with two (very) different monitors). There are several “Zoom” settings (on my TV monitor – I don’t think the other has any “Zoom” settings), but none provide any improvement. Neither monitor “fakes” a variable width / height screen (eg faking an analogue monitor) and don’t have “width” (horizonital size) and “height” (vertical size) and “centering” controls.

This problem does NOT occur with any of my Raspberry Pis. (Nor does it happen when I connected a MacMini via the VGA nor when I connect my Lenovo laptop via VGA either. So either all of the other devices are exactly anticipating overscan or something else is happening.

Or maybe there is a kernel setting to turn ON overscan in the HDMI driver (or in the device tree).

Did you try Armbian? At least this problem should not be there - video is set automatically depending on your monitor.

I have not tried Armbian. I guess I will have to start over… Sigh…

OK, I downloaded Armbian_5.24_Pine64_Debian_jessie_3.10.104_desktop.img and dd’ed to a MicroSD card. I got it too boot, but what is the default login & password?

OK, found the root pasword. Armbian_5.24_Pine64_Debian_jessie_3.10.104_desktop.img seems not to have WiFi support (bummer). I downloaded Armbian_20.05.4_Bananapim64_focal_current_5.4.45_desktop.img.xz, but it does not boot – it loops with this message:

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

This image has the same problem (“overscan”) as the Ubuntu image. There is something deeper going on here.

I do know with x86 (conventional PC) Linux, there are kernel command line options for default (vga) video scan settings for when dealing with “oddball” monitors or monitors that don’t report their supported video modes. I am presuming something similar exists for these kernels. If so, where is this documented? Or is this handled with a device tree?

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.