Jump to content

spock

Members
  • Posts

    29
  • Joined

  • Last visited

Recent Profile Visitors

1732 profile views
  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 ?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines