Hello again,
I saw the latest update when it was issued a few days ago, with these details being particularly important:
"PCBs are etched with acid, and when the tracks or pads are particularly close together (such as with BGA balls), not enough acid gets in to eat away the copper, and (in a very indirect way) the BGA pads end up being far larger than they should be. This, in turn, means that when the IC is put on the PCB and heated up, the BGA balls (which are made of solder) will spread out much farther, and potentially even spread so far that they contact each other and short out."
https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-a-...
From what it says, it rather sounds like same (or a similar) problem is being
encountered as the one which happened with the Ingenic JZ4775 boards:
"When the first 6 samples were done, only one was found to be working: for some reason the DDR3 BGA solder balls had spread and caused short circuits. One of the samples was still with the factory, and that too was found to have shorts. Mike has been extremely helpful, and this is the first time that he's been involved with BGA, where his uncle's factory has been the one that assembled the samples."
http://rhombus-tech.net/ingenic/jz4775/news/EOMA68-jz4775_XRay_Photos/
At that point in time, I don't remember any more news about resolving the matter, and with the campaign being finalised the priority was no longer to get these boards working. But perhaps one of these situations informs the other, or maybe they inform each other somehow.
Thanks in any case for keeping us updated!
Paul
On Mon, Dec 2, 2019 at 3:23 PM Paul Boddie paul@boddie.org.uk wrote:
Hello again,
I saw the latest update when it was issued a few days ago, with these details being particularly important:
"PCBs are etched with acid, and when the tracks or pads are particularly close together (such as with BGA balls), not enough acid gets in to eat away the copper, and (in a very indirect way) the BGA pads end up being far larger than they should be. This, in turn, means that when the IC is put on the PCB and heated up, the BGA balls (which are made of solder) will spread out much farther, and potentially even spread so far that they contact each other and short out."
https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-a-...
From what it says, it rather sounds like same (or a similar) problem is being encountered as the one which happened with the Ingenic JZ4775 boards:
yehyeh. except i didn't know about the PCBs not actually matching the gerber files, back then.
"When the first 6 samples were done, only one was found to be working: for some reason the DDR3 BGA solder balls had spread and caused short circuits. One of the samples was still with the factory, and that too was found to have shorts. Mike has been extremely helpful, and this is the first time that he's been involved with BGA, where his uncle's factory has been the one that assembled the samples."
http://rhombus-tech.net/ingenic/jz4775/news/EOMA68-jz4775_XRay_Photos/
At that point in time, I don't remember any more news about resolving the matter, and with the campaign being finalised the priority was no longer to get these boards working.
i did actually partly get them up and running, but i'd put a 24mhz XTAL on instead of 48mhz, and the SD/MMC wasn't having it. i tried fixing that in software (doubling the PLL frequencies for the SD/MMC) but couldn't get it up and running.
with it only being single-core 1ghz MIPS32 i dropped the investigation.
But perhaps one of these situations informs the
other, or maybe they inform each other somehow.
i'd forgotten about it, so thank you for the reminder.
Thanks in any case for keeping us updated!
no problem paul.
l.
i noticed the update too, right on que, was wondering how things where. :D Great that mikes helping. the project is fortunate to have someone like that.
noticed your ut demo vids about the motorbike to to e-bike upgrade kit. :) but when i searched that bike model on ebay, all i got seamed to be classic old bikes not the modem looking bike in the video.
Thanks again for efforts and the info :).
On Saturday, December 7, 2019, Alexander Ross maillist_arm-netbook@aross.me wrote:
i noticed the update too, right on que, was wondering how things where. :D Great that mikes helping. the project is fortunate to have someone like that.
yes, very.
noticed your ut demo vids about the motorbike to to e-bike upgrade kit. :) but when i searched that bike model on ebay, all i got seamed to be classic old bikes not the modem looking bike in the video.
look up "sur ron" on youtube, internet, and endless-sphere.
Thanks again for efforts and the info :).
:)
Hello,
Sorry, just warming this thread up with a few random observations...
On Monday 2. December 2019 20.05.55 Luke Kenneth Casson Leighton wrote:
On Mon, Dec 2, 2019 at 3:23 PM Paul Boddie paul@boddie.org.uk wrote:
https://www.crowdsupply.com/eoma68/micro-desktop/updates/measurements-and-%3... > a-hypothesis
From what it says, it rather sounds like same (or a similar) problem is being encountered as the one which happened with the Ingenic JZ4775 boards:
yehyeh. except i didn't know about the PCBs not actually matching the gerber files, back then.
OK, that would have been a bit awkward for troubleshooting, too.
[...]
i did actually partly get them up and running, but i'd put a 24mhz XTAL on instead of 48mhz, and the SD/MMC wasn't having it. i tried fixing that in software (doubling the PLL frequencies for the SD/MMC) but couldn't get it up and running.
Yes, I imagine that the external oscillator is supposed to be 48MHz, and there may well be a limit to how far you can get (and how well it will work) by just using the PLL multipliers to get you to the frequencies you want.
with it only being single-core 1ghz MIPS32 i dropped the investigation.
Interestingly, these SoCs all have other cores tucked away inside them, although you probably can't get away with regarding them as "proper" cores. For instance, on the JZ4780 (which is dual-core), but also the JZ4770, JZ4760 and most likely the JZ4775, there's a core called AUX in the VPU and another one called MCU in the programmable DMA peripheral, both of them being XBurst cores but without certain amenities. Typically, they lack full MMUs, cache, FPUs and other things, but they seem to have fast access to some cache-like memory (TCSM).
I imagine that with a bit more investigation, other cores will pop up, but it is interesting how they get a lot of mileage out of the same architecture instead of mixing and matching (like the ARC cores in Intel CPUs or the OpenRISC cores in Allwinner SoCs). I was also trying to find out a bit more about the dedicated video and "vector matrix arithmetic" blocks associated with the VPU functionality, and one has to wonder what is going on there as well.
Meanwhile, I wonder if you have heard from Mike lately or whether things are generally stalled with regard to the production issues. I guess that there will be a few weeks of holiday and disruption to take into account now, but I thought that maybe you'd caught up with him before the break.
Anyway, hope things are working out wherever you might be. (And that also goes for other readers of the list, of course!)
Paul
arm-netbook@lists.phcomp.co.uk
-
Alexander Ross -
Luke Kenneth Casson Leighton -
Paul Boddie