R16 - Porting of BPI M2 Magic

[hitech95]

Hi guys I'm working to port the bpi-m2m to armbian.
Right now i'm having a strange behaviour. I'm new to armbian development.
I only use it for a npi-neo back in time.

Anyway, my problem is quite simple.
I have a working uboot and a working kernel (I think). the decive tree is in mainline. Looking the schematic, the DTS looks it is ok.

I crated the armbian configuration, buit an image and it started "working" (you will se why is inside teh quote mark later) .
Somehow i got a shell via UART. I configured the wireless AP and I got a working image. (Only BT was not working, no idea why).

Due to the BT problem I decided to reboot the SBC and the problem I got before showed up again, but this time worse then before.
After the kernel boot (which i'm not able to see, how can enable the serial output during kernel boot?) the init/systemd start loading all the deamons and after a while instead of having a console i got nothing.
Then after a fiew seconds AXP PMIC shutdown the board (for no reasons, i don't have the kernel log to see what is going on).

I would like to know if someone had this type of problem. If I use another rootfs (same uboot and same kernel) like one made on yocto all works fine.

My mayor questions is, how can i enable the serial logging? This device doesn't have a display, it couldd be headless and it don't have a ethernet connection so i can access it only by serial.

For reference this is my bootlog:
https://pastebin.com/0gEr8jcGIf
I change the bootarg and I add the "init" parameter to the kernel and I specify the path for the shell I get a working image:
https://pastebin.com/qFDQ4JGW
 

Regards, Nicolò

[zador.blood.stained]

2 hours ago, hitech95 said:

Then after a fiew seconds AXP PMIC shutdown the board (for no reasons, i don't have the kernel log to see what is going on).

I would like to know if someone had this type of problem.

Yes, when PMIC on an A64 based device shut down after cpufrequtils.service was started - CPU frequency and voltage caused a power spike and undervoltage (i.e. due to microUSB powering) so PMIC protected device from undervoltage by killing the power.

 

2 hours ago, hitech95 said:

My mayor questions is, how can i enable the serial logging?

 Adjust kernel command line in boot.cmd/boot.scr to not include "console=tty1" in the kernel command line.

[hitech95]

1 hour ago, zador.blood.stained said:

Yes, when PMIC on an A64 based device shut down after cpufrequtils.service was started - CPU frequency and voltage caused a power spike and undervoltage (i.e. due to microUSB powering) so PMIC protected device from undervoltage by killing the power.

 

 Adjust kernel command line in boot.cmd/boot.scr to not include "console=tty1" in the kernel command line.

Thanks I'll try. According to the schematic the UART is 0 so tty0 should be right.

[zador.blood.stained]

1 hour ago, hitech95 said:

According to the schematic the UART is 0 so tty0 should be right.

UART 0 is ttyS0 and it is already defined as a serial console in the DT: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts?h=linux-4.14.y#n60

[hitech95]

Ok now it boot up each time. I tried to install on MMC and it works fine.
For now only BT seems that it is not working. on hciattach i get a timeout.

Not sure why, maybe i need to add something to the DTs to enable it? I have seen that BT have a lot of reset/enable/wake lines but I don't see where I can map those.

[zador.blood.stained]

2 hours ago, hitech95 said:

Not sure why, maybe i need to add something to the DTs to enable it? I have seen that BT have a lot of reset/enable/wake lines but I don't see where I can map those.

There is no kernel support for these types of BT chips (with reset/enable GPIOs), so these GPIOs are usually handled from userspace before running hciattach, i.e. like here

 

[hitech95]

So the reset is not handled by the driver? So i just need to disable the resets?
What is this line?

devmem2 0x1f00060 b 1

 

[TonyMac32]

On tinker board we would up using a script to toggle the resets/etc, once the reset was done then hci attach was performed.  I would recommend toggling the resets because you may want to disable/re-enable, and that has to be done for each cycle.

[zador.blood.stained]

5 minutes ago, hitech95 said:

What is this line?

devmem2 0x1f00060 b 1

This enables the "slow clock" (losc) output, though not all BT modules need this clock signal. Reference - Allwinner H5 user manual, section 4.8.3.16 (page 190).

Though in a more or less recent kernel this can be enabled with a DT property.

[hitech95]

4 minutes ago, TonyMac32 said:

On tinker board we would up using a script to toggle the resets/etc, once the reset was done then hci attach was performed.  I would recommend toggling the resets because you may want to disable/re-enable, and that has to be done for each cycle.

Ok so I just need to set the reset pin low and start with the hciattach.

1 minute ago, zador.blood.stained said:

This enables the "slow clock" (losc) output, though not all BT modules need this clock signal. Reference - Allwinner H5 user manual, section 4.8.3.16 (page 190).

Though in a more or less recent kernel this can be enabled with a DT property.

I have seen that this BT module receive the 32KHz clock from the clock output pin. (X32KFOUT) but i'm not sure if this clock is always present on R16/A33. right now I don't have a scope to test it out.
I have seen that someone use the rfkill gpio module to do that!

[TonyMac32]

https://github.com/armbian/build/blob/master/packages/bsp/rockchip/start_bt.sh

 

Is the Realtek 8723bs way to do it on the tinker board.  You might have to worry about the clock as Zador said, and if you look at this, typically driving reset low is the "in reset" state, letting it go high is active.  

[hitech95]

47 minutes ago, zador.blood.stained said:

This enables the "slow clock" (losc) output, though not all BT modules need this clock signal. Reference - Allwinner H5 user manual, section 4.8.3.16 (page 190).

Though in a more or less recent kernel this can be enabled with a DT property.

 

But according to the datasheet this disable something not enabling (if I git it right that command write a 0x01 as a byte to that register).

Another question: how is mapped the gpio export with the ports? (Does you have a reference to check) for example on dts <1 10> is  PORTA 10 but on export I have no idea on how the count is done. Is it divided by bank?
I have seen that my SoC have gpiochip0 and gpiochip352.

[zador.blood.stained]

20 minutes ago, hitech95 said:

But according to the datasheet this disable something not enabling (if I git it right that command write a 0x01 as a byte to that register).

The datasheet may be incorrect. This output should be disabled by default and writing 1 should enable it.

 

21 minutes ago, hitech95 said:

Another question: how is mapped the gpio export with the ports? (Does you have a reference to check) for example on dts <1 10> is  PORTA 10 but on export I have no idea on how the count is done. Is it divided by bank?

https://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel

 

Also <1 10> is PB10, PA10 would be <0 10>

 

[hitech95]

21 minutes ago, zador.blood.stained said:

The datasheet may be incorrect. This output should be disabled by default and writing 1 should enable it.

 

Uhm... this is not new to me. I'm working on my own SBC and i have seen lot's of errors.
Now I check on A33 Datasheet to see if that register is present.

Another question how did you get that base address? 0x60 is the register but that 0x1f00000?

 

21 minutes ago, zador.blood.stained said:

https://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel

 

Also <1 10> is PB10, PA10 would be <0 10>

 

Yup, my typo. I have found that page on the wiki. No idea why I don't have seen that before! (sorry for the time loss)

[zador.blood.stained]

10 minutes ago, hitech95 said:

Another question how did you get that base address? 0x60 is the register but that 0x1f00000?

This is the base address of the RTC controller, it is present in the overall memory map and at the beginning of the RTC controller description.

[hitech95]

2 hours ago, zador.blood.stained said:

This is the base address of the RTC controller, it is present in the overall memory map and at the beginning of the RTC controller description.

According to the datasheet of R16/A33 it should be the same address but I can't get the clock output working.
(See page 136 and 143 of R16 User manual )

root@bananapim2m:~# devmem2 0x1f00060 b 1
/dev/mem opened.
Memory mapped at address 0xb6fd8000.
Illegal data type '▒'.
root@bananapim2m:~#

At this point i have no idea on how i could test this out... if someone have a brilliant idea

It maybe that I'm missing this (so the clock is not set properly)? rfkill-gpio

[zador.blood.stained]

1 hour ago, hitech95 said:

It maybe that I'm missing this (so the clock is not set properly)? rfkill-gpio

This does not work, rfkill-gpio is not DT aware and it does not support any advanced properties like clocks or resets.

This commit is based on an old attempt to push this functionality to rfkill-gpio, but it was rejected.

[TonyMac32]

5 hours ago, zador.blood.stained said:

This commit is based on an old attempt to push this functionality to rfkill-gpio

 

Rockchip uses something like this in their BSP kernel, but from my experience it is a bit buggy and looked like a lot of work.  It's probably not a path worth going down.

[hitech95]

On Sunxi IRC they told me that that clock gate is handled by the kernel. So a module is needed.
They told me to watch linux serdev and associated stuff.

Any idea? Does someone tried this?

[zador.blood.stained]

Serdev is a right approach to handle this, but it may take several years to gain support for all necessary features (clocks, resets, regulators).

[hitech95]

1 hour ago, zador.blood.stained said:

Serdev is a right approach to handle this, but it may take several years to gain support for all necessary features (clocks, resets, regulators).

Why years? The driver to hook into hci should already be in mainline (the same used by RPI)

[zador.blood.stained]

2 hours ago, hitech95 said:

Why years?

Pessimistic/realistic expectations based on the status or timeline of some other kernel features (i.e. MLC NAND, requests API, sunxi DE2 driver / H3 DVFS and THS, ...)

 

2 hours ago, hitech95 said:

The driver to hook into hci should already be in mainline (the same used by RPI)

I see things like this and this, and as I understand it, you need to have support for such devices without any userspace hacks (i.e. loading firmware) in order to add it to the kernel.

And generic serdev bindings don't support any resets/clocks/regulators.

[TonyMac32]

I was re-reading this, did you check to see if you can enable the clock in the device tree? Zador mentioned that early on, but I only saw the userspace memory stuff going on.  I don't have any R16/33's anywhere to play with them, unfortunately.

[hitech95]

1 hour ago, TonyMac32 said:

I was re-reading this, did you check to see if you can enable the clock in the device tree? Zador mentioned that early on, but I only saw the userspace memory stuff going on.  I don't have any R16/33's anywhere to play with them, unfortunately. 

I tied with this: https://pastebin.com/hXy19ujx but without lucky. I'm tring to control that clk gate that but is managed by the kernel.

But today randomly that memory set worked and i got the clock out.

But i'm still having the timeout problem with BT.