<wolfspraul>
well that's really interesting indeed
<wolfspraul>
so Dieter and/or Harald or the whole osmocom do something about Thuraya now? like what?
<DocScrutinizer>
Harald told me old news Thuraya protocol is a pimped GSM
<DocScrutinizer>
and everything openly speced
<DocScrutinizer>
might be fun, though both expensive and possibly asking for real trouble
<DocScrutinizer>
just to *start* you need hw for $$$$
<DocScrutinizer>
I always wonder who's paying for Harald's hobbies
<DocScrutinizer>
and if you hack Thuraya, you might face unsolicited visits of some very US-american tough guys that don't like you to publish their backdoors to that sat network
<kristianpaul>
ah, not in my view
<kristianpaul>
real trouble.. yeah, i had heard from brazil
<kristianpaul>
not counting from my country in the 90's i think... :)
<wolfspraul>
you guys worry far too much about 'trouble'
<kristianpaul>
somethimes "hack" could be no intentional i had heard of such us cases for HAM satellites
<wolfspraul>
if some kids in the basement (or small office, ok) can hack into something, then foreign agencies like Chinese are long secretly recording 100% of traffic they can capture anywhere
<wolfspraul>
we should focus on making something work, everybody will appreciate the new opportunities
<kristianpaul>
first put your satellite i would say :)
<wolfspraul>
I was looking at the Thuraya modules recently, and wondered about schematics, bom, chips they use etc.
<wolfspraul>
if it's not open yet, let's open it ;-)
<wolfspraul>
does anybody have URLs to Thuraya schematics, chips/bom, etc?
<kristianpaul>
also satellites shares some specs with i.e TV receivers, so coming projects like that funcube dongle for example is not so uncommon for next years
<DocScrutinizer>
wolfspraul: (looking for thuraya modules) :-D \o/ wasn'T that what I sugested for a GTA04-special-edition?
<DocScrutinizer>
back when there's been a OM GTA04 in the pipe
<DocScrutinizer>
I bet it was on my brainstorming list
<DocScrutinizer>
probably next to laser and electromotor for moving the pop-out camera
<DocScrutinizer>
:-P
<DocScrutinizer>
>>The customer is warned that GSM cellular mode in certain third world countries is often more expensive that Thuraya "satellite" mode.<<
<kristianpaul>
actually i cant see Thuraya, in my skyview
<DocScrutinizer>
LOL on that though: >>Thuraya offers a 9600 bps data rate, which corresponds to about 4 MegaBytes (MB) an hour. This means Thuraya is very suitable for light to moderate data applications such as email or web browing(!!)<<
<kristianpaul>
at least i'm missing more satellites...
<DocScrutinizer>
kristianpaul: ??
<DocScrutinizer>
more thuraya sats?
<kristianpaul>
thuraya-1,2 and 3
<kristianpaul>
i got some TLEs :-)
<DocScrutinizer>
I don't think this sheik is pondering to shoot up a 2nd sat
<kristianpaul>
but i found on a osmocom header file that Thuraya is also a gsm network, s i'm confused now...
<kristianpaul>
may be the do roaming? :)
<kristianpaul>
he
<kristianpaul>
anyway
<kristianpaul>
DocScrutinizer: gpredict is a very interesting software when you want to know what's passing over you :)
<DocScrutinizer>
[2011-08-15 02:26:44] <DocScrutinizer> Harald told me old news Thuraya protocol is a pimped GSM
<wolfspraul>
DocScrutinizer: ok so who is doing Thuraya hacking and what is the goal?
<DocScrutinizer>
wlfI dunno
<DocScrutinizer>
wolfspraul: ^^^
<DocScrutinizer>
cya next day, I'm wasted
<wolfspraul>
n8
<DocScrutinizer>
n8 (and OM chandra still down, so still main mail acct dead, and mails bouncing)
<kristianpaul>
wolfspraul: had you visited mediatek?
<wolfspraul>
I had meetings with mediatek representatives yes, but it's a long time ago
<wolfspraul>
that's a huge company, so I'm not sure what you mean with 'visited mediatek'
<kristianpaul>
never mind, just asking in general, as when you visit ingenic and bought somw chips by cash ;)
<kristianpaul>
but yes, big company different products lines..
<kristianpaul>
sure visit to buy chips is not that general of course, just wondering same posibilites with mediatek no more from there
<wolfspraul>
you can buy mediatek chips in any quantity (down to 1) for a few USD on the street market in Shenzhen and other places
<kristianpaul>
afaik you cant do too much with it
<wolfspraul>
why not?
<kristianpaul>
sure is posible, jsut wondering linux suport, datasheets
<wolfspraul>
that's what osmocombb is working on
<kristianpaul>
ah, cool
<kristianpaul>
well i dint mentioned GSM
<kristianpaul>
well, i think i found my problem with namuru
<kristianpaul>
all this time i tought i was enabling some logic this way:
<kristianpaul>
case(addr) 8'hxx  reg <= 1'b1;
<kristianpaul>
but i dint work..
<kristianpaul>
i dont know if this a coding mistake from my part...
<kristianpaul>
but actually i never seem that implemented in a mux...
<kristianpaul>
wich actually go this way:Â Â case(addr) 8'hxx reg <= data_in[x];
<kristianpaul>
so, i'll definetelly will broke the original memory mapping of namuru, wich actually i dont see reason for keep it
<kristianpaul>
anyway, that also calm down my worrying about who hells the enable signals for some internal modules in namuru was going to be disabled some day..
<kristianpaul>
s/day/way
<kristianpaul>
question is, should i do this in the same clock cycle..
<kristianpaul>
cause if that the path the only way i see is include the enable as the MSB in the value of the register i'm actually writing for example to the NCO..
<kristianpaul>
nah, too odd
<kristianpaul>
separate enable register will be, and first i write value to foo register and later i enable the logic
<kristianpaul>
asociated with it
<kristianpaul>
wolfspraul: i comented about MTK cause i think i start see some blackperry/nockia clones in my local makerket at least in the city i work
<kristianpaul>
very few, but looked like clones for sure :)
<kristianpaul>
zzz
<kristianpaul>
Artyom, i now got values 2 and 3Â Â from STATUS , but NEW_DATA still zero same as accumlators...
<kristianpaul>
but i least i fixed the issue with the enable signals, moving it to a dedicated enabled register
<kristianpaul>
btw, so you never load NCO vales for the carrier?, can you remenber me later the intialization worflow and tracking loop implemented in your acquisition code?
<kristianpaul>
cause i'm enabling and intializing in this order: prog tic, accum tic, ch0 prn key, carrier nco, ch0 code nco, ch0 code slew and last is enable signal for ch0
<kristianpaul>
then i just keep clearing status jsut after reading it on my loop
<kristianpaul>
same when reading accumlators
<kristianpaul>
at least i got accum int to work.. now need to find what wrong with accumulators zeros...
<GitHub145>
[milkymist/gps-sdr-testing] Separate Accumlator status from init - Cristian Paul Peñaranda Rojas
<GitHub145>
[milkymist/gps-sdr-testing] Enable control for channels is now a separate register, same case of clear flag for both status and new_data registers - Cristian Paul Peñaranda Rojas
<Ayla>
hi
<Ayla>
how can I compile jzboot?
<xiangfu>
Ayla, under xburst-tools folder run: ./autogen.sh
<xiangfu>
  ./configure --enable-firmware CROSS_COMPILE=mipsel-openwrt-linux- --prefix=/usr --sysconfdir=/etc
<xiangfu>
only jzboot will not working. jzboot is a submodule of xburst-tools
<Ayla>
ok
<Ayla>
I installed the .deb
<`antonio`>
wpwrak, I ma trying to build the kernel for the wpan kit, I am building it using my toolchain and I flash it into my own image. but every time i get the kernel panic error
<`antonio`>
kernel panic not syncing vfs unable to mount root fs on unknown-block (0 0)
<`antonio`>
what could it be and how can I solve it.
<`antonio`>
I am using the master revision toolchain btw
<xiangfu>
`antonio`, where you get the toolchain?
<`antonio`>
I build my own toolchain with the qi-hardware feeds
<`antonio`>
from the qi-hardware git
<xiangfu>
openwrt-xburst?
<`antonio`>
yes
<xiangfu>
openwrt-xburst.git?
<xiangfu>
and the rootfs is latest openwrt release right?
<`antonio`>
i am using my own root rootfs
<xiangfu>
the kernel and rootfs better use same toolchain.
<`antonio`>
yes from same toolchain
<`antonio`>
basically i flash my own image on nanonote and then I build werner's kernel separately using the same toolchain
<`antonio`>
but when i install it I get that error.
<`antonio`>
the kernel seems to be built fine, but there must be something I am missing
<viric>
Anyone mastering the boottime ip configuration of linux?
<viric>
(ip=dhcp kernel commandline)
<xiangfu>
I found the 'ben-wpan' branch use a 1.5 rootfs. you can try to reflash rootfs and try again.
<kristianpaul>
Artyom: i was supposing to enable some logic in anmuru by doing enable_reg <= 1'b1; inside a case statement
<kristianpaul>
Artyom: now i get 2 and 3 from status
<kristianpaul>
Artyom: but bit high in new_data, also accumulators still zeroed, but at least i have one thing less to worry about (for now i hope)
<viric>
I wonder how to check the result of "ip=dhcp" from the booted linux
<viric>
from usermode
<kristianpaul>
Artyom: I managed to solve this implementing aditional register for enable stuff for the correlator and a separate clear flag for status
<kristianpaul>
you have idea why accumulators are zeroed?, first thing came to my mind division by zero of course ;)
<kristianpaul>
but i'm bit worried this mixing is done with combinational logic
<Artyom>
I couldn't find in your code how "accum_sample_enable" signal is generated... Can you point me?
<kristianpaul>
it came from time base, let me point some lins
<kristianpaul>
remenber i have namuru code in separate branch (gps-sdr-testing)
<kristianpaul>
you found another bug in the code, thanks a lot Artyom !
<kristianpaul>
the joy of porting :)
<Artyom>
I feel the same ;) With my port ;)
<kristianpaul>
btw i was asking a guy wich work with avalon
<kristianpaul>
I had some concerns about how that enabled logic is set(and unset?)
<kristianpaul>
mostly because the use of write & chip_select
<kristianpaul>
he pointed as it is implemente right now there is a chance for changing namuru registers in case you acess another slaves in the bus
<kristianpaul>
dunno if this can affect your desing, just droping this worried to you
<kristianpaul>
hum, i'm crazy i disabled accum_sample_enable in my time base with aparently not reason..
<Artyom>
thanks for info. I think you've noticed that I already changed namuru registers addressing. And I think I will possibly do it again latter....
<kristianpaul>
ah, i confused it with sample_clk -_-
<kristianpaul>
too many sample_* signals :)
<kristianpaul>
hum, but i is this accum_sample_enable really required?
<kristianpaul>
ah, i see
<kristianpaul>
thats how namuru avoid to more sampling that it should
<kristianpaul>
well, in my implementation i think is not neeed as namuru run with frontend clock
<`antonio`>
xiangfu, it worked ! thanks a lot
<xiangfu>
great
<Artyom>
yes, in your case it should be always '1'
<Artyom>
as I understand your design...
<kristianpaul>
yes you do rightly
<kristianpaul>
that should fire the damn accumulators :)
<DocScrutinizer>
wolfspraul: I dunno who's actually hacking thuraya right now. Harald suggested to better look into thuraya rather than IPv6 security. I asked him how far he and his "crew" got with that particular topic, and iirc he said they really are going to look into it, and there should be some details on osmocom.org or somewhere eventually
<DocScrutinizer>
the OTA protocol for thuraya seems quite similar to plain old GSM
<DocScrutinizer>
the 'public' OTA, not the trunk backend
<DocScrutinizer>
Harald claimed it's all well documented and specs publicly available
<DocScrutinizer>
the sat itself has some awesome technical details, like dynamic beam focusing etc
<kyak>
wolfspraul: perhaps you already know, but i just stumbled upon another open hardware project: http://code.google.com/p/lightpack/ (it's in Russian, kind of "Philips Ambilight" DIY)
<kyak>
the video is pretty cool :) i don't know if actual Philips technology works any better, but it definitely doesn't work with _any_ TV/monitor
<Jay7>
kyak: interesting
<Jay7>
other idea to use webcam instead of software client
<kristianpaul>
isnt okay?  i mean blocking asigment inside a always is not proper tight?
<kristianpaul>
s/tight/right
<kristianpaul>
:-)
<lekernel>
you can use non blocking here
<kristianpaul>
i knew it !
<kristianpaul>
thanks,
<kristianpaul>
now i need to understand why :)
<kristianpaul>
why was a used a blocking asigment in first place
<kristianpaul>
hum, so Artyom was right, acording to code gen core, i need at least enable and disable prn_key_enable in order to the dump_enable to work
<kristianpaul>
hum there is a hc_enable coming from code nco to code gen... i'll asume for now this work
<kristianpaul>
i'm getting crazy with all those enbled signals coming from here and there.. seems not stop :)
<DocScrutinizer>
lekernel: you linked me to that poettering post about systemd. It scares me he's stating it depends on dbus, which seems to sugest dbus changed from middleware to a core system component
<larsc>
dbus is the new unix-socket
<DocScrutinizer>
I damn sure would hate my embedded ATmega controller not to boot because there's some bug in *dbus* which I definitely never would want to run on that system anyway
<DocScrutinizer>
this poettering guy seems to care quite little about cross platform. All his "improvements" are targeted exclusively at desktop PCs when I think about it
<kristianpaul>
larsc: what? no
<kristianpaul>
havent had good experiences with gnome and dbus
<DocScrutinizer>
I gather in 5 yeras - when nobody stops poettering - not even a 8051 will boot anymore without proper pulseaudio support for playback of POST beeps, and without X support to display diagnostic msgs
<DocScrutinizer>
...on the 3 LEDs of that embedded device ;-P
<mth>
I don't know the process of adding the Qi patches to OpenWRT
<ignatius->
Well, i'm just looking for kernel source (that I can compile), that will work on the Nanonote's NAND. I don't like having a drive that I can't use its entirity.
<mth>
you can always go back in openwrt-xburst git to the older patch/diff files
<ignatius->
True.
<ignatius->
I'm rather stupid in that department, though.
<mth>
ideally they would be tagged, otherwise by date
<ignatius->
So far, the JLime kernel source works... but, then no, ks7010 driver.
<ignatius->
Tried compiling a ks7010 module outside of the source tree.... didn't work.
<mth>
jz-2.6.39 of qi-kernel is not working?
<ignatius->
Does it support using the entire NAND?
<mth>
what is special about the entire NAND? is it just partitioning or is it multiple chips?
<ignatius->
I don't like only having ~512MB user space.
<ignatius->
And I don't like weird split partitions.
<mth>
the NAND partitioning is configured in the board-qi_lb60.c source
<ignatius->
Ah.
<mth>
afaik it's not specific to any kernel version, but rather a configuration option
<mth>
arch/mips/jz4740/board-qi_lb60.c
<ignatius->
Really? I've been spending hours upon hours trying to determine that. A kernel configuration option?
<ignatius->
If so, which one(s)?
<mth>
ah no, there are two configurations, one for 1GB and one for 2GB
<mth>
and the right one is autodetected
<ignatius->
In which tree?
<mth>
so the only way to change the partitioning is the modify the table
<ignatius->
Hmm. Damn.
<mth>
I'm using jz-3.0 of OpenDingux, but it's very similar to jz-2.6.39 of qi-kernel
<ignatius->
Does it have support for the ks7010?
<mth>
the table is fairly straightforward though, just have a look
<ignatius->
Er. I mean it's a driver for a WIFI MicroSD card.
<mth>
ah, that one
<mth>
I don't see ks7010 in drivers/net/wireless in jz-2.6.39
<mth>
if there is another git archive that does have the driver in a nearby kernel version, it might not be too hard to merge it though
<ignatius->
Nod.
<mth>
anyway, the partition table approach is the same for all kernel versions I've seen, so if you have a kernel with ks7010 support it should be easy to change the partitioning on that kernel
<ignatius->
By replacing lines 86 - 103?
<ignatius->
Would that work?
<ignatius->
Er. Change, I mean.
<mth>
should work, if the new values are correct
<ignatius->
Ok
<mth>
the 0x100000 is probably the erase block size, so you should leave that as-is
<mth>
make sure that every offset is equal to the previous one + previous size
<mth>
and use 2048 blocks in total
<ignatius->
Hmm. Or would it be easier to just copy that file from a different tree...
<mth>
no, only copy the table then, not the entire file
<ignatius->
Ok.
<mth>
there have been changes in the rest of the file unrelated to NAND partitioning but necessary to properly init other devices
<ignatius->
I see.
<mth>
it's similar to partitioning harddisks, with the start sector (offset) and number of sectors (size)
<ignatius->
Nod.
<ignatius->
The "dd" Linux command is very helpful with that.
<mth>
with filling HD partitions, yes, but creating is easier with fdisk ;)
<ignatius->
True.
<ignatius->
I just use the standard fdisk. No cfdisk for me.