Jump to content

spock

Members
  • Posts

    29
  • Joined

  • Last visited

Everything posted by spock

  1. Thanks Igor - I will switch to nightlies. (The PJR account is a temporary alter-ego!)
  2. Thanks - I just copied the dtb across from the newer image
  3. @Igor - thanks that now works with your fixed image! What manual fix did you need to do? It may be quicker than moving all my stuff across to a new image!
  4. I updated my Neo today - it was running mainline kernel and xenial ... after the update the thing would boot but the ethernet connection is not working - both LEDs are lit. I downloaded a fresh mainline image (the new xenial "5.25" one) and have the same issue. Any ideas before I take the thing to bits and solder a header on it ... ? (BTW, this system has been running very, very nicely for about 6 weeks before I stupidly did the update ...)
  5. As far as RPI goes, I will ask around to see what the future might bring (I know people who know) ... but given the ties between the rpi foundation guys and Broadcom, we can expect them to continue to use their silicon and also to stay with something very similar to what they have now. Since Broadcom were taken over by Avago the strategy has changed a bit - and I have seen that in their wifi products, for example. We expect to see the same in their TV products (of which the RPI silicon is an example) eventually. This might mean change for the RPI guys. I can ask around to see what has changed there as this is the technology area that I work in. What I do know is that the Broadcom guys have traditionally been much more expensive than competitors and that they have lost significant share of the TV set top box market to the emerging Chinese vendors. Perhaps the best idea is to state clearly that the RPIs won't be supported as the Raspbian distro can best cover the needs of the RPI crowd ? Its a simple and clear thing to state and should not be that controversial! BTW, commenting on the lack of availability of the RPI Zero - this is all down to the fact that they lose a pile of money each time they make a batch. and the backstory is that they only released it to get some PR and bash the clones.
  6. @zador.blood.stained - I tried the latest full build from this image and we have both wifi and DVFS working In my post #286, I has started with the build from Dec 26th and updated it - somehow that ended up broken. Probably something I did Now to make these little boards useful ...
  7. With the latest though, there seems to be no CPU governor as '/sys/devices/system/cpu/cpu0/cpufreq/' is missing. Without this, I am fearful of burning them so will need to work out what is broken.
  8. Not to fan the flames, but as I received my zero's today, I installed the 4.9 kernel nightly build, updated and the wifi "just works" Awesome.
  9. NAND is specific type of flash device. eMMC is a system made of a few chips / devices - and could contain any kind of storage that fits into the physical specifications allowed. If you can't work out the difference, spend some time reading up on SW and HW, and there come back and comment. As for your comments on Wifi, perhaps you could go and read around a little before complaining about what is done here. BTW, I have only been doing engineering 31 years, so I could be wrong. Oh, and if you want to call people "thick", perhaps instead you should get off that "product management" horse and do a proper job instead - I have fired more people with your attitude than I care to remember. @tkaiser, @zador.blood.stained, @hmartin - I'm so inflamed by this thread that I feel compelled to make a generous donation. Keep up the good work guys!
  10. Hi @ccapublic, I installed octoprint this afternoon on a Nanopi Neo with the mainline kernel and Xenial - you can reach the octoprint web interface by http://<ip>:5000 without any further configuration.
  11. *** UPDATED *** Update on bcmdhd driver issues when building the latest "default" from @igor's repo. By removing two patches, I can now get the X2 to boot from the SD card :-) The previous debug can be ignored. As expected, the new dhd driver does not work on the X2 - and I think I know how to fix those issues (see my bug in @igor's repo) but need to learn how to submit patches :-) Looking at the impact of @jerenej's patches to rf_pm, it looks like there is a deadlock of some kind if the dhd module is not loaded during system startup. By adding dhd to /etc/modules, the driver is loaded (and then fails as expected) but the system eventually initialises properly. I'm not proposing to investigate why this is the case - we just need to ensure that the dhd entry is there on systems that might have the BCM wifi devices. Now I will focus on fixing the rest of the config for this driver and working out how to provide patches to @igor :-)
  12. Yes, very strange. I'm a bit puzzled as we don't see the message from sunxi-mci.c to say that the driver has been loaded. I have the "standard" image from 22/9 running just fine - I'm only doing this work to check that the wifi patches you put together work the way that @igor has implemented them. Anyhow, I just had a quick look through the patches since the 22/9 release and can't see anything related except that the kernel flag "CONFIG_MMC_PARANOID_SD_INIT" flag was reset. I'm building again with MMC and MMC_SUNXI debug turned on and the paranoid flag set - but don't see anything much different. I checked for the u-boot patch - yes it is in the build - I guess I am not the only one with issues booting from SD cards... Perhaps @igor has some input ?
  13. @jernej, Here's the full log as seen at the serial console - apologies I don't know how to do the "collapsible quotes". I can see that the mmc host driver is not loading ... I expected to see lines like: [ 1.475212] [mmc]: SD/MMC/SDIO Host Controller Driver(v1.111 2015-4-13 15:24) Compiled in Sep 14 2016 at 20:28:08 [ 1.475262] [mmc]: get mmc0's sdc_power is null! [ 1.475304] [mmc]: get mmc1's sdc_power is null! [ 1.475318] [mmc]: get mmc1's 2xmode ok, val = 1 [ 1.475332] [mmc]: get mmc1's ddrmode ok, val = 1 [ 1.475376] [mmc]: get mmc2's sdc_power is null! [ 1.475390] [mmc]: get mmc2's 2xmode ok, val = 1 [ 1.475405] [mmc]: get mmc2's ddrmode ok, val = 1 [ 1.475424] [mmc]: MMC host used card: 0x7, boot card: 0x5, io_card 2 [ 1.476929] [mmc]: sdc0 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B [ 1.478093] [mmc]: sdc0 set ios: clk 0Hz bm PP pm UP vdd 3.3V width 1 timing LEGACY(SDR12) dt B [ 1.478927] [mmc]: sdc2 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B [ 1.479654] [mmc]: sdc0 power_supply is null [ 1.481363] [mmc]: sdc1 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B But I don't see this in the full log ...
  14. @Igor, @jerenej - Update on bcmdhd WOW patch ... I have built the latest kernel packages (as of this morning) from @igor's repository, and things are broken :-( First, the "try your luck" method of booting from SD is as bad as ever - the serial console just shows: On this test it took 9 tries before the kernel boots ... This looks like a lock-up in u-boot? Second issue - since the full set of patches on the driver, we now have a problem on the X2 - it never reaches the console login prompt. Here's the tail end of the log where presumably the power on of the wireless module is done. The boot gets as far as udevd starting, and then we see errors from the mmc code ... The bcmsdh_sdmmc error sequence repeats ad infinitum - and the system never gets to a console log-in prompt. Earlier in the log I can see that mmc0 (the sd card I'm booting from) and mmc2 (the internal emmc) are detected OK - so I'm assuming that mmc1 is where the BCM wifi is located. My guess at least is that a side-effect of the power-on errors is that access to the micro SD (which is MMC1 as far as uboot sees it) becomes inaccessible - and so the system will not boot. Any ideas on where to start debug on this ?
  15. @igor - agreed. I guess that @jernej's patches are applicable to Bananapro and Cubietruck as well? If so, then we just need to test them. If not, we could keep the ap6212 directory for them and soft link to the firmware files? BTW, you will see that I put some comments in your github and also raised an issue - I did not want you to miss the problem of the configuration file and firmware location.
  16. @jernej There was an odd entry in the udev rules - a definition of wlan0 with a MAC address that I don't recognise. I cleared the /etc/udev/rules.d/70-persistent-net.rules, and all is working well now. So one bug gone :-) As far as the folder goes, I'm not worried - I think that the current split of ap6210 and ap6212 won't be needed now there are your patches to the driver.
  17. @jernej & @igor We have progress and a bug or two to report I placed the ap6210 & ap6212 files and config.txt into /lib/firmware and did the "echo 123 thing". The firmware now loads :-) but I see that the interface was renamed to "wlan1" (at 77.830501) - which looks a little odd ? Anyhow, I amended /etc/network/interfaces to add the new wlan1 and brought up the interface - but wifi did not get connected. Then I noticed that int the "ap6210" firmware there were both nvram.txt and nvram_ap6210.txt. I replaced nvram_ap6210.txt with the nvram.txt and rebooted. Now it all works :-) but really it's broken as we need to sort out where all the config files go - and make sure we have the right nvram for the X2 in place. So why was it broken in the first place? Well, the path for the configuration is set in CONFIG_BCMDHD_NVRAM_PATH - this is set in lib/config/kernel/linux-sun8i-default.config to be "/lib/firmware/ap6212/nvram.txt" ... and that does not work for the X2. @igor - I see that this path was set in this commit: 28d4b14 on 12th May - and this is why it works on your M2 as it just happens to be the right directory, but it is not on the X2. It would make sense to do as @jernej suggests and do something like the following: Have a "/lib/firmware/dhd" directory (or use the brcm directory - but there could be conflicts with configuration, so a dhd directory might be better?) In there, place config.txt and the firmware from the original ap6210 and ap6212 directories. We also (for the X2 - could be different for other boards) need to have the original nvram.txt renamed to nvram_ap6210.txt [ UPDATE: removing the two wlan entries in the 70-persistent-net.rules udev file fixed this ... @igor / @jernej - Do you know why the interface is getting renamed? Could it be to do with hitting /proc/driver/wifi-pm/power ?] I would have a go at this, but I have not worked with this stuff for over 20 years and would need to learn git and how to use the patch tool (again) :-) Perhaps you would be quicker? If you want me to sort it, then tell me and I will put the work in. Now back to sorting out reboot reliability.
  18. @reddwarf - If you downloaded the standard firmware, this does not contain the new patch of the driver that @igor and @jernej have been working on ... I suspect that we are close to sorting this out, and then I guess that @igor will publish a new version...
  19. Update, I can load the dhd driver (after removing the bcmdhd.ko, replacing with dhd.ko and a little depmod -a), and now don't crash. The crash was caused by having the old bcmdhd driver load during boot. Once this was removed, no more crash on load of dhd.ko. Now that dhd loads, we end up with the driver trying to load the wrong firmware, so there is a configuration problem I guess ... Here's a snip of the dmesg output: As we can see, the driver picks up the chipped *A962 (or 43362) - but then proceeds to pick the wrong firmware. I have put the following in /lib/firmware/brcm/config.txt ... I guess I am missing some config files? (Remember I am using the latest normal download of the X2 firmware, and then hacking in the newly built dhd.ko on top of this.)
  20. @Igor, @jernej: I had a quick look at @Igor's latest patch and think it corresponds to @jernej's. So, I did a build (in a new ubuntu VM) and then copied dhd.ko across to the X2. I placed the config.txt into the /lib/firmware/brcm directory. I took the wlan0 interface down and removed the bcmdhd driver (rmmod) and loaded the new one ... and, er, ended with a kernel crash. From a first look at the dmsg just before the crash, I noticed that the firmware had not loaded so something is not right. Before I get into debugging that, was there anything else I should have done first?
  21. @jernej I will have a go at building this for X2. But could you tell me which version of the driver are you patching against? A link would be helpful as I will simply build the driver on the X2 itself - I don't have time to set up a build machine until later next week. Thanks!
  22. @jernej So to make this work, we need to: remove bcmdhd from /etc/modules ensure we have the right nvram file in place for the X2 (or M2+) do the echo 123 thing during network initialisation (I will work out where when I have read up on systemd - I'm so old I still find system V init a bit modern!) I will take a look at this and work out where to put things & report back. I'm currently looking at why the X2 does not shut down properly - and as @tkaiser pointed out, the likely culprit is a driver crash and I have bcmdhd firmly in my sights as the culprit.
  23. @scargill - Pete - have you done an "lsusb" to identify the dongle. If you do that I will happily help you sort it out. ... and thanks for your blog ... you are responsible for spiking my interest in all this stuff Jason
  24. @tkaiser: Thanks, I will report back. Looking at the logs, it does seem that something odd is going on with sdio, so you may well be right. BTW, have you enjoyed the new ch340 kernel panic with OSX 10.12 ? This was how my day started when I added your "suggested accessory" to my X2 this morning :-)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines