[haiku-commits] Re: haiku: hrev51475 - src/system/boot/platform/u-boot
- From: kallisti5 <kallisti5@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 19 Oct 2017 10:12:43 -0500
On 2017-10-18 11:46, kallisti5@xxxxxxxxxxx wrote:
hrev51475 adds 1 changeset to branch 'master'
old head: 2618d62084a3d556dfdcba38bcd92917fe41401b
new head: 403baf656db95190c9b67c367840a608db979a95
overview:
http://cgit.haiku-os.org/haiku/log/?qt=range&q=403baf656db9+%5E2618d62084a3
----------------------------------------------------------------------------
403baf656db9: u-boot: mmc single case volume label
* Makes parsing slightly easier in tools like rune-image.
* Mixed case introduces some extra encoding the WIP Rust
FAT driver doesn't support (yet)
[ Alexander von Gluck IV
<kallisti5@xxxxxxxxxxx> ]
A little explanation of this since it has been a while.
The image preparation tool is going well. I've been externally working
on native
Rust modules to parse MBR partitions and improving some modules to
natively
work with FAT filesystems.
Things are creeping towards a useful state.
https://github.com/kallisti5/rune-image
Here are some examples:
Tool help:
$ ./target/debug/rune -h
rune - bless and write Haiku mmc images
Usage: ./target/debug/rune [options] <output>
Options:
-b, --board <board> target board
-i, --image <image> source OS image
-l, --list list supported target boards
-v, --verbose increase verbosity
-h, --help print this help
Listing the supported boards:
$ ./target/debug/rune -l
arm
===
Board SOC Name
rpi2 BCM2836 Raspberry Pi 2
rpi3 BCM2837 Raspberry Pi 3
1) The tool pulls a manifest with board firmware information here:
https://github.com/haiku/firmware/blob/master/manifest.json
$ ./target/debug/rune -v -b rpi2
~/Code/haiku/generated.arm/haiku-arm.mmc
Creating bootable Raspberry Pi 2 (BCM2836) media.
No source image. Attempting to make target media bootable..
Scan partition table in OS image...
Found: Partition { p_status: 128, p_cyl_begin: 2, p_head_begin: 140,
p_sect_begin: 1, p_type: 12, p_cyl_end: 9, p_head_end: 254, p_sect_end:
63, p_lba: 40950, p_size: 119700 }
+ GET
https://github.com/haiku/firmware/raw/master/arm/rpi2/README.md
Error: failed to fill whole buffer
It's still a little messy, so let me explain what is going on...
1) We provide the target device.
It grabs the manifest over https to know what needs to "happen" for
the target board.
2) We provide the generic Haiku ARM SD card image to the tool
3) The tool writes the source image to the output file/block device
(if a source image is provided)
Otherwise, the target file/block device is just made bootable.
3) The tool reads the partition table of the image, and looks at each
partition for a FAT filesystem with a label containing "haiku"
4) Once the boot partition is found, it then uses the ARM board
information to begin downloading the specified bootloader files needed.
(WIP below this line)
5) The required bootloader (u-boot) binaries are downloaded, then
placed onto the boot FAT partition.
6) Any additional steps needed to make the sdcard image bootable are
performed.
I'm still facing some occasional pressure on why I picked Rust, to
reiterate:
1) We get low-level C features with high level libraries like HTTP
parsing
2) Minimal dependencies.
3) Cheap cross platform. This tool will compile (and does on every
commit) right now for MacOS X, Linux.
4) Haiku support should be 95% there (we just need some polishing to
our Rust port)
5) Windows support should be 95%... I think we need extra logic around
"drives" vs block devices for writing.
-- Alex
Other related posts:
