龙芯开源社区

 找回密码
 注册新用户(newuser)
楼主: 三轮车夫

请问pmon支持UFS么?

[复制链接]
发表于 2007-1-8 13:55:57 | 显示全部楼层
原帖由 lyh 于 2007-1-8 01:30 PM 发表
可不可以让PMON加载一个第三方引导管理器如GRUB,然后再由它引导系统?

应可以,但不知道有没有支持龙芯这方面的GRUB?
发表于 2007-1-8 13:58:04 | 显示全部楼层
原帖由 caimouse 于 2007-1-8 01:55 PM 发表

应可以,但不知道有没有支持龙芯这方面的GRUB?


其实grub多数功能都可以实现了,只要实现一个类似的界面就行了,不必重头整一个。
发表于 2007-1-8 14:03:12 | 显示全部楼层
原帖由 foxsen 于 2007-1-8 01:58 PM 发表


其实grub多数功能都可以实现了,只要实现一个类似的界面就行了,不必重头整一个。

我看了一下编译出来的程序,好像已经有600多K了,而FLASH 只有512K,搞不了太多功能了吧?
难道增加FLASH的到1M,或者2M大小?
发表于 2007-1-8 14:35:41 | 显示全部楼层
原帖由 DragonLake 于 2007-1-8 02:29 PM 发表
caimouse同学要修改pmon,我也在看,但是不一定去修改,然而必定会有我自己的一些想法。不知道pmon是否会成为一个专门的项目进行开发,而且是能够有多一些人来参与。或者说把pmon上升到另外一个层次,能够和u-boo ...


我还在看,先看懂了再准备做什么东西。好的,我们可以一起思考怎么样开发它,可以多交流。在我的BLOG发表了一些文章。
发表于 2007-1-8 19:38:39 | 显示全部楼层
原帖由 DragonLake 于 2007-1-8 02:29 PM 发表
caimouse同学要修改pmon,我也在看,但是不一定去修改,然而必定会有我自己的一些想法。不知道pmon是否会成为一个专门的项目进行开发,而且是能够有多一些人来参与。或者说把pmon上升到另外一个层次,能够和u-boo ...


pmon肯定会成为一个专门的项目,目前pmon代码功能还是很不错的,但是还有很多需求,而且2f,显卡更换,或者用于嵌入式开发环境(需要更小更简单的pmon)等等还会产生很多需求,因此pmon肯定是长期维护的一个项目。

我想可以论坛上先开一个新版,对pmon感兴趣的可以有一个专门的地方讨论,另外我正在准备一个git/git-svn的使用指南,大家可以方便使用git作为svn的front-end,大家不再受网络速度影响而感觉代码很难交换,我自己用git确实用得很爽,呵呵

欢迎大家参与pmon的开发,我说的三个月的期限一点都没有忘。不过我自己的能力确实有限,需要大家一起来努力呀:)
发表于 2007-1-8 19:39:22 | 显示全部楼层
原帖由 caimouse 于 2007-1-8 02:03 PM 发表

我看了一下编译出来的程序,好像已经有600多K了,而FLASH 只有512K,搞不了太多功能了吧?
难道增加FLASH的到1M,或者2M大小?




里面有个zloader目录,make tgt-rom以后会产生一个压缩的bin文件
发表于 2007-1-8 20:17:59 | 显示全部楼层
我原先设想过三级引导的方案,后来也跟caimouse在qq群里边聊过,今天蔡总说了一下flash的价格,感觉还是成本不低啊。技术可行但是经济可操作性不高,所以方案取消。

我们的空间分配里面我记得最大能放1M的flash(0xbfd00000后面是IO空间),但是还有一块地址区域可以放,大概在bfc00000前面一点。

我给你报告一下我们现在代码的大小,
现在我的分支,编译出来压缩以后是270k左右,我们现在把最后一个block用来放环境变量,最后一个block的大小取决于我们flash驱动如何界定一个block,但是我们的winbond flash其实可以支持4k的擦写大小,因此最佳的情况下,我们可以用最后的4k来放环境变量(现在是64k)。
另外我们作了一个大大的bmp图,110k左右(当然这个图可选)。所以按照64k分配的block来看,我们刚刚好用完了。但是我觉得选择另外的图,以及更改flash驱动以后,可以得到128k的空闲空间。

三级引导的意思就是一级固化,不允许刷,能够做基本的引导,包括检测二级flash是否可用以及三级的移动介质是否可读。如果二级可用,那么就适用二级来作为扩展的引导程序,可以读取更大范围的三级移动介质和增加更多的扩展功能;如果二级不可用,那么就直接读取三级的基本类型可移动介质。

二级flash是可刷些的,这样我们可以随时更新里边的代码,扩展功能。但是万一刷写失败了,我们还有一级固化的可用,可以通过引导三级可移动介质重新刷回原始的二级引导程序,恢复原有功能。一级BIOS毕竟空间有所限制,所以不可能无限扩大,但是对于二级而言,可扩展空间还是不小的,对于开发的意义还是蛮大的。不过今天蔡总说如果一级能够引导U盘,那么其实二级引导程序可以放在U盘里边。这个方案其实也不错。

三级可移动介质可以是再次扩展的引导程序,可以是操作系统之类的东东了。这个跟BIOS基本上就没有多大关系了。


其实pmon现在的引导能力很强,可以访问几乎所有的介质了(光驱,u盘,网络,硬盘)。我认为基本上足够了,而且剩余的空间足以把他做的足够的完善,我想象中的有一个简单的explorer,我们以后最人性化的就是浏览内核进行启动,我觉得有足够的协议的话,我们做的更“智能”些,可以发现内核就更好了!这样的产品摆在世界同行面前也是一流的。另外的完善如本帖需要支持更多的文件系统等等。

关于安全写pmon方面,还是原来讨论的双pmon,其实这个是张老师最早要求的,上次我的论述基本上可以说是转述张老师的想法:)(原来我的想法是作flash内容校验,很土,不过现在想来,张老师的做法加上flash校验其实也不错)

怎么安全的写呢,就是flash分区存放两个pmon,一个固定不变,另外一个则可以更新,我们做一个界面explore到要升级的文件,把他烧写在第二个pmon的地址上,这样子第一个pmon就安全了,用界面的简易性防止敲命令敲错地址,这样子的安全性我觉得已经够了,你觉得呢?

至于下一级的引导程序,这对于pmon来说完全不是问题,下一级程序是什么pmon是完全不用理会的:),所以完全有可能是一个“grub”

[ 本帖最后由 kingkongmao 于 2007-1-9 09:20 AM 编辑 ]
发表于 2007-1-8 22:40:56 | 显示全部楼层
原帖由 DragonLake 于 2007-1-8 09:09 PM 发表
自动发现内核需要有内核基本的特征,有grub那种自动补全就很了不起了。哈哈……

其实我想加上二级pmon或者其他引导管理器,主要是希望有图形化。我没有亲眼见过SGI O2的东西,但是看过图片,觉得它的图形引导管 ...



关于图形的问题我有一招,就是类似于内核模块的思想,既然我们都可以读取硬盘的内核了,为什么不可以读取一个硬盘的模块:)

模块自动硬盘找图形界面需要的资源阿之类,这样子界面想多pp就有多pp了:)
发表于 2007-1-9 09:18:51 | 显示全部楼层
原帖由 DragonLake 于 2007-1-9 12:22 AM 发表
这个倒也是,让pmon可以读取配置文件来渲染。如果没有,那就适用默认的。grub也有splash.xpm.gz的做法嘛。呵呵……




4r4r,其实我就是参照grub的做法

另外:
1.Tab功能其实也是可以做的,我们现在就可以浏览文件,只是比较麻烦,每次都要打完整的路径
2.我说的发现内核很玄,但是其实我们现在x86的机器光驱放一个能启动的光盘,也能自动启动,而我们则需要敲命令找到内核或者可执行文件才可以,所以找找他们用的协议应该也可以做
发表于 2007-1-9 09:44:30 | 显示全部楼层
原帖由 kingkongmao 于 2007-1-9 09:18 AM 发表



4r4r,其实我就是参照grub的做法

另外:
1.Tab功能其实也是可以做的,我们现在就可以浏览文件,只是比较麻烦,每次都要打完整的路径
2.我说的发现内核很玄,但是其实我们现在x86的机器光驱放一个能启 ...

只要启动文件上面写成特定的文件名称,比如WINDOWS是叫 boot.ini文件,它会启动时就去硬盘第一个分区查找这个文件的。然后二级引导文件加入一个特定识别码,比如4个字节:0x11223344。然后再加入一个CRC32的检验码,就OK了。

本版积分规则

小黑屋|手机版|Archiver|Lemote Inc.  

GMT+8, 2019-9-20 17:43 , Processed in 0.192192 second(s), 16 queries .

快速回复 返回顶部 返回列表