maemo.org - Talk
Page 8 of 8 « First 67 8
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Alternatives (https://talk.maemo.org/forumdisplay.php?f=36)
-   -   Mer v0.6 released (https://talk.maemo.org/showthread.php?t=26310)

fanoush 2009-01-28 09:10
Re: Mer v0.6 released
 
Quote:
Originally Posted by daperl (Post 260326)
But I know that someone else could get there light years sooner. Like Russell King! The god of all things ARM-linux.
Sadly the more experienced person the less time they have for such experiments. There is plenty of people with skills far better than ours, linux-omap list is place to meet them. OTOH sometimes skill can be replaced by luck or lot of time spent trying semi-random things :-)
Quote:
Originally Posted by daperl (Post 260326)
I'ts just a menu script replacement for /sbin/init on the SD OS partition.
I did this so I could hack before booting without thrashing the internal flash. And obviously the internal initfs could be reworked to pass more responsibility to this 2nd init.
Oh I see, I was confused with '/sbin/init 2' and wifi driver kernel thread and the minishutdown reference too so I thought you tried it at device shutdown time.

Quote:
Originally Posted by daperl (Post 260326)
I just bought a new n810 that should arrive tomorrow, I'm hoping the hardware keyboard will let me fake a terminal at this point in the boot.
Using qemu may be easier, I'll try that when I have some time (pretty scarce thing for me nowadays and no sign of it getting better). qemu can boot kernel directly but in our case the better mode is to let it boot from bootloader and let the emulation run NOLO and load kernel. With real device enabling framebuffer console in both kernels (and/or having serial console attached) could help to see where it fails.

Quote:
Originally Posted by daperl (Post 260326)
It's funny you should mention this. Just yesterday, I took an SD card and I dd' initfs.jffs to the first partition. I then rebuilt the kernel with root=fe09 (/dev/mmcblock1p1) as a cmdline change. Needless to say, it didn't work.
yes, jffs2 does not work directly with block devices (=mmc), tar clone or cp -a of initfs would be better and also ext2 in kernel could help a lot :-)

Quote:
Originally Posted by daperl (Post 260326)
My original plan was to use just one kernel for my proof-of-concept. But if linux is going to boot linux, a minimal loading-linux is certainly the way to go.
Yes and in that case the version of the first kernel doesn't matter much as long as it can load the diablo one from somewhere. Having one kernel as you suggested would be certainly much easier if we can get it to work.

qole 2009-01-28 18:35
Re: Mer v0.6 released
 
Quote:
Originally Posted by fanoush (Post 260412)
Sadly the more experienced person the less time they have for such experiments. There is plenty of people with skills far better than ours, linux-omap list is place to meet them. OTOH sometimes skill can be replaced by luck or lot of time spent trying semi-random things :-)
Wow, fanoush, you summarized my entire approach to hacking on the tablet, right there: ".... skill replaced by ... a lot of time spent trying semi-random things"

And you're right, occasionally that approach succeeds!

daperl 2009-01-28 20:44
Re: Mer v0.6 released
 
Quote:
Originally Posted by fanoush (Post 260412)
Sadly the more experienced person the less time they have for such experiments. There is plenty of people with skills far better than ours, linux-omap list is place to meet them. OTOH sometimes skill can be replaced by luck or lot of time spent trying semi-random things :-)
The sad, universal constant is that their documentation skills are inversely proportional to their technical skills. These people need personal writing assistants. They could also fetch coffee.

And for them, it would be a project, not an experiment. :)

Quote:
Using qemu may be easier, I'll try that when I have some time (pretty scarce thing for me nowadays and no sign of it getting better). qemu can boot kernel directly but in our case the better mode is to let it boot from bootloader and let the emulation run NOLO and load kernel. With real device enabling framebuffer console in both kernels (and/or having serial console attached) could help to see where it fails.
You're probably right, but see my kernel-diversion comments below. I have major-kernel-releases on the brain. Maybe I'll revisit this later.

Quote:
yes, jffs2 does not work directly with block devices (=mmc), tar clone or cp -a of initfs would be better and also ext2 in kernel could help a lot :-)
If I understand you correctly, it sounds like I was trying to mix and match my character and block device metaphors. I think the initfs hard-coded mmcblock devices are valid. And I notice that these 2 [mmcqd] kernel processes are running before the 2nd init. Maybe I'll try this experiment again by compiling ext2 into the kernel and changing my cmdline to "root=fe09 rootfstype=ext2 ..."

But on a jffs note, I've used your jffs mount solution many times, something everyone should have in their toolbox.

Quote:
Yes and in that case the version of the first kernel doesn't matter much as long as it can load the diablo one from somewhere. Having one kernel as you suggested would be certainly much easier if we can get it to work.
I'm probably not spending my time wisely, but I want to know more why Nokia hasn't moved Diablo way passed 2.6.21. Fremantle is currently at 2.6.27 something. So, I'm currently going down this very deep patch and diff rabbit hole. Sorry, but I gotsta know what's on my devices. And I'm convinced I'll have a 2.6.22 running on a n8x0 in the next few days. Although not that big of a deal, I'm already running 2.6.21.7.


All times are GMT. The time now is 16:55.
Page 8 of 8 « First 67 8
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8