 TermiNexus
|
2a54e2bafb
|
清理了 t.CVoid
|
2026-09-16 16:07:04 +08:00 |
|
|
TermiNexus
|
a518f75b24
|
chore(vkernel): 重置基线 — 纳入 TPV codegen 修复配合的内核侧调整与既有工作区内容
- devfs.vp: string.split 传 PATH_BUFFER_SIZE（配合 split 新增容量参数）
- fat32_types.vp: lfn_extract 越界钳制（base+i > MAX_LFN 返回 -1）
- sheet.vp: gfx.Renderer 实参修正为 (fb, zb, w, h)（原单参导致 w/h=0 渲染空操作）
- 同批包含 VKernel 其余既有移植改动与 vpsdk/Apps/Libs 工作区内容
|
2026-09-11 14:27:01 +08:00 |
|
|
TermiNexus
|
cd1cc915c5
|
修正了build.py，重置基线
|
2026-09-11 10:34:34 +08:00 |
|
|
TermiNexus
|
4296d2a19e
|
fix(asm-inline): cmos_read 裸 in/out al 补 CLOBBER_RAX + 显式 mov；rdmsr out 绑定与 clobber 冲突（lo/hi 读不到 EAX/EDX）改显式 mov——同类 EAX 破坏根因，残留间歇性数据损坏源
|
2026-08-27 01:33:19 +08:00 |
|
|
TermiNexus
|
d4200f1129
|
debug(mm): 无条件打印 memmap 三参数 + fallback CMOS 原始值
serial.log 显示 memmap 分支（d[..] 转储 / mm: best=）从未打印 → 分支未执行，
size≈4GB 来自 fallback 的 detect_memory_size()（CMOS 读到垃圾）。加两处诊断：
1) init 开头无条件打印 MemmapAddr/MemmapSize/MemmapDescSize；
2) fallback 打印 CMOS 0x15-0x18 与 detect_memory_size 结果。
|
2026-08-26 19:11:22 +08:00 |
|
|
TermiNexus
|
1043343b9d
|
fix(mm): get_block_size 移位改 64 位，修复伙伴初始化无限循环
4096<<20 在 i32 下溢出为 0x0 → bs=0x0 → cur_addr/remaining 不变 → 无限循环
（[mm] it=1..6 order=20 bs=0x0 addr 不变）。改 t.CUInt64T 移位。另增关键数值
打印（memmap addr/size/desc/entries），配合描述符转储定位 4GB 伪可用区。
|
2026-08-26 19:04:55 +08:00 |
|
|
TermiNexus
|
f9ec205816
|
debug(mm): 转储 memmap 描述符 + buddy 初始化循环进度
mm.init 报 start=0x400000 size=4292411392（≈4GB）后挂起——256MB 内存不该有
4GB 可用区，怀疑 memmap 描述符读到垃圾。新增：1) init 内转储全部描述符
（type/start/pages）；2) buddy __init__ 循环打印前 6 次迭代与 loop done 标记，
定位挂起点。
|
2026-08-26 19:02:40 +08:00 |
|
|
TermiNexus
|
8b40203b63
|
提交新的建议忽略
|
2026-08-06 18:08:50 +08:00 |
|
|
TermiNexus
|
20e7289c61
|
将 .py 和 .pyi 后缀名改为了 .vp 和 .vpi 后缀名
|
2026-07-30 16:34:26 +08:00 |
|
|
Viper
|
6813947181
|
Initial import of ViperOS
|
2026-07-19 12:38:20 +08:00 |
|