Active Topics

 


Reply
Thread Tools
Posts: 1,224 | Thanked: 1,763 times | Joined on Jul 2007
#71
A few new items at http://my.svgalib.org/770/n900/u-boot/ :

u-boot with (intermittent) support for internal mmc. It works reliably once after I boot maemo, but if I do something in u-boot until the watchdog powers off, and then turn on the N900 with the power key, the internal mmc card is not found. This should allow for dual booting meego without an SD card.

btrfs.ko - this module allows maemo to access meego filesystem. It might have some bugs from my "porting" it to 2.6.28. Almost certainly leaking something on umount at the very least.
__________________
My repository

"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".

No more Nokia devices for me.
 

The Following 7 Users Say Thank You to Matan For This Useful Post:
Posts: 256 | Thanked: 92 times | Joined on Oct 2010
#72
example:
Code:
ext2load mmc 1:1 ${loadaddr} uImage
ext2load mmc 1:1 ${rdaddr} initrd
setenv bootargs root=/dev/mmcblk1p1
bootm ${loadaddr}  ${rdaddr}
EDIT:
to avoid confusion. this is an example. you will have to use the partition you put the kernel and initrd. 1:1 would be the first partition on the external sd. further you have to use fatload instead of ext2load if you partition is a fat partition. initrd needs to be prepared with mkimage like the kernel.
EDIT2:
same holds true for the "root=" param. the devicenodes may be swapped so mmcblk1 in maemo would be mmcblk0 for the argument.

Last edited by lunat; 2010-11-05 at 23:28.
 

The Following 2 Users Say Thank You to lunat For This Useful Post:
Posts: 116 | Thanked: 40 times | Joined on Mar 2010
#73
Originally Posted by Matan View Post
I think that bootm boots the kernel, so nothing after that is actually executed.

When you say "Kernel loads then reboots", do you mean that you don't see any kernel messages before it reboots?
That's correct. No more messages to the frame buffer. It act like flashing a kernel wo corresponding modules. If you interrupt and type run mmcboot it says invalid checksum. I'm guessing that is coded for the meego kernel? I think it is not finding a rootfs mount?
 

The Following User Says Thank You to xopher For This Useful Post:
Posts: 256 | Thanked: 92 times | Joined on Oct 2010
#74
Originally Posted by xopher View Post
That's correct. No more messages to the frame buffer. It act like flashing a kernel wo corresponding modules. If you interrupt and type run mmcboot it says invalid checksum. I'm guessing that is coded for the meego kernel? I think it is not finding a rootfs mount?
for you mention it.
another hint /if everything else is ok/ i repeat /if everything else is ok/
and you don't see messages despite enabled fb: the framebuffer needs memory so you have to either compile that amount of memory into the kernel or give it as an argument.
 
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#75
Okay, I have to ask, because now I'm confused:

What's the musb? Is that the patch that makes the kernel capable of interacting with the MeeGo filesystem? But if so, it wouldn't be differently named than the separate file for the same module, would it?

Just because if I am upgrading, I might as well know what the difference between the two is.

(Also, those of us who already flashed the original power41a kernel, do we need to redownload and unpack all the modules when flashing kernel? Or will it be fine?)

And, last question: If I already overwrote the system fmtx-status-menu-applet.so (or whatever it's called - I installed qwerty12's FMTX applet that doesn't hide and can switch radio on-off with longpress), and copied in a custom fmtxd (mostly the commonly available one, but I made a single change towards making it work mid-phone-call), installed fmtx-faker, and modified the /etc/init.d/rcS file - will any of those be overwritten if I use either

flasher --local -k [power41 whatever] -f
or
fiasco-flasher -k [power41 whatever] -f (<--- Yeah, I eventually figured out how to get it on my N900. Either extract it from the original PR1.0 firmware image, or PM someone to unofficially give you the binary. )

I'm guessing the answer is the same for both, but I felt it safer to list both in case they differ in how exactly they flash the kernel.

- Edit -

Is the fmtx-si4713.ko in your repository the same as the one MohammadAG posted in the FMTX Limitation Removing thread?

Last edited by Mentalist Traceur; 2010-11-06 at 01:17. Reason: One more final question I forgot to type.
 
Posts: 41 | Thanked: 10 times | Joined on Dec 2009 @ Woodbridge, CT USA
#76
Okay. This looks very cool and I've tried a few things but still seem to be missing something.

First, I've followed the instructions from Matan (more or less) to use his kernel.

Things I am doing differently:

First, before I load it permanently, I want to try and get things a little more configured the way I want, so I'm flashing from my Linux box:

sudo flasher-3.5 -k my.u-boot.power41d -l -b

My N900 starts uBoot and if I interrupt it and do a run noloboot I get taken to my regular boot process (which runs Multiboot giving me the choice between Maemo and NitDroid)

However, I have 16G SD card. I have Nitdroid at mmcblk1p7 and MeeGo at mmcblk1p5. (See MeeGo Bug 5136 for a discussion of how I did this).

With that, I've been trying to find ways to get bootargs environment to pass, e.g. root=/dev/mmcblk0p5.

I've installed my uImage in the first partition of my external mmc card. Then I try
mmc init
fat2load mmc 1:1 ${loadaddr} uImage
setenv bootargs root=/dev/mmcblk0p5
bootm ${loadaddr}

This through the startup, but it gags on the filesystem with essentially the same errors as I described in comment 9 on MeeGo bug 5136.
complaining about mmcblk0p5.

Anyone have any ideas?
 

The Following User Says Thank You to ahynes1 For This Useful Post:
Posts: 256 | Thanked: 92 times | Joined on Oct 2010
#77
yep. actually three ideas.

1. mmc support is not in the kernel. so it cannot mount the rootfilesystem. and it cannot access the modules on the rootfilesystem at that time for it is not mounted. in that case you need like i mentioned earlier either a different kernel with the mmc support compiled in or an initrd with the drivers.

2. i had the same issue still occuring with mmc support fix compiled into the kernel. funny enough it worked with an empty initrd(no modules). i didn't dig further into it. would be interesting what happenes there. but a initrd made it work(no solution but a workaround.)

3. the root command line is wrong. like i said before the numbering of the disks is not consitent. uboot numbering is independent from maemos and that again from other kernels.


Originally Posted by ahynes1 View Post
Okay. This looks very cool and I've tried a few things but still seem to be missing something.

First, I've followed the instructions from Matan (more or less) to use his kernel.

Things I am doing differently:

First, before I load it permanently, I want to try and get things a little more configured the way I want, so I'm flashing from my Linux box:

sudo flasher-3.5 -k my.u-boot.power41d -l -b

My N900 starts uBoot and if I interrupt it and do a run noloboot I get taken to my regular boot process (which runs Multiboot giving me the choice between Maemo and NitDroid)

However, I have 16G SD card. I have Nitdroid at mmcblk1p7 and MeeGo at mmcblk1p5. (See MeeGo Bug 5136 for a discussion of how I did this).

With that, I've been trying to find ways to get bootargs environment to pass, e.g. root=/dev/mmcblk0p5.

I've installed my uImage in the first partition of my external mmc card. Then I try
mmc init
fat2load mmc 1:1 ${loadaddr} uImage
setenv bootargs root=/dev/mmcblk0p5
bootm ${loadaddr}

This through the startup, but it gags on the filesystem with essentially the same errors as I described in comment 9 on MeeGo bug 5136.
complaining about mmcblk0p5.

Anyone have any ideas?
 

The Following 2 Users Say Thank You to lunat For This Useful Post:
Posts: 107 | Thanked: 74 times | Joined on Jan 2010
#78
Originally Posted by ahynes1 View Post
sudo flasher-3.5 -k my.u-boot.power41d -l -b

My N900 starts uBoot and if I interrupt it and do a run noloboot I get taken to my regular boot process (which runs Multiboot giving me the choice between Maemo and NitDroid)
If you switch the OS with multiboot you'll reflash the kernel and lose u-boot. There are other issue too such continuous reflashing and support only for Linux OS and kernels able to mount the nand rootfs and exec /sbin/preinit or you'll 'brick' your device and will need a kernel reflashing.
IMO nitdroid team should seriously consider to support u-boot with their kernel.

About your issue, I had the same experience fixed with a "rootwait".
 

The Following 3 Users Say Thank You to nicola.mfb For This Useful Post:
Posts: 256 | Thanked: 92 times | Joined on Oct 2010
#79
Originally Posted by nicola.mfb View Post
If you switch the OS with multiboot you'll reflash the kernel and lose u-boot. There are other issue too such continuous reflashing and support only for Linux OS and kernels able to mount the nand rootfs and exec /sbin/preinit or you'll 'brick' your device and will need a kernel reflashing.
IMO nitdroid team should seriously consider to support u-boot with their kernel.

About your issue, I had the same experience fixed with a "rootwait".
yes could be a race and the initrd i had could have provided the additional time needed. would match my observation.
 

The Following User Says Thank You to lunat For This Useful Post:
Posts: 1,224 | Thanked: 1,763 times | Joined on Jul 2007
#80
Originally Posted by Mentalist Traceur View Post
What's the musb? Is that the patch that makes the kernel capable of interacting with the MeeGo filesystem? But if so, it wouldn't be differently named than the separate file for the same module, would it?
musb is the hardware component controlling USB operation on the N900. In PR1.3 kernel Nokia fixed a bug "N900 does not know the difference between a dedicated charger and a charging downstream port". But this fix resulted in CPU at minimum 500MHZ when connected to charger. I reverted this fix.

Is the fmtx-si4713.ko in your repository the same as the one MohammadAG posted in the FMTX Limitation Removing thread?
Nokia added a lock attribute that when written, locks the fmtx configuration. MohammadAG compiled fmtx module from PR1.2 source. I left the lock attribute only making writing to it a NOP. Since the fmtx daemon writes to it, I think it is better to have this attribute.
__________________
My repository

"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".

No more Nokia devices for me.
 

The Following User Says Thank You to Matan For This Useful Post:
Reply

Tags
power kernel, uboot


 
Forum Jump


All times are GMT. The time now is 01:47.