Stephen Graf

Well I found it by asking for kernel configuration changes during the build setup. I think the original values were 15 for 17 and 12 for 15 but I can't remember for sure. Anyway with the new values I can see the beginning of the dmesg and journal does not report missing messages. However the extra data did not show anything to help me with the bluetooth problem. x General setup ---> x (17) Kernel log buffer size (16 => 64KB, 17 => 128KB) x x x (15) CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)

I think I retracted my proposal to enable all the hardware and just skip overlays. Armbian-config Hardware and overlays are very useful. My concern from the beginning has been the issue of overlays being "generic". Dts is a definition of the hardware on a SBC. Obviously the SOC is the major piece, but there are other items that need specification, memory, gpu, power regulator, ethernet phy, etc. Because these other items are unique to a SBC, the dts takes the name of the SBC, not the SOC. There is no such thing as a generic dts. Now since overlays are simply modifications to a dts it is logical that overlays should also be unique and tied to a specific dts. There are many overlays that are common among the SBCs just as many dts' share common dtsi, But the fact remains that the dts has the name of the SBC and I suggest that the overlays follow this naming convention. I think this would simplify creation and certainly testing of overlays. Fewer patches would be required and testing would be limited to the overlay for the SBC being worked on. If this approach were taken it would not require rework of the existing overlays that already work.

I'm still trying to find where to make the change. The internet message was from 10 years ago! I did not want you to rebuild, just start up zero2 and do a dmesg to see it it starts at time 0 or about .6 sec. Just to see if the problem is specific to zero3 or both.

@pixdrift Would you please look at dmseg on your orangepizero2 to see if it starts at time 0. I came across this in the internet: Your kernel's ring buffer ran out and the first entries were removed for new entries. Simply set CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT larger in your kernel config. yeah now works with 19! ~ $ cat /usr/src/linux/.config | egrep CONFIG_LOG_ CONFIG_LOG_BUF_SHIFT=19 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

I am asking for help in resolving an issue with dmesg and journal not starting at time zero on the orangepizero2. I don't' know about the zero2. I am actually trying to determine why bluetooth only works on the initial boot and never again after a reboot. I am booting from spi flash to a usb hard disk. The dmesg started at time .03 sec on the initial boot and only at time .6 sec on the second boot. In previous investigation I noted the journal indicates missing about 150 messages on boot. I am not sure if the missing data would help in my bluetooth investigation, but I feel very uncomfortable without the data. I have no idea of where to start looking at the missing data problem. An armbianmonitor -u has been uploaded: https://paste.armbian.com/isajocaper

Orangepizero2/3 are using spi0 internally to connect to the 16MB flash memory on the boards. Spi1 is available and should be enabled by a working overlay in the near future. In the meantime if you can find the driver source, it should be easy to change the spi port and cs in the code as they are usually just definitions. As an aside, if you are looking to use a tpm for secure boot, you should be looking at u-boot and not Armbian.

@MrK I think you owe @Gunjan Gupta an apology. There is no need for such language when people are volunteering their time and efforts, or ever for that matter. @MrK you are in the wrong forum. Changes such as you are proposing should be done at the Linux kernel level. @MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment. You will get more things done and with better results. If you had been working for me I would have fired you for behaving this way. It is just too disruptive.

I think this was meant for @SteeMan attention. I was following this discussion and I think the discussion should be going on upstream not at the Armbian level.

For hardware work I find 1GB is plenty. As Bill Gates once said "who needs more than 512KB".

When I was working with u-boot to test the orangepizero3 implementation there was an issue with memory size not being detected properly. The issue was resolved by raising the default memory speed parameter to the value recommended for LPDDR4. I have not seen an reported problems since then.

I think the bigtree board is the one that is causing all this conflict. It is a very specialized board built for a specific function - to run 3D printers. Bigtree paid Armbian to set up the image and they got the paid treatment regardless of the compatibility with other boards. I suspect future h616 and h618 boards will be much more alike and not similar to the bigtree board. As for the devices that hang on the spi and i2c buses, there are hundreds of them. Go to AliExpress and search for "i2c device". There is no way to provide overlays for each of them. My suggestion is to provide overlays for the the main i/o that the SBC advertises and brings out to the headers. If users want to implement some of the other muxed functions then it should be the users responsibility to provide a user overlay which does not impact the build environment. Yes there will be many overlays that are common between boards and yes there will be some overlays that are not. The difficulty is how to deal with the overlays that are not in common.

@Igor What is the status of the orangepione? On the download page there are no images presented yet in the build framework is shows up as "conf" in the support (1st) page.

@Gunjan Gupta Yes I can see that you are trying to take on too much and no I don't think this is that urgent. However in the interests of moving forward, is there anyone else who would have some cycles to deal with this? I would like to follow your proposal and stay with the existing naming convention for the time being. As the orangepizero3 is the first h618 SOC, in keeping with the existing procedures we should create a new overlay structure called sun50i-h618. I could recreate the patch for the overlays (5) that I think are useful for the zero3. Then by the time new h618 boards are added you may have had time to revisit the whole issue. In the meantime let others do the work. This change will not impact any other board. As I am proposing to stay with the existing procedures. I don't think this patch will require any significant time from you. I can see from @SteeMan comments that trying to improve things will be a big headache. What do you think?

@ag123@Gunjan Gupta@pixdriftLet's try to go back to fundamentals to see what we are trying to resolve with the overlays. I will try to give you an idea of what a hardware developer would think about when deciding on a specific SBC. The SBC designer will have made some choices as to what i/o will be available on the board. The SOC has numerous options of which only a few will be implemented. The hardware developer will look at the array of boards available and choose one that readily provides the functions that he thinks he would need. I chose the orangepizero3 based on the availability of i2c (aka twi), spi and gpio which is very similar to the orangepione that I have a lot of experience with. My problem is trying to get this i/o enabled via the usual armbian-config procedure. @Gunjan Gupta has taught me how to write overlays and I have been able to patch the dtb directly to get the i/o working. But that is not the preferred procedure. In the process I have come to question the rational of tying the overlays to the SOC instead of the SBC. Should the overlays for orangepizero3 be labelled sun501-h618? That would be an easy solution for today as there are no other h618 boards. I think the bigtree board should not have been allowed to use the label sun50i-h616 for its overlays as that board is a very specific implementation for a particular environment. After further reflection I don't think enabling the i/o in the dtb is the best idea. It is usually better to keep things turned off if not in use. @pixdrift Think of your problem with the half plugged in serial to usb adapter. In a similar vein I would recommend that gpu, bluetooth, wifi and hdmi not be always enabled. Many users will run a headless server using these boards and all these unused devices add a lot of software overhead in addition to the extra power drain and associated heat generated. I am not sure this moves us further along in resolving the issue, but I hope it provides some stimulus for thought.

@MrK Try the spidev_test tool. It has many options to set various parameters such as speed. https://github.com/rm-hull/spidev-test/blob/master/README.md

@pixdrift Thank you. I will test current on zero3. I don't think zero3 is supported on legacy. I have a monitor with hdmi and audio and can test sound over hdmi on zero3. I can also test analog sound from the header if the sound fix works for both.

@pixdrift If you want to proceed with a PR please go ahead. If you apply the patch to your repo I will build and test on current for the zero3. I still have concerns with a number of items that might be related: - Bluetooth only working on the initial boot - pinctl errors on boot - dmesg log not starting at time 0.

@MrK You should try the build from @pixdrift (edge only). https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix There is only one overlay item for spi, spi1, PH6,7,8 and cs0, which is on PH9 as per the orangepizero2/3 drawings. I have not put a scope on the pins but tested with spidev_test and a loopback on SI/SO which returns the correct data. I also put a meter on PH9 and it goes high during the test.

@pixdrift If your serial to usb adapter is not connected on the usb side, where is it getting power from? This could be a cause for possible garbage characters appearing on the input of the serial side that would stop u-boot. It is also possible for the serial side to oscillate (if not powered) just from the voltages on the output pin and u-boot is trying to decode a lot of garbage. Bus usb@5200400: USB OHCI 1.0 scanning bus usb@5200000 for devices... 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Autoboot in 2 seconds, press <Space> to stop Card did not respond to voltage select! : -110 Regarding an overlay for the leds. Currently in the dtb the leds are defined as: leds { compatible = "gpio-leds"; led-0 { function = "status"; color = <0x01>; gpios = <0x14 0x02 0x0c 0x00>; linux,default-trigger = "heartbeat"; }; led-1 { function = "power"; color = <0x02>; gpios = <0x14 0x02 0x0d 0x00>; default-state = "on"; }; }; What would you propose? Overlays can add or change existing lines. They can not remove lines. My recommendation is to just leave them as they are. There is a option to add user defined overlays. Check out the /boot/boot.cmd: for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done There is a catch. If the user overlay messes up the dtb is restored to the state before even the kernel overlays have been added! I think I would like to prepare the overlay patch as a PR to the Armbian master.

@pixdrift Comparing the debug console of the first boot and of a failed startup would be a good place to start. Have you tested on a zero3 with the fast SD? I'm sorry I can not help with the zero2. I am going to test with my hard drive again. If you need to cool things down, I could send you some snow. We had our first snowfall here today, about 20cm.

@pixdrift, @Gunjan Gupta Yes, the output of the serial debug console would be very useful to see how far into the boot process the system got. The speed of the SD card might be the trigger for the problem you are seeing, but I doubt it is the source of the problem. The system boots from a fresh flash and probably runs quite cool until a second boot. I have had an issue with what I think is timing related. I was using a usb hard drive for a system disk and booting from spi flash. The usb disk was twice as fast (40MB/sec) as the SD (17Mb/sec) card. On the initial boot after flash Bluetooth worked properly. After a reboot Bluetooth never worked again (the /dev/bluetooth was not created). I have now put away the usb disk and am using an SD card. I have on occasion seen a failure of Bluetooth on the SD card but am not really checking for it. Another concern I have is that the dmesg log does not start until about 1.6 sec or more instead of 0. This is not right. There is also some problem with setting up pinctl being logged. I dislike testing on a system that I know has problems that could be affecting the testing I am trying to achieve.