Em Qui, 2008-11-20 às 05:56 +0200, Ilya Petrov escreveu: > 2008/11/20 Daniel Ribeiro <[EMAIL PROTECTED]>: > > > Why would you buffer the entire file on ram before flashing?? This makes > > no sense. > > becouse file_fat_read() is stupid,
ack. > becouse it can be read error during file read, ack. But in this case you can check the integrity first, and then load it again. > becouse i`m lazy and stupid too. not ack. You are not stupid. :) > > KERNEL_RAM_BASE(0xa0200000) is not safe at all, gen-blob itself is > > loaded here on gen1. > > On gen2, gen-blob is loaded at 0xa0de0000, your phone reboots because > > you are overwriting gen-blob memory. > > hmm, i`l try place it after blob for now. after blob(0xa0de0000+1MB) it will work better, but you will still be limited to a little over 16MB (memory ends at 0xa1ffffff). > > Why dont you simply use a smaller buffer? > > i`l do so, but it is not so simple as one file_fat_read() call, so i > need more time Yeah, file_fat_read() would not work. But im sure that you can use file_fat_read as reference and implement some block_fat_read() function. > > Anyway, flashing from inside gen-blob is not a good idea at all, the > > mmc/sd code is too buggy to be considered reliable as the source of > > data. > > hmm, maby some checksum? Yeah, checksumming the data on mmc can assert integrity. In this case it would be safe, but the user would need to calculate the checksum previously, making the flashing proccess not so easy. > > But it is a good idea to use gen-blob to flash itself, new users could > > load gen-blob via boot_usb the first time, and have gen-blob to > > automatically backup the kernel partition and flash itself there. > > second part is already done and tested. Great! > you can tell destination address and path to file and it will flash it there. > blob is too small to read it just with one file_fat_read() call. > > do we really need to do backup of original kernel? it can be easylly > extracted from firmware and where can we place backup? Like the idea from the other email. The proccess would be: 1. use boot_usb to load gen-blob. 2. gen-blob reads the kernel partition from flash and copy it to ram, just after gen-blob. 3. gen-blob flashes gen-blob+kernel back to kernel partition. Not a real backup, its a way to eliminate the /boot/default on the mmc card, and boot the original kernel from flash. The issue is the size, as explained on the other thread, enough free size on gen2 but not on gen1. > > I will > > look into implementing something in this direction after the current > > upstream submission round. Of course, you can anticipate me, but note > > that we are interested on a gen-blob that can run on any ezx phone, > > being specific to 2nd gen as your code is now is a regression. > > is buffer address only thing breaking gen1? i never had any gen1 device at all I havent tested the code, but looking at the patch you sent i would say that the only showstopper is the 0xa0200000 buffer. -- Daniel Ribeiro
