<DocScrutinizer05>
Pali: >> So the RAM size is solved for the kernel as soon as we have fixed it for U-Boot (which also reports only 512 MByte RAM).<<
<paulk-aldrin>
so you can have 512mb per bank on the omap3 sdrc?
<DocScrutinizer05>
yes
<paulk-aldrin>
nice
<DocScrutinizer05>
and we do
<paulk-aldrin>
I'm fighting with it myself this very moment…
<DocScrutinizer05>
ooh?
<paulk-aldrin>
well, not on neo900
<DocScrutinizer05>
please elaborate!
<paulk-aldrin>
I'm adding upstream u-boot support for the lg optimus black
<DocScrutinizer05>
aaah ok
<DocScrutinizer05>
CPU?
<paulk-aldrin>
omap3630
<DocScrutinizer05>
resp SoC?
<DocScrutinizer05>
hah! :-D
<DocScrutinizer05>
and it has 1GB RAM?
<paulk-aldrin>
so 1-1 match with the dm3730 as far as I could see
<DocScrutinizer05>
yes
<DocScrutinizer05>
at least that's the common assumption
<paulk-aldrin>
well no, only 512, my problem is not the same as yours, I'm just fighting with the sdrc in general
<DocScrutinizer05>
aah k
<paulk-aldrin>
because I get random segfault and sigill
<DocScrutinizer05>
:-S
<paulk-aldrin>
and the kernel changes the clock about 50 times per second
<DocScrutinizer05>
duh
<paulk-aldrin>
clock: changing CORE DPLL rate from 200000000 to 400000000 back and forth
<DocScrutinizer05>
that's weird
<paulk-aldrin>
yeah
<DocScrutinizer05>
Pali: freemangordon: I seem to recall some of you guys said ROMBOOT or xLoader already detects amount of RAM and reports it to next in bootloader chain? is that correct?
<paulk-aldrin>
at least, it's likely that wrong/bad dram config ends up in random segfault/illegal instructions, right?
<DocScrutinizer05>
paulk-aldrin: quite possible
<paulk-aldrin>
DocScrutinizer05, oh another thing, is the neo900 display is parallel (DPI) or serial (DSI/MIPI)
<paulk-aldrin>
s/is parallel/parallel/
<DocScrutinizer05>
paulk-aldrin: btw Nikolaus tracked down xLoader locking-up to problems related to NAND detection
<DocScrutinizer05>
display is MIPI 3lane + clk serial differential (8 lines, 4 pairs)
<paulk-aldrin>
huh, I thought there were only 3 lanes total (including clock)
<wpwrak>
DocScrutinizer05: your approach of asking me if i can quickly help with something i have never looked at and that someone else is just about to solve seems to work - it encourages them to be that critical minute faster :)
<DocScrutinizer05>
I suppose we need a u-boot/include/configs/omap3_beagle__1GB-upgrade.h
<DocScrutinizer05>
derived from u-boot/include/configs/omap3_beagle.h
<enyc>
=)
* enyc
wonders if neo900 is expecting another proto board =)
<DocScrutinizer05>
umm this has 37 #define CONFIG_OMAP3430 1 /* which is in a 3430 */
<DocScrutinizer05>
enyc: yes, we hope we eventually get a proto_V2 but first we need to finalize the schematics for that. I guess I need to ask Nik when he will find the time to fix the interim and TBD stuff in the version we got
<bencoh>
cscope can help as well by the way
<DocScrutinizer05>
cscope?
<bencoh>
(regarding the "how to search for info in source code"
<DocScrutinizer05>
is this a binary? a website?
<enyc>
DocScrutinizer05: wheres the best place to see all those bugs and known outstandings listed? I'm interested to see/understand this in more detail, though not sure I'm in position to *help* but thats' another matter.
<DocScrutinizer05>
I'm used to stuff like eclipse with massive proprietary extensions
<DocScrutinizer05>
nasty
<bencoh>
hmm right, is the public bug tracker uptodate ?
<DocScrutinizer05>
which bugtracker?
<bencoh>
neo900/gdc
<DocScrutinizer05>
should, yes
<DocScrutinizer05>
more or less
<DocScrutinizer05>
not everything that gets or needs to get done is tracked on BT
<enyc>
DocScrutinizer05: ineded, if somebody god is worknig on something itonly adds overhead to use that? right?
<DocScrutinizer05>
well, some stuff simply is no bug, by whatever definition of "bug"
<enyc>
just a tbd hrrm
<DocScrutinizer05>
we could use some scheduling&planning tool
<enyc>
would it help?
<enyc>
are we in 'losing track of whats going on, ond ef project dragging on and on' symptomn ?
<DocScrutinizer05>
I think it would. I for sure tend to forget stuff
<enyc>
ive heard big rcomplex projects are easy to lose impetus, hard to ''complete''
<DocScrutinizer05>
yes, that's indeed a task that right now is only done in my wetware and could use some improvement
<DocScrutinizer05>
particularly since I'm not performing up to own expectations since 2 months, due to helth issues
<DocScrutinizer05>
health
<enyc>
any clue of suitable tools for the job that aren't too 'onerous' ?
<DocScrutinizer05>
not at all
<enyc>
DocScrutinizer05: hrrm know what you mean. I've learnt to change expectations, eventually!
<DocScrutinizer05>
I guess google will provide something for that too ;-)
<enyc>
If you give me an idea of the key point and what sort of things you want tracked etc etc (i.e. describe clearly what you think the problem is trying to solve) I can ask in my various circles and get some answers with any luck
<DocScrutinizer05>
we need to define and track tasks/workpackages, like task1::("source samples of 1GB PoP chips"->"test those 1GB chips") <depends on> task2::("get 3 BB-xM for rework" -> "find a company with rework tools" -> "send 3 BB-xM plus 10 PoP chips to rework company" -> "test the reworked boards <merges with task1 here>")
<DocScrutinizer05>
there are like 50 to 100 of those tasks we know of right now
<DocScrutinizer05>
and admittedly on some of them I drop the loose ends
<DocScrutinizer05>
iow I miss to track and follow up on them in a close and consistent way, sometimes
<DocScrutinizer05>
sounds pretty fuzzy und not quite clear
<DocScrutinizer05>
and*
<bencoh>
dont we have "stereo output" ?
<DocScrutinizer05>
of course. Unless we got a mono source, like voice call
<DocScrutinizer05>
but it's really amazing how most devels simply resign and revert to try&error when it comes to setup and adjustment of *analog* mixers
<DocScrutinizer05>
only a few muxes, attenuators and adders (plus an occasional amp incl possible inversion of signal) but it seems completely obscure to the average sw-devel
<DocScrutinizer05>
often even the ALSA soundcard mangles controls and doesn't export some of them at all
<DocScrutinizer05>
Pali: the alsa kernel module provides /dev/snd/*. The .asoundrc (or other config like /etc/asound.conf) file like ^^^ creates a layer in the audio stack the alsalib creates for each audio app/process in user land
<DocScrutinizer05>
when a system runs on PukeAudio then the /dev/snd/* devices are exclusively opened by pulseaudio-daemon and libalsa will fail to open `` pcm.real { type hw card 0 }´´
<DocScrutinizer05>
linasound?
<DocScrutinizer05>
lib*
<DocScrutinizer05>
at least that's how _I_ understood ALSA (and the little of PA I wanna know) so far
<DocScrutinizer05>
Pali: http://privatepaste.com/2e4f8a6ef9 the part without -c0 is what PA emulates for ALSA userland compatibility. -c0 is what the codec+mixer really provides
<DocScrutinizer05>
compare pcm.real { type hw ***card 0*** }
<DocScrutinizer05>
the rest (= adjusting all the -c0 alsa controls) is a matter of deciding what signal you want to route where to
<DocScrutinizer05>
you got exactly one stereo set of ADC and one stereo set of DAC (the second one on block-B is not connected)
<DocScrutinizer05>
so for ALSA it's quite "simple". What gives (at least me) headache is how to tell PolypAudio to do the correct mixer control setup
<DocScrutinizer05>
I've never seen anything like amixer for PA
<DocScrutinizer05>
plugin:hooks can even remember value of controls and restore them to their old value when the app closes the audio device. And I designed a lib (alternative for # Library file (default libasound.so) ) that allows to call arbitrary executable on audio-device open() and on close()
<DocScrutinizer05>
so you could implement more complex stuff like priority handling which is lacking on "standard" alsa hooks type ctl_elems - for e.g. a rimgtone and/or voicecall can override mp3-playback setting, but mp3-playback cannot imterupt/override voice call
<DocScrutinizer05>
you'd use ^^^ with playback device (=pcm) of name "ringerpcm"
<DocScrutinizer05>
e.g. aplay -D ringerpcm somesound.wav
paulk-aldrin has quit [Quit: Quitte]
<DocScrutinizer05>
hook_args {
<DocScrutinizer05>
open "date;sleep 5;date"
<DocScrutinizer05>
close "mdbus -s ACI-PFaudio-arbiter free 'dev=2ChPCM_sounder,policy-key=dialer-ringtone'"
<DocScrutinizer05>
}
<DocScrutinizer05>
is what gets executed at start and at end of playback
<DocScrutinizer05>
when open returns error, the app tring to open the audio device throws error
<DocScrutinizer05>
trying*
<DocScrutinizer05>
i.e. in above example when "date" would return !=0, the aplay command would tell sth about "error on opening audio playback device"
<DocScrutinizer05>
of course "date" as command makes little sense. You probably want to call some command that manages resources and does complex mixer setup, maybe starts vibrator, etc
<DocScrutinizer05>
ou see the idea in the "close" section above, where mdbus (~= dbus-send) tells a dbus listener daemon to free a audio resource so other apps may continue using it. That process also could unpause (or even kill -SIGCONT) an arbitrary mp3-player process that happens to want playback music via the 2Ch-sounder (= stereo speakers)
<DocScrutinizer05>
for swwitching between e.g. wired headphone and stereo-speakers, this concept would use parallel output to both audio sinks, even when no headphone attached when mp3player starts playback. On plugging in headphone some daemon detecting that would send a message to the dbus listener daemon which in turn levels down (mutes) softvol for speakers and levels up (unmutes) softvol for headphone
<DocScrutinizer05>
this concept should even work for bluetooth headsets that were already paired and trusted when the audio stack gets initialized (aka audioplayback starts). Powering up BT and the headset would get handled equivalent to wired headset plugin
<DocScrutinizer05>
the concept fails for **pairing** a new never-before-seen BT device after audio playback started. I tthink this is a feature and not a bug
che12 has joined #neo900
<DocScrutinizer05>
I guess this concept could even almost completely emulate what we got on maemo now, particularly by sending arbitrary dbus signals/messages on asound-open()/close() of arbitrary abstract audio devices user defined in .asoundrc
che12 has quit [Ping timeout: 256 seconds]
ashneo76 has joined #neo900
<DocScrutinizer05>
I just don't see how every PA-based audio app would be able to open their own ALSA audio device
<DocScrutinizer05>
unless maybe by LD_PRELOAD to replace the PA stuff by some adapter that diverts the pa-open() to a asound-open() and does same for *read() *write() *close() etc
<DocScrutinizer05>
haven't looked into that to evaluate if it's even feasible
<DocScrutinizer05>
Pali: the idea about all this being: replace that /usr/share/policy/etc/rx51/pulse/xpolicy.conf nonsense like `` [stream]; property = application.process.arg0@equals:"/usr/bin/chessui"; group = game´´ by simply chessui using ALSA device "game" for output
che11 has quit [Remote host closed the connection]
fling has quit [Ping timeout: 250 seconds]
phre4k has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
even those fubar programs that have a hardcoded "default:0" ALSA audio device can get handled easily by a pcm.!default{...} audio device definition in .asoundrc and starting the app with an env var, like `ALSAOUTDEV=game fubar-app´
<DocScrutinizer05>
likewise you can create per-app softvol volume controls by simply using argv[0] in the global .asoundrc to name the softvol control
<DocScrutinizer05>
nice property of those softvol controls: they are persistent in mixer apps, they don't vanish as soon as playback of the sound finished. I wouldn't know how to adjust for example the touchscreen-feedback-click volume in PA since the volume slider probably not even renders in the time the click plays
<DocScrutinizer05>
and nobody has a clue how to properly install and particularly uninstall the audio setting stuff of a program package, since... /usr/share/policy/etc/rx51/pulse/xpolicy.conf is *one* file
<MonkeyofDoom>
mm
sparetire has joined #neo900
<DocScrutinizer05>
with above concept the audio config for a particular program is comprised within the program package in a natrual way
nox- has joined #neo900
* DocScrutinizer05
wonders how PA (or OHM) even gets to know about a new process just started, so a rule like application.process.arg0@equals:"/usr/bin/chessui" can get evaluated
<Wizzup>
presumably they know as soon as libpulse makes a connection
<Wizzup>
which is also when pulse starts if it is not already running
<DocScrutinizer05>
makes sense
<Pali>
every pulse client set application name property
<Pali>
and pulse server know all client properties
<kerio>
much simpler
<Pali>
there is also pulse role property (which PA devs thinks every PA client *must* set and correctly)
<Pali>
DocScrutinizer05: only privileged nokia apps can do something with audio :D (and nokia privileged apps are already defined in xpolicy.conf)
<DocScrutinizer05>
yeah, obviously just another reinventing-the-wheel done in PA
<Pali>
other applications are of course not priviveged...
<DocScrutinizer05>
just using the appropriate audio device would be too obvious and simple
<DocScrutinizer05>
and it wouldn't allow to configure audio properties of all apps on sstem in just one file
<DocScrutinizer05>
system*
<DocScrutinizer05>
remember the FMRX problem where all apps didn't work until Nokia provided a [stream] or [group] or routing or whatever to make audio work?
<DocScrutinizer05>
all FM radio apps that is
<Pali>
I do not remember :-) and I'm happy for it
<DocScrutinizer05>
hehe yeah
<DocScrutinizer05>
I also tried to forget so I can't recall the details
<DocScrutinizer05>
honestly the first thing to get fixed in maemo is that audio mess
<DocScrutinizer05>
I don't think there's anything else similarly fubar in maemo5
<Pali>
right, inventing new stack orientated virtual machine with own new language (DRES) and using even more funny logic programming language (prolog)...
<DocScrutinizer05>
some more or less random acronym for basically the hookslib I designed and the few concept details around it
<DocScrutinizer05>
lib "ALSAso/src/testhook.so" --> should correctly get named libAlsaACI.so
<DocScrutinizer05>
think of it maybe as Alsa Command Invocation lib. Though I made that up right now. I forgot what it means
<DocScrutinizer05>
the core of all this being to invoke a system() call on ALSA init() open() and close() anyway
<DocScrutinizer05>
and the configuration for all this is inside .asoundrc audio device definition
<DocScrutinizer05>
without breaking syntax or compatibility
<DocScrutinizer05>
IOW it's a simple extension to ALSA which doesn't need any patches to the "core" ALSA system
<DocScrutinizer05>
ou just need libAlsaACI.so and you're ready to define e.g. a pcm.ringer{...} audo device that for example also triggers the vibrator
<DocScrutinizer05>
an arbitrary dialer can use ringer audiodevice and whenever it plays a ringtone, the vibrator kicks in as well, and - depending on what else you configure - mediaplayers are stopped etc
<bencoh>
this doesnt sound alsa-specific at all (?)
<DocScrutinizer05>
sorry?
<bencoh>
I mean, why would you tie this to alsa (or to sound management) ?
<DocScrutinizer05>
err because... it's about sound?
<bencoh>
vibrator ?
<DocScrutinizer05>
shell?
<DocScrutinizer05>
amixer?
<DocScrutinizer05>
dbus-send alsaped $profile ?
<bencoh>
hmm
<bencoh>
would you also tie ... I dunno, leds to that as well ?
<DocScrutinizer05>
asking how this is alsa specific is like asking how foxes are related to printing when you echo "the quick brown fox..."|lpr
<DocScrutinizer05>
(LEDs) I dunno. Would you? Anyway you're free to do, just add the according commandline to .asoundrc
<bencoh>
yeah actually my question was more like "why do you want to have vibration management as an alsa extension"
<bencoh>
vibrator*
<DocScrutinizer05>
heck, how is a shell command invocation of $random-command "an ALSA extension by $random-command"? It's up to USER what to invoke
<bencoh>
nevermind, I guess I just misunderstood what you meant then
<DocScrutinizer05>
you're arguing why echo can output "fox" to a pipe
<DocScrutinizer05>
you can extend ALSA by whatever you like, by just editing it
<DocScrutinizer05>
which is exactly the point
<DocScrutinizer05>
obviously a very 'clever' usecase would be to make some mixer settings by this feature
<DocScrutinizer05>
but it's not limited to that
<DocScrutinizer05>
you know "if this than that"?
<bencoh>
yeah, I see
<DocScrutinizer05>
this is siimilar in that you can define whatever you want to get done, when app X opens alsa audio device Y
<DocScrutinizer05>
s/than/then/
<DocScrutinizer05>
and note that you don't need to patch the app either for doing all that
<DocScrutinizer05>
to the app that's completely transparent
<DocScrutinizer05>
to core ALSA it's also completely transparent in as far as you don't need to patch upstream ALSA for it to work
<DocScrutinizer05>
works on every arbitrary linux with ALSA installed
<DocScrutinizer05>
while it seems for PA the app devel needs to set properties to define which audio class their app is in
<DocScrutinizer05>
and PA needs a central file (/usr/share/policy/etc/rx51/pulse/xpolicy.conf) to define such audio classes
<DocScrutinizer05>
sur you probably would want to configure some audio devices in /etc/alsaconf as well, something like "ringer", "game", "music" etc. But that's on a per-user basis when you want
<DocScrutinizer05>
in ~/.asoundrc
<DocScrutinizer05>
and the concept is ultra-lean and extremely flexible, unlike that PA convolution
<DocScrutinizer05>
aplay -D headphone mymusic.wav ; -- how would you do that with PA?