Jump to content

Orange Pi Lite - now available

Tido

By Tido
in Allwinner sunxi

 Share

Recommended Posts

jernej

jernej

Posted
Posted
I started doing what you've said, I got some part done, but now I'm a bit lost about platform files searching for the legacy sys_config.h

 

You should mark it as 386 platform, e.g. no special platform initialization. Also copy wifi power part from OPi2 dts.

martinayotte

martinayotte

Posted
Posted

Thanks for the clue !

Unfortunately, it was producing a module with 2 undefined symbols, extern_wifi_set_enable() and sdio_reinit().

Since it was originally set in the Legacy to use CONFIG_PLATFORM_ARM_SUN8I, I've look at CONFIG_PLATFORM_ARM_SUNxI instead, it is compile and load successfully, but no wlan0.

So, I think now it is because the DTS isn't set at all for SDIO, I will have to go back studying that and fixing it !

Not a trivial task finally ...

martinayotte

martinayotte

Posted
Posted

I've been looking at that Makefile the whole day (those Makefile are so ugly with tons of ifdef), and unfortunately if no platform is defined, I'm end up with "not build target", so a platform seems to be required.

Thank for the "wifi_pwrseq" hint, I will take a look a that tomorrow ...

martinayotte

martinayotte

Posted
Posted

I've added the "wifi_pwrseq" stuff, but "wlan0" doesn't show up.

I think it still related to the "platform" config in Makefile.

For now, I don't have much choice to throw the towel ... :-(

jernej

jernej

Posted
Posted

Why don't you just disable all platforms and when you get compile error, check how it was fixed in RTL8189ES sources. HAL part should be very similar.

martinayotte

martinayotte

Posted
Posted

I've tried without any platform, but the Makefile is choking by saying "No such file or directory"/"recipe for target 'modules' failed".

I've diff-ed Hans version and current one, I didn't figure out where is the problem. (I must admit that I'm not a Makefile expert)

I've ported all other changes in Hans version into current, it compile fine but only when a platform is defined.

jernej

jernej

Posted
Posted

Ok, I checked few things and this should work:

 

1. edit platform/platform_ops.c and remove lines from 34 to 39 so the function will just return 0.

2. deselect all platforms in Makefile

3. compile with:

make KSRC=/lib/modules/$(uname -r)/build ARCH=arm
1
martinayotte

martinayotte

Posted
Posted

Thanks a lot !

It is now compiled without any platform (I had to add CONFIG_LITTLE_ENDIAN in the EXTRA_CFLAGS)

The modprobe succeeded, but still no wlan0 ... :-(

Is there something else missing in the DTS apart from wifi_pwrseq ?

jernej

jernej

Posted
Posted

All seems good. How does your system behave? When I start board, I didn't even need to modprobe, because sdio interface has similar autoloading mechanism to USB. Maybe you can check if kernel even detected your wifi chip. This can be done over /sys interface, I'm just not sure how exactly. Maybe you can measure power pin with multimeter. Another attempt would be setting pin in u-boot just to be sure it's on...

martinayotte

martinayotte

Posted
Posted

I got the idea to try it out also on my previous build of 2 week ago, the Armbian_5.12_Orangepih3_Debian_jessie_4.6.0.raw, (the current one was Armbian_5.14_Orangepilite_Debian_jessie_4.6.2.raw), but without much success there too. On both, the 8189fs is never loaded (I have to do a modprobe to get it), and doing "dmesg | grep -i sdio" doesn't show anything while doing it with a Legacy build reveal several lines, samething with "mmc1" or "wifi".

 

On your side, which kind of board and kernel are you using ?

 

EDIT : wait a minute, the DTS doesn't have any "mmc1", I will add it and keep you posted ...

martinayotte

martinayotte

Posted
Posted

Got it for 4.6.0, it was the missing "mmc1" in the DTS :

[    5.586907] mmc1: new high speed SDIO card at address 0001

and :

[   12.613221] ######platform_wifi_power_on:    
[   13.583977] 29 81 03 CC 00 00 50 00 00 00 04 CC 0A 0C 00 00
[   13.589991] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
[   13.595831] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

But, unfortunately, for the 4.6.2, even if I get the same stuff above in dmesg, it still not loading the driver and make the "wlan0" appearing.

I will try to figure out, but at least, it is a BIG step toward !!! :)

 

Thanks, Jernej for all your help !!!

(and thanks to provide me the link from JFMoine for his patch, it can help even if I got it, and I've been in touch with Jef a month ago for other issues.)

jernej

jernej

Posted
Posted

You're welcome. I'm really interested what's left to be fixed...

 

/offtopic Do you know anything about the state of his display engine driver?

martinayotte

martinayotte

Posted
Posted

For the 4.6.2 left to be fixed, me too !

Hoping it is not some regression ...

Armbian 5.15 will be out soon, I will check that too, because in fact the main thing I'm aware between my 4.6.0 and 4.6.2 was that previous was generic for all H3 and newer is specific for H3-Lite.

 

For Jef's display engine ? I don't know ... Patches take sometime months before getting merged ...

I was in touch with him for other reason, I'm not using his display engine since all my boards are headless.

He is a nice friendly guy, so don't hesitate to contact him, he has done an update few days ago on his page : http://moinejf.free.fr/opi2/index.html

martinayotte

martinayotte

Posted
Posted

For the 4.6.2 dmesg, you can see that it has the SDIO transaction shown, but wlan0 doesn't appear.

We can see in the 4.6.0 a line with "######platform_wifi_power_on:", but this line isn't present in the 4.6.2.

I will continue investigate today, but I have some other tasks too...

 

EDIT : About the "######platform_wifi_power_on:", it seems that it was some kind of randomness.

Today, I've rebooted, and got it printed, and the "wlan0" appeared and worked.

So, maybe yesterday, there was a ghost around ... ;-)

Issue closed !

lite-462-dmesg.zip

lite-460-dmesg.zip

martinayotte

martinayotte

Posted
Posted

Yes, it is autoloaded, but yesterday too.

The difference with yesterday is that "######platform_wifi_power_on:" wasn't appearing.

I will do reboot 10 times to confirm robustness ...

martinayotte

martinayotte

Posted
Posted

Yes ! Thanks a lot, @zador !

I'm seeing in the history that it was added a day after I built my Armbian_5.12_Orangepih3_Debian_jessie_4.6.0.raw.

But even if were there, since the lsmod wouldn't report 8189fs presence, it wouldn't have created the 8189fs.conf file ... ;-)

lanefu

lanefu

Posted
Posted

Ok, for the THS, adding back the 1008000 entry is a kind of ugly workaround : during boot FREQ switch is crashing, but at least it continue to boot completely.

I presume that real fix would not be adding it, but change the value at the origin of that 1008000, which is probably in u-boot, but this is outside of my knowledge.

@Tkaiser, the patches you mentioned, and even Megi's change doesn't seem to be part of the Armbian build process. Maybe patches are not applied for some reason.

 

@jernej, I started doing what you've said, I got some part done, but now I'm a bit lost about platform files searching for the legacy sys_config.h

 

 

I did some poking with my Opi One because I was having the same problem..   u-boot does have a default for 1008000 for the h3 devices.. most of the DTS files end up just including the Orange Pi PC DTS file

 

I made a dinky u-boot patch and it works now, but there's other thermal stuff missing.. i get fun errors and only 1 cpu core in /proc/cpuinfo

 

Naturally--I barely know what i'm doing :)

diff --git a/configs/orangepi_one_defconfig b/configs/orangepi_one_defconfig
index de6e9c8..4dd59a8 100644
--- a/configs/orangepi_one_defconfig
+++ b/configs/orangepi_one_defconfig
@@ -23,3 +23,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_USB_EHCI_HCD=y
+##lj Clock freq defaults are 10080000 inherited from OPI PC default, kernel DTS doesn't have that speed, trying valid ones from kernel dts
+CONFIG_SYS_CLK_FREQ=1200000000
+#CONFIG_SYS_CLK_FREQ=816000000
+#CLK_DIVIDER_ALLOW_ZERO=y  ## didn't make my error go away
martinayotte

martinayotte

Posted
Posted

For the 1 core in /proc/cpuinfo, I've just figured out now (I didn't noticed before) that all my newer kernels (4.6.2) on orangepilite/orangepipcplus/orangepiplus2e have only 1 core while older ones 4.6.0+ on orangpipc/orangepione have 4 core. So, maybe a bug introduced recently somehow ...

 

EDIT : Oh ! looking at the root DTS, there wasn't any of this clock stuff defined in 4.6.0+, and in the 4.6.2 it is defined but only for cpu0. So, I wonder if only duplicating it for cpu1/cpu2/cpu3 will do the job.

1
jernej

jernej

Posted
Posted

For the 1 core in /proc/cpuinfo, I've just figured out now (I didn't noticed before) that all my newer kernels (4.6.2) on orangepilite/orangepipcplus/orangepiplus2e have only 1 core while older ones 4.6.0+ on orangpipc/orangepione have 4 core. So, maybe a bug introduced recently somehow ...

 

EDIT : Oh ! looking at the root DTS, there wasn't any of this clock stuff defined in 4.6.0+, and in the 4.6.2 it is defined but only for cpu0. So, I wonder if only duplicating it for cpu1/cpu2/cpu3 will do the job.

 

Not sure if this would help. On H3 U-Boot is actually responsible for bringing up all cores through PSCI interface.

1
martinayotte

martinayotte

Posted
Posted

Do you mean that it is some kind of regression bug introduced recently in u-boot ?

 

EDIT : searching quickly, I've only find #define CONFIG_ARMV7_PSCI_NR_CPUS 4 in u-boot/v2016.05/u-boot.cfg.

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept