Raspberry Pi 4 bcm2711 / Raspberry Pi 3 bcm2837 (aarch64)
slarm64This forum is for the discussion of slarm64.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Without these mods the screen overscans, I can't access the menu bar and am basically flying blind as all sorts of stuff is at the screen edge. We've discussed this before, and fingered my tv as the culprit.
Last edited by business_kid; 11-18-2022 at 12:13 PM.
Right, I actually got back and tested that all from the Pi. Just as feedback, he overscan parameters don't seem to be working, and the firefox on your current MMC image is rearing up in alarm if I try to download ungoogled chromium in Firefox. I'm not unduly worried by either error as it boots and I have a terminal, which is all I want really.
The image filesystem landed in poor shape, so I'll check my download before I do much. It's the 6.2.x version I'll want to see behaving itself.
BTW, I'm intrigued by what those rpi-eeprom-update & rpi-userland scripts do, but they do plenty. Is there a document somewhere? They have been changes since 15.0
Right, thanks for those. They appear to be the Raspbian utilities which accounts for the bloat and lack of comments.
I have tried to get the screen correctly sized without success. The first page of text output on boot seems to obey the "overscan" directives but page 2 of the boot is oversized and off screen. Here's some things from dmesg that seem odd:
Code:
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 snd_bcm2835.enable_hdmi=0 snd_bcm2835.enable_hdmi=0 smsc95xx.macaddr=DC:A6:32:73:7D:DF vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 root=/dev/mmcblk0p2 ro rootwait nofont console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 elevator=noop snd-bcm2835.enable_compat_alsa=0
[ 0.000000] Kernel parameter elevator= does not have any effect anymore.
Please use sysfs to set IO scheduler for individual devices.
[ 0.000000] Unknown kernel command line parameters "nofont selinux=0", will be passed to user space.
[ 52.332555] hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
[ 52.332580] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
[ 52.332587] MAI: ASoC: __soc_pcm_prepare() failed (-22)
<<Repeated 20+ times>
[ 52.587848] MAI: __soc_pcm_open() failed (-19)
[ 52.588993] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 52.589112] MAI: __soc_pcm_open() failed (-19)
[ 52.590313] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 52.590380] MAI: __soc_pcm_open() failed (-19)
[ 52.608150] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 52.608249] MAI: __soc_pcm_open() failed (-19)
[ 52.608992] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 52.609079] MAI: __soc_pcm_open() failed (-19)
[ 52.611349] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 52.611534] MAI: __soc_pcm_open() failed (-19)
[ 52.922620] Bluetooth: RFCOMM TTY layer initialized
[ 52.922678] Bluetooth: RFCOMM socket layer initialized
[ 52.922730] Bluetooth: RFCOMM ver 1.11
Despite all those errors, sound works
There's also nothing about video drivers, or the GPU in dmesg. No module loaded? Every mention of video or hdmi is in connection with the bcm 2835, which is the audio chip unless I'm mistaken. The only thing I got was this
and that's apparently incapable of following "overscan" orders.
Looking at /var/log/Xorg.0.log, it has modelines, and maximum dotclock. As I go back to the days of Analogue monitors, I can cobble myself up something in /etc/X11/xorg.conf.d/50-video.conf to sort it, but I won't bother unless the new 6.2.x drivers need to be bent straight. It does appear that the endless list of parameters in /boot/cmdline.txt need a once-over as some are deprecated. I'm currently using that.
Despite all those errors, sound works
There's also nothing about video drivers, or the GPU in dmesg. No module loaded? Every mention of video or hdmi is in connection with the bcm 2835, which is the audio chip unless I'm mistaken.
At a semi-educated guess, that 15.0 command line looks like the o/p of config.txt being passed as kernel parameters. The current kernel command line (2 posts down) isn't half that elaborate, as if config.txt is being ignored.
Again, this isn't a priority. I'll be making noise if I can't stop the 6.2.x kernels from overscanning.
So the penny finally dropped here. I moved cmdline.txt to cmdline.orig, and put the kernel command line as logged in the dmesg of 15.0 in as cmdline.txt on your current image with the 6.0.9 kernel, and it booted with no extra errors and solved my overscan problem.
I know you recommend u-boot. But that pays no heed to the parameters in config.txt. I have been using the standard RazPi boot sequence of config.txt & cmdline.txt. But config.txt is obviously not being processed on this iteration of current.
I'm usually ok - just my quirky monitor, a usb keyboard & mouse, a single hdmi monitor and a usb wifi adapter. I'm not using I2C, funny baud rates or GPIO. But guys doing clever things with this Pi may want a very peculiar setup and if the setup is not being processed, that's an issue. I've attached the new working cmdline.txt. I'm pretty sure the overscan setting in config.txt was 32, not 48 and have no idea where the difference came from.
So the penny finally dropped here. I moved cmdline.txt to cmdline.orig, and put the kernel command line as logged in the dmesg of 15.0 in as cmdline.txt on your current image with the 6.0.9 kernel, and it booted with no extra errors and solved my overscan problem.
I know you recommend u-boot. But that pays no heed to the parameters in config.txt. I have been using the standard RazPi boot sequence of config.txt & cmdline.txt. But config.txt is obviously not being processed on this iteration of current.
I'm usually ok - just my quirky monitor, a usb keyboard & mouse, a single hdmi monitor and a usb wifi adapter. I'm not using I2C, funny baud rates or GPIO. But guys doing clever things with this Pi may want a very peculiar setup and if the setup is not being processed, that's an issue. I've attached the new working cmdline.txt. I'm pretty sure the overscan setting in config.txt was 32, not 48 and have no idea where the difference came from.
When using the kernel=Image parameter, the loading line is taken from cmdline.txt. Under kernel=u-boot.bin, the loading line is taken from /boot/uEnv.txtextraargs supplements the bootargs parameter from boot.scr
I'm looking here at the /var/log/messages that I have built up with about half a dozen boots on this MMC card with the 6.0.9 image. My principal changes to config.txt was overscan arguments, and kernel/initrd arguments. Just focussing on the kernel command line,the arguments passed are interesting. Here's the config files
which seems to be the 2 files one after the other. So any configuration with u-boot has to be in uEnv.txt translated into kernel arguments.
Working with config.txt & cmdline.txt, but before I fixed overscanning, only this bit of the total command line was coming from config.txt, or elsewhere
and because of the hdmi=0, the thing was booting on 1280x720. All those "snd_bcm2835_enable..." options should be set to 1 and not 0.
To fix it, I suggest you find why config.txt settings are not being passed, or expand cmdline.txt. I'm just passing this on, as I had the logs to hand. Maybe I'm behind on the eeprom updates or something.
To fix it, I suggest you find why config.txt settings are not being passed, or expand cmdline.txt. I'm just passing this on, as I had the logs to hand. Maybe I'm behind on the eeprom updates or something.
config.txt is only processed when the rpi loader is running (kernel=Image)
Well, I am using that the "kernel=vmlinuz-6.0.9" setup, because I'm not able to run u-boot with my monitor. I'm actually using the copies with version numbers to avoid confusion, but they're identical. My setup on your recent image is identical to my 15.0 setup. 15.0 works, your recent image doesn't, because it isn't passing extra options from config.txt to the kernel. That's why I'm flagging it.
I worked around the issue with an expanded cmdline.txt. But my settings are strictly "Works For Me" and won't necessarily work for others. Come to think of it, u-boot has no provision for setup except the kernel options in uEnv.txt & cmdline.txt. How is u-boot ever going to load an overlay?
Well, I am using that the "kernel=vmlinuz-6.0.9" setup, because I'm not able to run u-boot with my monitor. I'm actually using the copies with version numbers to avoid confusion, but they're identical. My setup on your recent image is identical to my 15.0 setup. 15.0 works, your recent image doesn't, because it isn't passing extra options from config.txt to the kernel. That's why I'm flagging it.
I worked around the issue with an expanded cmdline.txt. But my settings are strictly "Works For Me" and won't necessarily work for others. Come to think of it, u-boot has no provision for setup except the kernel options in uEnv.txt & cmdline.txt. How is u-boot ever going to load an overlay?
missing parameters just need to be added/replaced in /boot/uEnv.txt parameter extraargs=.
That's crazy. I can imagine that working for 'switch' type arguments (e.g. turbo=0). The Pi boot system loads the overlays before it boots the kernel. There's no kernel firmware for the bcm2835. How do you specify, for example, your choice of video overlays or the cpu/gpu frequency with kernel arguments? The kernel only loads kernel firmware, not boot firmware.
Last edited by business_kid; 11-25-2022 at 07:49 AM.
when using u-boot, this is a chain from the rpi loader (where config.txt is used, loading overlays) and then passes to u-boot where uEnv.txt is already used.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.