rygD
Nihilistic Mystic
So the troublesome material was a Grammar Nazi joke? I am just trying to figure out what offends people.
quickcharge functionality (like from qualcomm)
So the troublesome material was a Grammar Nazi joke? I am just trying to figure out what offends people.
Welcome to the forum!Hi, I've been lurking for quite some time, your post got me curious enough to register!
Actually I was, yet I had managed to completely forget about that one! It has also been ported to a newer u-boot by rcn:I assume you are aware that igepv5 works with LPAE and 4GB
Via kernel parameters instead of DT... not very pretty, but hey if it works...mem=2032M@0x80000000 mem=2048M@0x300000000
No, I'm pretty sure second cpu goes straight from ROM to linux. My first guess would be that the 16M@0xff000000 is intended for use by the multimedia firmware running on various subsystems. Or maybe it just gets cargo-culted around with the original reason lost in time ;-)And I think there's the second cpu startup loop and whatever other boot rom stuff is at the 2032-2048
All DDR3 signals have dedicated pins, no pinmux. There's a bit of I/O config for them, but the control signals (cas, ras, reset, we, cs0, cs1, ck0, cke1, odt0, odt1) are all grouped together and use the same settings (in byte at 0x4a002e37).Also n-tuple-check the pin muxing for cke1 and ncs1..
I see absolutely nothing noteworthy in it with regard to memory setup. They configure 2 ranks in the geometry, enable impedance calibration for both of them, make some unnecessary changes to LISA section mapping, and inform the kernel. I guess I should just have faith and configure it. I got a bit side-tracked by trying to understand the phy init better, trying to get the u-boot equivalent of earlycon working (sigh), etc.
Oh, fun fact: while exploring the ram init code I realized that u-boot-2016.11 on omap5/dra7 entirely neglects to enable ram-side impedance calibration! Whoops I'm referring to zq_config bits 30-31 (for rank 0-1), which must be set to make EMIF send commands to the RAM chips to make them calibrate their drivers and ODT. Maybe it accidently got restructured out at some point, haven't checked yet.
No, I'm pretty sure second cpu goes straight from ROM to linux. My first guess would be that the 16M@0xff000000 is intended for use by the multimedia firmware running on various subsystems. Or maybe it just gets cargo-culted around with the original reason lost in time ;-)
I would not recommend trying to make a modern linux system free of DRM (the Direct Rendering Manager), except for displayless systems of course.I hope she's open-source and DRM free.
Well @sm0kew0n comment would make more sense if Wally didn't delete the prior post.I would not recommend trying to make a modern linux system free of DRM (the Direct Rendering Manager), except for displayless systems of course.
I would not recommend trying to make a modern linux system free of DRM (the Direct Rendering Manager), except for displayless systems of course.
Nope.
your work would merit it's own blog in the Pyra OS discussions area
I've been trying to Debian Stretch command line only on a server and it's driving me nuts. The install works fine but GRUB won't boot from the hardware RAID unless I include the desktop environment for which Stretch overrides and installs XFCE (and components) even if deselected. Gotta love Debian testing releases. I'll have to drop back to Jessie for now I guess. Yes - topic strayed.