This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - tangrs
Pages: 1 ... 4 5 [6] 7 8 ... 16
76
« on: January 25, 2013, 04:08:57 am »
FlashFX is patented, only the wear-leveling, so we can use it read-only?
Hmmm, I'm not sure. I'll look into it a lot deeper once I can actually get something working with the NAND.
77
« on: January 25, 2013, 03:55:58 am »
Why should we need to reverse-engineer it? We have the source code! (And it works, could confirm it with an hexeditor)
Most of the code is obfuscated though and I'm still unsure about the copyright issues involved. It could be possible that the filesystem is patented. Anyhow, I was talking about reversing the OS for the NAND driver.
78
« on: January 24, 2013, 07:09:32 pm »
nobody really knows how to interface with the NAND controller. Isn't the nspire_emu source enough to start from?
Yep, it's helpful for a starting point but all my attempts at a NAND driver still ended up freezing the calculator I might have to go disassemble the OS code to try and see exactly how they do it :S
79
« on: January 24, 2013, 09:24:18 am »
There's two things we need to solve for NAND accesses to work. First is to actually get access to the NAND (i.e. get a driver working) and second is to get it to work with a filesystem of some sort. At the moment, we don't even have a driver for the NAND controller yet (the PL350 is really weird to control). In fact, this is the main limitation that's holding us back - nobody really knows how to interface with the NAND controller. I have also considered the filesystem issue where there's no public driver for the Datalight filesystem and FlashFX. Unfortunately, we'll probably have to give up being able to access those filesystems. The plan I have in my head is to try and 'partition' the NAND to divide some space between the Nspire OS and Linux - each to their own filesystems. We could probably find entry points to certain functions in boot2 or the Nspire OS to format the flash and trick them into believing we have less flash than we actually have. That way we could probably have some flash unused at the end that Linux could utilise. Failing that, we could probably modify nLaunch in a way to load the kernel directly from flash and have the whole NAND to ourselves (save the pages required by the booting process). Obviously, if we use this method, the Nspire OS will not be able to exist so it'd be a Linux-only calculator (whether that's for the better or worse hehe). Anyhow, no point discussing all that when we don't even have a driver yet. And writing a NAND driver isn't to be taken lightly, it's a notch harder than writing a keypad driver for example (to say the least). I still don't get how the PL350 in the CX works
80
« on: January 24, 2013, 05:44:30 am »
I forgot that while searching through menuconfig.
But do we really need a small kernel? They're only 0.2 MB in difference and they're almost the same but with more drivers. Also, there's an option to include b43-firmware in buildroot. Should I include it in xconfig only or in smallconfig, too?
IMHO, the defconfig should be kept minimal - basically enough to get the system to boot. That way everyone is happy - people who want the smallest working kernel doesn't have headaches working out which options can be disabled from the defconfig and people wanting more features can opt-in the ones they want. In other news, I have a little surprise to demonstrate a potential use for the USB gadget framework. Attached is a special kernel that acts as a mass storage device to dump the boot1 ROM - because dumping boot1 using polydumper is so mainstream No initrd required, it's all included in the kernel. Just boot with cx_use_otg if you're using a CX model. http://tangrs.id.au/linux_snapshots/zImage.tns
81
« on: January 24, 2013, 05:40:51 am »
Yes, it is. (hopefully)
I didn't test x, I used links -g (directfb) which printed "current mode not upported". It works only if I return 0 in clcdfb_check. That's exactly the same error mssage we had earlier.
I changed hsync_len to be 6 so it should pass the clcdfb_check tests. Can you pull the latest changes and check that it actually worked?
82
« on: January 24, 2013, 04:04:44 am »
I removed the logo in expandedconfig, if you can see it, you're using the wrong version.
I just got an idea from this. How about we add "-defconfig" and "-expandedconfig" to CONFIG_LOCALVERSION on the different builds so users can work out which config they're on by running uname -a?
83
« on: January 24, 2013, 03:37:23 am »
With the other kernel, initrd and loader, every time I connected my Nspire to my PC the calculator would show a message saying a USB connection was made and the computer would recognize it as a Gadget Serial and use the corresponding driver. I was able to establish a serial connection using putty, even tough the console was always black (idk if it was suposed to show something but at least I know it was connected). This time the calculator shows nothing when connected to my PC and the computer is unable to recognise it, calling it Unknown Device. I'm also unable to use putty with this kernel. BTW, linux logo is still there, I'm using the expanded cfg kernel provided in the nspire linux builds homepage.
Which kernel did it work with and which did it not work? Did you connect any USB host devices to it beforehand? To get a shell on the Gadget Serial device through putty, you need Nspire Linux to attach a shell to /dev/ttyGS0
84
« on: January 23, 2013, 09:56:56 pm »
I've changed it so the classic nspires uses 8bpp. I'll push it when X is working on it. @Vogtinator, I've been researching the meanings behind clcdfb_check's (5+1) magic numbers and this is what I got. Does this mean we can simply put hsync_len as 6 (and change left_margin and right_margin as appropriate as well)? It doesn't seem to be panel specific so maybe we don't have to set it to the same settings the nspire OS uses. Also, regarding X being broken, did you enable the FBDEV driver in buildroot? The config option is BR2_PACKAGE_XDRIVER_XF86_VIDEO_FBDEV When I use the FBDEV driver, I found that clcdfb_check isn't even called at all so even hsync_len values less than 6 will be accepted (possibly because FBDEV doesn't try to change the video mode). Basically, should we just simply chuck the minimum value of 6 into hsync_len, left_margin and right_margin? Edit: Woo!
85
« on: January 23, 2013, 07:47:50 pm »
On my Touchpad, when I use the defconfig kernel, tiny buildroot ramdisk, and ramdisk script from tiplanet.org/nspire-linux-builds, I get a kernel panic. What am I doing wrong? Can anybody help?
What does the kernel panic message say? Edit: Does the kernel seem to work correctly after the panic?
86
« on: January 23, 2013, 07:01:39 pm »
When I enter nano on linux, the ctrl key state reverses, so whenever I press ctrl, it is off, and when I release ctrl it thnks that it is on. How do I fix this
Is this a touchpad/clickpad model? This issue was fixed just yesterday. It should be in the next nightly build at http://tiplanet.org/nspire-linux-builds/
87
« on: January 23, 2013, 08:44:45 am »
The contoller http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#C0000000_-_LCD_controller Supports 8 bpp. Maybe just use 8bpp instead of 4bpp?
The controller might support it but the panel doesn't. I've already tried
Edit: unless I'm missing something... Was it ever possible to use 8bpp in Nspire OS? Linux renders the screen weirdly when I try to use 8bpp mode.Edit2: Just had an epiphany. It is most likely possible after all. I made a wrong conclusion I'll give it a whirl again tomorrow.
88
« on: January 23, 2013, 08:10:43 am »
Is it possible to get X working on a click pad/touchpad? Mine complains about the color depth being unsupported. Is there a way around that?
Yep, I get that too. It seems that the fbdev Xorg driver doesn't support 4bpp hence X can't run either.
89
« on: January 19, 2013, 05:57:31 am »
Why build in such a limitation? just make sure there's a warning somewhere, and make the default lower. Ideally, the default would be normal, so new users can't blame their problems on it.
Sounds good. I'll only include frequencies that Nover doesn't report as dangerous. Edit: Implemented a simple cpufreq driver. It can only scale between two frequencies though: half of base freq and 1/4 of base freq. It's limited because we can't touch the AHB speed (or else, drivers relying on the AHB and APB clocks will be all messed up) unless we notify the drivers of the change. I'm still looking into it.
90
« on: January 19, 2013, 05:25:01 am »
The experience with the CX shows that on the CX, IMO, the AHB frequency should never be touched. The default is 66 MHz, and NAND memory corruption occurs quickly if the AHB is set to 75 MHz. 72 MHz seems to be safer, but then it's less than 10% overclocking margin. The Clickpad & Touchpad have higher tolerance to AHB overclocking, IIRC.
It's okay if the AHB speed is slower than 66MHz right? I'm working with the values that Nover gives me and avoiding everything that's "dangerous".
Pages: 1 ... 4 5 [6] 7 8 ... 16
|