[00:00] <nbd> but if we flash a jffs2 image we can assume that it takes all blocks from the beginning until our end marker
[00:00] <[mbm]> ok so if I have
[00:00] <[mbm]> [firmware ... ] [ jffs2 ] [ something ]
[00:01] <[mbm]> and that suddely changes to
[00:01] <[mbm]> [firmware ............ ] [ jffs2 ] [ something ]
[00:01] <nbd> i'm not talking about squashfs+jffs2 at all
[00:01] <[mbm]> with a much bigger firmware overwriting part of jffs2, how is an end marker supposed to help?
[00:01] <nbd> i'm only talking about having jffs2 as root filesystem
[00:02] <nbd> without any squashfs parts
[00:02] <[mbm]> *mumble* why didn't you say that in the first place?
[00:02] <nbd> i thought i did
[00:02] <nbd> actually the first line
[00:02] <nbd> :)
[00:03] <[mbm]> well, wasn't clear if you meant the squashfs with jffs2 root or the jffs2 only
[00:03] <nbd> ok
[00:03] <nbd> do you see what i mean now?
[00:03] <[mbm]> ok, so I flash [firmware [ jffs ... ] [end marker] ]
[00:04] <[mbm]> and it's smart enough to erase everything after the end marker
[00:04] <nbd> yes
[00:04] <nbd> including the end marker itself
[00:04] <[mbm]> right
[00:04] <[mbm]> makes sense
[00:04] <nbd> we'd still need jffs2root on broadcom to modify the trx
[00:04] <[mbm]> right
[00:04] <nbd> but the extra reboot would be gone
[00:05] <[mbm]> not quite
[00:05] <[mbm]> we'd still need to implement an ioctl to rescan the trx header and recalculate the partitions
[00:05] <nbd> well, if we tell the mtd map to cover the whole firmware area from the beginning
[00:05] <nbd> then we don't need a rescan
[00:05] <nbd> simply have it use the right layout from the start, whether it's already in the trx or not
[00:06] <[mbm]> that's the problem .. jffs2 has no superblock so it's hard for the kernel to detect it when setting up the mtd partitions
[00:06] <nbd> squashfs has one
[00:07] <[mbm]> that only works on the assumption that if it isn't squashfs it must be jffs2
[00:07] <[mbm]> but I suppose that will work for now
[00:07] <nbd> well, we can start implementing this for other platforms first
[00:07] <nbd> and when it works there, we can deal with broadcom
[00:08] <[mbm]> ok
[00:08] <nbd> i came up with this idea right now, because i'm currently trying to build routerboard images that work with any cf card size and use jffs2
[00:09] <[mbm]> at some point we need to address the issue of dealing with jffs2 durring upgrades
[00:09] <[mbm]> particularly how to preserve /etc/config so the settings don't get wiped out every reflash
[00:09] <nbd> yes
[00:10] <[mbm]> the idea I mentioned before was always upgrading via an mtd script that copied important data to a ramdisk, reflashed and then copied back to the new jffs2 partition
[00:11] <[mbm]> meaning that if you ever reflashed any other wy your settings would be lost
[00:11] <[mbm]> (which actually might be a feature considering we don't know what state the last firmware left things in)
[00:11] <nbd> yeah
[00:11] <nbd> for the ramdisk stuff we definitely need the rescan ioctl
[00:12] <[mbm]> yep
[00:12] <nbd> the annoying thing about the routerboard is that it requires a dos partition table with a 4 MB kernel partition
[00:12] <[mbm]> eww
[00:12] <nbd> but i'll just generate a partition table with only one partition and figure out the rest dynamically
[00:13] <[mbm]> but then you're using a compact flash card so 4M really isn't that much
[00:13] <nbd> yeah
[00:13] <nbd> the partition table is the annoying part :)
[00:13] <[mbm]> you're still using jffs2 on a compact flash?
[00:13] <nbd> at the moment i'm using ramdisk only
[00:13] <[mbm]> (didn't think those got assigned an mtdblock)
[00:13] <[mbm]> ah
[00:13] <nbd> they don't
[00:13] <nbd> i intend to use a modified block2mtd
[00:14] <[mbm]> well, here's a tip mtdloop
[00:14] <nbd> mtdloop?
[00:14] <[mbm]> think that's the name of it
[00:14] <[mbm]> lets you mount any file/device loopback as an mtdblock
[00:14] <[mbm]> adter it's an mtdblock you can run jffs2 on it
[00:14] <nbd> block2mtd does that
[00:14] <nbd> well, with block devices
[00:15] <[mbm]> which means that you can even mount jffs2 firmware images on your pc
[00:15] <nbd> and it's in the kernel already
[00:15] <[mbm]> (it was discussed on the forum)
[00:16] <[mbm]> http://forum.openwrt.org/viewtopic.php?pid=26462#p26462
[00:16] <nbd> ah, that uses blkmtd
[00:16] <nbd> block2mtd is the rewrite of blkmtd
[00:16] <nbd> blkmtd is deprecated in current 2.6
[00:44] <CIA-18> mbm * r3946 / (3 files in 3 dirs): fix display of uninitialized ports
[00:45] <[mbm]> nbd: that should fix the switch issue
[01:00] <RoDent> I am now seriously laughing my arse off
[01:00] <RoDent> So, I have this sveasoft account see.
[01:00] <RoDent> And I downloaded the fabled Talisman that supports "WVLANs" or multiple ssids, as normal people know it.
[01:01] <RoDent> So I add a "WVLAN" using the webif, and reboot.
[01:01] <RoDent> Only to be greeted with an oops at bootup :)
[01:01] <RoDent> Oops in fault.c::do_page_fault, line 206:
[01:01] <RoDent> etc... :)
[01:02] <RoDent> Process wlconf (pid: 156, stackpage=80e6c000)
[01:02] <RoDent> Haha
[01:02] <[mbm]> ...
[01:03] <RoDent> What was interesting, is that with only one "wvlan" enabled.
[01:03] <RoDent> His wireless interfaces started at "wl0.1"
[01:03] <RoDent> No wl0
[01:03] <RoDent> I shall give that tactic a try.
[01:04] Action: [mbm] wonders why this is even being discussed here
[01:05] <RoDent> I saw the earlier banter about it. Just thought I'd investigate the claims.
[01:05] Action: RoDent stops mentioning it.
[01:05] <nbd> was the wireless interface called 'wl0'?
[01:05] <RoDent> No. it was wl0.1
[01:05] <nbd> i mean the main interface
[01:05] <nbd> ok, so he didn't copy my interface rename hack...
[01:05] <nbd> :)
[01:06] <RoDent> :)
[01:06] <RoDent> Was that the default driver behaviour ?
[01:06] <nbd> default is ethX as main interface and wl0.X for virtual interfaces
[01:06] <nbd> i changed it to use wl0 as main interface name
[01:07] <RoDent> Yeah, I saw that bit of sed hacking in the Makefile :)
[01:07] <RoDent> I thought not having a wl0/eth0 was the default behaviour - that's why I asked.
[12:29] <florian__> did mickael or any bcm43xx developper answered you
[12:30] <florian__> because you did a great work, but it looks like they are really not interested in getting AP mode working, either because they want to stabilize the client mode, or because they do not care
[13:07] <NDL> florian__: As I wrote already at openwrt forum, I had a talk with Michael about integrating that patch to the main source tree.
[13:07] <NDL> However, of course, I do not have influence to demand that from anybody ;-)
[13:08] <NDL> florian__: So far, there was smb interested on bcm43xx-dev in bringing it up at the BE machine.
[13:09] <NDL> florian__: I'm not sure if it was developer of bcm43x, or some user that wanted it for personal use.
[13:11] <NDL> florian__: anyway, you're right that it seems nobody from developers is really interested in having full AP mode implementation.
[13:12] <NDL> florian__: I've tried to get more info from specs group about PS implementation in AP mode, and while they were quite responsive, they do not have too much info on that and it seems they're not really interested in investigating that topic further.
[15:02] <nbd> NDL: what's the problem with your patch? i'd like to help
[15:19] <NDL> nbd: well, that's not the problem with the patch exactly, but with the fact that it's not yet merged in the main development tree of bcm43xx
[15:19] <nbd> has it been updated to their latest version?
[15:19] <NDL> nbd: yes.
[15:20] <NDL> nbd: I sill hope it will be merged, though.
[15:20] <NDL> nbd: (there's not that much time passed from the moment I posted the updated version, so it's just possible noone from developers had time to merge it)
[15:44] <CIA-18> nbd * r3947 /branches/buildroot-ng/openwrt/toolchain/gcc/Config.in: fix gcc version selection
[18:40] <CIA-18> nbd * r3948 /branches/buildroot-ng/openwrt/toolchain/ (Config.in gcc/Config.in gcc/Config.version): fix menuconfig developer options structure
[18:41] <CIA-18> nbd * r3949 /branches/buildroot-ng/openwrt/package/dropbear/Makefile: fix dropbear depends and defaults
[18:42] <CIA-18> nbd * r3950 /branches/buildroot-ng/openwrt/package/hostapd/Makefile: fix hostapd-mini dependencies
[19:21] <CIA-18> nbd * r3951 /branches/buildroot-ng/openwrt/package/base-files/ (22 files in 16 dirs): clean up handling of the root filesystem mount - remove broadcom specific junk from the generic base-files part
[19:22] <CIA-18> nbd * r3952 /branches/buildroot-ng/openwrt/target/linux/ (generic-2.6/files/init.d/ kernel.mk): remove old junk
[20:26] <CIA-18> nbd * r3953 /branches/buildroot-ng/openwrt/package/hostapd/Makefile: remove global hostapd builddep on openssl
[20:32] <CIA-18> nbd * r3954 /branches/buildroot-ng/openwrt/package/openssl/Makefile: add openssl depend on zlib
[20:35] <[mbm]> wow, webif manages to use every css color notation syntax :P
[20:36] Action: [mbm] starts cleaning up the css
[20:38] <Kaloz> nbd: for some reason it still wants to build openssl
[20:39] <nbd> ah, the dependency system isn't smart enough to handle that situation yet
[21:17] <CIA-18> mbm * r3955 /branches/whiterussian/openwrt/package/webif/files/www/webif.css: a much cleaner version of the css theme
[22:05] <nbd> xrg_: ping
[22:05] <xrg_> yeah?
[22:06] <nbd> did you know that the upper 512 bytes of ram on the routerboard are not usable?
[22:07] <xrg_> Do you mean RAM as that on the ram chip?
[22:07] <xrg_> sth like a vector?
[22:07] <nbd> i mean when you try to use it as ram in linux
[22:07] <nbd> you get a data bus error if you hit that area
[22:07] <nbd> i found a note of yours in the code, something like TODO: fix memory map
[22:08] <nbd> before i found that, i literally spent hours tracking down a crash in block2mtd
[22:08] <xrg_> yes..
[22:08] <nbd> because it would always crash when erasing the cf
[22:08] <nbd> and now i found out it's due to that ram limitation
[22:08] <xrg_> Actually, with block, there could be the chance of rewritting the CF driver to be a mtd instead of a block.
[22:09] <xrg_> There was sth with the -512 mem calculation..
[22:09] <xrg_> Let me read the files and remember..
[22:09] <nbd> well, now you know that this is important :)
[22:09] <nbd> i will try to fix it
[22:09] <nbd> but i don't know the proper place for a fix yet
[22:10] <xrg_> #define RAM_SIZE (32*1024*1024 - 512)
[22:10] <xrg_> 0x80000400 /* Leave room for interrupt vectors */
[22:10] <xrg_> ...
[22:10] <xrg_> Let us see..
[22:11] <xrg_> it is prom.c:161
[22:11] <xrg_> define: DEBUG_DDR=1 first..
[22:12] <nbd> i think i'll just duplicate some code from parse_cmdline_early
[22:12] <nbd> then i can just subtract 512 bytes from the mem= parameter
[22:12] <nbd> as a hack i already did this in the generic code and it worked
[22:13] <xrg_> You could use the 'IGNORE_CMDLINE_MEM' arg..
[22:13] <nbd> yes
[22:13] <nbd> that's the plan
[22:13] <xrg_> and then, the mem size will be read directy from the registers.
[22:13] <xrg_> on which, you can just do the arithmetics.
[22:14] <nbd> you mean, i can just manipulate the boot_mem_map thing?
[22:15] <xrg_> which one? where is the boot_mem_map ?
[22:15] <nbd> arch/mips/kernel/setup.c
[22:15] <nbd> it's the place where the global memory map is stored
[22:16] <nbd> or just add a new memory region to the upper 512 bytes?
[22:16] <nbd> yeah, i think that'll work
[22:17] <nbd> i could add it as BOOT_MEM_ROM_DATA
[22:17] <nbd> or BOOT_MEM_RESERVED
[22:17] <xrg_> Try only to alter code in the rb500 files, not the generic ones.
[22:17] <xrg_> What you say seems reasonable.
[22:17] <nbd> i was planning on doing that
[22:18] <nbd> i don't want to mess with the generic code
[22:18] <xrg_> we are then talking about the add_memory_region(....) on prom.c:161, right?
[22:19] <xrg_> brb
[22:24] <nbd> yes
[22:24] <nbd> i'm almost done creating flashable cf card images
[22:27] <xrg_> back..
[22:30] <[mbm]> .
[22:30] <nbd> yay... it works :)
[23:18] <nbd> haha... i just finished a first version of the image building code for the rb532
[23:19] <nbd> it's a bit crazy, though: http://pastebin.com/711623
[23:44] <CIA-18> nbd * r3956 /branches/buildroot-ng/openwrt/target/ (18 files in 5 dirs): add rb532 support
[23:44] <nbd> :)
[23:47] <xrg_> :D
[23:58] <CIA-18> mbm * r3957 /branches/whiterussian/openwrt/package/webif/files/ (usr/lib/webif/webif.sh www/webif.css): fix some webif rendering bugs
[00:00] --- Fri Jun 16 2006
[00:00] <[mbm]> ok so if I have
[00:00] <[mbm]> [firmware ... ] [ jffs2 ] [ something ]
[00:01] <[mbm]> and that suddely changes to
[00:01] <[mbm]> [firmware ............ ] [ jffs2 ] [ something ]
[00:01] <nbd> i'm not talking about squashfs+jffs2 at all
[00:01] <[mbm]> with a much bigger firmware overwriting part of jffs2, how is an end marker supposed to help?
[00:01] <nbd> i'm only talking about having jffs2 as root filesystem
[00:02] <nbd> without any squashfs parts
[00:02] <[mbm]> *mumble* why didn't you say that in the first place?
[00:02] <nbd> i thought i did
[00:02] <nbd> actually the first line
[00:02] <nbd> :)
[00:03] <[mbm]> well, wasn't clear if you meant the squashfs with jffs2 root or the jffs2 only
[00:03] <nbd> ok
[00:03] <nbd> do you see what i mean now?
[00:03] <[mbm]> ok, so I flash [firmware [ jffs ... ] [end marker] ]
[00:04] <[mbm]> and it's smart enough to erase everything after the end marker
[00:04] <nbd> yes
[00:04] <nbd> including the end marker itself
[00:04] <[mbm]> right
[00:04] <[mbm]> makes sense
[00:04] <nbd> we'd still need jffs2root on broadcom to modify the trx
[00:04] <[mbm]> right
[00:04] <nbd> but the extra reboot would be gone
[00:05] <[mbm]> not quite
[00:05] <[mbm]> we'd still need to implement an ioctl to rescan the trx header and recalculate the partitions
[00:05] <nbd> well, if we tell the mtd map to cover the whole firmware area from the beginning
[00:05] <nbd> then we don't need a rescan
[00:05] <nbd> simply have it use the right layout from the start, whether it's already in the trx or not
[00:06] <[mbm]> that's the problem .. jffs2 has no superblock so it's hard for the kernel to detect it when setting up the mtd partitions
[00:06] <nbd> squashfs has one
[00:07] <[mbm]> that only works on the assumption that if it isn't squashfs it must be jffs2
[00:07] <[mbm]> but I suppose that will work for now
[00:07] <nbd> well, we can start implementing this for other platforms first
[00:07] <nbd> and when it works there, we can deal with broadcom
[00:08] <[mbm]> ok
[00:08] <nbd> i came up with this idea right now, because i'm currently trying to build routerboard images that work with any cf card size and use jffs2
[00:09] <[mbm]> at some point we need to address the issue of dealing with jffs2 durring upgrades
[00:09] <[mbm]> particularly how to preserve /etc/config so the settings don't get wiped out every reflash
[00:09] <nbd> yes
[00:10] <[mbm]> the idea I mentioned before was always upgrading via an mtd script that copied important data to a ramdisk, reflashed and then copied back to the new jffs2 partition
[00:11] <[mbm]> meaning that if you ever reflashed any other wy your settings would be lost
[00:11] <[mbm]> (which actually might be a feature considering we don't know what state the last firmware left things in)
[00:11] <nbd> yeah
[00:11] <nbd> for the ramdisk stuff we definitely need the rescan ioctl
[00:12] <[mbm]> yep
[00:12] <nbd> the annoying thing about the routerboard is that it requires a dos partition table with a 4 MB kernel partition
[00:12] <[mbm]> eww
[00:12] <nbd> but i'll just generate a partition table with only one partition and figure out the rest dynamically
[00:13] <[mbm]> but then you're using a compact flash card so 4M really isn't that much
[00:13] <nbd> yeah
[00:13] <nbd> the partition table is the annoying part :)
[00:13] <[mbm]> you're still using jffs2 on a compact flash?
[00:13] <nbd> at the moment i'm using ramdisk only
[00:13] <[mbm]> (didn't think those got assigned an mtdblock)
[00:13] <[mbm]> ah
[00:13] <nbd> they don't
[00:13] <nbd> i intend to use a modified block2mtd
[00:14] <[mbm]> well, here's a tip mtdloop
[00:14] <nbd> mtdloop?
[00:14] <[mbm]> think that's the name of it
[00:14] <[mbm]> lets you mount any file/device loopback as an mtdblock
[00:14] <[mbm]> adter it's an mtdblock you can run jffs2 on it
[00:14] <nbd> block2mtd does that
[00:14] <nbd> well, with block devices
[00:15] <[mbm]> which means that you can even mount jffs2 firmware images on your pc
[00:15] <nbd> and it's in the kernel already
[00:15] <[mbm]> (it was discussed on the forum)
[00:16] <[mbm]> http://forum.openwrt.org/viewtopic.php?pid=26462#p26462
[00:16] <nbd> ah, that uses blkmtd
[00:16] <nbd> block2mtd is the rewrite of blkmtd
[00:16] <nbd> blkmtd is deprecated in current 2.6
[00:44] <CIA-18> mbm * r3946 / (3 files in 3 dirs): fix display of uninitialized ports
[00:45] <[mbm]> nbd: that should fix the switch issue
[01:00] <RoDent> I am now seriously laughing my arse off
[01:00] <RoDent> So, I have this sveasoft account see.
[01:00] <RoDent> And I downloaded the fabled Talisman that supports "WVLANs" or multiple ssids, as normal people know it.
[01:01] <RoDent> So I add a "WVLAN" using the webif, and reboot.
[01:01] <RoDent> Only to be greeted with an oops at bootup :)
[01:01] <RoDent> Oops in fault.c::do_page_fault, line 206:
[01:01] <RoDent> etc... :)
[01:02] <RoDent> Process wlconf (pid: 156, stackpage=80e6c000)
[01:02] <RoDent> Haha
[01:02] <[mbm]> ...
[01:03] <RoDent> What was interesting, is that with only one "wvlan" enabled.
[01:03] <RoDent> His wireless interfaces started at "wl0.1"
[01:03] <RoDent> No wl0
[01:03] <RoDent> I shall give that tactic a try.
[01:04] Action: [mbm] wonders why this is even being discussed here
[01:05] <RoDent> I saw the earlier banter about it. Just thought I'd investigate the claims.
[01:05] Action: RoDent stops mentioning it.
[01:05] <nbd> was the wireless interface called 'wl0'?
[01:05] <RoDent> No. it was wl0.1
[01:05] <nbd> i mean the main interface
[01:05] <nbd> ok, so he didn't copy my interface rename hack...
[01:05] <nbd> :)
[01:06] <RoDent> :)
[01:06] <RoDent> Was that the default driver behaviour ?
[01:06] <nbd> default is ethX as main interface and wl0.X for virtual interfaces
[01:06] <nbd> i changed it to use wl0 as main interface name
[01:07] <RoDent> Yeah, I saw that bit of sed hacking in the Makefile :)
[01:07] <RoDent> I thought not having a wl0/eth0 was the default behaviour - that's why I asked.
[12:29] <florian__> did mickael or any bcm43xx developper answered you
[12:30] <florian__> because you did a great work, but it looks like they are really not interested in getting AP mode working, either because they want to stabilize the client mode, or because they do not care
[13:07] <NDL> florian__: As I wrote already at openwrt forum, I had a talk with Michael about integrating that patch to the main source tree.
[13:07] <NDL> However, of course, I do not have influence to demand that from anybody ;-)
[13:08] <NDL> florian__: So far, there was smb interested on bcm43xx-dev in bringing it up at the BE machine.
[13:09] <NDL> florian__: I'm not sure if it was developer of bcm43x, or some user that wanted it for personal use.
[13:11] <NDL> florian__: anyway, you're right that it seems nobody from developers is really interested in having full AP mode implementation.
[13:12] <NDL> florian__: I've tried to get more info from specs group about PS implementation in AP mode, and while they were quite responsive, they do not have too much info on that and it seems they're not really interested in investigating that topic further.
[15:02] <nbd> NDL: what's the problem with your patch? i'd like to help
[15:19] <NDL> nbd: well, that's not the problem with the patch exactly, but with the fact that it's not yet merged in the main development tree of bcm43xx
[15:19] <nbd> has it been updated to their latest version?
[15:19] <NDL> nbd: yes.
[15:20] <NDL> nbd: I sill hope it will be merged, though.
[15:20] <NDL> nbd: (there's not that much time passed from the moment I posted the updated version, so it's just possible noone from developers had time to merge it)
[15:44] <CIA-18> nbd * r3947 /branches/buildroot-ng/openwrt/toolchain/gcc/Config.in: fix gcc version selection
[18:40] <CIA-18> nbd * r3948 /branches/buildroot-ng/openwrt/toolchain/ (Config.in gcc/Config.in gcc/Config.version): fix menuconfig developer options structure
[18:41] <CIA-18> nbd * r3949 /branches/buildroot-ng/openwrt/package/dropbear/Makefile: fix dropbear depends and defaults
[18:42] <CIA-18> nbd * r3950 /branches/buildroot-ng/openwrt/package/hostapd/Makefile: fix hostapd-mini dependencies
[19:21] <CIA-18> nbd * r3951 /branches/buildroot-ng/openwrt/package/base-files/ (22 files in 16 dirs): clean up handling of the root filesystem mount - remove broadcom specific junk from the generic base-files part
[19:22] <CIA-18> nbd * r3952 /branches/buildroot-ng/openwrt/target/linux/ (generic-2.6/files/init.d/ kernel.mk): remove old junk
[20:26] <CIA-18> nbd * r3953 /branches/buildroot-ng/openwrt/package/hostapd/Makefile: remove global hostapd builddep on openssl
[20:32] <CIA-18> nbd * r3954 /branches/buildroot-ng/openwrt/package/openssl/Makefile: add openssl depend on zlib
[20:35] <[mbm]> wow, webif manages to use every css color notation syntax :P
[20:36] Action: [mbm] starts cleaning up the css
[20:38] <Kaloz> nbd: for some reason it still wants to build openssl
[20:39] <nbd> ah, the dependency system isn't smart enough to handle that situation yet
[21:17] <CIA-18> mbm * r3955 /branches/whiterussian/openwrt/package/webif/files/www/webif.css: a much cleaner version of the css theme
[22:05] <nbd> xrg_: ping
[22:05] <xrg_> yeah?
[22:06] <nbd> did you know that the upper 512 bytes of ram on the routerboard are not usable?
[22:07] <xrg_> Do you mean RAM as that on the ram chip?
[22:07] <xrg_> sth like a vector?
[22:07] <nbd> i mean when you try to use it as ram in linux
[22:07] <nbd> you get a data bus error if you hit that area
[22:07] <nbd> i found a note of yours in the code, something like TODO: fix memory map
[22:08] <nbd> before i found that, i literally spent hours tracking down a crash in block2mtd
[22:08] <xrg_> yes..
[22:08] <nbd> because it would always crash when erasing the cf
[22:08] <nbd> and now i found out it's due to that ram limitation
[22:08] <xrg_> Actually, with block, there could be the chance of rewritting the CF driver to be a mtd instead of a block.
[22:09] <xrg_> There was sth with the -512 mem calculation..
[22:09] <xrg_> Let me read the files and remember..
[22:09] <nbd> well, now you know that this is important :)
[22:09] <nbd> i will try to fix it
[22:09] <nbd> but i don't know the proper place for a fix yet
[22:10] <xrg_> #define RAM_SIZE (32*1024*1024 - 512)
[22:10] <xrg_> 0x80000400 /* Leave room for interrupt vectors */
[22:10] <xrg_> ...
[22:10] <xrg_> Let us see..
[22:11] <xrg_> it is prom.c:161
[22:11] <xrg_> define: DEBUG_DDR=1 first..
[22:12] <nbd> i think i'll just duplicate some code from parse_cmdline_early
[22:12] <nbd> then i can just subtract 512 bytes from the mem= parameter
[22:12] <nbd> as a hack i already did this in the generic code and it worked
[22:13] <xrg_> You could use the 'IGNORE_CMDLINE_MEM' arg..
[22:13] <nbd> yes
[22:13] <nbd> that's the plan
[22:13] <xrg_> and then, the mem size will be read directy from the registers.
[22:13] <xrg_> on which, you can just do the arithmetics.
[22:14] <nbd> you mean, i can just manipulate the boot_mem_map thing?
[22:15] <xrg_> which one? where is the boot_mem_map ?
[22:15] <nbd> arch/mips/kernel/setup.c
[22:15] <nbd> it's the place where the global memory map is stored
[22:16] <nbd> or just add a new memory region to the upper 512 bytes?
[22:16] <nbd> yeah, i think that'll work
[22:17] <nbd> i could add it as BOOT_MEM_ROM_DATA
[22:17] <nbd> or BOOT_MEM_RESERVED
[22:17] <xrg_> Try only to alter code in the rb500 files, not the generic ones.
[22:17] <xrg_> What you say seems reasonable.
[22:17] <nbd> i was planning on doing that
[22:18] <nbd> i don't want to mess with the generic code
[22:18] <xrg_> we are then talking about the add_memory_region(....) on prom.c:161, right?
[22:19] <xrg_> brb
[22:24] <nbd> yes
[22:24] <nbd> i'm almost done creating flashable cf card images
[22:27] <xrg_> back..
[22:30] <[mbm]> .
[22:30] <nbd> yay... it works :)
[23:18] <nbd> haha... i just finished a first version of the image building code for the rb532
[23:19] <nbd> it's a bit crazy, though: http://pastebin.com/711623
[23:44] <CIA-18> nbd * r3956 /branches/buildroot-ng/openwrt/target/ (18 files in 5 dirs): add rb532 support
[23:44] <nbd> :)
[23:47] <xrg_> :D
[23:58] <CIA-18> mbm * r3957 /branches/whiterussian/openwrt/package/webif/files/ (usr/lib/webif/webif.sh www/webif.css): fix some webif rendering bugs
[00:00] --- Fri Jun 16 2006