Re: [PATCH v6 09/17] mips: use fallback for random_get_entropy() instead of just c0 random

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jason,

> >  Unfortunately I'm a little stuck at the moment, especially as one of my
> > main MIPS machines (a 5Kc Malta system) died mid-May while operating.  It 
> > seems to be a faulty CPU core card and the base board may be fine, though 
> > I cannot know for sure as I only have one each and I don't have a logic 
> > analyser or at least a JTAG probe to peek at the system and see what's 
> > going on inside.
> > 
> >  If anyone knows a source of a replacement Malta, preferably with a 5Kc 
> > CoreLV CPU module or another 64-bit hard core card (a number of different 
> > ones have been made), then I'll appreciate if you let me know.  I feel 
> > rather depressed knowing that many if not most hit the scrapper already 
> > while they could still find a good use.  Somehow it is easier to get way 
> > more obsolete hardware from 1980/90s just because it was general purpose 
> > rather than niche.
> > 
> >  Otherwise I'll try to get back to this stuff later in the year with 
> > whatever I have that still runs, but don't hold your breath.  Sorry!
> 
> Just thought I'd poke you about this, on the off chance that you found
> some new hardware and feel like tinkering around with cycle counters
> again. Some old MIPS platforms were recently dropped, too, which makes
> me wonder whether there's some room for more simplification here.

 I have a replacement CPU module now, but it is not the same as the old 
one was and it has a built-in different system controller (a MIPS SOC-it 
IP implementation) rather than a discrete Galileo GT-64120A chip the 
original module had.

 And the system controller suffers from PCI handling issues, i.e. the 
YAMON firmware hangs in PCI enumeration if there are more than 2 buses 
present (my configuration used to have 3) and in Linux one of the option 
cards seems not to respond to MMIO accesses (a mapping error?), with 
exactly the same hardware configuration that worked just fine with the 
Galileo.  I had to pull some hardware to make the system boot at all.

 It's not clear to me yet if these are symptoms of hardware errata or bugs 
in the respective pieces of software, but I fear debugging fatal issues 
has to take precedence over optimisations for me, so I have to defer cycle 
counter tinkering yet more.

 NB the replacement CPU module is also 32-bit rather than 64-bit as the 
broken one was and therefore I'm still looking for a replacement 64-bit 
CPU module.  Malta CPU modules seem exceedingly scarce nowadays, it seems 
easier to track down a 30 years old MIPS R3000 DECstation machine, sigh...

  Maciej



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux