**** BEGIN LOGGING AT Fri May 09 02:59:56 2008 May 09 11:30:51 03marceln * r8295 10optware/trunk/make/vblade.mk: vblade: 14 -> 16 May 09 15:09:04 is slug firmware is intresting in change the bootloader support? May 09 18:42:16 j24: One of the requirements of the various firmwares for the NSLU2 projects is that they must not require alterations to the existing redboot bootloader. This is so that users do not risk bricking the devices. May 09 18:42:47 j24: We work around this limitation by using the APEX bootloader as a second-stage bootloader after Redboot. May 09 18:43:13 j24: Do you have specific reasons or goals for changing the bootloader that cannot be done using APEX? May 09 18:55:56 mwester: u-boot is better May 09 18:56:12 Yes, but installing it risks bricking the device. May 09 18:56:51 But there are several folks who are working on u-boot for the NSLU2. It just won't be something that will be required by any firmwares. May 09 18:57:44 The nslu2 will be in the next u-boot release May 09 18:59:00 That's good news. Last I heard there was still an outstanding issue with the PHY for the network. May 09 19:00:35 I've nearly fix everything and port the new network drivers May 09 20:03:44 mwester: U-Boot could also be use as second or third bootloader May 09 20:03:56 It's done for the at91 cpu May 09 22:48:56 j24: welcome! May 09 22:49:21 (j24 is the ixp4xx maintainer for u-boot, so he is the person who will be merging the new nslu2 support into u-boot) May 09 22:50:11 j24: we currently use apex, cause it has some specific code to get around a vendor redboot limitation (it copies a ramdisk from a fixed location in flash, which limits the kernel to 1MB) May 09 22:50:25 But apex does not have network support. May 09 22:50:46 I have verified that u-boot/nslu2 works as a second-stage bootloader, and can be accessed via netconsole. May 09 22:51:14 So eventually I want to add the same support into u-boot to work as a second stage bootloader and to work around the vendor redboot limitation May 09 22:51:37 (basically, it has to skip 16 bytes in flash whenever reading or writing across a certain location May 09 22:52:42 mwester: we're working on both first-stage and second-stage u-boot support (but would only put second stage in public images) May 10 00:35:40 rwhitby: slugimage finally did work for me - I got the updated version (but didn't need it with "-r Flashdisk:Flashdisk" parameters May 10 00:36:23 excellent. so you're all up and running now? May 10 00:37:09 rwhitby: affirmative. Also updated apex for slugosbe. Not sure if it was needed but I used the one I built that specified 16mb in the filename (replaced it from build via slugosbe). May 10 00:37:36 yes, you need the 16mb apex so it looks in the right place for the fis directory May 10 00:39:08 I used your newer redboot, updated with my MAC. I haven't installed any apps yet and haven't confirmed whole 16mb flash is detected by slugosbe. However, makes me wonder, part of the build process, there's a file called "slugosbe-4.10-alpha-nslu2-16mb.bin". From the filename, I would take that to mean it supports 16mb flash, so is apex 2nd stage replacement with apex "apex-slugos-nslu2-16mb-armeb-1.5.13.bin" necessar May 10 00:39:56 Specifically, does the apex that comes with slugosbe-4.10-alpha-nslu2-16mb.bin file already support 16mb flash? May 10 00:39:59 no, it should have already built and put the 16mb apex into that image May 10 00:40:09 so yes, it already supports it May 10 00:40:30 (I flash that slugosbe-...-16mb.bin image all the time) May 10 00:40:31 ok, I did see a difference in file size between apex extracted via slugimage and the apex built in ~/kernel May 10 00:41:37 apex.bin - from slugimage = 48680, apex...16mb...1.5.13 is 48648 May 10 00:43:04 Both show version 1.5.13 (header - at position 0x7-0xd). May 10 00:47:15 Just curious why apex built into slugosbe is different than apex built stand-alone. Doing "xxd file.bin >file.hex" on both versions, there are a lot of differences between the two (at least 12*70 lines different via diff = about 11*70/2*8 bytes different) May 10 00:48:39 Thanks for your help with redboot. Once I confirm your redboot, attempt to reverse-port to older redboot (if possible), then post deltas on wiki and encourage more 16MB slugs. May 10 01:16:28 rwhitby: just confirmed, 256MB RAM and 16MB flash detected via apex/slugosbe. Cool... just wonder if same kernel bug (>64MB) is in this one as in the etch debian. **** ENDING LOGGING AT Sat May 10 02:59:57 2008