* freemangordon_
wonders if it is possible to replace PoP in N900
<DocScrutinizer51>
in theory yes
<freemangordon_>
could you use one of mozilla's devices to try?
<freemangordon_>
I'll buy it if you have success :D
<DocScrutinizer51>
I don't have the tools needed
<freemangordon_>
oh
<DocScrutinizer51>
the rework will cost a few €€€
<freemangordon_>
3630 is pin-compatible with 3430, correct?
che1 has quit [Ping timeout: 265 seconds]
<DocScrutinizer51>
we'll learn soon enough about reworking BB-xM
<freemangordon_>
though, I am not sure NOLO will like such a change
<DocScrutinizer51>
yes, for 168pin PoP they for sure are pin compatible
mvaenskae has quit [Ping timeout: 264 seconds]
mvaenskae has joined #neo900
che1 has joined #neo900
<DocScrutinizer05>
we should get rid of NOLO
b1101 has joined #neo900
che1 has quit [Ping timeout: 255 seconds]
<wpwrak>
YES ! kill, kill, kill ! ;-)
<DocScrutinizer51>
well, nolo is just a bootloader. I heard you're somewhat familiar with those
<wpwrak>
yeah, vaguely ;-)
<DocScrutinizer51>
it seems nolo does some device init that is essential for the device to work
<wpwrak>
the thought of a closed bootloader has something quite revulsive to it. this is just the kind of piece you don't want to have guess about.
<wpwrak>
see :)
<DocScrutinizer51>
exactly
<DocScrutinizer51>
that's why I hope for you and pali joining forces to create a BL that not only works as chainload after nolo (like our current uBoot) but actually could replace NOLO and bring up N900
<freemangordon_>
NOLO works in secure mode? or was it xloader?
<Pali>
xloader is in secure mode
<Pali>
secondary image (nolo) is not in secure mode
<freemangordon_>
well, i guess we can RE NOLO now we have arm hexrays
<freemangordon_>
it is not that big
<wpwrak>
i'm trying not to pile new stuff on my plate. it's not as if there wasn't enough to do already ... also, as things progress, we'll have plenty of additional development work, just to test the prototypes
<Pali>
you can try, but why? we cannot use that info for uboot, because uboot is too big and does not fit into nand :-(
<Pali>
we have no space for adding new features to nolo
<freemangordon_>
yeah
<Pali>
so I do not see reason for rewriting nolo
<wpwrak>
for efficient bootloader development, i would recommend the approach andy green chose with "qi" (but simpler, if possible): just initialize the basics, load the kernel, and be done with it
<freemangordon_>
wpwrak: what about stuff like mmc boot, usb boot, ect?
<wpwrak>
then you can make a small system with initramfs and kexec and realize all your wildest dreams in that
<Pali>
kexec is broken on arm and n900
<freemangordon_>
even in upstream kernel?
<Pali>
looks like for omap3/n900 yes
<Pali>
but maybe it is working
<wpwrak>
sounds like an item worth fixing then :)
<Pali>
I did not tested it
<Pali>
there was problem with display and mmc which was not initialized
<freemangordon_>
wpwrak: why do you think only your plate has lots of stuff on it? :P
<wpwrak>
kexec if basically you "get out of hell" card when it comes to bootloader features. else you end up doing things like u-boot, small kernel wanna-bees ...
<Pali>
I think current approach: xloader --> nolo --> uboot (in kernel partition) --> what you want -- is the best what we can have
<wpwrak>
freemangordon_: i'm working on my delegating and outsourcing skills ;-)
<Pali>
2MB for uboot is enough, so better patching uboot as hacking nolo
<DocScrutinizer51>
I don't care *how* you guys make maemo boot on prototypes with 1GB RAM
<freemangordon_>
wpwrak: oh, you have free manpower? GIVE IT TO ME!!!
<Pali>
DocScrutinizer51: ^^^ I mean for n900 devices
<Pali>
of course I do not see any reason to use nolo in neo900
<Pali>
it will even not work (because nolo is for HS devices)
<freemangordon_>
:nod:
<wpwrak>
freemangordon_: heh, you wish :)
<freemangordon_>
u-boot is the way to go IMO
<wpwrak>
i would try to drop u-boot, too. it's just a mess. and why duplicate tons of kernel functions if you already have a perfectly good kernel ?
<wpwrak>
and the first stage loader can be extremely simple, as andy's "qi" has proven
<wpwrak>
didn't develop this critter further, though. it was meant mainly as an inspiration for others
<Humpelstilzchen>
wasn't the point behind qi problems with uboot in freerunner where the problems where caused by the openmoko patches?
<freemangordon_>
BTW, who's going to code those pieces fo Neo900? first/second stage bootloaders?
<wpwrak>
Humpelstilzchen: very possible :) openmoko tried aggressively to extend u-boot. but it's just too weak a basis. so in the end we had a crippled baby brother of the linux kernel ...
<Pali>
cannot we use x-load and uboot from TI?
<Pali>
or uboot SPL?
<DocScrutinizer05>
I don't care what we use, as long as it brings up maemo
<freemangordon_>
:)
<freemangordon_>
my point exactly :P
<DocScrutinizer05>
and afaik replacing NOLO with uBoot did result in non-booting N900 devices so far
<DocScrutinizer05>
so there must be some tiny "magic" in NOLO that needs porting to whatever you love most for BL
<DocScrutinizer05>
I'd not be surprised if is was around PVR
<wpwrak>
my suggestion would be a loader that loads one kernel image from one source. could be from NAND or from MMC. then we can put all the fun stuff into the kernel. later, we can always teach the first stage loader new tricks
<DocScrutinizer05>
whatever you like
<DocScrutinizer05>
just the point is: so far it seems people failed on that, on N900
<Humpelstilzchen>
why tech the first stage new tricks? I'ld stick to the 2nd
JoHnY_ has joined #neo900
<DocScrutinizer05>
that's why I suggested replacing NOLO on N900. when it works there, it will also work on Neo900
<wpwrak>
Humpelstilzchen: that's also an option. but sometimes it can make sense to have a plan B also in the first stage
<DocScrutinizer05>
Humpelstilzchen: I couldn't be less emotional about *how* you make maemo on N900 boot without NOLO
<DocScrutinizer05>
and we hardly will mess with first stage which is xloader
<DocScrutinizer05>
aka MLO
<wpwrak>
Humpelstilzchen: in any case, the first stage should be dead simple. and the second stage should be linux. we need to do all the driver etc. work for linux anyway, so who not just use that for the boot loader as well ?
gurki_ has joined #neo900
<freemangordon_>
we can't touch xloader on n900, unless we steal the signing keys from Nokia
<DocScrutinizer05>
the first stage should be signed and fit into 64kb of RAM
<DocScrutinizer05>
the second stage should bring up a decent kernel
<DocScrutinizer05>
and provide all the stuff maemo needs for booting
<freemangordon_>
or invent a quantum computer to break the RSA
<Humpelstilzchen>
wpwrak: doesn't the 2nd needs to set tup the RAM to copy the kernel in to?
arcean has joined #neo900
<DocScrutinizer05>
no, RAM setup needs to get done by 1st stage
<wpwrak>
Humpelstilzchen: do that in the first stage. ah, i don't mean these stages too literally. depending on implementation constraints, a stage may have to have sub-stages. but they'd be parts of the same program.
<DocScrutinizer05>
and that's another possible problem, maybe xloader does incomplete RAM setup
<wpwrak>
like lilo had a tiny first stage that brought in all the rest of lilo
<wpwrak>
dunno if xloader sets up the memory nicely enough, but something like basically xloader -> linux would keep things nice and simple. if xloader can't do that, we'd need a bit of glue. maybe some "xloader done right", i.e., something that can then run standalone (without xloader) on neo900
<DocScrutinizer05>
hmmpf, in 64kB
<Humpelstilzchen>
wpwrak: and what do we do with a broken kernel?
<wpwrak>
the linux that gets booted by this would then be a trimmed system. you can do that by just starting with an empty rootfs and installing specific packages. did that at openmoko. DocScrutinizer05, you'll remember the little system for modem flashing :)
<Humpelstilzchen>
wpwrak: if your kernels fails to boot, you just use the uboot shell to boot another
<wpwrak>
Humpelstilzchen: that's equivalent to any other severe bricking. so you go to flash-from-scratch-over-usb (or similar)
<wpwrak>
Humpelstilzchen: this kernel is supposed to be stable. you then kexec to the "application" kernel
<Humpelstilzchen>
wpwrak: only
<Humpelstilzchen>
wpwrak: ARM kernel seems to fail from time to time
<wpwrak>
the trick is that the kernel used for booting has access to the whole world of linux
<wpwrak>
well, don't install before testing ;-)
<DocScrutinizer05>
huh? ARM kernel fails?
<wpwrak>
it's the same with u-boot: if you install a broken version of u-boot, you're dead in the water as well
<Humpelstilzchen>
right, but u-boot seems to get more tests on ARM then linux
<DocScrutinizer05>
that's a moot argument
<wpwrak>
so the normal sequence would be: [xyz]loader -> boot kernel --(kexec)--> user kernel
<wpwrak>
the boot kernel has access to all the drivers and protocols linux supports
<wpwrak>
(conceptually - of course, you may want to exercise some restraint :)
<DocScrutinizer05>
when you manage to cram all this into bootloader NAND partition of limited size
<bencoh>
kexec on arm isnt exactly the most reliable "techno" I can think of
<wpwrak>
the space-constrained part is the [xyz]loader. afterwards you can already pick a decently sized source.
<DocScrutinizer05>
ot when your system has only 254MB of NAND ad most of that is used for rootfs
<bencoh>
linux on arm is tested/used in every kind of plateform and I have no doubt about it being intensively tested, but kexec is another story
<bencoh>
especially regarding device/peripherals (re)init
<wpwrak>
bencoh: maybe there's a chicken and egg problem: people don't use it because it's perceived as unreliable, and since nobody uses it, bugs don't get fixed ...
<bencoh>
wpwrak: I dunno
<bencoh>
maybe it's just not the kind of thing people arent used to
<bencoh>
even on x86 I see pci devices which wont support it
<bencoh>
(well, pci device drivers* to be more specific)
<DocScrutinizer05>
.oO(???)
<bencoh>
broken driver which wont reset some registers at boot, which basically means your card might be in the state you left it
<bencoh>
which can lead (in my example) to enabled DMA and interrupts, while the interrupt handler isnt properly set -> ooops!
<wpwrak>
we'll have the advantage that our use case still has a controlled environment for the boot kernel. so kexec doesn't have to work - in our case - out of a "hot" regular system that's already doing gazillions of things
<DocScrutinizer05>
which is exactly the purpose of any bootloader, no?
<wpwrak>
bencoh: sounds like a classical hunt and kill mission ;-)
<bencoh>
DocScrutinizer05: dunno whose responsibility it should be (I still think the driver should do some checking) but I think that's a typical example where kexec would give headaches ;)
<bencoh>
wpwrak: yeah
<DocScrutinizer05>
when your BL kernel enables interrupts, then who's to blame? ;-D
<bencoh>
BL ?
<DocScrutinizer05>
BootLoader?
<bencoh>
oh
<wpwrak>
to weed out this sort of problems, one could also check for active DMA channels and maybe wait a few seconds for interrupts. if something shows up, the problem can be reported in a controlled way and it then shouldn't be too hard to find and fix the culprit.
<bencoh>
to be honest I believe the culprit in this specific case is the driver :)
<bencoh>
(another example where it would fail is in vm env with iommu/pci-passthrough)
<wpwrak>
hah ! fix one driver and all sorts of users get to celebrate ;-)
<DocScrutinizer51>
how's that related to NOLO or uBoot?
<bencoh>
not related to nolo or uboot, just to the kexec discussion
<bencoh>
and "why it might/could/would fail in some cases" and "why it might be less reliable than a plain bootloader"
<DocScrutinizer51>
the kexec discussion IS about bootloaders
<wpwrak>
it's about the concern that kexec is just too unreliable. it seems that this sort of perception often comes from drivers that are broken anyway, and one just runs into all their problems with kexec, while other users experience these problems at a lower density.
<bencoh>
wpwrak: yup
<bencoh>
(although kexec has its share of bugs)
<bencoh>
anyway, back to reading linux/fs/cifs/ code ....
afics__ has joined #neo900
<wpwrak>
bencoh: you mean kexec in general or kexec on arm ? on x86, people seem to have gotten quite confident about it. even with kexec on crash, etc. now that's scary :)
<bencoh>
on arm
<wpwrak>
yeah, maybe there's some catching up to do
<DocScrutinizer51>
tbh I don't even care when you use a non-standard nonsigned xloader and some BS2000 as 2nd stage. As long as it brings up maemo on a 1GB RAM tweaked BB-xM
<DocScrutinizer05>
however I have to remark that uBoot on gta04 already works afaik
<bencoh>
neat :)
<DocScrutinizer05>
hm?
<DocScrutinizer05>
it does since err 4 years?
<DocScrutinizer05>
3?
<DocScrutinizer05>
the task at hnd is: make uBoot boot up maemo
<DocScrutinizer05>
on a 1GB RAM system
<DocScrutinizer05>
s/uBoot/$whatever/
<DocScrutinizer05>
I.E. have 512MB NAND initialized, have 1GB (in two banks) of RAM initialized, then provide ATAGS and whatever else it needs to make maemo kernel happy when it's started after loading it from NAND
<DocScrutinizer05>
and I think even chainloaded uBoot had a 100% doesntwork on certain hw revisions of N900. Pali should know details
<DocScrutinizer05>
major suspected culprit: RAM config
<Pali>
DocScrutinizer05: no it is working
<Pali>
problem was with onenand uboot code
<Pali>
that onenand support does not working
<Pali>
and when it was enabled at compile time it caused problems on some hw revisions (no boot)
<Pali>
but when is disabled at compile time, there is no problem
<Pali>
and memory banks configration is set also in kernel DT
<Pali>
so bootloader does not need to set that in ATAGs
<Pali>
or better, bootloader can provide full DT
modem has quit [Ping timeout: 250 seconds]
afics__ is now known as afics
modem has joined #neo900
<bencoh>
Pali: does than mean we can chainload microsd uboot from nand uboot ?
<DocScrutinizer51>
keep in mind that a standard powerkernel50+* is supposed to boot without any problems on Neo900, and iirc this has no DT
<Pali>
bencoh: NOLO loads uboot from NAND to RAM and then it execute. and then uboot can boot anything from ROM, RAM, uSD or eMMC
<kerio>
bencoh: sure, why not
<kerio>
i have uboot-bootimg installed
<kerio>
it boots nicely from itself
<bencoh>
Pali: I mean, chainload uboot, not load a kernel/initrd from sd
<Pali>
DocScrutinizer51: uboot can still provides all needed ATAGs, so there is no problems with old kernels
<DocScrutinizer51>
that's the way :)
<Pali>
bencoh: uboot can load & execute any image, there is no difference between kernel and uboot, both images are just executable arm code
<bencoh>
okay
<bencoh>
I'll have to give it a try then
<Pali>
you just need RAW executable image (no ELF, not other funny formats)
<bencoh>
hm, yeah
<bencoh>
would standard SPL qualify ?
<bencoh>
(do we have SPL in n900 uboot ?)
<Pali>
but normally uboot boots some special images which are RAW images with special uboot header. you can generate it via uboot program mkimage (set type to kernel!!)
<Pali>
I can normally boot uboot image from eMMC via exeisting uboot in RAM :D
<bencoh>
hmm right I would still need a uboot header
<Pali>
I think SPL for n900 does not work
mvaenska1 has joined #neo900
mvaenskae has quit [Quit: leaving]
mvaenska1 has quit [Quit: leaving]
mvaenskae has joined #neo900
mvaenskae has quit [Signing in (mvaenskae)]
mvaenskae has joined #neo900
SylvieLorxu has joined #neo900
GMsoft has joined #neo900
<kerio>
Pali: my uboot has a "uboot" menu entry
<kerio>
:3
<Pali>
:D
<kerio>
i still don't agree with the way the kernels are handled the maemo packaging
<kerio>
i hope we can do better for fptf
<kerio>
(maybe matching the way debian does it)
zrafa has quit [Ping timeout: 256 seconds]
zrafa has joined #neo900
<bencoh>
kerio: what does it contain ?
<kerio>
each kernel is in a new package
<kerio>
it's not uninstalled when the new kernel is installed
<kerio>
the bootloader just points to the most recent one
<bencoh>
err sorry I was talking about the uboot menu entry ... (how debian handles kernel is interesting nonetheless)
<kerio>
oh
<kerio>
well
<kerio>
it's the standard entry from uboot-bootimg
<bencoh>
oh, okay
<kerio>
it's called "U-Boot <something>"
<kerio>
and when you run it, it runs uboot
<bencoh>
:)
merlin1991 has joined #neo900
illwieckz has quit [Ping timeout: 264 seconds]
sixwheeledbeast1 is now known as sixwheeledbeast
illwieckz has joined #neo900
modem has quit [Quit: Quitte]
<mvaenskae>
can someone tell me whether it is possible to boot from a usb-stick on the neo900 or just from the internal nand?
<kerio>
the neo900 doesn't exist
<kerio>
can uboot do usb?
<kerio>
Pali: will uboot on neo900 do usb?
<Pali>
depends on usb host mode...
<kerio>
i assume the neo900 will have usb otg
<Pali>
uboot has support for usb, so it could be possible
<mvaenskae>
nice, this allows then for proper fde on the neo900 :)
<mvaenskae>
obviously this makes booting a bit of a hassle but have fun breaking in :)
<kerio>
fde?
<kerio>
oh, full disk encryption
<kerio>
...what do you need usb for?
<mvaenskae>
how am i saving the kernel if every bit is encrypted :)
<kerio>
why the fuck would you need an encrypted kernel
<mvaenskae>
kerio: no, that's not what i meant
<mvaenskae>
if i use fde then there is no way i can store the kernel on that "disk"
<kerio>
yes
<mvaenskae>
else it would not be FULL disk encryption :)
<kerio>
so that's why you leave the kernel on a separate partition
<mvaenskae>
or go true fde and have the kernel on a usb
<mvaenskae>
it is a bit more cumbersome but then just by stealing the device one cannot easily grasp what happened to the chips :)
<kerio>
yes
<kerio>
the big storage unit with seemingly random data will be absolutely suspicious
<kerio>
they will never guess it's encrypted
<mvaenskae>
kerio: could have just wiped it with /dev/urandom to prepare for further data ;)
<kerio>
or, you know
<kerio>
/dev/zero
<kerio>
so the controller can mark pages as unused instead of having to keep a whole everything of data on hand
<mvaenskae>
what is /dev/zero? ;)
<mvaenskae>
:D
<kerio>
assuming you're talking about the emmc
<kerio>
cuz writing urandom on the nand is just shitting on any kind of possible write performance
<mvaenskae>
the controller can decide to ommit data writes and just mark the corresponding areas as unsused?
<mvaenskae>
*unsued
<kerio>
DocScrutinizer51: feature request: TRIM
<mvaenskae>
what would be if i read out such an area?
<kerio>
mvaenskae: that seems like a simple enough optimization
<kerio>
huh.. controller sees "unused area" in the list and returns 0
<kerio>
it's not like you get the actual data in any position
<mvaenskae>
TRIM is usually dependant on the FS btw; at least btrfs has such a mount-option
<kerio>
yes, but you need a controller that understands it
<mvaenskae>
kerio: if one were to replace the controller with one that returns the actual content disregarding of the "is used"-bit i could still reconstruct data i wanted to get removed?
JoHnY_ is now known as JoHnY
<kerio>
erasing a page is a destructive operation
<kerio>
similarly to TRIM for ssds
<mvaenskae>
but you just said the controller could just decide to ommit data writes and mark the area as unused
<kerio>
no, i said the controller could just decide to omit data writes, erase the underlying page and then mark the area as unused
<mvaenskae>
page != area ?
<kerio>
page = storage unit of the underlying flash
<kerio>
NAND flash requires "expensive" erase operations before being able to write something in a page that's not empty
<kerio>
so, either the controller in the case of SSDs, or the file system algorithms in the case of filesystems that work directly with MTDs, usually try to use the empty pages before erasing the old ones
che1 has joined #neo900
<kerio>
if you're using a file system on a MTD, or you're using a SSD with a file system that supports trim, there's some garbage collection going on in the background
<kerio>
unused pages are erased when there's nothing else going on
<kerio>
so they're ready to be written to, once the need arises
<mvaenskae>
one can stop the erasing though, right?
<kerio>
in which case?
<mvaenskae>
similiar to trim
<kerio>
ubifs, no
<kerio>
SSDs, sure - just don't send TRIM commands
<kerio>
(aka remove the "discard" option in fstab)
<mvaenskae>
from what i understand trimming is the process of taking unused pages which are holding invalid data and erasing them to 0
<kerio>
you don't erase them to anything
<kerio>
you tell the controller that you don't need them
<kerio>
they stop holding data
<kerio>
(NAND flashes are usually 1s when erased)
<mvaenskae>
oh, interesting; and for emmc?
<kerio>
the n900 emmc is dumb as fuck
<kerio>
so nothing of this sorts happens
<kerio>
but i'm fairly sure, from empirical tests, that writing zeros all over "cleans" it
<kerio>
cuz the subsequent write operations are fast
<kerio>
which usually means that the controller did erase pages in the underlying flash
<kerio>
regardless of what happens, writing zero is pretty much as good as writing random shit all over, for the purpose of privacy
<kerio>
if there was a way to save the new data *and* the old data, the manufacturer would've used it to **store more data**
<kerio>
which is what you pay them for
<mvaenskae>
don't SSDs these days have some extra amount of memory which they can attach after detaching the bad blocks?
<mvaenskae>
thus prolonging their life
<kerio>
sure
<kerio>
well, it's not that they "attach" them
<kerio>
they just have more space than the amount they show
<mvaenskae>
true, i worded that awkwardly :)
<kerio>
so they have a lot of slack if some blocks end up being bad
<kerio>
your data isn't really written *that* sequentially
<kerio>
it's written in big chunks, all over the flash
<mvaenskae>
that's why there are multiple chips i gather :) let's just parallelize and keep a LUT for where we actually stored what
useretail has quit [Remote host closed the connection]
che1 has quit [Ping timeout: 264 seconds]
<kerio>
well, each chip has multiple pages
<mvaenskae>
i need to sadly go now home, studies were moderatly successful today :/