Android Tablets Forum banner
1 - 20 of 100 Posts

·
Registered
Joined
·
1,352 Posts
Look at this here fancy subforum. Let's USE it.

I had returned my PDN because Kohl's messed up my rebate and I anticipated the possiblity of getting the Augen. However, the Augen looks pretty half-baked at this point (both in terms of hardware and software), so I'll probably be hitting up BBB at some point and picking up a PDN. I figured I'd give an outline of what I know at this point and I'm hoping maybe we can collaborate and improve this thing (more)!

Most of the brainpicking from me will be due to not using linux all that often, so hopefully some people here will be able to fill in the gaps.

1. Starting off, I'd like to look at the possiblity of getting standard "vanilla" 2.1 on the PDN. We have no idea what PD has done to customize the kernel. The version number should be the same, but who knows what might have been tweaked. The quick-and-dirty way would be to grab a kernel and ramdisk from a Samsung Moment (or some other Samsung 6410 platform if we can find one) and see if we can get it up and running. Failing that, the source for the Moment kernel is available, so we could look into compiling that as well.2. Froyo for the Moment is currently experimental. I'd love to leapfrog 2.1 altogether, but I figure it would be better to have an experimental setup over an experimental^

2 setup. Additionally, I am not aware of source being available for the Froyo kernels that people are building (not sure if they're being maintained privately or if I just haven't found them yet), so if we end up needing the source, we might be stuck at that point.

Ok, so...how are the 2 devices different:

1) capacative vs resistive screen
2) keyboard and additional buttons vs .....our 2 buttons

3) Probably a few other things as well.

The most progress I've made so far is getting Calkulin's 2.1 Moment Rom to boot up to the lock screen, but I get stuck there. (Calkulin's appears to be a Cyanogenmod port, if anyone cares). Logcat shows that the system sees input from the touchscreen, volume buttons, and accelerometers (that's good!), but there's also a running message that says something like "accelerometer= -1" (that's bad!), so I'm guessing that the system thinks that the input would need to be remapped somehow. (As in, "That constant input you're getting is the accelerometer, not the "Q" key, so treat it as such). I've tried to modify the volume screen hack to get past the lockscreen, but no go (even though it does register the button presses in logcat)

Off the top of my head, my guesses are:

1) Volume hack isn't working so we can't get past the lockscreen.
2) There is no issue with the lockscreen, but the home cannot display because it assumes there is an accelerometer and is waiting for input from it on how to orient itself.
3) Some other unknown issue with the homescreen setup.

So that is currently where I'm at in terms of 2.1. I'm also working on being able to flash a "normal" android kernel/ramdisk, as the PDN flasher has a header and integrity test. We may be able to see if a Moment kernel/ramdisk will run with out existing setup before we proceed on to /system, or we can just start making changes to /system and hope the kernel is close enough to keep up. (I'm making good progress on this front, but it will take just a bit more time). Additionally, there are some very well optimized Moment kernels from what I've read, so we may pick up a significant benefit just from that if we manage to switch over.

So, question time:

1) What platform-specific hardware do we have? Do we need compiled drivers for:
  • sound
  • touchscreen (is it possible this is just done over serial?)
  • display?
  • power manager (battery/AC)
  • wifi
Also, is there a way for us to figure out devices/device IDs in the event we end up needing to compile.
2) We know we have CPU-level compatability with the Moment. What else might me have to worry about, hardware-wise, in terms of compatability?
3) If we want to "borrow" the Moment kernels, is there a way for us to determine if hardware support for the PDN hardware is built into the PDN kernel, or if it is in a module that we can hopefully just carry along if we want to try shifting to a new kernel. (Also, how likely would it be that modules compiled for 2.6.29 (Eclair kernel) might work on 2.6.32 (Froyo kernel).

So, there's my rambling mess of thoughts for now. Hopefully we can get some smart people in here and do some further brainstorming.

4/8/11 Mod Edit: Fixed formatting. Please report any broken links or other errors. Thanks --MrsB
 

·
Premium Member
Joined
·
1,425 Posts
I think the best starting point would be to look in to making a new recovery.img. This will allow us to recover from a bricking of the device. It can also provide us the ability to do Nandroid backups and restores which helps with the recovering from the bricking. CyanogenMod is built from source. Perhaps the best way would be to see about building from source. When I started playing with this on my Droid you hooked up your phone to the PC and specific device related information was pulled from your device. I would assume that this wold also work for the Novel.
 

·
Registered
Joined
·
1,352 Posts
stoic said:
I wonder if Pandigital would provide an sdk or other info about the device as I would expect they would want more apps to run on thier device = sell more devices.S
Their device isn't meant to be extensible in the first place, so I doubt it is a priority.

I think a recovery is a good idea as well. Anyone know if the image layout is yaffs as well? I think I tried to unpack it with a perl script I found for recovery images and got an error.
 

·
Premium Member
Joined
·
1,425 Posts
clockworx said:
I think a recovery is a good idea as well. Anyone know if the image layout is yaffs as well? I think I tried to unpack it with a perl script I found for recovery images and got an error.
Hmm, I was hoping that would work. I'm trying to do some research in to this but haven't gotten far yet. Of course work and family is kind of getting in the way.
 

·
Registered
Joined
·
147 Posts
Regarding the original thread topic, as much as I would love to see Froyo (2.2) eventually running on my PDN, I just updated my Droid to it last night (somewhat painfully) and I have to say I don't think the hardware of the PDN would be capable of running it in a usable fashion. Granted, I am not using a stock Froyo install, but I just don't see it in the near future for my PDN.

I am all for getting a more suitable version of 2.1 running properly on the PDN though and will probably be a willing tester if someone can come up with a ROM.
 

·
Registered
Joined
·
1,352 Posts
Oh, there was one concern I had with doing a recovery image. For whatever reason, PD has their stupid "fuse" program to write firmwares rather than just using the standard "flash_image" that I think vanilla android uses. I can't find any reference to what the fuse binary is or does, so I'm concerned it might possibly do something weird other than just a regular flash.

So what?
Well, my understanding is that you can screw up your recovery image (which I've done, and then reflash w/ stock), and you can screw up your "regular" boot files (pretty much everything else), but if you do both you're screwed. If you screw up your recovery, just boot up and reflash recovery. If you screw up your boot files, just go into recovery and reflash.

So we write up an amazing new recovery, and write an update.zip to test it. (or do a nandroid backup/restore). Oops, we're missing some piece of the puzzle and now we can't boot and all we have is our broken recovery.

In other words, whoever tries to use a custom recovery the first time has a not-insignificant chance of bricking the device.
 

·
Premium Member
Joined
·
1,425 Posts
clockworx said:
Oh there was one concern I had with doing a recovery image. For whatever reason, PD has their stupid "fuse" program to write firmwares rather than just using the standard "flash_image" that I think vanilla android uses. I can't find any reference to what the fuse binary is or does, so I'm concerned it might possibly do something weird other than just a regular flash.

So what?
Well, my understanding is that you can screw up your recovery image (which I've done, and then reflash w/ stock), and you can screw up your "regular" boot files (pretty much everything else), but if you do both you're screwed. If you screw up your recovery, just boot up and reflash recovery. If you screw up your boot files, just go into recovery and reflash.

So we write up an amazing new recovery, and write an update.zip to test it. (or do a nandroid backup/restore). Oops, we're missing some piece of the puzzle and now we can't boot and all we have is our broken recovery.

In other words, whoever tries to use a custom recovery the first time has a not-insignificant chance of bricking the device.
Ah, the joys of hacking.
 

·
Premium Member
Joined
·
1,425 Posts
BiPolarBear said:
Regarding the original thread topic as much as I would love to see Froyo (2.2) eventually running on my PDN, I just updated my Droid to it last night (somewhat painfully) and I have to say I don't think the hardware of the PDN would be capable of running it in a usable fashion. Granted, I am not using a stock Froyo install, but I just don't see it in the near future for my PDN.

I am all for getting a more suitable version of 2.1 running properly on the PDN though and will probably be a willing tester if someone can come up with a ROM.
I think it will work a bit better then you are thinking. Look at the G1. It runs rather well on that old hardware.
 

·
Registered
Joined
·
11 Posts
I've looked at the modules that are loaded into the kernel using lsmod when root on the pd. It looks like there are only 3 modules and they are all for the wireless Ralink chipset. Based on this, I suspect that the touchscreen, audio, and volume keys are built into the kernel.

It'd be nice to know somehow if pandigital had used a development board with more access when they built and developed software for the novel. I've seen some good info on http://real6410.com as to what the Samsung 6410 chipset can support.
 

·
Registered
Joined
·
1,352 Posts
reslip said:
I've looked at the modules that are loaded into the kernel using lsmod when root on the pd. It looks like there are only 3 modules and they are all for the wireless Ralink chipset. Based on this I suspect that the touchscreen, audio, and volume keys are built into the kernel.

It'd be nice to know somehow if pandigital had used a development board with more access when they built and developed software for the novel. I've seen some good info on http://real6410.com as to what the Samsung 6410 chipset can support.
Excellent, this is the kind of help I was hoping for


The ralink modules are there in lib, and since that was all I saw, I kind of suspected that was all there was, but I was hoping for better


Is there any way to get hardware IDs for anything so we at least know what we're dealing with? Maybe touchscreen and audio might have native support?
 

·
Registered
Joined
·
11 Posts
I've dumped the contents of /dev/mtdblock using dd. I was going to try and mount the other partitions to see what was on them. The 512Mb of mtdblock looks to be partitioned as follows:

mtdblock0 2Mb
unknownmtdblock1 8Mb
unknownmtdblock2 1Mb
unknownmtdblock3 10Mb
unknownmtdblock4 3Mb
unknownmtdblock5 200Mb
yaffs2/systemmtdblock6 100Mb
yaffs2/cachemtdblock7 188Mb
yaffs2/data

Does someone know if the internal micro_SD card is just for the PD_Novel disk that shows up? I'm curious if there is 512Mb of internal NOR flash that stores the system image and potentially uboot along with the separate internal micro_sd. If we can get access to uboot, then you should be able to recover pretty easily from a bad system image.

It also looks like /dev/block/mmcblk0p1 is the /sdcard and /dev/block/mmcblk1p1 is /PD_Novel
 

·
Registered
Joined
·
1,352 Posts
Yeah, I think everything other than 5-7 are a weird format that you need to take special steps to decode. I think the numbering for the blocks for android is fairly standardized, so we can probably get more info from other sources and it will still correspond:

From elsewhere:

mtd0: 00021000 00000420 "bootloader"
mtd1: 000c6000 00000420 "kernel"
mtd2: 00759000 00000420 "filesystem"

I'm not sure what "filesystem" is......the ramdisk, maybe?
I believe 3 is recovery.
Maybe someone can run an updater-script that just dumps out the contents of mount to the log? (unless there's an easier way for us to find it)
 

·
Premium Member
Joined
·
2,102 Posts
I like where this is going. Proceed. This discussion will bear fruit - I guarantee it.

We should seriously push our 10,000 brethren to help us launch an email campaign to get Pandigital to release the kernel and give us the information to develop or an sdk. 10,000 emails might in some circumstances be considered a DOS attack, but here we have a legitimate interest in development on this device.
 

·
Registered
Joined
·
668 Posts
i was reading in an android forum last nite.. System.img, userdata.img, and a few other are yaffs2 format (i have utils needed to extract and pack this format)

the other 3... ramdisk.img, recovery.img and another one are u.makeboot or something format. I have the guide to un/packing bookmarked at home, i'll post it when i get there.
 

·
Registered
Joined
·
1,352 Posts
This is probably what you're thinking of: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images The perl script to unpack doesn't work for me, though..

C:>unpack-bootimg.pl ramdisk.img
Subroutine Cwd::fastcwd redefined at C:/Perl/lib/Cwd.pm line 812.
Subroutine Cwd::getcwd redefined at C:/Perl/lib/Cwd.pm line 812.
Subroutine Cwd::abs_path redefined at C:/Perl/lib/Cwd.pm line 812.

Could not find any embedded ramdisk images. Are you sure this is a full boot image?same results for bootloader, recovery, and ramdisk
 
1 - 20 of 100 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top